Log inRegister an accountBrowse CSDbHelp & documentationFacts & StatisticsThe forumsAvailable RSS-feeds on CSDbSupport CSDb Commodore 64 Scene Database
You are not logged in - nap
CSDb User Forums


Forums > CSDb Discussions > Green Beret - Is any interested in..
2010-07-31 17:06
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....
 
2010-08-08 22:09
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
2010-08-10 06:13
Wile Coyote
Account closed

Registered: Mar 2004
Posts: 646
@STE’86
I’m 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 original’s playability.
2010-08-10 08:10
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.
2010-08-10 11:50
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
2010-08-10 19:01
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.

2010-08-10 19:07
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.
2010-08-10 19:27
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.
2010-08-10 19:39
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
2010-08-10 20:15
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 !
2010-08-10 20:16
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.
Previous - 1 | 2 | 3 | 4 | 5 | 6 | 7 - Next
RefreshSubscribe to this thread:

You need to be logged in to post in the forum.

Search the forum:
Search   for   in  
All times are CET.
Search CSDb
Advanced
Users Online
bugjam
obliterator918/Strate
Magic/Nah-Kolor
E$G/HF ⭐ 7
Krill/Plush
Guests online: 78
Top Demos
1 Next Level  (9.7)
2 13:37  (9.7)
3 Mojo  (9.7)
4 Coma Light 13  (9.7)
5 Edge of Disgrace  (9.7)
6 Uncensored  (9.6)
7 Comaland 100%  (9.6)
8 No Bounds  (9.6)
9 Wonderland XIV  (9.6)
10 Bromance  (9.5)
Top onefile Demos
1 Layers  (9.6)
2 Cubic Dream  (9.6)
3 Party Elk 2  (9.6)
4 Copper Booze  (9.6)
5 Rainbow Connection  (9.5)
6 It's More Fun to Com..  (9.5)
7 Dawnfall V1.1  (9.5)
8 Onscreen 5k  (9.5)
9 Morph  (9.5)
10 Quadrants  (9.5)
Top Groups
1 Nostalgia  (9.4)
2 Oxyron  (9.3)
3 Booze Design  (9.3)
4 Censor Design  (9.3)
5 Offence  (9.3)
Top NTSC-Fixers
1 Pudwerx  (10)
2 Booze  (9.7)
3 Stormbringer  (9.7)
4 Fungus  (9.6)
5 Grim Reaper  (9.3)

Home - Disclaimer
Copyright © No Name 2001-2024
Page generated in: 0.039 sec.