Eliminator

[Thorsten Günther]

I'd put the status bars above or below the action screen instead of using PM graphics for that (if I could program, that is), using GR. 0 mode so the player can actually distinguish weapons .

 

But watching this game, I can not understand why so few games using these pseudo 3D effects were published on the A8 (Ballblazer, Trailblazer, Encounter, Dimension X, Pole Position and some other racing games being the most prominent ones, but Pole Position's effect being the most convincing one among the racers), as the A8 hardware actually seems ideal for this kind of game - moving the horizon by altering the Display List and creating the speed effect by DLI colour cycling.

 

Thorsten

Edited August 3, 2011 by Thorsten Günther

[emkay]

But watching this game, I can not understand why so few games using these pseudo 3D effects were published on the A8 (Ballblazer, Trailblazer, Encounter, Dimension X, Pole Position and some other racing games being the most prominent ones, but Pole Position's effect being the most convincing one among the racers), as the A8 hardware actually seems ideal for this kind of game - moving the horizon by altering the Display List and creating the speed effect by DLI colour cycling.

 

 

The problem is, you cannot add software generated objects then without big troubles, because the framebuffer is changing continously. And the A8 has limited options for hardware generated objects.

 

The double scanline mode still has it's "foes" , but it is the best choice for having games with big counts of software generated moving objects at a high framerate.

It's THAT fast, you can draw many things faster than to manipulate the Display List.

[sack-c0s]

 

It's THAT fast, you can draw many things faster than to manipulate the Display List.

 

Really?

 

I would've thought the loads/stores alone would outweigh the logic needed to manipulate the DLIs - and that's before taking into account the logic that needs to be wrapped around it.

[sack-c0s]

<duplicate - removed>

Edited August 4, 2011 by sack-c0s

[popmilo]

Just checked C64 version with ICU64 debugger:

 

2 bitmap screens (for double buffering probably).

Sidebar status and central "track" (road) are simple bitmap.

That explains every second line used (50% less cpu time for road animation).

Even the "chessboard" effect is done with "drawing" 2 colors - no raster color changes used.

 

All the other objects are sprites.

 

As someone else said - could have been much, much better...

 

For C64 "proper" way would be with character based road (different characters depending on road direction and height) + raster color changes for changing colors.

 

For A8 - just look what yoomp did.

Eliminator has roughly 4 times less road surface to draw and much simpler patterns.

That would leave plenty of time for software sprites.

[emkay]

Just checked C64 version with ICU64 debugger:

 

2 bitmap screens (for double buffering probably).

Sidebar status and central "track" (road) are simple bitmap.

That explains every second line used (50% less cpu time for road animation).

Even the "chessboard" effect is done with "drawing" 2 colors - no raster color changes used.

 

 

That's exactly how it looks.

 

All the other objects are sprites.

 

As someone else said - could have been much, much better...

 

For C64 "proper" way would be with character based road (different characters depending on road direction and height) + raster color changes for changing colors.

 

And changing the movement resolution from 160x100 to 40x25?

 

 

For A8 - just look what yoomp did.

Eliminator has roughly 4 times less road surface to draw and much simpler patterns.

That would leave plenty of time for software sprites.

 

Yoomp! was done in 32 byte mode. Not needed for Eliminator. Possibly we could go a slight different way than my proposed one. Which means to use the playfield Gfx for the road AND the Status "pillars" . Just using PM for colour enhancements, and/or for shots and some enemies.

The "good impression" at the 2 scanline mode, comes with fullscreen usage, and adjusted gfx..

[Heaven/TQA]

MK... using charmode means that all possible road positions are stored as chars... so no time consuming bitmap calculations on c64 needed but char mode would be better to use... so everything would be faster for the 0,9 MHz CPU... that's what Popmilo thinks I guess... the resolution would be the same 160x... just simulated bitmap mode in char mode...

[popmilo]

MK... using charmode means that all possible road positions are stored as chars... so no time consuming bitmap calculations on c64 needed but char mode would be better to use... so everything would be faster for the 0,9 MHz CPU... that's what Popmilo thinks I guess... the resolution would be the same 160x... just simulated bitmap mode in char mode...

Yes, that is what I think

 

With few character sets you can achieve very fine (160pix) animation of the road curvature.

Vertical color changes are at 1 line resolution.

 

Same can be applied for A8 also. (maybe with few more charsets, but that is no problem with few LMSs).

 

But no need I think - better stick to bitmap mode and DLIs for vertical color changes.

Background black.

2 colors for the road ("even - odd" fields on chess pattern).

1 color left for highlighting sprites.

 

With PM underlayed we could make "black - PM color - highlight color" sprites.

 

2x2 or 2x1 depending on cpu time.

 

Yoomp rendering method gives much more detail for road texture.

But the geometry of road is kinda fixed.

It takes roughly 20k for yoomp renderer. And since it uses same renderer for upper and lower half of screen, it means that it needs 20k for that lower half of screen ~ 1500 pixels (2x2).

 

Similar renderer with different geometry could handle smaller rectangle area in lower part of screen to produce "textured road" effect.

Maybe even in Gtia modes with more colors...

Left-right movement yes, but no rotation thou... that would be too much...

 

Again - real code would give us enough info...

 

Ahhh... I guess this one goes on bottom of "ideas for a new A8 game list"

[emkay]

MK... using charmode means that all possible road positions are stored as chars... so no time consuming bitmap calculations on c64 needed but char mode would be better to use... so everything would be faster for the 0,9 MHz CPU... that's what Popmilo thinks I guess... the resolution would be the same 160x... just simulated bitmap mode in char mode...

 

 

???

 

Chessboard/Variations + 4 different positions in one char + different sizes ? I guess, even the sorting routine for all possibilies gets slower than to simple draw a line every 2nd scanline.

 

Well, we know how this will end.

In the "available" Eliminator on the C64 , the view of depth isn't 100% yet, but it's ok.

In no game on the C64 with char animations the view of depth is anyhow ok. It's crap. Non correct zooming of the objects, tearing.... and so on. You have to be a fan of the C64 to think it's ok.

[sack-c0s]

MK... using charmode means that all possible road positions are stored as chars... so no time consuming bitmap calculations on c64 needed but char mode would be better to use... so everything would be faster for the 0,9 MHz CPU... that's what Popmilo thinks I guess... the resolution would be the same 160x... just simulated bitmap mode in char mode...

 

and any objects on the road could be built from sprites. What I'd also look at doing is putting the logic that handles the object/game movement into the raster interrupt and having the road in the free-running loop, so even if the framerate of the road does have to drop then the motion of the objects on the road and the logic would still run fixed at 50hz so the game would be unaffected and it'd be less obvious.

[Heaven/TQA]

anything less then 50 FPS would be bad... how fast are Amiga running?

[sack-c0s]

anything less then 50 FPS would be bad... how fast are Amiga running?

 

it looks a bit clunky on the Amiga too - which is rubbish really because the Amiga is ideal for this - it's a bloody A8 with extra CPU horsepower and extra hardware that solves precisely the problems being discussed here. I first thought it was the youtube encoiding letting it down, but the colour cycling on the intro screen looks perfectly smooth so that probably rules it out.

 

If I was doing the Amiga version I'd use 2 playfields:

the back playfield would be the road/sky. Everything would be on a 2 screen wide bitmap of 3 planes (2 planes to give the road colours, 1 to overdraw tunnel entrances/walls/etc. it would need *no bitmap manipulation whatsoever because you could just set the scroll registers and screen address pointers on a line-by-line basis and reload the palette from the copper program.

 

the front playfield would be double buffered and used for blitting the moving objects to it.

 

what I'm guessing *really* happened was they took the ST code, altered the hardware specific parts and did a lazy port job.

[Heaven/TQA]

yeah, piece of cake for Copper & Agnus. you could even use Blitter to draw the road... and the ST would be fast enough, too. there is no "high fency" code for the game imho...

 

sprites are prescaled anyway... and there are not many on screen either... I can not understand why they even used the checkboard as gfx instead of using rasters... but maybe because the code went too complicated?

[sack-c0s]

 

Chessboard/Variations + 4 different positions in one char + different sizes ? I guess, even the sorting routine for all possibilies gets slower than to simple draw a line every 2nd scanline.

 

Well, we know how this will end.

In the "available" Eliminator on the C64 , the view of depth isn't 100% yet, but it's ok.

In no game on the C64 with char animations the view of depth is anyhow ok. It's crap. Non correct zooming of the objects, tearing.... and so on. You have to be a fan of the C64 to think it's ok.

 

I thought the original point is it isn't 'okay'. The game is absent on the Atari and could be a lot better on the C64. You might look down on people talking compromises but if you think you can get something on either machine without doing that then you're just naive and destined to end up with a folder full of theoretical screenshots and nothing more. It'll never be perfect on either machine but we're just looking at the best set of compromises to make for each machine to get the best out of it you can under the circumstances.

 

You don't like the C64 - we get it. I like the A8 and the C64 and have no problems discussing both machines at the same time, there will always be references between the two in any discussion due to architectural similarities. It's 2011 and machines are fairly cheap and plentiful - grab yourself a bloody C64 from ebay, set it up next to (or behind if it makes you feel better) your Atari and relax fer chrissakes.

[emkay]

 

 

I thought the original point is it isn't 'okay'.

 

 

The game is slow and doesn't play as it is supposed for that game.

And, I wrote the depth of view is OK. As it seems, it is one point you won't get....

 

You don't like the C64 - we get it.

 

 

.... as so many other points....

[emkay]

yeah, piece of cake for Copper & Agnus. you could even use Blitter to draw the road... and the ST would be fast enough, too. there is no "high fency" code for the game imho...

 

sprites are prescaled anyway... and there are not many on screen either... I can not understand why they even used the checkboard as gfx instead of using rasters... but maybe because the code went too complicated?

 

Less than 1MHz. You can only exchange precision for speed. I guess, the coder wanted to have the best precision for the depth movement, which is not reachable when using Charmode/Raster tricks.

[Heaven/TQA]

yeah, piece of cake for Copper & Agnus. you could even use Blitter to draw the road... and the ST would be fast enough, too. there is no "high fency" code for the game imho...

 

sprites are prescaled anyway... and there are not many on screen either... I can not understand why they even used the checkboard as gfx instead of using rasters... but maybe because the code went too complicated?

 

Less than 1MHz. You can only exchange precision for speed. I guess, the coder wanted to have the best precision for the depth movement, which is not reachable when using Charmode/Raster tricks.

 

we will see...

[popmilo]

...

Less than 1MHz. You can only exchange precision for speed. I guess, the coder wanted to have the best precision for the depth movement, which is not reachable when using Charmode/Raster tricks.

 

we will see...

 

Is that a promise of something new ?

[dmlloyd]

Still I think using PMG for the "road surface" might be a good idea. You could simply rotate between 4 to 8 PMBASE values to animate the road surface, and use the horizontal position registers + DLI to create the curve, and simply use software sprites for the rest. The most complex calculations are drawing software sprites - easy if you stick to lower resolution but still doable even in e.g. $E probably, even easier if you use $4 though it might not look as smooth - and curving the road which occupies some of your display time. But I bet it could be done pretty well even on 60Hz systems.