[Brainstorming] Power Drift and pseudo 3D circuit games

[dlfrsilver]

Originally Posted by saimon69

I always hope someone like Fedepede on Atari STE comes and try to optimize it: it can be tweaked but there are also bigger issues with it like cars size and circuit being too tight in my opinion - this was ZZKJ of Super Hang on fame so i think he really squeezed stuff like a lemon for ST but then no optimization for make it run better on amiga,nor improvements like a copper sky and crappy uncle art instruments -_-

You got the picture

[saimon69]

This REALLY make me wish i know to code in assembly to make a clone, but all stuff involved are not trivial: 3d maps manipulation, proper rendering, jumps, etc.

[Photon]

Originally Posted by saimon69

I did realize, watching the longplay videos of Power Drift, that the way materials are assigned to the sprite layers is through some sort of fill

Arcade version has a specialized sprite chip, like many games that inspired the SNES chip. No fill.

Originally Posted by saimon69

An undisclosed coder told me that making a game like this will be a "nail in the 655" due to the calculations but like the idea...

Calculations are no problem, pixel bandwidth requires specialized chip or making up for one with CPU speed, as on PC.

Originally Posted by PatmanQC

the PC game that was shown looks fantastic and I will definitely check out.

Year is important. Is it 100% accurate to the Arcade version? A specialized version (not MAME) could have been available post 2001, MAME version running full framerate on good PCs post 2005.

This is the power of custom chips (some being more special purpose than others!)

[saimon69]

Hey, the two games i proposed did something that was almost there, and i think by tweaking we can get it work at decent speed on a 500 and 1 meg RAM - not necessarily a port but also a stand alone game with same technology - and no am not bothered by huge pixels if the Drivin Force approach is used, those add appeal to the scaling
The PC version is an actual indie game made with gamemaker [2020] but asset style is simple enough to look portable somehow - i really think an A1200 could do it almost 1:1, a 500 will need tweaks

[a sad story of redemption and late pointless revenge towards perceived wrongs - Power Drift the Drama - soon on NetFlix]

[saimon69]

Arcade version has a specialized sprite chip, like many games that inspired the SNES chip. No fill.

Am talking about the Amiga/Atari version; is pretty visible here in this frame capture, using what seems a16x16(?) tile on the ground elements [and the wood, and the gravel]



Btw someone got me the files from the Arcade audio; i know there is no chance in hell to have the amiga game revised or recoded but am going to see if i can do a better version of the songs!

[saimon69]

Ok question: did PD used the fast memory for double buffer? And would turning off copperfills increase a bit performance? I would do those tests if i knew where to point - all the rest would be still messed up of course but can give ideas for improvements

[VladR]

Originally Posted by saimon69

For the frame rate this is the kind of game that if even goes to 25fps should be still enjoyable.

Wait, what ? "Even if" ? On a 7 MHz 68000 ?

Powerdrift would actually give Jaguar run for its money to reach stable 25 fps. And that's 13.3 MHz 68000 + two 26.6 MHz RISCs + Blitter + ObjectProcessor.
And no, you couldn't even use Blitter to scale the bitmaps there - I did some benchmarks, and even if the texture fit into GPU's 4 KB cache, and there is a 64-bit separate bus between the two, it still can't scale full screen at 60 fps. So, you would still have to break it down between all processors and render screen concurrently using at least 3-4 chips (good luck Z-sorting that ) and just use pre-scaled/pre-compiled sprites as those are obviously fastest.


But 7 Mhz 68000 + basic Blitter ?

What other 25 fps racing games are there on OCS that are doing this many sprites per frame (no color cycling racers) that make you think this is remotely reasonable ?

I noticed in YT vid that when there are great many objects, the framerate dips below ~5 fps, which is understandable given the load.

I'm not saying it couldn't be optimized, but 25 fps at this level of sprite coverage and overdraw on 7 MHz ?



The single biggest optimization one could do here is removing overdraw (assuming this already isn't taken care of, which we don't know).


Short of that, level design should be dictated by target framerate to avoid these huge framedrops.

Even on X360 with 3x 3.6 GHz cores, devs needed to make sure they didn't overload the system, so on a puny 7 MHz 68000, this is a no brainer...

[VladR]

Originally Posted by saimon69

Ok question: did PD used the fast memory for double buffer? And would turning off copperfills increase a bit performance? I would do those tests if i knew where to point - all the rest would be still messed up of course but can give ideas for improvements

I would start somewhere much simpler.

How about you create a double-buffered screen and just brute-force render some random background + simple loop of rendering as many tiles as you can within 25 fps.
You can create the one tile yourself in 15 minutes in Paint.


That would be a great starting point in finding out what can 7 MHz accomplish at your target framerate

Honestly, I don't think 85 MHz Vampire could handle this at 60 fps without framedrops as there's just too much stuff on screen. Maybe in 320x200...

[saimon69]

Actually i think 12 is a decent target but if reprogrammed from scratch we can reach 25 with twice the objects here (this one uses Dual Playfield and goes 50fps) AND the big pixels give better superscaler feeling

[ Show youtube player ]

[VladR]

I figured I could swing one day with PowerDrift-style renderer and implemented some additional functionality into my Heimdall codebase just to see how it would look and feel:

- designed a very simple base tile in PaintShopPro in 15 minutes
- replaced Drawing of polygons with a 2D scaled sprite
- implemented all cases of clipping
- all rendering is obviously CPU -> SW rasterizer

Few more details:
- 800x600x32bit, CyberGraphX
- written in Higgs (my high-level assembler)
- currently tested under WinUAE
- track is fully 3D (X,Y,Z) with elevation changes and curves
- camera follows the track curvature at specified distance
- spacing (depth/width) is a run-time parameter
- number of visible segments is also a run-time parameter
- This is fully "playable" - as in, you can speed up/down and go from start to the end of the track (only limited by RAM)
- Physics is same as what is already implemented (speed up/down based on hills, strafing inertia, acceleration based on gears transmission), but obviously for a different game I would implement a different physics model.


This might be a good candidate for my second game (whenever that might happen (or not ))...

[saimon69]

You got the tiles from Victory Heat Rally looks like there ^^
Circuit scaler are - beside the two examples above - not well represented in the boing ball land; actually i think even just having flat 'savoiardi' (a circuit tile look like a savoiardo aka lady finger cookie) would do interesting results if well implemented and even only using regular OCS dual playfield; i just wonder: how tracks are designed? I know those are essentially dots with attributes (a specific tile assigned) in the 3D space

[saimon69]

Another thing that was not implemented good on the port was a proper Field of View - read: we know that the engine can move n tiles in T timeframe so we implement an area that can have hardly more than the number of tiles available in the timeframe t; it seems to me instead that the Amiga port had tiles too tightly packed (if was for map size problem not sure) but that essentially choked the engine.

[VladR]

Originally Posted by saimon69

You got the tiles from Victory Heat Rally looks like there ^^

i just wonder: how tracks are designed? I know those are essentially dots with attributes (a specific tile assigned) in the 3D space

Yeah, I got inspired by VHR, it's good enough for quick prototype.

I design the track in 3dsmax. It's a curve that gets exported.

The engine then extrudes 3D mesh along the curve at loading time.

For this type of engine, I only extrude 2 vertices per segment - those get 3D transformed and those points then represent the endpoints of the 2D tile.
So, there's nothing fake about their movement, as it's a proper 3D transformation based on camera position and vertex position.

Also, because we have gobs of RAM, we could have dozens of different tiles per each level/area.
It doesn't cost anything to switch between the textures during rendering - so if an artist designed a track with twenty different tiles, the engine can run that just fine as I already tested this on primary game, it's just that I spent just 15 minutes creating a single tile.

One thing that would be nice to implement is the camera roll in curves - when each tile gets rotated, just like in Powerdrift. But that's for later, assuming I get serious about this game...

[saimon69]

You could have the copper bend the visual on curves
And by the way since am a pixel artist and musician i can help with assets if needed

[VladR]

Originally Posted by saimon69

You could have the copper bend the visual on curves
And by the way since am a pixel artist and musician i can help with assets if needed

Forget copper. This is all CPU.

Whatever is the lowest config for CybergraphX, that's what this runs on - I suspect 68030-040.

Another thing - Vampire can run this at 32-bit colors. I think this is something that has not even been explored yet - perhaps aside from that PC game.

A very simple FX would be fog into the distance.

The tiles can be hires. V4 has 512 MB. Lots of textures fit there.
The one I created is 256*32, but it's runtime configurable, so we could have a tile that is 1,024*128 or 2,048*256. Performance is same regardless of resolution, obviously.

Maybe the tiles could have shadows from roadside objects - that would certainly be very original.

If tiles were textured, we could have dozens of different looks/areas.

[VladR]

Originally Posted by saimon69

Another thing that was not implemented good on the port was a proper Field of View - read: we know that the engine can move n tiles in T timeframe so we implement an area that can have hardly more than the number of tiles available in the timeframe t; it seems to me instead that the Amiga port had tiles too tightly packed (if was for map size problem not sure) but that essentially choked the engine.

It's not just a question of tile count.

It's the number of pixels drawn. A single tile right in front of camera can have more pixels than 5-7 tiles in the distance.

I can implement some quick benchmarks and stats tomorrow.

Probably the next most important feature is reducing overdraw by not processing rows of pixels that are covered by front tiles - essentially Z-buffering.

A very interesting performance exercise would be implementing front-to-back rasterizer which would guarantee zero overdraw as each row of pixels, before being written, would be checked against a list of rows already drawn.

[VladR]

Attached you can find the output of the stats (I disabled skybox so we can read it easily) of the engine. I ran this at 640x480.

Numbers are in hexa (obviously) and show the clipped number of pixels per each tile (40 in total) in the order they are rendered (back to front, obviously).

Last number is the total number of pixels drawn : $12843 = 75,843 px

Notice the last 4 tiles (the front ones):

$13EC : 5,100
$2000 : 8,192
$37C8 : 14,280
$4000 : 16,384

These 4 tiles take 43,956px out of 75,843 = 58% !
Basically, front 10% of tiles take almost 60% of CPU power.

Now notice the last 8 tiles, each at $2E = 46px - we could have literally 300 of them and they would take less than the very first tile.


So, the count of tiles means nothing for performance - it's less than a drop in the bucket.


Now, let's see what's the impact of first 10 tiles: $11A66 = 72,294 -> 95%
So, for ~5% of performance, we can quadruple the tile count and visibility.

And we really need at least 10 tiles in the front for any remotely meaningful visibility.

[VladR]

Originally Posted by VladR

If tiles were textured, we could have dozens of different looks/areas.

I just realized I could generate textured tiles procedurally, at loading-time.

The tile would be a generic 3D mesh, textured with various materials (different texture for edges and center part).

The 3D engine would simply apply textures, perhaps smooth blending between various textures (via alpha masks) and render it from point of view of camera.
Because this is a loading-time cost, it wouldn't matter if the 3D mesh of the tile had 10,000 polygons.

Resulting render would then be copied into the tile pointer,which would be reused the same way as if it was imported during development

Then, all I need is just a pile of textures from some texture pack. Apply some special FX during loading-time (blur, fog, specular shading, etc.). This would result in a very unique and original look - a very hard thing to get these days with billion other games

Sky's the limit

[saimon69]

Originally Posted by VladR

Attached you can find the output of the stats (I disabled skybox so we can read it easily) of the engine. I ran this at 640x480.

Numbers are in hexa (obviously) and show the clipped number of pixels per each tile (40 in total) in the order they are rendered (back to front, obviously).

Last number is the total number of pixels drawn : $12843 = 75,843 px

Notice the last 4 tiles (the front ones):

$13EC : 5,100
$2000 : 8,192
$37C8 : 14,280
$4000 : 16,384

These 4 tiles take 43,956px out of 75,843 = 58% !
Basically, front 10% of tiles take almost 60% of CPU power.

Now notice the last 8 tiles, each at $2E = 46px - we could have literally 300 of them and they would take less than the very first tile.


So, the count of tiles means nothing for performance - it's less than a drop in the bucket.


Now, let's see what's the impact of first 10 tiles: $11A66 = 72,294 -> 95%
So, for ~5% of performance, we can quadruple the tile count and visibility.

And we really need at least 10 tiles in the front for any remotely meaningful visibility.

In what hardware configuration are you testing and how do numbers scale down in the case limit (a500 1 meg OCS/ECS)?

[VladR]

Originally Posted by saimon69

In what hardware configuration are you testing and how do numbers scale down in the case limit (a500 1 meg OCS/ECS)?

I have V4 at home, though currently not in a state of being able to upload any builds to it, so all my Vampire tests are remote for now.
The WinUAE config is for 040 + Zorro III.

I don't know if CGX works on A500, but I doubt it, as it doesn't seem to allow lower bitdepth than 8, which would imply AGA.

In theory, I could write my own C2P routine instead of using CGX and then it would also run on OCS (I did some fumbling with bitplanes earlier).

But I would have to spend at least a month writing a dozen different versions for OCS and benchmarking it, till I would figure out which approach is fastest for OCS.