That's how an A8 racing game should look like... ;)

[Heaven/TQA]

 

[emkay]

 

5-6 fps ?

Depending on other's meanings , it is a no go. 

 

 

 

[Rybags]

Looks pretty good, it even has hills.

 

It's reasonable to think it could run on our machine as well or better.  We have a slight speed advantage in standard graphics mode and the Plus4 has no PMGs.

[VladR]

Clearly a lot of work went into this. I don't mind the lower framerate because it's compensated by the visuals.

 

Can't help but think how it would work on A800. There doesn't appear to be too many colors on a same scanline, other than with the trees, which could be colored via PMG masking+DLI.

 

Dithering definitely helps.

[emkay]

The main problem still is that such a game on the Atari has to run at 50 fps , otherwise a coder doesn't care

Still today people don't believe that Test Drive on the C64 only runs at about 4 fps.

They do the same trick a with the C64 , btw.  : The Frame isn't build in "one frame" . Parts of it get shown later. This gives the impression of a faster engine.  

 

[VladR]

6 minutes ago, Rybags said:

Looks pretty good, it even has hills.

 

It's reasonable to think it could run on our machine as well or better.  We have a slight speed advantage in standard graphics mode and the Plus4 has no PMGs.

It's not full-blown hills, though. I haven't seen the partial per-pixel occlusion of roadside sprites by the hills, so it would appear they don't do a full drawing of road+environment Back-To-Front, despite the lower framerate.

 

Given that the target framerate is ~10 fps, about 6 frames, at 160x192 we have 20,250 cycles (on NTSC), that's 6*20,250 = 121,500 cycles for everything.

Heavy PMG usage will chip into the cycle budget substantially, as PMG's steal cycles during all 60 frames, even if the real framerate is 10 fps...

So, around ~100,000 c for all sprites, bitshifting and audio.

 

I know the textured/dithered road itself can be easily done in far less than that as I've benchmarked that about a year ago on 6502, but the killer is the SW sprites.

 

Then again, on Atari, we could simply ask for more RAM and preshift all sprites, at which point it's a simple LDA/STA combo. Or, why stop there and straight create a separate kernel per each sprite, embedding sprite data into the code.

 

Even 130XE could hold the preshifted sprites just fine, though I understand it would piss many people if we went the Separate Antic access route...

[VladR]

6 minutes ago, emkay said:

The main problem still is that such a game on the Atari has to run at 50 fps , otherwise a coder doesn't care

I know what you mean, but I strongly believe the two different camps can peacefully coexist:

1. 60-fps with simple visuals

2. 10-fps with complex visuals

 

I believe there's lots of games in the first group. What's wrong with couple in the second one ?

 

6 minutes ago, emkay said:

They do the same trick a with the C64 , btw.  : The Frame isn't build in "one frame" . Parts of it get shown later. This gives the impression of a faster engine.  

You make it sound simple, but it's not, really. It has to be perfectly sync'ed or the illusion is broken.

Then, there's the problem if something else in the pipeline takes longer and spills over to the next frame. This means much more expensive sync code has to be executed each frame. Which sucks when you must debug it. Thanks, but no thanks

 

[emkay]

19 minutes ago, VladR said:

It's not full-blown hills, though. I haven't seen the partial per-pixel occlusion of roadside sprites by the hills, so it would appear they don't do a full drawing of road+environment Back-To-Front, despite the lower framerate.

Ofcourse, the procedural graphics only can be build on the machine's capacity.

 

 

19 minutes ago, VladR said:

Given that the target framerate is ~10 fps, about 6 frames, at 160x192 we have 20,250 cycles (on NTSC), that's 6*20,250 = 121,500 cycles for everything.

Heavy PMG usage will chip into the cycle budget substantially, as PMG's steal cycles during all 60 frames, even if the real framerate is 10 fps...

PMg don't usually steal cycles, if you use them for colorization. 

 

19 minutes ago, VladR said:

So, around ~100,000 c for all sprites, bitshifting and audio.

Do the calculation with 6 fps and even more cycle stealing on the 16/plus 4....

 

 

19 minutes ago, VladR said:

I know the textured/dithered road itself can be easily done in far less than that as I've benchmarked that about a year ago on 6502, but the killer is the SW sprites.

Seems no problem on a slower computer. 

 

19 minutes ago, VladR said:

Then again, on Atari, we could simply ask for more RAM and preshift all sprites, at which point it's a simple LDA/STA combo. Or, why stop there and straight create a separate kernel per each sprite, embedding sprite data into the code.

All wrong thinking, and might not lead to a working game. 

 

19 minutes ago, VladR said:

Even 130XE could hold the preshifted sprites just fine, though I understand it would piss many people if we went the Separate Antic access route...

Why using something that obviously don't give any advantage?

For Games, when graphics has to be drawn, the CPU needs the access to the video range. 

[emkay]

12 minutes ago, VladR said:

I know what you mean, but I strongly believe the two different camps can peacefully coexist:

1. 60-fps with simple visuals

2. 10-fps with complex visuals

 

They could but they don't. 

 

Quote

 

I believe there's lots of games in the first group. What's wrong with couple in the second one ?

 

Don't know. Ask them who define that rules.

 

Quote

You make it sound simple, but it's not, really. It has to be perfectly sync'ed or the illusion is broken.

 

It is exactly NOT not simple. 

They use the characters as graphics buffers and change the content in the sky after the road is completed. 

 

Quote

Then, there's the problem if something else in the pipeline takes longer and spills over to the next frame. This means much more expensive sync code has to be executed each frame. Which sucks when you must debug it. Thanks, but no thanks

 

If things spill over to the next frame they simply drop it. 

Edited December 8, 2019 by emkay

[VladR]

5 minutes ago, emkay said:

Ofcourse, the procedural graphics only can be build on the machine's capacity.

 

 

PMg don't usually steal cycles, if you use them for colorization. 

 

Do the calculation with 6 fps and even more cycle stealing on the 16/plus 4....

PMGs : ANTIC has to process them, so for each Byte read, there's a cycle down, right there (and if I'm not mistaken another cycle for doing the change?). And even if the game ran at 1 fps, ANTIC still has to process PMG 60x per second, so the total cycle count will be substantial. However, to get more colors, it's a necessary evil on Atari.

Same thing for DLIs for the PMGs (the trees) and DLIs for the background. That's again a lot of cycles that are taken 60x per second, regardless of game's framerate.

 

Such DLI requires STA WSYNC, or not ? That completely kills CPU for that scanline, which is what - about 105c per scanline ?

Now, there appear to be about 8 such changes for the road, so multiply the cost by 8 and then by 60. Boom

 

By the time we get to do some actual drawing, our cycle budget just got sodomized by ANTIC

I couldn't actually do the calculation with 6 fps, as for me, 10 fps is brutal in itself, but 6 fps is just plain sadomasochistic. I just can't. There should be a law that racing games shouldn't go below 10 fps...

[VladR]

16 minutes ago, emkay said:

All wrong thinking, and might not lead to a working game. 

What are you talking about ? By embedding the sprite data directly into the code (LDA #QuadPixel) you save outrageous amount of cycles on reading each byte, then process its indexing, then go on to store it.

If the data is straight in the code, you can now use both index registers for speeding up the write to framebuffer. That's a very significant cycle savings per each byte processed.

Downside is that you need additional byte for each byte of data just for LDA, but with 1 MB - 4 MB available these days, that's not an unsurmountable problem.

 

Of course, you don't want to create such code manually, you need some script that can do that, to preserve the sanity

16 minutes ago, emkay said:

Why using something that obviously don't give any advantage?

For Games, when graphics has to be drawn, the CPU needs the access to the video range. 

You're kidding me ? No advantage ? There's tremendous performance advantage of separate Antic access just like on 130XE. You can access all kinds of precomputed tables without affecting rendering. I don't want to go too much into details, we had a long thread about the advantages of such approach.

 

Unfortunately, a lot of apparently popular RAM expansions don't support that feature, which is a real bummer...

 

[emkay]

33 minutes ago, VladR said:

PMGs : ANTIC has to process them, so for each Byte read, there's a cycle down, right there (and if I'm not mistaken another cycle for doing the change?). And even if the game ran at 1 fps, ANTIC still has to process PMG 60x per second, so the total cycle count will be substantial. However, to get more colors, it's a necessary evil on Atari.

Same thing for DLIs for the PMGs (the trees) and DLIs for the background. That's again a lot of cycles that are taken 60x per second, regardless of game's framerate.

Using PMg DMA in such a game is simply silly. 

As it is all software driven and DLIs needed anyways, the PMg should be used in the Shape Mode and put behind the graphics. 

Don't forget the heavy DMA on the C16/plus 4. 

 

Quote

Such DLI requires STA WSYNC, or not ? That completely kills CPU for that scanline, which is what - about 105c per scanline ?

Now, there appear to be about 8 such changes for the road, so multiply the cost by 8 and then by 60. Boom

WSYNC saves the stability. Without that, it may jump some scanlines. So, If it is about changing the PMg shapes, and to give it some lines space, you don't need WSYNC.

 

Quote

By the time we get to do some actual drawing, our cycle budget just got sodomized by ANTIC

I couldn't actually do the calculation with 6 fps, as for me, 10 fps is brutal in itself, but 6 fps is just plain sadomasochistic. I just can't. There should be a law that racing games shouldn't go below 10 fps...

But that Game of the topic runs at about 5-6 fps .

 

 

Edited December 8, 2019 by emkay

[VladR]

1 hour ago, emkay said:

Still today people don't believe that Test Drive on the C64 only runs at about 4 fps.

I actually have an update for you, as we had this discussion earlier this year. In summer, I created a 6502 proto (within my Atari:Dev.Emu PC-based dev emulator) that applied differential rendering into a TestDrive scene.

 

Turns out, you can actually render the differences between 2 frames under 25,000c, thus making it a 60 fps game in 160x96. It's just a real nasty, borderline undebuggable code.

 

But, you don't have to do clearscreen, you don't have to fill 85% of screen's scanlines, just the differences between the two frames (which, in 3D, are anything but intuitive).

 

You obviously drop to 30fps with an on-screen enemy car and you drop a frame every time new road segment is processed. But, on an empty road, Atari can do the whole scene at 60 fps.

[VladR]

4 minutes ago, emkay said:

Using PMg DMA in such a game is simply silly. 

As it is all software driven and DLIs needed anyways, the PMg should be used in the Shape Mode and put behind the graphics. 

Don't forget the heavy DMA on the C16/plus 4. 

 

WSYNC saves the stability. Without that, it may jump some scanlines. So, If it is about changing the PMg shapes, and to give it some lines space, you don't need WSYNC.

I don't believe you can get away without WSYNC. The cars and trees literally go to the edge of screen. The resulting jitter (without WSYNC) would certainly be very ugly, once the bitmaps would get to the screen edge.

 

Now, you could have a separate codepath, that if (Sprite.XP > ThresholdDistance from screen edge) you could skip WSYNC, but that's introducing additional combinatorial complexity into the code, doubling everything else that has ever to interact with it (sync, data feed, sanity checks, etc.).

 

You gonna write, test and debug all that additional code ?

[emkay]

4 minutes ago, VladR said:

I actually have an update for you, as we had this discussion earlier this year. In summer, I created a 6502 proto (within my Atari:Dev.Emu PC-based dev emulator) that applied differential rendering into a TestDrive scene.

 

Turns out, you can actually render the differences between 2 frames under 25,000c, thus making it a 60 fps game in 160x96. It's just a real nasty, borderline undebuggable code.

 

But, you don't have to do clearscreen, you don't have to fill 85% of screen's scanlines, just the differences between the two frames (which, in 3D, are anything but intuitive).

 

You obviously drop to 30fps with an on-screen enemy car and you drop a frame every time new road segment is processed. But, on an empty road, Atari can do the whole scene at 60 fps.

 

Your thoughts and solutions are a little to much theory. Not to approve. 

But guess why I ALWAYS propose Mode D for a lot games. It's just the fact that in one frame the CPU can use 50% for calculation , and the projection in the other 50% . 

In theory you could do Realtime calculation on every frame.

The character mode kills a lot time for Realtime calculations, but offer a lot tricks to speed up things on the graphics part. 

And here, also is the possibility given to only draw the changes into the chars in the same frame, while the frame is displayed.

[rensoup]

 

this one still looks better (and probably doable at 50hz with 2 cars)

 

 

[VladR]

8 minutes ago, emkay said:

 

Your thoughts and solutions are a little to much theory. Not to approve. 

But guess why I ALWAYS propose Mode D for a lot games. It's just the fact that in one frame the CPU can use 50% for calculation , and the projection in the other 50% . 

In theory you could do Realtime calculation on every frame.

The character mode kills a lot time for Realtime calculations, but offer a lot tricks to speed up things on the graphics part. 

And here, also is the possibility given to only draw the changes into the chars in the same frame, while the frame is displayed.

It was only a theory until I implemented it. At that point I got real cycle data on 6502's load.

 

It would, for sure, require at least 3-4 weeks, full-time, to write a simple racing game around it, but it's far from undoable or impossible...

 

The single greatest advantage of 160x96 for flatshading is that you have 50% of scanlines compared to 160x192, as there's tremendous performance cost incurred in scanline traversal.

[VladR]

1 hour ago, rensoup said:

 

this one still looks better (and probably doable at 50hz with 2 cars)

 

 

I feel you. On Jaguar, I'm doing the same - figuring out how much scene complexity I can get away with at Hires (640x24), HiColor (65,536) at 60 fps.

 

But, aren't there quite a lot of 50-60fps racing games on A800 ? I believe the sweet spot for racing games is around 20 fps, as it gives you 3 full frames worth of CPU for quite complex scene, yet is still "smooth enough".

[AtariLeaf]

Why is there a tiny AT-AT in the top right corner? ?

[R0ger]

I'm first to say you don't need 50fps, but this seem too slow .. I think 2 frame refresh would be ideal, 3 or 4 acceptable.

[Gunstar]

I assume you are joking, but the AT-AT is the gear shifter...

 

[Poison]

There are not racing games on atari like lotus. Atari is not powerful computer for that ?

[emkay]

21 minutes ago, Poison said:

There are not racing games on atari like lotus. Atari is not powerful computer for that ?

 

The problem for the Atari is that there is no Coder interested in doing such projects.

Either they prefer the classic games ,  they just want to have their own ideas running, or they want to beat the C64 and get lost.

Also: It is not enough to just crop the game code and to put it to the Atari. The graphics part always has to be written particular to fit to the capabilities of the Atari.  

 

[rensoup]

5 hours ago, VladR said:

But, aren't there quite a lot of 50-60fps racing games on A800 ? I believe the sweet spot for racing games is around 20 fps, as it gives you 3 full frames worth of CPU for quite complex scene, yet is still "smooth enough".

I don' t recall any good looking racer at 50/60 on the A8, (except for elektraglide? and there aren't any cars...) so there's still that gap to fill?

 

The problem is the road which probably requires a kernel (it seems to be the only fast solution for drawing it with PMGs). A kernel at 25fps is a more annoying if you want to do something useful in it (on top of repositioning PMGs)

[R0ger]

You simply can't make cars and 50fps.

You can use hardware to have nice road .. and the use PMG for cars. Problem is, Atari's PMG is too limited, and you end up with simple cars.

I tried using the opposite approach ..  PMG for the road, field for car, which simplifies things greatly, see here: https://www.youtube.com/watch?v=2iT2_PdJa3g
But there is too many limitations, mainly width of the road, I don't think it's the right way.

Or you can do it like Electra Glide - first person view. That would be possible even with more complex road and hills, but having tried myself, I must say even that would be an achievement.

Other than that, you have to use software sprites. But then that's the same for most 8 bit platforms.

You could go for fake road .. like C64 outrun https://www.youtube.com/watch?v=Jt7xn_K6WX8

The road is just few frames, made from charset, and it only scrolls to the left and right, no distortion is made. Really fast to render. You still have to do the cars somehow though. Game like this is more about evading other cars, rather then following the road perfectly. It's not what I would expect from a racing game, but it's also fun.

Also games like Chase HQ on spectrum us characters to some extent https://www.youtube.com/watch?v=s2aYrkofKHM

You can see how the road itself is actually done using characters, and the bends are only on multiples of 8.

Also the cars are not merged with background, and are only on character boundaries. Only the player car is merged with background. It's all software rendered, they just used every possible trick to make it simpler, thus faster.