Gdash

cirix · Post by **cirix** » Sun Oct 19, 2008 12:15 pm

Dustin wrote:
cirix wrote: recently I always try to deal with compatibility issues, too, as many of you already have levels saved by gdash.
Where to download these games?? )

Well, nobody sends me those.

LogicDeLuxe · Post by **LogicDeLuxe** » Wed Oct 22, 2008 2:14 pm

1stB, CrLi uses 4 stages for ghost explosion, clock birth, steelwall birth, bomb explosion and boulder birth each. The first is for delay state purposes and has the same graphics assigned as the 2nd stage. The 3rd and 4th are for the following frames with the other two explosion graphics. That makes those explosions last for 3 frames actually.

I noticed that GDash uses 4 different graphics for those and they also last 4 frames.

Same with the bomb, once armed, it lasts 6 frames until it explodes while it is 7 in GDash.

RTADash · Post by **RTADash** » Fri Oct 24, 2008 3:57 am

I'm a bit late in mentioning this, but thanks for improving the BDCFF saving; it seems waaayy better now! (No more crashes when trying to update an old one)

LogicDeLuxe · Post by **LogicDeLuxe** » Fri Oct 24, 2008 8:06 pm

I've got an idea for extending the color names in order to keep the original Atari values in BDCFF files. So along with C64 names and 6-digit hexnames, we could just add names like "Atari_1e" where we have a hex byte at the end, representing the original Atari value. That would have several advantages:

- Selecting another Atari-palette after loading a game from BDCFF, just like with the C64 games.
- Giving other tools the same opportunity of using their own palette. Especially useful on hardware with fixed saturation and thus unable to interpret hex triples.

cirix · Post by **cirix** » Sat Oct 25, 2008 8:47 am

LogicDeLuxe wrote:just add names like "Atari_1e" where we have a hex byte at the end,

i already mentioned this in the bdcff discussion forum.

LogicDeLuxe · Post by **LogicDeLuxe** » Sat Oct 25, 2008 10:19 am

You might add an GDashVersion attribute to BDCFF files. That way, you could easily detect outdated versions by this in the future and upgrade those automatically on loading without risking breaking anything unintentionally.
Concerning the current line issue, this might be useful once solved. Also in the unlikely event that there are competing BDCFF files which draw lines differently to GDash (given the issue isn't solved), I can read that attribute and decide on how to draw those lines.

CWS · Post by **CWS** » Sat Oct 25, 2008 10:40 am

A new idea: As soon as "Intermission" is check in cave properties, the default values for width and height should be 20 x 12 as intermissions are typically in this size.

cirix · Post by **cirix** » Sat Oct 25, 2008 10:42 am

LogicDeLuxe: please do not write here about bdcff issues. it is of no relevance for the users of gdash; also, the problem about the bresenham line algorithms has also nothing to do with gdash. the readers of this forum do not even know what you are talking about. THANKS.

BadDog73 · Post by **BadDog73** » Tue Oct 28, 2008 12:30 am

I've been thinking about this for a while, and I've made some caves for my 2 daughters, who really love the game.

2 things that I think would improve the cave creation process:

- Default timing values reflect a real-world setting to begin with. For example, default cave timing (ms) might be 180, 160, 140, 120, 120. There might be other things that occur to you.

- If intermission box is checked, ask the player if he wishes to resize the cave to standard intermission size. In some cases, you would not want to do this, so it would be good to ask first.

Thanks again for all the work

cirix · Post by **cirix** » Mon Nov 03, 2008 7:33 pm

hi

BadDog73 wrote:- If intermission box is checked, ask the player if he wishes to resize the cave to standard intermission size. In some cases, you would not want to do this, so it would be good to ask first.

CWS already requested that, but I discarded the idea. I think I will implement it, but it will require a "new cave" dialog, which selects intermission or not. it is not feasible (under any circumstances) to automatically change the size after using the normal "cave properties" dialog.

currently I have a lot of other things to do, so I just can't work on gdash

bye

CWS · Post by **CWS** » Sat Nov 08, 2008 12:40 am

Small feature request: an active gravitation-switch in the element box/for effects. So no pot is needed to activate it first...

cirix · Post by **cirix** » Mon Nov 10, 2008 12:49 pm

hi

this is a new version with some small changes & fixes, as unfortunately i do not have much time now.

changes:
- wraparound drawing for cave objects
- correct bd2 scheduling for both c64 and atari
- corrected capital nouns for german translation
- some games imported
- 2x vertical scrolling (for lcd screens, helps a lot on mine)
- 50hz scroll (sdash only), faster than the normal, but is very smooth, i like it
- gravity switch can be activated at cave start (can be accessed from cave properties)
- for new caves: more realistic timing as default setting (180, 160, 140, 120, 120). created intermissions are also small.
- and that's all for now.

bye

CWS · Post by **CWS** » Tue Nov 11, 2008 9:24 am

Wow! That's what I call softscrolling!

Thanx for that!

LogicDeLuxe · Post by **LogicDeLuxe** » Tue Nov 11, 2008 6:25 pm

The 3x nearest scaler looks distorted in sdash, ie. the top row and leftmost column of each element have 4 pixels and the bottom row and rightmost column have only 2. This issue is sdash only.

I see you read Atari## colors from BDCFF files now. That's nice. If we could select them in the color picker as well, that would be perfect.

And better handling for unknown color names would be very nice too. They should be chosen like with the Random button in gdash's color picker, which produces quite useful colors. Same for BDCFF files with no colors specified at all.

And the scrolling works fine indeed.

CWS · Post by **CWS** » Wed Nov 12, 2008 8:56 am

Beginning with Quolder Dash 23 the colors are totally wrong.