[Brainstorming] Power Drift and pseudo 3D circuit games

[saimon69]

Originally Posted by VladR

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).

Yup, forget about CGX on anything less than a 1200

[saimon69]

If a game like that has to run in a normal A500 then you need PLANAR or use less screen area for calculation like driving force, that calculates at 1/4 screen then expand via blitter; WILL come blocky but since we are emulating a super scale big pixels are ok

[VladR]

Originally Posted by saimon69

Yup, forget about CGX on anything less than a 1200

A1200 is actually pretty neat. That's 020 @14 MHz, 2+ MB RAM !

This is basically Jaguar without GPU/DSP/OP so I am quite familiar with this kind of a config.

I wonder how does the 256-byte cache behave compared to 68000 and especially with regards to blitting and where exactly would the threshold be between CPU vs Blitter - those would be some fun exploration benchmarks!


Of course, 32-bit colors would have to be downscaled to 8-bit, but that's a minor thing.

[VladR]

Originally Posted by saimon69

If a game like that has to run in a normal A500 then you need PLANAR or use less screen area for calculation like driving force, that calculates at 1/4 screen then expand via blitter; WILL come blocky but since we are emulating a super scale big pixels are ok

Why exactly does it have to run on A500 ? Was that what you had back in the day perhaps ?

Amiga's Blitter can do 2x/4x zoom ? That would certainly come in handy...

[VladR]

I did a quick and dirty per-pixel Fog, and while fog color is a parameter - for now it's best if the fog color is white for performance reasons (has a separate codepath).

Ultimately, this is probably best precomputed at a loading-time, though I'm sure that Vampire could process about ~30 tiles in distance in a fraction of a frame time, so it could be kept real-time.

Which would allow for real-time fog adjustment between areas (kinda like in OutRun when it changes areas) and perhaps even a day-of-time effect where fog color interpolates real-time.

[roondar]

Originally Posted by VladR

Amiga's Blitter can do 2x/4x zoom ? That would certainly come in handy...

Nope, no zoom. I guess you could fake a 'vertical scale up' by doing several blits with a larger than normal destination modulo and then offsetting their starting points, but that's not HW zoom.

[VladR]

Originally Posted by roondar

Nope, no zoom. I guess you could fake a 'vertical scale up' by doing several blits with a larger than normal destination modulo and then offsetting their starting points, but that's not HW zoom.

I guess I could then zoom each scanline horizontally on CPU and then blit it (up to zoom number) via Blitter.

I recall reading in some thread that CPU is faster than Blitter (in simple writes) below 68030.
I reckon, A1200's 68020 might already be faster in that regard perhaps?

Also, this is no Jaguar - we are not limited to a 2MB executable- we can load data from HDD on demand and have each level preprocessed into 4-8 MBs.

[saimon69]

Originally Posted by VladR

Why exactly does it have to run on A500 ? Was that what you had back in the day perhaps ?

Amiga's Blitter can do 2x/4x zoom ? That would certainly come in handy...

Is more doubling the pixels of the output, not exactly a hardware zoom

But the hypothesis is that Power Drift port sucks because was badly programmed, so the brainstorm is to see if is possible to fix the port or to have a similar game tipology running on a base A500 with 1 megabyte RAM.

While a 1:1 port might be off question am convinced that a decent implementation can be done with the right tweaking; not necessarily the arcade itself as much than a racer with similar structure

However the REAL purpose is to make jaws drop: is more fun to surprise people with a underpowered hardware than with unlimited power (that and a personal feud for improve amiga bad games)

[VladR]

Originally Posted by saimon69

Is more doubling the pixels of the output, not exactly a hardware zoom

But the hypothesis is that Power Drift port sucks because was badly programmed, so the brainstorm is to see if is possible to fix the port or to have a similar game tipology running on a base A500 with 1 megabyte RAM.

While a 1:1 port might be off question am convinced that a decent implementation can be done with the right tweaking; not necessarily the arcade itself as much than a racer with similar structure

OK, thanks for explanation. I can see your point now.

From my perspective, it's more important to be efficient in time spent on coding it.

As much as I love extracting last bit of performance, I don't think I can justify burning through 2-3 full-time months of writing dozen different OCS renderers just to see what approach results in highest performance on A500, and then I sell 3 copies on OCS

A1200, though ? Sure, why not ? That's still a relatively reasonable HW target.

[VladR]

Originally Posted by saimon69

However the REAL purpose is to make jaws drop: is more fun to surprise people with a underpowered hardware than with unlimited power

I feel you there, though from my personal gaming experience, I'd rather lower the visuals a bit to ensure locked fps gaming experience.

It's no good that you have 60 fps every other second, but have framedrops randomly.


Much better to lock framerate to 30 fps and adjust the most complex scenario in game still fits within that budget.


60 fps on A500 is really barely enough time for color cycling and few changes to the scanlines in a racing game...

[saimon69]

Originally Posted by VladR

As much as I love extracting last bit of performance, I don't think I can justify burning through 2-3 full-time months of writing dozen different OCS renderers just to see what approach results in highest performance on A500, and then I sell 3 copies on OCS

I sometimes thought that a fund should be set up to do a bounty system similar to those in AROS in order to pay for 'fixing' or recoding bad ports, so that coders would see some cash anyway...

...however if the game is technically solid i think you could sell more than three copies, i can go up to.... six :P

Ten if we implement some kind of parallel/serial match more :P

[VladR]

Originally Posted by saimon69

...however if the game is technically solid i think you could sell more than three copies, i can go up to.... six :P

Ten if we implement some kind of parallel/serial match more :P

Dang, you drive one hell of a hard bargain

[VladR]

On a more serious note, I spent 15 minutes resizing and colorizing one 2D tree bitmap - which absolutely does not mix visually together with neither current tile sprite, nor skybox and implemented some road-side props functionality.

[saimon69]

This looks already interesting

[VladR]

I experimented a bit with creating a textured tile (512x64), but it needs perspective applied, which I didn't feel like messing around with (so it doesn't have that), it's just a cut out of the texture.

But at least it gives a hint of how it might look like if textures were used.

I see I forgot to put camera above road back to its previous value, so now it's viewed from high above (kinda like you made a jump or something).

This definitely makes a valid case for run-time rendering of 2D tiles from 3D mesh (say, created in 3dsmax) during loading time...

[saimon69]

Improvements lately?

[VladR]

Originally Posted by saimon69

Improvements lately?

Nah, unfortunately. I'm having a pretty miserable week, given my last feature was six days ago.

I started coding the scanline texturer, with perspective texturing, so that I can define the shape of the tile in 3D and just project the transparent texture on top of it.

One application would be an effect at start of the level where the tile would slowly rotate from vertical to horizontal position.

Of course, with the RAM we have these days we can precompute all kinds of angles and use them dynamically at runtime on the track, based on slope of the track.
That should work even on 2 MB systems...

[VladR]

I implemented the above mentioned functionality and created perspective-correct tile at run-time via rendering to an off-screen buffer and then copying it into run-time created texture pointer.

I'm now realizing that the downside is that some part of the texture resolution is lost in the process as the texture resolution at close-up is now slightly lower.

That could be tweaked by creating a much larger off-screen buffer.

[VladR]

It was worth a shot to try a combined grass/rock/asphalt texture and it isn't entirely useless, actually.

At this point, lots of different environments can be done by simply replacing base tile texture.

If I had few alpha maps, I then wouldn't even need the base materials to be seamless, as creating a new tile would at that point become just a question of blending between two RGBA texels, which is a load-time performance cost, hence has no impact on framerate...

[saimon69]

Is bordering on Rad Mobile now