Gdash
Moderator: Admin
Another thing I noticed while testing: Scrolling is faster on GDash. Should be just a little bit slower.
Maybe slower is not the right word: Scrolling in GDash begins normal speed, speeds up, and slows down. On C64 the scrolling is always the same speed.
I do not know if this is good or bad but it looks strange if you play C64 Boulder Dash and GDash at the same time (in my case for testing reasons).
Maybe slower is not the right word: Scrolling in GDash begins normal speed, speeds up, and slows down. On C64 the scrolling is always the same speed.
I do not know if this is good or bad but it looks strange if you play C64 Boulder Dash and GDash at the same time (in my case for testing reasons).
- LogicDeLuxe
- Member
- Posts: 655
- Joined: Sun Jul 15, 2007 12:52 pm
- Contact:
On C64 you only have 40x22. With 128x128 you really need accelerating scrolling, or it would take forever. Imagine the scrolling takes longer than the hatching delay, which would be disastrous.CWS wrote:Maybe slower is not the right word: Scrolling in GDash begins normal speed, speeds up, and slows down. On C64 the scrolling is always the same speed.
Btw., The new Dash Dimension was supposed to have accelerating scrolling, but since the source is lost, I never got this feature working.
Maybe you are right. I only wrote this experience because I noticed it while testing GDash and playing the same cave on C64 at the same time.LogicDeLuxe wrote:On C64 you only have 40x22. With 128x128 you really need accelerating scrolling, or it would take forever. Imagine the scrolling takes longer than the hatching delay, which would be disastrous.CWS wrote:Maybe slower is not the right word: Scrolling in GDash begins normal speed, speeds up, and slows down. On C64 the scrolling is always the same speed.
Btw., The new Dash Dimension was supposed to have accelerating scrolling, but since the source is lost, I never got this feature working.
After some hours of intensive testing I encountered some things that could be improved:
*) A really big problem is that if I would like to draw an outlined rectangle or a line which is as big as the whole cave borders of the editor window do not scroll automatically if I reach them. So such things can not be drawn correctly. I can draw outside the window (if I keep pressing the mouse button) but I do not see it. That's bad. They should scroll as soon as reaching them!
*) After playing around with the "Draw rectangle outline" and some other options I noticed that there is no fill tool. A separate fill tool would be nice!
*) Caves with more objects than BD1-engine (in my case "CWS Boulder Dash 2") must be flattened otherwise they not saved. If you do not know this, edit some caves, save it - you will be frustrated as soon as you open it next time and notice that GDash didn't save your work last time. In e.g. "Boulder Dash 1" it works but in "CWS Boulder Dash 2" or "Crazy Dream 6" not. I think that's the 2-character map codes that are not supported yet you mentioned.
*) Option "View/Overview" does also not show changes in such caves until they are flattened ("Save PNG" does also not save it right).
*) By the way: "Save PNG" does not automatically add the ".png" extension to the saved file (same as games are not add ".bd"). It's interesting that the option "Save HTML Gallery" does add all necessary extensions!
*) "Save HTML Gallery": As there is some space under each cave in the html file it would be great if you could show more options under it (maybe two or three rows). E.g. Cave size, Amoeba time and threshold, Delay, Magic Wall milling time, etc.
*) If changing anything in a cave "Save" and "Save as" are ghost menus. Only going back to index allows me to save. I think it should be possible to cave within a cave. Or what do you think?
*)Shouldn't it be possible to select more than one object by pressing the Shift key? Would be nice if you want to select some objects to copy them all together.
*) Can you add a separator above "Edit/Cave properties"?
*) Do not know if I already requested this but in index clicking on the name of a cave should always result in beeing able to rename it right there (without opening cave set properties).
*) I would recommend to show the variables while testing in another order: Speed (in C64 Delay and ms), Amoeba timer, Magic Wall timer, Expanding Wall direction, Creatures (what does this option show?) and the Voodoo doll options are used at the moment.
*) In the "Select cave to play" window it is possible to scroll to the caves by pressing the up and down arrow keys. What do you think in showing the levels by pressing the left and right arrow keys?
*) A really big problem is that if I would like to draw an outlined rectangle or a line which is as big as the whole cave borders of the editor window do not scroll automatically if I reach them. So such things can not be drawn correctly. I can draw outside the window (if I keep pressing the mouse button) but I do not see it. That's bad. They should scroll as soon as reaching them!
*) After playing around with the "Draw rectangle outline" and some other options I noticed that there is no fill tool. A separate fill tool would be nice!
*) Caves with more objects than BD1-engine (in my case "CWS Boulder Dash 2") must be flattened otherwise they not saved. If you do not know this, edit some caves, save it - you will be frustrated as soon as you open it next time and notice that GDash didn't save your work last time. In e.g. "Boulder Dash 1" it works but in "CWS Boulder Dash 2" or "Crazy Dream 6" not. I think that's the 2-character map codes that are not supported yet you mentioned.
*) Option "View/Overview" does also not show changes in such caves until they are flattened ("Save PNG" does also not save it right).
*) By the way: "Save PNG" does not automatically add the ".png" extension to the saved file (same as games are not add ".bd"). It's interesting that the option "Save HTML Gallery" does add all necessary extensions!
*) "Save HTML Gallery": As there is some space under each cave in the html file it would be great if you could show more options under it (maybe two or three rows). E.g. Cave size, Amoeba time and threshold, Delay, Magic Wall milling time, etc.
*) If changing anything in a cave "Save" and "Save as" are ghost menus. Only going back to index allows me to save. I think it should be possible to cave within a cave. Or what do you think?
*)Shouldn't it be possible to select more than one object by pressing the Shift key? Would be nice if you want to select some objects to copy them all together.
*) Can you add a separator above "Edit/Cave properties"?
*) Do not know if I already requested this but in index clicking on the name of a cave should always result in beeing able to rename it right there (without opening cave set properties).
*) I would recommend to show the variables while testing in another order: Speed (in C64 Delay and ms), Amoeba timer, Magic Wall timer, Expanding Wall direction, Creatures (what does this option show?) and the Voodoo doll options are used at the moment.
*) In the "Select cave to play" window it is possible to scroll to the caves by pressing the up and down arrow keys. What do you think in showing the levels by pressing the left and right arrow keys?
- LogicDeLuxe
- Member
- Posts: 655
- Joined: Sun Jul 15, 2007 12:52 pm
- Contact:
You can modify the size of existing rectangles, though. Ie. it is no problem to place it, scroll and resize it.CWS wrote:*) A really big problem is that if I would like to draw an outlined rectangle or a line which is as big as the whole cave borders of the editor window do not scroll automatically if I reach them. So such things can not be drawn correctly. I can draw outside the window (if I keep pressing the mouse button) but I do not see it. That's bad. They should scroll as soon as reaching them!
Good idea. Defining a Flootfill object to BDCFF doing exactly what the floot fill in the CLCK does, would be usefull. That way, we could easily create any polygon (rather than rectangles only) and fill them with few drawing instructions.*) After playing around with the "Draw rectangle outline" and some other options I noticed that there is no fill tool. A separate fill tool would be nice!
That's a possibility. But as we have a modern OS it's quite comfortable to let it do it's tricks! The simpliest and most intuitiv method reaching one's goal is certainly the best one.LogicDeLuxe wrote:You can modify the size of existing rectangles, though. Ie. it is no problem to place it, scroll and resize it.CWS wrote:*) A really big problem is that if I would like to draw an outlined rectangle or a line which is as big as the whole cave borders of the editor window do not scroll automatically if I reach them. So such things can not be drawn correctly. I can draw outside the window (if I keep pressing the mouse button) but I do not see it. That's bad. They should scroll as soon as reaching them!
You a totally right - I've seen and used it in CLCK! It's quite good!LogicDeLuxe wrote:Good idea. Defining a Flootfill object to BDCFF doing exactly what the floot fill in the CLCK does, would be usefull. That way, we could easily create any polygon (rather than rectangles only) and fill them with few drawing instructions.CWS wrote:*) After playing around with the "Draw rectangle outline" and some other options I noticed that there is no fill tool. A separate fill tool would be nice!
floodfill object
hi,
i think i will implement floodfill on map based caves, but defining a floodfill object and enabling using it in the editor (!) is not a good idea. if you check the join object, even that one is very hard to use by some "let's see what happens"-style editing.
imagine a floodfill object. you delete some other object which is under it, and which defined the floodfill's boundaries... the cave is immediately filled. so it is only correctly usable on maps. for object-based caves, the user will see logical, but unexpected results.
bye
i think i will implement floodfill on map based caves, but defining a floodfill object and enabling using it in the editor (!) is not a good idea. if you check the join object, even that one is very hard to use by some "let's see what happens"-style editing.
imagine a floodfill object. you delete some other object which is under it, and which defined the floodfill's boundaries... the cave is immediately filled. so it is only correctly usable on maps. for object-based caves, the user will see logical, but unexpected results.
bye
cirix
- LogicDeLuxe
- Member
- Posts: 655
- Joined: Sun Jul 15, 2007 12:52 pm
- Contact:
Re: floodfill object
When the floodfill object is highlighted, you could draw a mark indicating its origin in order to give some insight in what's going on. Having this as an object also has the advantage that you can undo any fill at any time. It also could be combined with level based random placement, which isn't possible in map based caves.cirix wrote:for object-based caves, the user will see logical, but unexpected results.
I'd really like to have this as an object rather than map based only.
new
hi
i uploaded a new version. only a few new features, which include:
- tuned c64 timing, which now seems to be accurate within 5%
- pal timing for slower-than-the-real-one seconds
- automatic scrolling in the editor
- two types of floodfill objects - please read the explanation in the editor help!
- automatic adding of extensions (png, bd, ...)
bye
i uploaded a new version. only a few new features, which include:
- tuned c64 timing, which now seems to be accurate within 5%
- pal timing for slower-than-the-real-one seconds
- automatic scrolling in the editor
- two types of floodfill objects - please read the explanation in the editor help!
- automatic adding of extensions (png, bd, ...)
bye
cirix
GREAT new version!
Bravo!
Woohoooo! 
I have to test new c64 timing more detailed (speed in the caves seems to be much much better now!) but I noticed that hatching delay seems to be too long. Default is 4 but the correct "felt" hatching delay is more like 2. I tested this with CLCK 3.0 on C64 and after playing around a little bit I found that 2 would be the best.
In "Select cave to play" it's great that the arrow keys left and right can select level now but how about pressing return to begin playing?
Only cosmetic: "Cave Properties/Initial Fill" - can you add a little space between the first two (Initial border/Initial fill) and the random fills? Would be more clearly. And I think the menu option "Edit/Object Properties" should be moved below right above "Edit/Cave Properties" (with a separator between them).
By the way: BDCCF should be higher than 0.5 as you implemented some new things. Maybe 0.6?
As almost all seems to be all right you can finally start to concentrate on the TO DO list...
I have to test new c64 timing more detailed (speed in the caves seems to be much much better now!) but I noticed that hatching delay seems to be too long. Default is 4 but the correct "felt" hatching delay is more like 2. I tested this with CLCK 3.0 on C64 and after playing around a little bit I found that 2 would be the best.
In "Select cave to play" it's great that the arrow keys left and right can select level now but how about pressing return to begin playing?
Only cosmetic: "Cave Properties/Initial Fill" - can you add a little space between the first two (Initial border/Initial fill) and the random fills? Would be more clearly. And I think the menu option "Edit/Object Properties" should be moved below right above "Edit/Cave Properties" (with a separator between them).
By the way: BDCCF should be higher than 0.5 as you implemented some new things. Maybe 0.6?
As almost all seems to be all right you can finally start to concentrate on the TO DO list...
I tested the new Hatching Delay default value with several Boulder Dashes on C64 but I always come to the same result: default value should be 2 and not 4 (with C64 scheduling on).
Load my CWS Boulder Dash 2, cave 03. With Hatching Delay 4 Rockford explodes on the butterflies because it takes too long to appear in the cave. With Hatching Delay 2 it's the same as on C64 and it's possible to solve the cave. Same with Intermission 3 - the Biter eats too much diamonds before Rockford appears.
I even counted the seconds in Boulder Dash 1, cave A from the moment the inbox begins to blink until Rockford appears. With the default value 4 of Hatching Delay it takes twice as long to enter the cave, with value 2 it's the same speed as on C64.
After continueing testing caves because of the C64 scheduling it really seems the speed is almost the same as on C64 - in combination, of course, with PAL-timing! Man, this is just great!
One question: Where do I have to place the C64 graphics theme so that it appears in the preferences/theme window? It would be a good thing if there would be a button under the theme window like "Add theme" or such, so another theme could be added to the game at ease.
Load my CWS Boulder Dash 2, cave 03. With Hatching Delay 4 Rockford explodes on the butterflies because it takes too long to appear in the cave. With Hatching Delay 2 it's the same as on C64 and it's possible to solve the cave. Same with Intermission 3 - the Biter eats too much diamonds before Rockford appears.
I even counted the seconds in Boulder Dash 1, cave A from the moment the inbox begins to blink until Rockford appears. With the default value 4 of Hatching Delay it takes twice as long to enter the cave, with value 2 it's the same speed as on C64.
After continueing testing caves because of the C64 scheduling it really seems the speed is almost the same as on C64 - in combination, of course, with PAL-timing! Man, this is just great!
One question: Where do I have to place the C64 graphics theme so that it appears in the preferences/theme window? It would be a good thing if there would be a button under the theme window like "Add theme" or such, so another theme could be added to the game at ease.
I tested several games more and I found out that speed is really almost perfect! It seems that GDash is about 2 - 3 % faster than the real Boulder Dash. As you said, the range is within 5 %. Can you make it 2 - 3 % slower for testing reasons?
There are some speed issues. I think they are there because of many objects in the caves (at least I noticed them in caves with many objects only).
Crazy Dream 5/Cave Many Biters: Way too fast! Cave delay in GDash is at 0 but on C64 it runs much slower. With Cave Delay 14 it seems same speed. By the way: This cave is not working as an effect is not converted right.
Crazy Dream 6/Cave Peace: Way too fast! Cave delay in GDash is at 0 but on C64 it runs much slower. With Cave Delay 18 it seems same speed.
One bug: Index window is not refreshed immediately. If you load a game in editor, edit the first cave, close the window, load another game in editor - the first cave shows the overview of the previous game. Only clicking on it refreshes the overview.
Hatching delay is really 2. I tested many other games and it's 2.
There are some speed issues. I think they are there because of many objects in the caves (at least I noticed them in caves with many objects only).
Crazy Dream 5/Cave Many Biters: Way too fast! Cave delay in GDash is at 0 but on C64 it runs much slower. With Cave Delay 14 it seems same speed. By the way: This cave is not working as an effect is not converted right.
Crazy Dream 6/Cave Peace: Way too fast! Cave delay in GDash is at 0 but on C64 it runs much slower. With Cave Delay 18 it seems same speed.
One bug: Index window is not refreshed immediately. If you load a game in editor, edit the first cave, close the window, load another game in editor - the first cave shows the overview of the previous game. Only clicking on it refreshes the overview.
Hatching delay is really 2. I tested many other games and it's 2.
- LogicDeLuxe
- Member
- Posts: 655
- Joined: Sun Jul 15, 2007 12:52 pm
- Contact:
Well, there is something I forgot to mention about the 4 seconds hatching delay: The hatching timer is initialized at the beginning of the build up effect, rather than the actual cave action (like the amoeba timer does in BD1 somewhat inconsistently.) Since this build up effect lasts 2 seconds, only the remaining 2 seconds are left during the actual action.
I assume, Gdash initiates this timer after the build up effect, so 2 seconds matches the C64 timing indeed. As the build up time is a constant value as well, I see no reason not to make hatching delay default 2 seconds then.
And I also agree on C64 timing still needs tweaking: Dr. Watsons BD4, Cave D (many Butterflies) and Cave O (many Fireflies) are far too fast.
Some menus are German, but umlauts don't seem to work.
CTRL-Z should be used as the undo hotkey, as pretty much any software does this.
I think, we can stay with 0.5 until at least one engine is complete using it.
I assume, Gdash initiates this timer after the build up effect, so 2 seconds matches the C64 timing indeed. As the build up time is a constant value as well, I see no reason not to make hatching delay default 2 seconds then.
And I also agree on C64 timing still needs tweaking: Dr. Watsons BD4, Cave D (many Butterflies) and Cave O (many Fireflies) are far too fast.
Some menus are German, but umlauts don't seem to work.
CTRL-Z should be used as the undo hotkey, as pretty much any software does this.
Not really. 0.5 isn't even documented completely yet. Don't rush things. It's not like that we badly need this increase in order to detect things, like we had before with the visible size and border behavior.By the way: BDCCF should be higher than 0.5 as you implemented some new things. Maybe 0.6?
I think, we can stay with 0.5 until at least one engine is complete using it.
I'm really relieved that I didn't imagine this too long delay...LogicDeLuxe wrote:I assume, Gdash initiates this timer after the build up effect, so 2 seconds matches the C64 timing indeed. As the build up time is a constant value as well, I see no reason not to make hatching delay default 2 seconds then.
I noticed that, too. Umlauts are a problem (also in cave names).LogicDeLuxe wrote:Some menus are German, but umlauts don't seem to work.
CWS wrote:By the way: BDCCF should be higher than 0.5 as you implemented some new things. Maybe 0.6?
It was just an idea because there were added new things so the incease in version number would be justifiable. But ok, your arguments are understandable.LogicDeLuxe wrote:Not really. 0.5 isn't even documented completely yet. Don't rush things. It's not like that we badly need this increase in order to detect things, like we had before with the visible size and border behavior.I think, we can stay with 0.5 until at least one engine is complete using it.
By the way: "program a Highscore-Table" is missing in the TODO-list...