| |
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. |
|
| |
iAN CooG
Registered: May 2002
Posts: 3145 |
open a bounty for it (lol) |
| |
STE'86
Registered: Jul 2009
Posts: 274 |
i would have thought that hi res sprite overlays would be a touch ambitious for green beret. there are rather alot of potential sprites in a line during sections of that game.
and 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.
i'm not saying that the graphics couldnt be improved, but hi res overlays would be pushing your luck i think :)
Steve |
| |
v3to
Registered: Feb 2005
Posts: 150 |
green beret graphics can be improved in some ways, but i agree with steve that overlay sprites are probably a bit too much. but more fluid animation should do...
stephen wahid did a pretty good job with the char-bg-gfx. actually there might be some chars left if there are unique sets for each level, but thinking of the colorscheme of the arcade there is very limited potential. slightly better dithering here or one more screw and weld seam there.
to get a more high-detail-level or something like that you need a more flexible color combination for the characterset and this means loosing authenticity.
green beret uses the fixed colors "light blue - medium grey - black" and you would need something like "brown - light blue - light grey" to become more flexible. the bg would get a different look (more dirty, divergent contrast, less saturated). |
| |
STE'86
Registered: Jul 2009
Posts: 274 |
i've just been staring at the green beret screns on lemon for the first time in many years and tbh i can't see a way of improving the the colours either.
it seems to me that the colours picked are pretty much required for all the levels to provide clarity and contrast against the sprites given the lower 8 colour limit on char colour.
given that Collier is scrolling pretty vast amounts of colour ram in GB and its associated memory overhead, the only way i could see an improvement would be a transient (multiload).
possibly given memory you could have multiple "flagged" charsets per level in memory for added detail.
in such a system you could do the following:
(AAAAAAAABBCCCCCCC)
where A are screens comprising 1 charset C are screens defined by another charset and B are screens built from say 50 chars common to both sets. charsets can then be switched over when uncommon chars are no longer visible on screen.
HOWEVER, having looked at GB again, i would hazard a guess that Collier may already be doing this in the area between the red bridge and the missile trucks :)
so basically it would come down to the possibility of improving the draughtsmanship and not much else :)
Steve |
| |
Wile Coyote
Account closed
Registered: Mar 2004
Posts: 646 |
1x1 hires font could be improved. It could look 100% like the Arcade game font.
Title screen logo. It could look 100% like the Arcade game, all-be-it using the C64s Green.
In game:
Sky colour, I would have chosen Cyan, not Medium Blue as used my Imagine.
Pixeling of the back drops could be much improved.
Sprites:
If hires overlays are not possible, I still think it would be possible to create sprites that look like those of the Arcade games, complete with black outlines.
Playability:
The Imagine game featured 2 major faults:
1. The enemy bullet speed was too fast.
2. While running along ground, the player when jumping can be effectively kicked in the head. This never happen on the Arcade game.
The C64 Green Beret was actually tougher than the Arcade game. I could complete the Arcade game, but not the C64 conversion. |
| |
v3to
Registered: Feb 2005
Posts: 150 |
for the bg cyan is not the best choice for bg, though it may be possible to get a bit more detail by pixelling transitions. there are some color-combinations with the variable color that will provide problems. that is the reason why i think you need a lighter shade of grey or you need to use cyan like grey. both versions would cause a color cast.
the whole thing would look more grey-ish.
playability: agree, without a doubt. |
| |
STE'86
Registered: Jul 2009
Posts: 274 |
well, personally i found the cyan of the c64 not very easy on the eye. but technically yes the arcade is closer to the "duck egg" colour of c64 cyan. tho tbh i am unsure how well this would "gel" with the other c64 colours.
the draughtsmanship yes could probably be improved in a few areas. Steve Wahid did pretty well in this conversion but he wasnt a graphic artist in the Steve Thompson class. But again in defence, drawing stuff in char mode takes a different mindset to doing it in bitmap or you run out of chars quicksmart.
you are in no way ever going to get black outlines in those sprites, sorry but its never going to happen in 2:1 multicolour mode.
fair point about the c64 version being so hard, but in mitigation, the bullet speed is so because its alomost certainly a software sprite and so has to move 8 pixels a time.
Steve
edit no i am reliably informed the bullets are HW sprites and move fast to get them off the screen quickly to prevent the multiplexor overloading and glitching. :) |
| |
Wile Coyote
Account closed
Registered: Mar 2004
Posts: 646 |
With the original Steve Wahid graphics, they look stretched horizontally.
This had the knock on affect of making the play area appear lacking in height.
One idea might have been to narrow the play area width. Another idea might have been to keep the wider player area, and show more of the backdrop.
Speaking hypothetically, and given the fact Im not a programmer, the illusion of a taller play area might be possible.
 |
| |
cadaver
Registered: Feb 2002
Posts: 1154 |
But what's the pixel aspect ratio on the real arcade screen? The resolution seems similar to NES, which stretches its pixels horizontally to fill the TV screen, but emulators don't always emulate that.
Of the graphics, you could possibly achieve more colorful level backgrounds by not making black a common color, but a char color instead. However at some points that could be a detriment. Or perhaps even using bitmap mode and VSP scrolling :) |
| |
algorithm
Registered: May 2002
Posts: 703 |
Sprites with overlays would give 4 characters on one section (including player) But would need to take into account any enemies/player jumping up to next section on screen (eg if there are already 4 players on the top platform=no more sprites. but the AI would take care of that. would ofcourse require a considerable amount of multiplexing although would not hit cpu resources greatly and due to the simplicity of the background graphics, charmode will do (although bitmap and vsp) would give more color combinations.
For the bullets/missile, would be easier to use charmode and to eor the bullets with the background
|
| |
cadaver
Registered: Feb 2002
Posts: 1154 |
There could still be some unforeseen shit happening, like a dead enemy (if you emulate that from the arcade, it would be nicer than just always turning into a skeleton) or weapon falling into a group of enemies on a lower platform, and overwhelming the multiplexer. But in that case you could flicker the objects like on NES :) |
| |
algorithm
Registered: May 2002
Posts: 703 |
Bitmap mode would solve that problem somewhat. Or using spare characters that are not used in display to 'ora' the killed enemy onto a strip with background definitions and then plotting the new chars there etc. same for bullets.
Flickering the bullets also would not be that much of an issue if they are sprites |
| |
Oswald
Registered: Apr 2002
Posts: 5034 |
wow, atariage forums have arrived. blabbling instead of coding is indeed very easy, a few sentences in a minute, and the game will just code itself after that.
all this overlay and graphics shit wont make the game better anyway, playability is more important than 'nice' overlayed flickering sprites. |
| |
algorithm
Registered: May 2002
Posts: 703 |
Quote: wow, atariage forums have arrived. blabbling instead of coding is indeed very easy, a few sentences in a minute, and the game will just code itself after that.
all this overlay and graphics shit wont make the game better anyway, playability is more important than 'nice' overlayed flickering sprites.
Yes, talking about things instead of doing it is indeed easy in comparison to taking out time to actually create it, but thats not exactly rocket science is it? People here are just putting idea's together and making some time pass by with comments.
Yes, gameplay is important but if the graphics are 'better' it adds to the gaming experience |
| |
STE'86
Registered: Jul 2009
Posts: 274 |
sorry but no matter how u look at it, you arent going to get hi res overlays. there are too many variable positioned enemies to consider wasting half your sprites on black outlines.
u say there can be 4 men in a line including yourself, well thats fine for when u are standing but what happens when u get 3 enemies on one level and u duck?
your player is 2 sprites wide when lying down
so you would suddenly go from requiring 8 sprites on a line to requiring 10. ditto when u get a green man doing a flying kick.
realistically no matter which way you come at this, it just not possible to do overlays on GB.
and once again i point out that Dave Colliers 'plexer is a serious bit of AI. he already takes into consideration how many enemies are on each level before letting guys shoot or change levels.
indeed as Pete pointed out to me last night night, when an enemy fires and there are too many sprites in a line, all that happens is that a gap the height of the bullet appears between the torso and legs of the sprites. in most 'plexers you would lose the legs off one of the sprites. like i say. serious bit of kit.
Steve |
| |
The Shadow
Registered: Oct 2007
Posts: 304 |
 |
| |
algorithm
Registered: May 2002
Posts: 703 |
The overlay layout would not need to stay the same. When the player ducks. one sprite would be x expanded and the other would somewhat be positioned in an area where details are important (eg torso section)
Unfortunately the multicolor pixel would be 4 pixels wide, but the overlay should minimize the blockiness to some extent.
|
| |
STE'86
Registered: Jul 2009
Posts: 274 |
ok sounds like u have a plan. so when can we expect the initial alpha testrun?
Steve |
| |
Hein
Registered: Apr 2004
Posts: 935 |
I'd start without overlay too. Why focus so much on black outlines, instead make a good animation (and save that spare sprite for game play). After all, you're free to interpret Green Beret the way you want. |
| |
Wile Coyote
Account closed
Registered: Mar 2004
Posts: 646 |
I guess hires overlays would limit the game to having a maximum of 3 characters per horizontal line,
which would be no good.
Using hires on the main character, and chunky pixels on the enemy would look odd.
I've never liked that, when I see it in games.
Heres how the lead character Green Beret could possibly look using multi colour.
Using Black, Yellow and any 3rd colour seems the way to go.
Green - Lead character
Brown - Usual Enemy
Grey - Kung Fu Enemy
etc.
Given the choice between pink and yellow for skin colour, when it comes to Arcade games, Ive always prefer yellow over pink.
Based on the sprite from the Arcade game. He looks like a proper Green Beret, double 'ard ;)
|
| |
robozz
Registered: Oct 2003
Posts: 42 |
Interesting, I find the original sprite actually looks alot better than this new mockup. But maybe that is because I've never seen the arcade version. :)
If you're going to improve on a arcade->C64 conversion (graphic wise) why not select a game like 1942, Elevator Action or Gun Smoke instead... |
| |
algorithm
Registered: May 2002
Posts: 703 |
Quote: ok sounds like u have a plan. so when can we expect the initial alpha testrun?
Steve
I agree that gameplay is important. but in my opinion, it is not worth reinventing the wheel if everything looks similar
perhaps even interlaced sprites (flicker would be minimized if mixing colors with similar luma)
With the disk trackloading system and compression this should not be a problem |
| |
STE'86
Registered: Jul 2009
Posts: 274 |
well in all fairness the "arcade" sprite was just a de-res and auto recolour.
he could be retouched to something like this:
which is a quick lash up based on a cross between the arcade version posted and the late Joffa Smiths Spectrum version. whose sprites are admittedly closer to the arcade than the c64 ones.
anyway it does give a more "beefy" impression than the c64 ones.
Steve
|
| |
Wile Coyote
Account closed
Registered: Mar 2004
Posts: 646 |
well in all fairness the "arcade" sprite was just a de-res and auto recolor.
The arcade sprite was re sized in the x direction only, and from the 2 resulting lo-res frames (which could be interlaced) the better looking frame was used.
There was no auto recolor. Using my own judgement, I decided what pixels should be black, green or yellow.
I think the results work well.
The sprite you have designed deviates too much from the original for my liking. Black and Yellow as the 2 main colours works much better than pink. |
| |
STE'86
Registered: Jul 2009
Posts: 274 |
you actually think that works well?
honestly?
|
| |
algorithm
Registered: May 2002
Posts: 703 |
Quote: well in all fairness the "arcade" sprite was just a de-res and auto recolour.
he could be retouched to something like this:
which is a quick lash up based on a cross between the arcade version posted and the late Joffa Smiths Spectrum version. whose sprites are admittedly closer to the arcade than the c64 ones.
anyway it does give a more "beefy" impression than the c64 ones.
Steve
Now that looks great for a multicolor sprite. Perhaps interlaced sprites would be ok like i may have mentioned before. Flicker would not be that bad if similar intensities are mixed and would allow more players on screen etc |
| |
JCB
Account closed
Registered: Jun 2002
Posts: |
Quote: Now that looks great for a multicolor sprite. Perhaps interlaced sprites would be ok like i may have mentioned before. Flicker would not be that bad if similar intensities are mixed and would allow more players on screen etc
How would you envisage utilising interlaced sprites? If you're flickering between 2 different sprites how would you design all the graphics? They could be anywhere on the screen over any part of the background so which intensities would produce less flicker? I can understand it working ok with a bitmap where the adjacent pixels being similar intensity would reduce flicker between the 2 frames but not free moving sprites with unknown colours.
Personally I'd much rather see something like this ported to C64. It started out as a Green Beret ripoff from what Ste tells me and he's still got all the graphics ;)
Pete |
| |
algorithm
Registered: May 2002
Posts: 703 |
the two sprites which produce the image would be offset 1 hirespixel, hence would be designed (or converted) same was as those mcol lace pics etc. they can be moved anywhere on screen. Yes would be nightmare to draw from scratch, but can be converted to this type of mode
|
| |
JCB
Account closed
Registered: Jun 2002
Posts: |
Quote: the two sprites which produce the image would be offset 1 hirespixel, hence would be designed (or converted) same was as those mcol lace pics etc. they can be moved anywhere on screen. Yes would be nightmare to draw from scratch, but can be converted to this type of mode
I see what you're getting at now ;) When you said it would allow more players on screen I thought you meant more than there currently are but instead you're trying to enhance the resolution and just mean more than if they were hires overlaid?
Pete |
| |
NecroPolo
Registered: Jun 2009
Posts: 231 |
The effort of making the re-make is fully respectable.
If I may suggest, with this combined effort and attention on details, you would surely be able to create a vastly improved Green Beret II instead of Green Beret I re-make ;) |
| |
chatGPZ
Registered: Dec 2001
Posts: 11188 |
yeah, now turn the babble into code =P |
| |
iAN CooG
Registered: May 2002
Posts: 3145 |
while at it also Prince of Persia port, kthx! |
| |
Carlos
Account closed
Registered: Mar 2009
Posts: 15 |
Quote: The effort of making the re-make is fully respectable.
If I may suggest, with this combined effort and attention on details, you would surely be able to create a vastly improved Green Beret II instead of Green Beret I re-make ;)
yeah, i also think is a better idea to make a new 'green beret inspired' game than a remake of an existing one... |
| |
STE'86
Registered: Jul 2009
Posts: 274 |
well as u well know the POP sprites are done and dusted so any time u want to supply me with an email Ian then u can have a crack at it yourself.
or are u only up for sniping?
Steve |
| |
algorithm
Registered: May 2002
Posts: 703 |
Quote: I see what you're getting at now ;) When you said it would allow more players on screen I thought you meant more than there currently are but instead you're trying to enhance the resolution and just mean more than if they were hires overlaid?
Pete
Well. it also increases the amount of 'players' per line as there is no need for each character to use two sprites (overlaid on each other) 'blocky' max 8 sprites per line and with the interlace treatment. Ofcourse sprites will use twice the ram but no problem for a disk loader |
| |
JCB
Account closed
Registered: Jun 2002
Posts: |
But if you start trying to do 8 sprites per line then 8 beneath for their legs you'll quickly get into a lot of problems with timing interrupts etc. I suppose there are plenty of ways around that (the overlap/repeat data in next sprite trick for example).
It could do with (of course) some test code writing for this stuff and this is where it'll probably go nowhere. I know I'm too busy, if I finish what I'm doing I've got 100 other things on my list, I'm sure you and every other coder is the same..
Still, despite some moaners I like this kind of discussion, it's my favourite part of writing games (much better than the no sleep for days deadline crunches)
Pete |
| |
Wile Coyote
Account closed
Registered: Mar 2004
Posts: 646 |
As to not derail this thread, this thread should not mention:
Prince of Persia
Green Beret II or Green Beret the enhanced version ;)
The original idea was simply to recreate the original Arcade game as faithfully as possible on the C64, and make it better than the Imagine effort.
@STE'86 well in all fairness the "arcade" sprite was just a de-res and auto recolour.
The sprite represents on C64 a sprite that is half the resolution in the x direction of the original arcade sprite. No auto colour was used. Black Green Yellow were decided upon, and placed in position. The vibe from the sprite feels somehow correct. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11188 |
or Prince of Persia vs Green Beret ? could get interesting :o) |
| |
STE'86
Registered: Jul 2009
Posts: 274 |
Wile it needs a redraw.
the direct port and de-res does not work. believe me i am very aware of this from not too long ago having to do exactly the same to 250 odd frames of the PC POP sprites.
a simple halving of the horizontal only gets u so far. then u have to do some real work.
quite honestly i couldnt even tell if your sprite was carrying a weapon or just running without, so i guessed for my version.
by all means give it the once over to redefine it and prove me wrong but in its current form it only gives me the vibe of "errored data"
and i know you think that yellow works but it just makes horrendous colour clash to me and when u think just how much yellow would be on screen with all the other characters, it would, i guarantee, look like a real mess.
Steve |
| |
STE'86
Registered: Jul 2009
Posts: 274 |
heres my alpha run cycle.
done yours yet?
Steve |
| |
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: 210 |
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: 1154 |
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.
|
| |
algorithm
Registered: May 2002
Posts: 703 |
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: 1154 |
$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: 703 |
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: 210 |
@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: 11188 |
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 ^^ |
