| |
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. |
|
... 55 posts hidden. Click here to view all posts....
|
| |
chatGPZ
Registered: Dec 2001
Posts: 11182 |
VSP is overrated imho - when it comes to game engines anyway, and it doesnt really dramatically solve all problems either.... and on top of that it creates new ones. there is a reason that only *very* few games use it (is there even one besides "another world" ?)
i agree with cadaver though, a "modern" multiplexer can do wonders. and many "old" games have really simple multiplexers which can be improved rather easily :)
|
| |
algorithm
Registered: May 2002
Posts: 703 |
Would always be a good idea to avoid VSP unless scrolling data at high speed or using bitmap mode. And to prevent crashes on some C64's There would be around 4 frames to transfer screen data the usual method if scrolling at 2 pixels per second.
Creatures, Mayhem in Monsterland and Phobia are those from the top of my head that use VSP |
| |
Perplex
Registered: Feb 2009
Posts: 254 |
@algorithm: ITYM 2 pixels per _frame_, not per second. ;-)
And there were guys outside the UK that knew how to code games in the late 80's as well. Manfred Trenz, anyone?
|
| |
Spinball
Registered: Sep 2002
Posts: 87 |
freds back 1-3 from cosmos designs uses MulticolorBitmap+AGSP. |
| |
TWW
Registered: Jul 2009
Posts: 542 |
I don't really want to get into this but I will say though that I have experienced a rather successfull usage of double screen-buffers in terms of gfx scrolling.
The only real limitation is that you need to scroll the $d800 collors on 2 frames but the rest can be scrolled in the remaining frames (thus reduces r-time(even more with speedcode)).
bullets / stuff----> Char-animations ftw! |
| |
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: 542 |
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: 5034 |
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: 542 |
*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 |
