| |
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....
|
| |
algorithm
Registered: May 2002
Posts: 705 |
Quote: Some notes: sprite glitches start to appear when you have more than 4 soldiers (you + enemies) on a line, or even earlier when there are bullets, then you have to reuse an upper body sprite for the legs.
As far as I remember, Ocean/Imagine games, GB included, use a kind of "lazy" multiplexer, which is not unrolled, and does manual $d010 and/or arithmetic in the middle of the sprite-IRQ, instead of precalculating.
But by using tighter (unrolled) multiplexer code, you probably can reduce the glitches. You can calculate the sprite-rastersplits beforehand and then you can estimate how many lines' worth of time you have to rewrite the sprite attributes (and always write Y coords first)
Feel free to rip out the multiplexer from MW4 :)
Also for color-scrolling, you probably can use speedcode to some degree.
There have been a considerable amount of advancements since the days of the mid 80's.
VSP for scrolling, and the $d018 switch method to remove the glitches in the multiplexor alone will dramatically solve most of the issues.
With the power of a pc available the color scrolling can be omitted with using a universal color via converter which produces least error.
Interlaced sprites will bring the resolution back to the characters (although twice as much ram) yet again conversion process can make this trivial. And combined with packing and a fast loader (eg krills loader 6k per sec at full load etc) then we are talking about a game that would certainly beat the original hands down. |
| |
cadaver
Registered: Feb 2002
Posts: 1160 |
$d018 switch means you have to copy screen data twice? Yeah, for VSP scrolling that probably isn't a big deal.. but there will still be color & X-coordinate glitches, as it eliminates just the framepointer glitch. |
| |
algorithm
Registered: May 2002
Posts: 705 |
No. Would only copy data to the required area's eg before the d018 switch and after to the other screen page area without duplicating. If screen is scrolling at 2 pixels per second even with duplicating screen banks and without vsp, there is 4 frames to do this in. would require 4 pages (4k) of double buffer however |
| |
rattus
Account closed
Registered: Oct 2002
Posts: 14 |
Hi !
If you will do this Greenberet conversion, I promise I'll drink a bottle of "koskenkorva" and play it as long as I can.
Succeeding in this would be the ultimate scene project ever done. I mean ever !
|
| |
Angel of Death
Registered: Apr 2008
Posts: 211 |
@STE'86
My post was meant to, more or less, challenge people on the forum. But I forgot that we are surrounded by complete nutcases. :)
Let's do what I used to do on a c64 party. sit down and have a laugh and a beer.
And I totally agree with you on the "top shortlist" of David Collier and Tony Pomfret. But I'd like to add Chris butler to that.
To the nutcases :
I was suggesting VSP, mainly because with smaller sprites I think a less high play-field can be used. So less screenlines need to be scrolled. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11360 |
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: 705 |
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: 255 |
@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: 88 |
freds back 1-3 from cosmos designs uses MulticolorBitmap+AGSP. |
| |
TWW
Registered: Jul 2009
Posts: 545 |
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! |
| Previous - 1 | 2 | 3 | 4 | 5 | 6 | 7 - Next |
