Can the code be optimized any further?

Everything about the old and new Boulder Dash games for C64, Atari, ...

Moderator: Admin

Post Reply
User avatar
LogicDeLuxe
Member
Posts: 638
Joined: Sun Jul 15, 2007 12:52 pm
Contact:

Can the code be optimized any further?

Post by LogicDeLuxe »

Just checked the IRQ timings in CrLi to have a reference for possible optimizations.

Animations (without magic wall): 48 raster lines at 25 Hz. This seems to be quite a lot optimized already, but still has its flaws.
This takes place just a few lines after the status bar, causing tearing effects in animated elements in the first 3rd of the screen. Interestingly, I frequently noticed this effect in PLCK and later engines, but never on BD1 or BD2 engine games.
While 48 is too much to be moved into the vertical border on NTSC, the animation could be split into 24 raster lines at 50 Hz. (Would interfere with the virtual screen routine, though. Read on.)

Also since most original graphics only have 4 different graphics of those 8 available, the animation could take this into account to speed up the cave further. This would restrict the possibilities for custom graphics, though, thus probably not worth the effort.

Timers: 18 raster lines. Plus a some more each second for counting and displaying.

Sound (without magic wall): 10 max. 4-6 average.

Scrolling: 16

Virtual screen emulation: 173 raster lines at 25 Hz.

There is always one field for virtual screen emulation and one field for all the other interrupt stuff in an alternating pattern.

For the good news, there is enough time left in the "other stuff field" for flashing foreground color 3. So this feature can be done after all.

For the other thing, I'm curious if it would be feasible to write an alternative scrolling routine without a virtual screen buffer which must be just as soft without taking any more rastertime. Even better, if it also could write all the color RAM, so the amoeba and slime color feature, which was not ported from the Atari could be done.
Code size may be 3.5 kB more than now as that is gained by getting rid of the virtual screen buffer. Even a few kB more won't hurt, as we still have all the RAM at $d000-$ffff unused, where the caves can go easily.
I'm not that experienced in writing scrolling routines. Any comments or ideas on this?
Post Reply