| |
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....
|
| |
GT
Account closed
Registered: Sep 2008
Posts: 308 |
Quote: or Prince of Persia vs Green Beret ? could get interesting :o)
Don't troll. :) |
| |
GT
Account closed
Registered: Sep 2008
Posts: 308 |
Quote: heres my alpha run cycle.
done yours yet?
Steve
Looks really good Steve. |
| |
v3to
Registered: Feb 2005
Posts: 150 |
steve: like the sprite, waiting for the final anim. the movement looks a bit unbalanced atm |
| |
STE'86
Registered: Jul 2009
Posts: 274 |
alpha v2 and we have a tidy up and the addition of a bit of a head bob as he hits the floor. and the animation speed is increased to test it.
getting there now:)
Steve
and if u think thats unbalanced, check out the actual green beret animation in the arcade version in mame. that looks totally fcked to me. like they are playing the frames in the wrong order :)
|
| |
Angel of Death
Registered: Apr 2008
Posts: 211 |
Quoting STE'86and bearing in mind that the original was written by Dave Collier who was a sprite multiplexer pioneer, the sprites in green beret have some problems with glitches when lots of nasties appear.
you are right about DC being a multiplexing pioneer. (he developed what we now call "the ocean sorting method")
But constantly being forced to work at light-speed his games did have their flaws. (just ask the people in Remember what they fixed in arkanoid)
I think, with tech and knowledge now at our disposal, that we could make a better version.
Ste'86 's actor is only one sprite big. When the screen is moving there are about 12 actors at the same time on screen. Add some bullets and mines and you end up at about 16 to 18 sprites. Easy with nowadays multiplexers.
As far as I can see plenty room for some fancy hires scrolling with track-loading levels... ;) |
| |
STE'86
Registered: Jul 2009
Posts: 274 |
somebody be sure to send me a PM then when anyone on here has done a screen high colour ram scroll with an AI multiplexer capable of deciding what sprites are able to move between levels based on what other sprites are doing on other levels.
and i'm sure we can talk ;)
Steve |
| |
Wile Coyote
Account closed
Registered: Mar 2004
Posts: 646 |
@STE86
Im working on it.
Your sprite animation: Good effort.
It would suite Green Beret the 100% re-imagined version.
That could be cool, to take the existing Green Beret map layout, and re-imagine the graphics, to suite the C64, all the while retaining the originals playability. |
| |
Merman
Registered: Dec 2002
Posts: 140 |
Quote: somebody be sure to send me a PM then when anyone on here has done a screen high colour ram scroll with an AI multiplexer capable of deciding what sprites are able to move between levels based on what other sprites are doing on other levels.
and i'm sure we can talk ;)
Steve
Are you sure on your figures there? Having been playing the arcade game a lot recently, in most cases the maximum is six-eight enemies at a time. |
| |
STE'86
Registered: Jul 2009
Posts: 274 |
each 2 sprites each, at least half of which can change levels and follow you about as you do.
plus bullets, plus weapons, plus mortars, plus trucks, plus the kung fu guys going from 1x2 to 2x1 sprites when they attack, plus the guys crawling on the floor that are 2 sprites across.
all starts to get a touch complicated for the "usual" sprite counting multiplexer.
hence in the old old days of zzap when they spent paragraphs extolling the prowess of Andy Braybrook and Archer McClean, those of us who actually looked at what was happening on screen knew it was Dave Collier and Tony Pomfret who u watched.
Steve |
| |
cadaver
Registered: Feb 2002
Posts: 1160 |
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.
|
| Previous - 1 | 2 | 3 | 4 | 5 | 6 | 7 - Next |
