Boulder Dash Forum

Posted: **Wed Sep 03, 2008 10:43 pm**

Could you make the negative "Diamonds needed" count the Diamonds at hatching instead of at the very beginning. The thing is, in random caves, there might be explosions destroying some of the diamonds. And at hatching, such explosions are usually done.

Posted: **Thu Sep 04, 2008 3:57 am**

cirix wrote:check the timing settings of the cave. Hatching delay might be seconds for c64-schedulings, and frames for milliseconds-based. No consensus for that in the BDCFF, unfortunately. I will also check the game.

Here, I opened the exact same BDCFF file in GDash 20080621 (Which I'm currently sticking with, as it seems the most stable) and the newer 20080901. Here are the results:

20080621

20080903

Consequently, the inbox takes a "tad" longer to hatch in 20080901 than in past versions, without any form of modification or corruption in the BDCFF between versions.

(Don't worry about the 0's in "diamonds needed" - I had yet to set that parameter for this cave.)

Posted: **Thu Sep 04, 2008 8:13 am**

LogicDeLuxe wrote:Would it be possible to set the graphic scaling independently for the game and the editor? For instance, I'd like to play in "double" while I prefer the editor window at "normal".

This would be certainly the best - different settings for the two different windows.

Speaking of this I also miss the "Open shipped" menu option in the editor window. It should be placed right under the "Open" menu option.

A graphic scaling option for sdash would also be nice as Apple computers can only go as low as 640 x 480 so it is not shown full screen at the moment. It must be at least double size to play at full screen on Macs. Moreover if you like to have a higher screen resolution you can set to e.g. triple size and - depending on the resolution set - it's full screen or at least almost full screen.

Also some ideas for sdash:
*) including graphics theme option
*) starting the game with RETURN instead of SPACE would be more intuitiv
*) What about the music theme at the title picture?
*) What about any kind of animation in the title picture like in Boulder Dash 1 (the scrolling titan wall in the background)?

CWS wrote:The Scheduling type only lists BD1, CD7 and Construction Kit. But what about CLCK? Does it have the same timing as Construction Kit? Really? And BD2? Does it have the same timing as BD1? How does it detect which timing is the correct?

LogicDeLuxe wrote:Didn't you do the research on this?

Yes I did! That's the reason why I'm wondering why there is only "BD1", "CD7" and "Construction Kit" in it. If "BD1" is almost as fast as BD2 and because of this both are used as one scheduling model I think it should be called "BD1+2" otherwise I think it's too confusing.

And what about "1stB"? There is a significant number of fan made games made using the 1stB engine. Is it necessary to include the "1stB" scheduling model?

I also noticed that most fan games are marked as "Construction Kit" - I think most of them are really made with it. The "Don Pedro" games are marked as "BD1" as they are not made with any CK as there where no CK back then. GDash has a really good engine detection!

If "Construction Kit" and CLCK 3.0 have other timings there should be the additional scheduling model "CLCK" included. If it's only slightly different it could be left as it is. I do not know exactely how much faster or slower CLCK is compared to the original PLCK. But I think it should be slower. Slightly or significant enough to justify a separate scheduling model?

Nevertheless it's wonderful that you did a list which game uses which engine some year back (http://www.gratissaugen.de/erbsen/liste.html). It's the best method checking the engine detection of GDash...

Posted: **Thu Sep 04, 2008 8:50 am**

CWS wrote:And what about "1stB"? There is a significant number of fan made games made using the 1stB engine. Is it necessary to include the "1stB" scheduling model?

Considering, there is even a "Crazy Dream 7" setting for which only one game exist, there really are a lot more 1stB games.

GDash has a really good engine detection!

No surprise, since it really has to detect the engine in order to convert the caves in the first place.

Posted: **Thu Sep 04, 2008 9:49 am**

LogicDeLuxe wrote:
CWS wrote:And what about "1stB"? There is a significant number of fan made games made using the 1stB engine. Is it necessary to include the "1stB" scheduling model?
Considering, there is even a "Crazy Dream 7" setting for which only one game exist, there really are a lot more 1stB games.

I also think so! The only good question left is if the PLCK is as fast (or almost as fast) as CLCK or if there is such a significant difference in speed that it would justify a separate scheduling model!?

LogicDeLuxe wrote:
GDash has a really good engine detection!
No surprise, since it really has to detect the engine in order to convert the caves in the first place.

And that is good as it is!

Posted: **Thu Sep 04, 2008 11:32 am**

CWS wrote:The only good question left is if the PLCK is as fast (or almost as fast) as CLCK or if there is such a significant difference in speed that it would justify a separate scheduling model!?

As I wrote, PLCK, 1stB, CrDr and CrLi appear to have all the same TV field based timing. As long as the cave author doesn't set the speed higher than the processing takes, they would be the same speed.

In my Cross Development C64 engine, I intend to sync the timers to the actual speed. That means, if the cave temporarily encounters slowdowns due to heavy loading elements, the timer would slow down with it. That way, the relations remain absolutely predictable.
Btw., The New Dash Dimension has implemented it that way from the beginning in order to ensure the relation doesn't get out of sync on slow computers.
Also the C64 would benefit from such a timing model, since there is a difference between PAL and NTSC, and on machines with a turbo card or a DTV in burst mode, we would gain a more steady speed as well. It won't become unexpectedly fast either, since the author designs the caves most likely in GDash which is fast enough to archive frametimes of only 50 ms with ease.
At least, we won't need another scheduling type when XDC becomes reality as you would just select "milliseconds based" for that. (Will be all mentioned in the guidelines which come with the engine).

Posted: **Thu Sep 04, 2008 8:28 pm**

Hi

RTADash: yes, because hatching delay might be interpreted as seconds (for bd1 scheduling) or frames (for milliseconds). 2 seconds and 21 frames are the default values, therefore you can see the 2 and the 21 in the different versions of the editor. I think you should use the latest version, and correct this mistake by hand. maybe i should have increased the bdcff version number... see what i can do.

LogicDeLuxe: what do you think we could do with this? implement HatchingDelaySeconds= and HatchingDelayFrames=? as there are CaveDelay= and FrameTime=? i think this could be the best.

CWS: not gdash does the detection of the engine, but any2gdash

the engine to be used is already coded in the .gds files. and yes, to import the caves, engine detection has to be done. i also used the explanations found in LogicDeLuxe's boulder-dash-inside-faq to find those things out.

i think 1stb and clck are not so different, when it comes to schedulings. maybe if you find some caves, where the faster 1stb is important, i will check it! maybe the timings can be compared by building the same caves in plck and clck, as clck is based on 1stb. also, clck and 1stb have even less difference in timing, so there is no point in creating different settings for that. and crazy dream 7 is so much slower (water, wall reappear...), that i had to create its own scheduling. it is a so much extended version of the original game, almost too much for a c64

LogicDeLuxe: slowing down timers is a good idea. gdash internally does that: keeps track of elapsed _cave_ time (emulated) as milliseconds, so that the speed of the computer does not matter. when the emulated time is >1000ms, cave time is decreased by one "second".

i recorded your requests about graphics and other things in my todo file

if you find some annoying bug, i try to correct them. features come later.

bye

Posted: **Thu Sep 04, 2008 9:30 pm**

There seems to be a serious problem with magic walls. Whenever a diamond or boulder is about to be converted, the game crashes immediately. If the time is up or the magic wall is blocked so that no conversion takes place, the game runs fine.

cirix wrote:LogicDeLuxe: what do you think we could do with this? implement HatchingDelaySeconds= and HatchingDelayFrames=? as there are CaveDelay= and FrameTime=? i think this could be the best.

This is what the current specs state:

HatchingDelay

The guy's hatching delay. This is the number of scanning frames inbox will be flashing before the guy's hatching. (number, default=21)

So yes, something like that. Except we should stay with the keyword HatchingDelay as a frame based delay, like it was suggested since the beginning of BDCFF. In addition to this, we could offer an alternative with HatchingDelaySeconds to allow seconds based delays. A HatchingDelayFrames-keyword is not needed, as this only would break downward compatibility.

LogicDeLuxe: slowing down timers is a good idea. gdash internally does that: keeps track of elapsed _cave_ time (emulated) as milliseconds, so that the speed of the computer does not matter. when the emulated time is >1000ms, cave time is decreased by one "second".

Just like I did in "The new Dash Dimension", it's the best one can do to ensure compatibility to different computers.

Posted: **Thu Sep 04, 2008 9:36 pm**

LogicDeLuxe wrote:There seems to be a serious problem with magic walls.

Sorry, I missed the last update somehow. I see you fixed it.

Posted: **Fri Sep 05, 2008 6:57 pm**

cirix wrote:correct this mistake by hand.

Here's what I have in the BDCFF (the lack of line breaks really helps):

Code: Select all

[cave][highscore]1 Compaq_Owner 337[/highscore]Name=Cave A. IntroSelectable=trueIntermissionProperties.rewardlife=trueSize=40 22 0 0 39 21Colors=Black Black Orange Gray1 White White WhiteDiamondsRequired=15 20 20 20 20DiamondValue=10 15CaveTime=125 100 75 55 40BD1Scheduling=trueRandSeed=33 5 8 16 0RandomFill=BOULDER 70 DIAMOND 10 DIRT 0 DIRT 0MagicWallTime=0AmoebaTime=0SlimePermeabilityC64=0CaveDelay=12 6 3 1 0[objects]Line=1 6 32 6 WALLLine=32 7 32 16 WALLLine=25 10 25 20 WALLLine=6 13 24 13 WALLPoint=1 2 INBOXPoint=24 16 OUTBOX[/objects][/cave]

Which one of these is the hatching delay?

Posted: **Fri Sep 05, 2008 8:22 pm**

RTADash wrote:Which one of these is the hatching delay?

If there is no HatchingDelay-keyword, the default should be used, which is 21 frames.
We currently consider using a seconds based hatching delay, which would be used when a C64 type timing is used and defaults to 2 seconds.

Though, I think, your actual problem is in the timing type setting.
Your "BD1Scheduling=true" should be probably changed to "CaveScheduling=bd1".
Keep in mind that Gdash is still beta, and keywords can change, until they prove usable and become part of the BDCFF specifications.
HatchingDelay=2 and CaveScheduling=bd1 is currently written for BD1 games, which is indeed not the way BDCFF meant it to be used, and cirix is aware of that problem, as you can see some posts earlier.

Btw., what editor did you use. Even Windows Wordpad or "type" and "edit" at the command prompt display it fine. I never saw a file with line feeds only and no carriage returns, though. I usually have both (DOS, Windows standard) or carriage return only (Unix, Commodore standard).

Posted: **Fri Sep 05, 2008 9:16 pm**

LogicDeLuxe wrote:Your "BD1Scheduling=true" should be probably changed to "CaveScheduling=bd1".
Keep in mind that Gdash is still beta, and keywords can change, until they prove usable and become part of the BDCFF specifications.
HatchingDelay=2 and CaveScheduling=bd1 is currently written for BD1 games...

Thanks!

That did the trick for playing them in SDash (my primary intention), but GDash still interprets that I have "21" and "Construction Kit" scheduling selected, even when those aforementioned lines are clearly in the BDCFF.

LogicDeLuxe wrote:Btw., what editor did you use. Even Windows Wordpad or "type" and "edit" at the command prompt display it fine. I never saw a file with line feeds only and no carriage returns, though. I usually have both (DOS, Windows standard) or carriage return only (Unix, Commodore standard).

Notepad

However, I've opened BDCFF's created with x2bdcff in notepad, and they had the line breaks present.

Posted: **Sat Sep 06, 2008 12:42 am**

Why are there 2 mazegen functions in caveobject.c?

Posted: **Sat Sep 06, 2008 3:24 pm**

hi

rtadash: "correct by hand", i meant loading the file in gdash editor, and correcting the hatching delay field to 2 or 21 in the cave options window. no notepad needed for anything!!! also, gdash and sdash cannot interpret the same file differently. if this is the case, you must be using different versions of gdash and sdash; as the same source file is linked into both of them.

logicdeluxe: actually, three, but those are not used. the second one is compatible with the disassembled crdr9 maze generator. the third one is the growing tree generator implemented (explained on the daedalus maze homepage). those are written, but not currently used. all three create different mazes (with different characteristics) for same seed settings.

also logicdeluxe: no, cr-only files are no standard in any way (maybe on commodore?). line feed's on unix (ascii 10)! cr-lf (13, 10) is the dos/windows nightmare.

bye

Posted: **Sat Sep 06, 2008 4:18 pm**

cirix wrote:logicdeluxe: actually, three, but those are not used. the second one is compatible with the disassembled crdr9 maze generator. the third one is the growing tree generator implemented (explained on the daedalus maze homepage). those are written, but not currently used. all three create different mazes (with different characteristics) for same seed settings.

I see.
Generating the maze in a temporal array is a good idea, I think. Makes it more versatile. Should be even affordable on the C64.
I suppose the recursive one is a bit faster, but not the best thing to do on small computers like the C64. I think, it would be a good idea to add the bias parameter to the crdr9 algorithm, which should be easy to do since it doesn't have to emulate any existing game (crdr is true random after all). The maze could start at the center and grow from there.
Having a highly portable algorithm definitely is preferable.

also logicdeluxe: no, cr-only files are no standard in any way (maybe on commodore?). line feed's on unix (ascii 10)! cr-lf (13, 10) is the dos/windows nightmare.

On C64 and also Amiga, iIrc, cr also implies a linefeed (just like on a typewriter). If there is also a linefeed along with it, you'll get an extra empty line. If you have a linefeed only, you just go to the next line, but stay in the column (like if you would press cursor down). A pity, there is no real standard. With a good editor like Notepad++, it doesn't matter anyways. A BDCFF parser should be able to recognize each kind of newline properly, though.

Boulder Dash Forum

Gdash

Re: bugs & new version

couple of things

Re: couple of things

Re: couple of things

Re: couple of things

Re: couple of things

Re: couple of things

things

Re: things