Kroc Camen
Kroc Camen
I've no real hardware to test with, just emulators. Yes, you're right that the game just goes as fast as the system does so tying the logic/physics to some fixed...
No, sorry; Uz has never released his code (I asked), so I had to start from scratch.
Note to self: I've found the line-drawing routine, so we could replace this with something much faster, like Oxyron's Bresenham routine sampled here: http://www.codebase64.org/doku.php?id=base:lines assumedly used in some form in...
Note to self: Possible build option to utilize an REU's DMA channel to speed up transfers. We could use this to blank the entire bitmap screen faster than erasing all...
An on-going concern for absolute line-drawing speed is the amount of parameter validation that occurs every time a line is drawn. What I would like to do is completely remove...
It has occurred to me that the actual line drawing only cares about an initial point (X/Y) and a width & height -- not the end co-ordinates. Therefore it is...
It's not 8'000 bytes, because the viewport is only 18 rows, not 25, it turns out to be 4'608 bytes. Even erasing that many bytes in a loop would still...
That can't be done buffered though unless you take a copy of the color RAM for the second buffer(?) A dirty-tile cache might take an awful lot of RAM though...
Oh silly me, I read you as saying colour RAM ($D800), not the screen RAM ($400 each), my bad!
I'll add a build option to remove the sound engine & music, so that'll give a few KB free for any play-around.