STUNT CAR RACER?

[Mclaneinc]

 

"OT"... that means Old Timer, right? old timer.png

 

 

Yes and I have official Grumpy mug somewhere

[Heaven/TQA]

Mark told me that its 16bit.

[kiwilove]

OK - just because Stunt Car Racer has now been fully realised on this particular hardware - it doesn't necessarily mean that 3D games can be done also to as high a standard.

But that SCR worked because it had only certain elements present - like no other cars.

 

That for a fast enough frame rate - to incurr motion sickness - pseudo 3D graphics tend to be used - like in Encounter and other games.

The A8 hardware is simply not fast enough for a so-called 3D environment that has more than one object moving around. That's why in Mercenary - you have a very sparse landscape. I got a bit bored by it - because of it's sparseness and simplicity.

 

You can't ever expect to see "Star Wars" running in all it's 3D-ness on the A8 hardware - but the ST had the power to do it justice - with a high enough frame rate and responsiveness present.

 

Some 3D games can be done - like SCR has shown.

 

Harvey

Edited March 13, 2018 by kiwilove

[Heaven/TQA]

OK - just because Stunt Car Racer has now been fully realised on this particular hardware - it doesn't necessarily mean that 3D games can be done also to as high a standard.

But that SCR worked because it had only certain elements present - like no other cars.

 

That for a fast enough frame rate - to incurr motion sickness - pseudo 3D graphics tend to be used - like in Encounter and other games.

The A8 hardware is simply not fast enough for a so-called 3D environment that has more than one object moving around. That's why in Mercenary - you have a very sparse landscape. I got a bit bored by it - because of it's sparseness and simplicity.

 

You can't ever expect to see "Star Wars" running in all it's 3D-ness on the A8 hardware - but the ST had the power to do it justice - with a high enough frame rate and responsiveness present.

 

Some 3D games can be done - like SCR has shown.

 

Harvey

 

Rescue on Fractalus, Koronis Rift, Eidolon, Battle Zone, Star Raiders are not not pseudo-3d... e.g. for me pseudo-3d is Chrystal Castle, Rainbow Walker, Alternate Reality, Q-Bert, ...)

 

Is Spindizzy 3d or pseudo-3d? I would tend to say more 3d than speudo. Pseudo means for me "3d baked into gfx" no 3d calcs etc. and yes... Yoomp falls into category "not 3d".

and SCR has 2 cars I tend to say that SCR has "most 3d" implemented... plus Physics. (complete pipleline means world 3d coords, rotation/translation, persp trans, clipping, drawing and filling, in x,y,z). while Rescue on Fractalus et all except for Mercenary cheat here and there.

Edited March 13, 2018 by Heaven/TQA

[Rybags]

It'd be over flattering to even call it pseudo 3D. There's occlusion and that's about it. No sprite scaling due to distance either.

IMO an isometric game doesn't deserve to be called 3D.

 

A proper "pseudo 3D" game at the least should have some sort of distance based scaling of objects and game world.

[Heaven/TQA]

so Space Harrier/Pole Position = Speudo-3d while Spindizzy not? even Spindizzy has 3 axis movement and "free" 90 deg rotation?

 

Capture the flag / Way Out?

Edited March 13, 2018 by Heaven/TQA

[Rybags]

Rotation? I've just checked a YT video, it seems to be a flip-screen from one to the next room with the player "top" or whatever it is spinning as it moves around.

 

Pole Position, not even 2.5D really.

The technique in use is fairly well known and was common for the first half of the 1980s. In essense just a static image like / | \ with scroll and colour tricks to create the illusion of movement. Signs and other cars seperate objects with scaling tricks thrown in.

 

Capture the Flag I would suspect to use proper raycasting.

 

The problem with the term "3D" is the liberal usage, even today.

It's all too often applied to attempt to give the product more prestige and technical merit than it's due.

Edited March 13, 2018 by Rybags

[Heaven/TQA]

Spndizzy has rotation as you can turn around to watch the scene... not freely but you can... player moves in x,y,z so in my term it's 3d... not Yoomp.

[Rybags]

Changing the point of view, and it's just a flipscreen from one to the next. I'd not call it 3D. Nice innovation but obviously required for that game.

[Mclaneinc]

Are we not nitpicking as to what is perceived as 3D and the actual mechanics of how the 3D style effect is achieved or if it is classed as real 3D.

 

I say it because for the most part none of really care how its done or what fake or real method was used, so unless the chat will somehow invent new ways to do these effects it all seems rather pointless?

 

We seem to doing a game by game breakdown on how its done which apart from being a bit tedious for some is also taking time away from doing something possibly more creative with your time

 

SCR plays well, do I give a monkies how its done, not really, I'm just glad they did it so well

Edited March 13, 2018 by Mclaneinc

[VladR]

OK - just because Stunt Car Racer has now been fully realised on this particular hardware - it doesn't necessarily mean that 3D games can be done also to as high a standard

Why ? Because you have a vague feeling about it? How about being just a tiny little bit more technical ? Why don't we rephrase the question into something more concrete, we can actually work with ?

- Framerate is directly dependent on cycles consumed by CPU.

- Let's use resolution 160x96x4 with bigger, but nicely rectangular pixels

 

- After Antic takes its toll, we have 24,186 cycles available per frame. So, if we can fit whole code under 24k, we can run at 60 fps. Burn ~28k cycles and you're at 30 fps. Burn ~96k cycles and it's 15 fps. And so on.

- Of course, due to the nature of 3D, each rendered frame costs different amount of cycles

- SCR showed that even if the game runs at ~7 fps, it's still OK. So, that's about (60/7)*24,186 = 207,308 cycles per frame

 

- Now we have something concrete: We have a budget of 200,000 cycles per rendered frame.

- Ever had to do a grocery shopping a week before the paycheck without credit cards ? Same thing. Gotta fit within the budget

- Here's some shopping items we are considering:

• 15,400c: [per rendered frame] ClearScreen
• 179c: [per vertex] Transform the 3D Vertex into 2D coordinate (using a table)
• 54c: [per pixel] Average cost of drawing single pixel of the line (not even unrolled code, averaged across 500 px of all possible lines (say, filling a test rectangle)).
• 190c: [per line] Computing Fixed-point coefficients for line drawing
• 125c: [per line] DLI: bringing new colors on screen

 

There's obviously more (culling, clipping, ...), but then this post would be 3 pages long. Based on the above, you can now choose the 3D scene complexity, namely:

- number of vertices/polygons/lines

- number of pixels drawn

 

Last week I've been doing experiments with my 6502 flatshader, and I'm pretty sure I can do the SCR's 4 track segments (average: 12 lines , 400 pixels) under 48,000 cycles. Which is 30 fps. I'm still working on the 8-bit transform&clip. But all the clearing&rendering takes ~30,000 cycles now. So I still got a buffer of 48,000 - 30,000 = 18,000 for the transform&clip&line coefficients.

 

Of course, game&physics will burn some cycles. So, if we did a game without expensive physics (so, definitely not like SCR), and burn only another 24,000c (for everything else - audio,input,hud), it could run around 20 fps. Hence why I say that StunRunner is possible (as the physics there is very simple, compared to SCR).

 

You can't ever expect to see "Star Wars" running in all it's 3D-ness on the A8 hardware - but the ST had the power to do it justice - with a high enough frame rate and responsiveness present.

Very bad example

That Arcade Star Wars has mostly vertical lines (that you can unroll nicely for a significant speed boost), and about 6 generic diagonal lines. Use the table above and you can render the environment easily under 100,000 cycles.

The TieFighters would be more taxing, yes.

 

It should still fit nicely under 200,000 cycles.

[emkay]

Some 3D games can be done - like SCR has shown.

SCR is done on the C64 tricking around the rather slow CPU. Handling the character mode is also very time consuming. The Atari has the better modes for 3D .

Mercenary, well, if coders need pr0n, they may play such interactive slideshows.

A good game had to be build on a "perfect" demonstration and the right degree of interactivity.

It's not to understand, why people always try to deny the double scanline mode of the Atari. Most games up to the late 90s showed 160x100 at higher color resolution, but the main calculated resolution was 160x100.

Which games do we know yet, using "160x100" resolution and did very well?

 

GYRUSS for example.

Starraiders (1979)

Space Harrier

Yoomp!

 

 

Particular Space Harrier shows what could be done, if the double scanline mode is used well: Lot's of moving objects. Full DLI animations, digitized speech...

Actually, Wolf 3D would need less. Nobody cares of the "lower" resolution, if the sreen is shaking by gaming action.

Oh, well, except C64 people who prefer motionless hires pictures. So let them stare on their weird colored hires pictures and let the action start on the A8

[zzip]

 

Is Spindizzy 3d or pseudo-3d? I would tend to say more 3d than speudo. Pseudo means for me "3d baked into gfx" no 3d calcs etc. and yes... Yoomp falls into category "not 3d".

and SCR has 2 cars I tend to say that SCR has "most 3d" implemented... plus Physics. (complete pipleline means world 3d coords, rotation/translation, persp trans, clipping, drawing and filling, in x,y,z). while Rescue on Fractalus et all except for Mercenary cheat here and there.

 

Spindizzy is isometric. Looks 3D, but really isn't at all. It's 2D sprite and bitmap projected onto a 3D looking playfield.

[Heaven/TQA]

 

Spindizzy is isometric. Looks 3D, but really isn't at all. It's 2D sprite and bitmap projected onto a 3D looking playfield.

3d = 3 dimensional... if you would render the sprite as faces/vertices? Instead of sprite?

 

The game works in x,y, z axis = 3 dimensions = 3d.... sort of...

 

And please dont argue with me what is 3d as I coded 3d engines on 6502

 

What about Arsantica 3 Voxel space? What if I tell you that there is no 3d envolved on the 6502 side? Psst but dont tell anybody.

Edited March 13, 2018 by Heaven/TQA

[Heaven/TQA]

SCR is done on the C64 tricking around the rather slow CPU. Handling the character mode is also very time consuming. The Atari has the better modes for 3D .

Mercenary, well, if coders need pr0n, they may play such interactive slideshows.

A good game had to be build on a "perfect" demonstration and the right degree of interactivity.

It's not to understand, why people always try to deny the double scanline mode of the Atari. Most games up to the late 90s showed 160x100 at higher color resolution, but the main calculated resolution was 160x100.

Which games do we know yet, using "160x100" resolution and did very well?

 

GYRUSS for example.

Starraiders (1979)

Space Harrier

Yoomp!

 

 

Particular Space Harrier shows what could be done, if the double scanline mode is used well: Lot's of moving objects. Full DLI animations, digitized speech...

Actually, Wolf 3D would need less. Nobody cares of the "lower" resolution, if the sreen is shaking by gaming action.

Oh, well, except C64 people who prefer motionless hires pictures. So let them stare on their weird colored hires pictures and let the action start on the A8

I like 160x96 but dont underestimate char mode...

 

With one poke (STA) you can set 64 pixels in 4 cycles... thats impossible in any bitmap mode.

[+MrFish]

...IMO an isometric game doesn't deserve to be called 3D.

 

A proper "pseudo 3D" game at the least should have some sort of distance based scaling of objects and game world.

 

Spindizzy is isometric. Looks 3D, but really isn't at all. It's 2D sprite and bitmap projected onto a 3D looking playfield.

 

Isometric is definitely 3D. It just uses parallel projection as opposed to perspective projection.

 

Now if you're talking about how they achieved it, that's another subject. But frankly, if the final result looks how it's supposed to, it doesn't matter.

Edited March 13, 2018 by MrFish

[emkay]

I like 160x96 but dont underestimate char mode...

 

With one poke (STA) you can set 64 pixels in 4 cycles... thats impossible in any bitmap mode.

But you have to sort the screen memory + the character memory....

 

in 160x100 , you can set 8 pixels on the screen with one sta, no additional quirk calculations needed.

Also, the saved CPU cycles allow faster 3D calculations.

[emkay]

Isometric is definitely 3D. It just uses parallel projection as opposed to perspective projection.

 

Now if you're talking about how they achieved it, that's another subject. But frankly, if the final result looks how it's supposed to, it doesn't matter.

Depending on the gameplay, it is 3D as soon as 3 dimensions take part . Iso 3D is more into "real 3D" action and reaction.

The contrary part is DooM, which seems to be full 3D in presentation, but only 2D operation is used for the level design.

 

And, how Yoomp! could work without the 3D presentation , could be approved by people who claim that Yoomp! isn't 3D.

[Heaven/TQA]

Depending on the gameplay, it is 3D as soon as 3 dimensions take part . Iso 3D is more into "real 3D" action and reaction.

The contrary part is DooM, which seems to be full 3D in presentation, but only 2D operation is used for the level design.

 

And, how Yoomp! could work without the 3D presentation , could be approved by people who claim that Yoomp! isn't 3D.

http://a8.fandal.cz/detail.php?files_id=6110

 

In 2d.... BTW the C64 version is not so bad of yoomp which gets released soon.

[Heaven/TQA]

But you have to sort the screen memory + the character memory....

 

in 160x100 , you can set 8 pixels on the screen with one sta, no additional quirk calculations needed.

Also, the saved CPU cycles allow faster 3D calculations.

 

yeah but clear screen, filling polygon etc are far faster in charmode if done right... see SCR.

 

simple example

 

clear screen in charmode

 

40x25 = 1000 bytes

 

clearing 160x100 = 160 div 4= 40*100 = 4000 bytes = 4x more...

 

another "trick" avoiding "quirk" calculations...

 

unrolling code then layout doesnt matter... or using an EOR filler which takes a custom screen layout and "print it on screen" etc... plenty of ways to avoid nasty pixel adressing...

 

of course best is linear bitmap... but other layouts are not bad either.....

Edited March 13, 2018 by Heaven/TQA

[emkay]

yeah but clear screen, filling polygon etc are far faster in charmode if done right... see SCR.

There is no real evidence. The Atari version uses that solution and does it faster by the 30% of more CPU.

If the screen handling was optimized to fill the screen in byte boundaries, it will take 4 times more by calculations, but not all parts would need to be cleared, by special routines.

Btw. have you recognized that the "hills" were much smaller than on the Amiga version? On the Atari, and using the double scanline mode, the correct size was directly possible. The Character mode doesn't show all what's needed for the correct 3D presentation. You see that in every C64 game, where the presented pixels might get up to 320x200 resolution, but the "resolution by feeling" is mainly 40x25. The exception is somehow SCR . The game acts more fluent than 40x25 but also is too slow on the C64 to have gaming fun.

[zzip]

3d = 3 dimensional... if you would render the sprite as faces/vertices? Instead of sprite?

 

The game works in x,y, z axis = 3 dimensions = 3d.... sort of...

 

And please dont argue with me what is 3d as I coded 3d engines on 6502

 

What about Arsantica 3 Voxel space? What if I tell you that there is no 3d envolved on the 6502 side? Psst but dont tell anybody.

 

And I've coded isometric engines. It's a completely different set of issues from a 3D engine.

 

If you spin an object in an isometric engine, does the engine compute the different angles? No! You have to provide bitmaps for all sides.

 

Do the objects get larger as they get closer? No

 

Is the nearest part of the playfield rendered larger than than the most distant part for accurate perspective? No! All tiles on the Isometric playfield look the same size no matter how far away they are.

 

Can you rotate the camera a full 360 degrees on an isometric playfield? No! If you are lucky, sometimes you can view it from 4 different angles like spindizzy, but many iso games don't even allow that much.

 

You can't do any of this because it's not real 3D at all. It's a 2D-tile based projected in a way to look 3D. Not that there's anything wrong with that, for a long time 3D games looked like crap, and isometric engines looked much better because they have much lower processing requirements.

[Heaven/TQA]

 

And I've coded isometric engines. It's a completely different set of issues from a 3D engine.

 

If you spin an object in an isometric engine, does the engine compute the different angles? No! You have to provide bitmaps for all sides.

 

Do the objects get larger as they get closer? No

 

Is the nearest part of the playfield rendered larger than than the most distant part for accurate perspective? No! All tiles on the Isometric playfield look the same size no matter how far away they are.

 

Can you rotate the camera a full 360 degrees on an isometric playfield? No! If you are lucky, sometimes you can view it from 4 different angles like spindizzy, but many iso games don't even allow that much.

 

You can't do any of this because it's not real 3D at all. It's a 2D-tile based projected in a way to look 3D. Not that there's anything wrong with that, for a long time 3D games looked like crap, and isometric engines looked much better because they have much lower processing requirements.

 

 

yeah I coded iso, too... so dont get me wrong, too. I know how much "3d" iso games are (mainly 0%)... but all started with "Yoomp" being a 3d game and it is not. but what emkay states correctly is that for a "player" it might feel like 3d even the engine itself is "not" 3d in academic coding sense...what I wanted to point out... spindizzy player moves in 3 axis... and 3 axis so ppl might say under that definition... it is 3d...and you can not deny that you can turn the camera/viewpoint in 90 deg steps... wether you deliver prerendered tiles or you would calc the tiles on the fly...

 

is Zaxxon 3d? nope... but some sort of yes... (up/down/left/right/front/back)....

[Heaven/TQA]

There is no real evidence. The Atari version uses that solution and does it faster by the 30% of more CPU.

If the screen handling was optimized to fill the screen in byte boundaries, it will take 4 times more by calculations, but not all parts would need to be cleared, by special routines.

Btw. have you recognized that the "hills" were much smaller than on the Amiga version? On the Atari, and using the double scanline mode, the correct size was directly possible. The Character mode doesn't show all what's needed for the correct 3D presentation. You see that in every C64 game, where the presented pixels might get up to 320x200 resolution, but the "resolution by feeling" is mainly 40x25. The exception is somehow SCR . The game acts more fluent than 40x25 but also is too slow on the C64 to have gaming fun.

 

i only stated that char mode is not that bad... and has it's advantages even in mimic bitmap...

[emkay]

Can you rotate the camera a full 360 degrees on an isometric playfield? No!

That is nitpicking...

How many games of today do real 3D calculations? Please name some.

 

If you are lucky, sometimes you can view it from 4 different angles like spindizzy, but many iso games don't even allow that ...

In Starraiders you can rotate the camera in x, y - axis while flying the z-axis. But the Objects were simple 2D.

Is it 3D or not?