Boulder Dash Forum

LogicDeLuxe wrote:I noticed that some games from the Boulderrush directory have really strange colors (Achim Haertel for instance), while others have adequate c64 colors (Examples for instance).

Yes, those are from the atari. I correct them to use the atari colors.

Edit: corrected some of them. But the "Unknown" compilation even seems to be a mix of c64 and atari caves... Maybe one can use the "random colors" in the preferences window to play. The Wilhem Oelinger caveset seems to be false color for c64 and atari, too.

cirix wrote:But the "Unknown" compilation even seems to be a mix of c64 and atari caves...

There seems to be more problems than that. Cave 07, Cave 16 and Cave 29 are garbled, ie. shifted two rows to the left and all the parameters are wrong. Must be something wrong with the conversion.

Maybe Atari caves could be autodetected by looking if either the default amoeba or slime color is present. Would only work for PLCK caves, though.

LogicDeLuxe wrote:Cave 07, Cave 16 and Cave 29 are garbled, ie. shifted two rows to the left and all the parameters are wrong.

I think I will simply delete that file. It is not converted by the any2gdash, rather it was "surgically removed" (:)) from a .dll file of boulder rush. It would be worth rather checking which caves those really are, and convert the original games.

I have not found any method of selecting an effect for the nitro pack. Would be nice if there would be an option in cave properties/cave effects. "Explosions convert to" does not have any effect on the explosion of the nitro pack.

Editor crashes when unknown attributes are in the BDCFF file and you try to change certain parameters and than save the file.
I tested this with required diamonds and with cavename which results in a crash when trying to save.
I also did test changing the colors or any cave objects, and it is saved fine, including the unknown attributes.

A simple example to test it with. (test=47 is of course a placeholder for any feature not currently implemented)

The Atari colors are good now. Thanks.

Also, did you do anything to the scrolling routine before the 1st October release (pre slime_permeability fix)? It wasn't mentioned in the change list, but it seemed much improved to me. Less flickering when scrolling, and faster when Rockford was at the edge of the screen? To me this was an extremely important fix for gameflow/timing/feel. Before this, it just didn't seem right.

BadDog73 wrote:Also, did you do anything to the scrolling routine before the 1st October release (pre slime_permeability fix)?

Not at all. Maybe the scheduling of the cave was changed, and scrolling does not seem so slow compared to cave events.
But scrolling will be worked on a bit. At least the problem with vertical scrolling: if one uses pal scanlide shade, lcd screens flicker a bit for vertical scrolling, when scrolling down or up an odd number of pixels. (So that light and dark rows change place.)

bye

Did you notice that the PAL emulation does not work on the one colored white letters in the status line? Looks strange when all other things are PAL emulated...

CWS wrote:Did you notice that the PAL emulation does not work on the one colored white letters in the status line? Looks strange when all other things are PAL emulated...

It is just how PAL works. Much more color artifacts than luminance artifacts. The most unreadable color combination I found was red+green and blue+brown Just try it on a real TV Press ctrl+2 and type something when you have turned on the C64.

cirix wrote:The most unreadable color combination I found was red+green and blue+brown

There are a total of seven such combinations on a VIC-II. red+green isn't one of those worst case combinations actually. See here for the most detailed investigation in VIC-II colors: http://www.pepto.de/projects/colorvic/
The table "late VIC-II luma" is of particularly interest here, as it pairs those worst case combinations.
The Gdash palette is fine, though. It has better gamma than that example given on that site, which is far too dark, imho.


Although, the PAL emulation looks better then last time I checked, it looks more like NTSC emulation, as I don't see any averaging over lines at all. It does emulate color carrier influences on edges well, though. Works well in the title screen at least, but this effect is not there between elements placed side by side in the game, which looks strange.

LogicDeLuxe wrote:... but this effect is not there between elements placed side by side in the game, which looks strange.

You are right. Some elements (not all) have strange sharp left or right endings in PAL emulation (e.g. the brick wall mostly on the left side) - but only in fullscreen mode in sdash! Maybe only because the elements are shown much larger then in window mode and the display errors are much more visible then.

But all in all PAL emulation just looks great! Btw - I use 50 % PAL scanline shade which looks even more realistic than the suggested 85 %! Veeeery nice!

LogicDeLuxe wrote:Works well in the title screen at least, but this effect is not there between elements placed side by side in the game, which looks strange.

and will never be, as cells are "pal-emulated" one by one, not the whole screen - for speed.
and yes, no averaging between lines, but no, ntsc does not generate checkerboard patterns. http://www.techmind.org/vd/paldec.html. and that one would also create color shift. sometimes i am really amazed how fussy you people can be.

cirix wrote:sometimes i am really amazed how fussy you people can be.

I think all we want is to report any findings just to insure if it is intended as it is or it could or should be improved.

Regarding scrolling:

If the possibility of Rockford getting to the edge of the screen and causing a pause were eliminated at faster speeds, I wouldn't mind at all. I know it's not authentic, but it's the one element of the original game which has IMHO no merit. I'm sure if Peter Leipa et al had been able with the hardware available, they wouldn't have made it that way - it's just that the computers of the time couldn't be made to scroll any faster.

Just my 2 cents.

BadDog73 wrote:it's just that the computers of the time couldn't be made to scroll any faster.

That's not true. If you would take a look at the scroll routine, you would realize that it is designed in a way (Atari version as well as the C64 port) which would allow scrolling instantly anywhere in the cave with each TV frame.