I spent some time in January reviewing the sprite drawing & erasing routines, and the collision routines. I discovered a couple areas I could optimize the code. Maybe this is prep for working on a 2600 game next, counting cycles so much. With 5200 programming, although I did optimize, I didn't really analyze the cycles as much (I didn't need to!) as I did this month. I've heard it said among more experienced [Atari 2600] homebrewers than myself, that there's always another byte you can save, and you can always reduce another cycle. You just have to hunt for them!
I was doing this to prevent a collision glitch in the game. When there are 2 creatures on screen, and also several items, near the top 1/4 of the screen there is a section where the collision would get confused. See my previously posted YT video for evidence of that.
I was able to reduce many cycles from the Player (Atari hardware's version of a "sprite") Draw & Erase loops! These routines are performed in the Vertical Blank Interrupt, when the monitor's electron beam resets from bottom-screen to top-screen again. Because Adventure II's creatures can sink beyond the bg-graphics overscan area (which I like), I can't change the logic to start before Vertical blank. I do some Pre-Processing in on-screen time, but certain logic needs to be in the VBI.
Results: I immediately noticed a good side-effect of the optimization. Gone was another minor visual glitch that I'd previously see sometimes on busy screens - where the DLI color changes would not get activated in time and the top of certain screens could have the wrong color. This problem appears to have been 100% remedied by my January optimizations.
On the above screen, there are two dragons and 4 items (although I could only capture 2 of them due to the flickering). The screen's background colors are always rock solid now. The same thing on the Castle Ramparts screen (where I actually had 3 creatures on that screen for a few seconds) - rock solid colors and no more DLI color errors on busy sprite screens.
Well unfortunately, I didn't totally eliminate that busy-screen collision glitch. But the affected area has moved higher on the screen; but it can still occur. I still have more time before end of January and I hope to totally eliminate the bug by end-of-month.
Thanks to RUSH , always great music to code to!
c(_)
-
entries
69 -
comments
86 -
views
49,348
-
Recently Browsing 0 members
- No registered users viewing this page.
0 Comments
Recommended Comments
There are no comments to display.