Hard Drivin’ on the 8 Bits?

[Gunstar]

Yep, not that much faster:

Whose to say that game couldn't be faster and smoother with further optimization or starting from scratch with another 3D game engine in that resolution, considering all the advanced development tools programmers have to day that they didn't have back then,. Also less restrictions on more base memory and extended memory. Couldn't a lot of the math be predetermined in look-up tables instead of calculating it all in real time too? Given extra memory to store all the data?

 

On a slightly related note, has anyone ever compared 3D games like Domark's Star Wars or Novegen's Mercenary or other 3D games on the Atari with standard OS's and custom OS's with faster floating point routines? Would that effect this type of math calculations?

 

And is that a PAL machine the game is running on in that video? I would assume so since Domark's Star Wars was released in PAL territory only, because Parker Brothers had the license for Star Wars Arcade in the U.S at least, and released that really shitty version. Will Domark's version run on a standard NTSC machine, and if so, is there a significant speed increase? I don't remember if it was any faster when I had an NTSC 1200XL with a PAL Antic in it for compatibility, running at 60Hz. I've had my 1200XL fully converted to PAL for a couple of years now, and have long since gotten used to the speed impact and the "squashed" PAL screen when over-scan isn't used...I'm expecting to be pleasantly surprised at the speed increase of compatible games once I get my other NTSC only 1200XL up and running again. Of course it will have Rapidus installed in it, so 50/60Hz speed change will be a moot point with compatible 3D games.

Edited October 16, 2018 by Gunstar

[emkay]

Yep, not that much faster:

 

Particular the animation of the "Death Star zoom" is about 3-4 fps on the C64 and 8-10 fps on the Atari, while the game controls still work.

Also, people shouldn't compare apples with pears.

There is a lot going on, on the screen. Different moving objects using different directions, different collision detections.... and so on.

A 3D projection game, has all polygons in a depending environment.

Also, using grids instead of filled polygons, doesn't help much

It's better to use filled polygons, when you create the lane.

 

And, well, if Hard Drivin' isn't fun, how about 4D Sports Driving ?

 

 

And, btw. , not sure how to help people who would activate PM DMA for raw objects , like bridge pillars

... or even some colored fields.

Yes, it would need some additional code, every frame, but drawing costs CPU time aswell ...

[R0ger]

On a slightly related note, has anyone ever compared 3D games like Domark's Star Wars or Novegen's Mercenary or other 3D games on the Atari with standard OS's and custom OS's with faster floating point routines? Would that effect this type of math calculations?

 

 

I'm quite sure none of these games use floating point routines from ROM. They typically use their own very specific format of numbers, or do not use floating point numbers at all (my engine for example). You need your math waaay faster than what ROM can do, on the other hand you don't need the precision of those routines.

[EnderDude]

What about using an overclocked CPU? Like, you can use one that's at 21 Mhz?

Edited October 17, 2018 by EnderDude

[Wrathchild]

Easier to use UNO Cart as a co-processor

[R0ger]

Or what the hell, just play the new Forza game, it's good

[Wrathchild]

I've only just got Dirt Rally and then only 'cause it was on sale on Steam

Maybe Speed Run should be done properly

[EnderDude]

Also, is filling in a polygon expensive with cycles? Just look at Leaderboard that is incredibly slow on the Atari, Spectrum, C64, CPC, etc. But, hey, that might just be another example of inefficient coding...

Edited October 17, 2018 by EnderDude

[Level42]

Yep, not that much faster:

 

Another pointless conversion....sorry ....but having owned the Star Wars Cockpit arcade machine.......this even doesn't deliver 5% of the fun of the game.....

[R0ger]

Depends .. in some specific cases it can be done real fast. In totally free 3D, where you have to overwrite the background, and you have to basically draw several layers to get the final image, it's pretty slow. I mean compared to wire frame. And mind, most of the wire frame games are pretty slow as they are.

As I said .. filled polygons are imho appropriate technology for 16 bit computers. For 8bits go wire frame.

[pseudografx]

I don't mind using wireframe on 8-bit. But at least hidden lines removal would be a nice "upgrade". But that is also quite expensive on CPU cycles.

[_The Doctor__]

Depends .. in some specific cases it can be done real fast. In totally free 3D, where you have to overwrite the background, and you have to basically draw several layers to get the final image, it's pretty slow. I mean compared to wire frame. And mind, most of the wire frame games are pretty slow as they are.

As I said .. filled polygons are imho appropriate technology for 16 bit computers. For 8bits go wire frame.

if you have the room, an unused player or missile could be used to mask some stuff or act as a fill for an object or two... a mix of the technology so to speak. Only fill/shade or mask the targeted item. all others could stay lines or poorly rendered. This is the case for targeting computers. why not continue the proud tradition in our games. but only if speed isn't terrible in that case either!

Edited October 17, 2018 by _The Doctor__

[emkay]

Seeing, what's the usual prod , and what people expect...

 

Do you know an other platform than the 8 bit Atari sharing this huge gap?

 

[EnderDude]

Okay, this looks a bit more promising.

[Lost Dragon]

Okay, this looks a bit more promising.

Ahhh the work of the very talented Nick Pelling.

 

A man who didn't let limited hardware obscure his vision of doing 3D on it:

 

 

 

Fast multiplication on the Game Boy!

You say: what are you talking about, Nick? The Game Boy (or even the Game Boy Color) wasn't designed to do anything fast?

 

To which I reply: when Dave Leitch & I were programming our "3D Pocket Pool" game ("3D Pool Allstars" in the US, for obvious reasons), we needed fast maths routines - so I had to come up with some. It didn't matter whether it was possible or not. :-) So here's what I devised...

 

Firstly, I don't think I'm breaking my Nintendo NDA by saying that the GB/GBC is powered by a low-power Z80 clone with the complex instructions taken out, but with other useful ops put in their place (any emulator site would tell you this). However, my solution didn't end up using any of the new instructions, so I don't feel too bad about posting my code openly. That's only relevant so I don't get emails saying "Hey Nick, why didn't you use LD HL,DE?"... it's because the GB doesn't have it. :-)

 

Anyway... overall, my approach to the problem was to figure out what the bare minimum set of instructions for any given multiply would be, and then try to achieve that. Also: because speed was so critical our title, my design aim was to fit it into the lowest (permanently banked in) ROM bank, so 16K was the upper size constraint... any solution I could construct in that space was fair game. :-)

 

In the end, though, I have to say that I created a monster of a routine. If you're expecting a petite 50-line masterpiece, look away now.

 

The code multiplies an 8-bit unsigned char (A) with a 16-bit unsigned short (DE), and here's how it begins:

 

Stage 1: build (from A) an offset (in HL) into a 256-element table, where each element holds up to 8 bytes of code. To avoid unnecessary shifts, the H and L values are simply masked from the A-value - so this isn't a simple "multiply by 8", it's also changing the order of the 256 elements, in a way which the table itself will have to be inversely ordered around. But it saves several run-time cycles for no actual cost, so I like this trick a lot. :-)

 

ld h,a

and $f8

ld l,a

xor h

 

Stage 2: add the start of the table into H, and set B = A = 0 (which many of the routines will rely on):

 

add a,>multiplyjumptable

ld h,a

xor a

ld b,a

 

Stage 3: jump directly to the appropriate code fragment - get on with it!

 

jp (hl)

 

All each of the 256 code fragments then needs to do is to multiply DE by a single fixed value: though I optimised most of these routines quite closely, there were (IIRC) a handful that could have been further tweaked - but I'd had quite enough of this accursed routine by that stage. :-)

 

Finally: it was absolutely essential that each element got padded up to 8 bytes, hence all the NOPx macro calls - for those routines that were longer than 8 bytes, the code jumps into various lumps of shared code, which I constructed by hand.

[VladR]

Whose to say that game couldn't be faster and smoother with further optimization or starting from scratch with another 3D game engine in that resolution, considering all the advanced development tools programmers have to day that they didn't have back then,. Also less restrictions on more base memory and extended memory. Couldn't a lot of the math be predetermined in look-up tables instead of calculating it all in real time too? Given extra memory to store all the data?

You are absolutely right on the money on all accounts!

If we take a 130XE, which is still a stock machine with 128 KB, we can significantly speed up line drawing and 3D transformations.

 

I haven't touched my 6502 flatshader in way over 6 months (still busy with Jaguar), but from the benchmarks I ran before (to get a breakdown of line drawing and transformations) the tunnel segment (different segments would have different framerates, as rendering cost varies greatly) would spend roughly this much:

17,000 cycles : Tunnel + Lasers Drawing

11,200 cycles : Clear Screen (160x70x4) - the 3D viewport is just 70 scanlines tall in that game

1,800 cycles: 3D Transformations via tables

2,000 cycles: Explosions

---------------------

32,000 cycles

 

Since on NTSC (after Antic takes its toll) we're left with around 24,186 cycles per frame, the tunnel portion could run at 30 fps, and still have about ~48,372 - 32,000 = 16,372 cycles for input/audio/score and basic gameplay management (way more than enough).

 

If we rather went for 15 fps, that's ~97,000 cycles (and 60,000 more for rendering than now), we could literally raise the scene complexity by a factor of 4 (or, add shaded floor/ceiling via DLIs - that would be a nice touch, though totally killing those 60,000 cycles). And 15 fps is still pretty nice. But as it is in that YT video, 30 fps is totally doable assuming 128 KB for tables, unrolled code and, of course, a really fast line drawing routine (not some Bresenham)...

 

 

This is also something that can be cobbled together in just few weeks (unlike, say, a proper 3D racing game that would need months)...

 

And don't even get me started on what's possible if we go for 512 KB RAM (though, of course, coding effort is then raised adequately)...

 

 

EDIT: What's interesting is that 32,000 cycles is very close to the PAL value per frame (29,895 after Antic). So, the base tunnel flythrough (30,000 cycles without explosions) could actually run on PAL at 50 fps (with framedrops, of course). I'm sure we could shave off some cycles on clearing (for areas not touched) to give it some additional breathing room (for less frequent framedrops below 50 fps)...

Edited October 28, 2018 by VladR

[Heaven/TQA]

The 3D Pool game of the bbc would make a nice addition to the a8 library as we dont have any?

[emkay]

Hard Drivin' really shouldn't be a problem. And, as it would run approximatly 3 times faster than the C64 version, it would gain playable speed.

Now that Total Eclipse has been released, showing double speed to the C64 version, AND looks better, on a stock machine, I'm even more sure.

Antic D plus filled "Polygons" will make any racing game possible on the Atari. ANTIC D+E (quirk mode ) will show miracles

[jvas]

Stunt Car Racier is at the edge IMHO. Any racing game with lower framerate is not more than an impressive demo, but not a racing game. But this is just my opinion.

[VladR]

I don't understand why majority of people here only consider two extremes:

- 5 fps

- 60 fps

 

What about 20 fps? Or 15 fps?

 

If the car doesn't move at insane arcade speeds, then 15 fps can feel as smooth as 60 fps- it all depends on how many pixels the environment skips. If it won't move more than 15 pixels per second on the screen, then it will feel as smooth as 60 fps. I love great speed but it's not the only element of fun.

 

15 fps on ntsc gives about 100,000 cycles at 160x96

 

That's a substantial performance for a clever combination of soft sprites, dli, and some flatshading.

[jvas]

I don't understand why majority of people here only consider two extremes:

- 5 fps

- 60 fps

 

What about 20 fps? Or 15 fps?

 

If the car doesn't move at insane arcade speeds, then 15 fps can feel as smooth as 60 fps- it all depends on how many pixels the environment skips. If it won't move more than 15 pixels per second on the screen, then it will feel as smooth as 60 fps. I love great speed but it's not the only element of fun.

 

15 fps on ntsc gives about 100,000 cycles at 160x96

 

That's a substantial performance for a clever combination of soft sprites, dli, and some flatshading.

 

No, we don't consider extremes only. But if you double the speed of Total Eclipse, you still far from 15 fps.

[emkay]

No, we don't consider extremes only. But if you double the speed of Total Eclipse, you still far from 15 fps.

Test Drive C64 ~ 3-6 fps

Rescue on Fractalus ~ 4 fps

Star Wars C64 ~ 3fps

MOOD C64 3 fps

... and they swear it's playable.

 

Compared to

 

Project-M Atari ~20 fps

Star Wars Atari 6-10 fps

 

Too slow

[jvas]

Test Drive C64 ~ 3-6 fps

Rescue on Fractalus ~ 4 fps

Star Wars C64 ~ 3fps

MOOD C64 3 fps

... and they swear it's playable.

 

Compared to

 

Project-M Atari ~20 fps

Star Wars Atari 6-10 fps

 

Too slow

Hehe, this is not what I was saying. What I was saying is that below the frame rate of Hard Driving, a racing game is not enjoyable. It may be was ok back in the day, but I don't like 3-4 FPS. While it is OK for a game like Total Eclipse or Mercenary.

[emkay]

Hehe, this is not what I was saying. What I was saying is that below the frame rate of Hard Driving, a racing game is not enjoyable. It may be was ok back in the day, but I don't like 3-4 FPS. While it is OK for a game like Total Eclipse or Mercenary.

It's hard to determine the speed of games , so the fps are coarse to approximate.

But the C64 Version is about 2-3 seconds per frame. While the Atari version keeps it mostly 1 fps.

[EnderDude]

What's this?