| |
Wile Coyote
Account closed
Registered: Mar 2004
Posts: 646 |
Green Beret - Is any interested in..
Is anyone interested in making a new version / conversion for the C64, as I am sure it can be done better than the original official Imagine release. The Imagine release was impressive especially the Audio which could be re-used, or conversed to use less raster time, although the graphics, and some of the playability could be much improved.
Ideas:
If the game were based on disk / cartridge, I thought it would make sense to load each level during the interlude screens.
With the extra memory, maybe it would be possible to use hires overlays on the sprites.
If the score were placed in the upper border, the playing area could be increased, to match that / be similar to that of the Arcade version. |
|
... 60 posts hidden. Click here to view all posts....
|
| |
TNT
Account closed
Registered: Oct 2004
Posts: 189 |
If you are scrolling 8 pixels/frame maximum and your color memory doesn't have an awful lot of "spans" of colors it's faster to update only their edges. I think I got my routine down to 30-35 cycles per change + 30 cycles if the first visible span scrolled out of view and a new one was fetched - that can be during the next frame if you scroll at half speed. Data format was length,color byte pairs with separate span data for each row. |
| |
STE'86
Registered: Jul 2009
Posts: 274 |
yep that would work, but alas not on GB. check out the missile trucks they have individual character square colour maps.they are not tiles and matching single block colours.
so in order just to retain parity with what DC did in '86 any coder now would have to do the same intricate colour map routine.
and to better it, you would have to go to Bitmap mode.
Steve
|
| |
TWW
Registered: Jul 2009
Posts: 543 |
Fullscreen Bitmapscrolling without VIC-Trix (Using speedcode / double buffer):
8000 bytes bitmap
1000 bytes char mem
1000 bytes collor mem (has to happen on frame before and after bufferchange)
9000 bytes to move x 6 cycles = 54000 cycles
54000 / 6 frames = 9000 cycles ; which rougly translates to 150 lines of r-time (depending on NTSC/PAL vs. Number of badlines encountered)
The really bad news is the memory needed to do a fully unrolled speedcode which require 6 bytes for each byte to move... 2 buffers... not good.... You could however loop over a few times and slice the RAM needed down to, say, a quarter which is almost doable (however a slight penalty to r-time would apply offcourse).
this ofcourse scrolling 1 pixel at the time. 2 pixels or more you can forget about without using VSP/VIC-TRICK.
But fuck it... doesen't everybody have a REU these days anyways? should be possible to do some serious DMA to make a nifty scroller right? |
| |
Oswald
Registered: Apr 2002
Posts: 5078 |
moving a byte will take you 8 cycles unless your whole bitmap & color data is on the zp. using a loop will make it 9 cycles + loop overhead. anyway GB is perfect for vsp scrolling. |
| |
TWW
Registered: Jul 2009
Posts: 543 |
*ehheemmm* Yes as I said... It will take 8 cycles a byte...
(nittpicker :D)
edit: To my defense I'm in another timezone ^^ |
| Previous - 1 | 2 | 3 | 4 | 5 | 6 | 7 - Next |
