Better Outrun port for Amiga

[Samurai_Crow]

Last update 2018, FEBRUARY

Yes. It needs updating.

[axilmar]

Well, sorry for being too late in this discussion (by a few years!!!), but two digital loves that I have is the Amiga and the Outrun game, and I still haven't seen anyone tackling their marriage... ;-)

Regarding huge sprites and smooth 3d motion, there is a game named Drivin' Force. Not the very best of games, but its huge sprites and 50 fps gameplay are difficult to go unnoticed.

And it runs like that on a stock A500!!!

Couldn't a possible Outrun port take a few hints from Drivin' Force?

Has anyone ever disassembled Drivin' Force's graphics to see how they work?

Thank you for your attention in this decades old now topic...

[saimon69]

Originally Posted by axilmar

Regarding huge sprites and smooth 3d motion, there is a game named Drivin' Force. Not the very best of games, but its huge sprites and 50 fps gameplay are difficult to go unnoticed.

And it runs like that on a stock A500!!!

Couldn't a possible Outrun port take a few hints from Drivin' Force?

Actually i consider Drivin'force as a template for a Power Drift port; as far as i remember it uses one quarter screen (160x100) in dual playfield to render the scene that then is expanded via blitter/copper - player is a sprite. End result is a bit blocky but that is not a problem since gives a superscaler feeling.

For a better OCS/ECS port i consider the source code improvement by Fedepede04 on STE as the best option.
They showed earlier in this same thread here

[axilmar]

Originally Posted by saimon69

Actually i consider Drivin'force as a template for a Power Drift port; as far as i remember it uses one quarter screen (160x100) in dual playfield to render the scene that then is expanded via blitter/copper - player is a sprite. End result is a bit blocky but that is not a problem since gives a superscaler feeling.

For a better OCS/ECS port i consider the source code improvement by Fedepede04 on STE as the best option.
They showed earlier in this same thread here

Thanks for the info about Drivin' Force. That was a very clever trick! Judging from that and from copper chunky demos (with resolution similar to that), it seems the Amiga needs about 4 times the processing power to implement basic scaling/rotation on the 320x256 resolution at 50 fps...

Regarding roadside objects, one thing that could be implemented is minimal precalculated scaling on intermediate states between two bitmaps.

I really hate roadside objects not being enlarged smoothly as they go by.

So, I just thought that perhaps the 'lost frames' could be represented as precalculated lists of blit commands that blit overlapping parts of a bitmap.
Since there are a lot of bitmaps for each roadside object, only a few lists would be needed between two actual frames.

For example, images could be scaled down by splitting them in 4 parts and draw them in overlapping fashion.

For example, a 5x5 image:

12345
6789A
BCDEF
GHIJK
LMNOP

Could be made to be 4x4 pixels, like this:

1245
679A
GHJK
LMNP


And it could be made to be 3x3 pixels, like this:

145
GJK
LOP

[axilmar]

Another crazy idea might be the following: during a blit operation, either the CPU or the copper modifies the blitter source registers so as that they repeat a previous pixel of a line, effectively doing actual scaling.

i.e. if the blitter has to blit the following line:

123456789ABCDEFGHIJK

then if pixels '5', 'C' and 'H' must be duplicated, then the copper or CPU could affect the blitter source position while these pixels are drawn in order to repeat the operation, in order to duplicate pixels.

The result would be:

1234556789ABCCDEFGHHIJK

I know the timings of the CPU, copper and blitter are known exactly, but I don't know if this can actually be achieved due to other issues.

[defor]

Originally Posted by axilmar

Another crazy idea might be the following...

Are you talking about OCS or AGA (with some beefed up expensive turbo card?)
Do you know that Amiga blitter doesn't work with separate pixels but with data aligned to "words" only (= 16 pixels)? Pixel zooming is not an easy task for standard Amiga. Especially if you need to scale many objects separately. Don't be fooled by demos (for example by the famous Elysium/Sanity full-screen zoomer).

[saimon69]

Originally Posted by defor

Are you talking about OCS or AGA (with some beefed up expensive turbo card?)
Do you know that Amiga blitter doesn't work with separate pixels but with data aligned to "words" only (= 16 pixels)? Pixel zooming is not an easy task for standard Amiga. Especially if you need to scale many objects separately. Don't be fooled by demos (for example by the famous Elysium/Sanity full-screen zoomer).

Yup, you want zoom you have to follow the Lotus approach and have several pre-scaled assets

[buggs]

Originally Posted by Samurai_Crow

Last update 2018, FEBRUARY

Yes. It needs updating.

Maybe you'd like to have a look at https://github.com/HenrykRichter/Cannonball-C for an updated version (binary archive in release/). It sill requires tons of CPU (060) and Picasso96 in HiColor but renders faster than the MVG's old port and has all graphics enabled.

[Samurai_Crow]

Originally Posted by buggs

Maybe you'd like to have a look at https://github.com/HenrykRichter/Cannonball-C for an updated version (binary archive in release/). It sill requires tons of CPU (060) and Picasso96 in HiColor but renders faster than the MVG's old port and has all graphics enabled.

Not me. That post you quoted was over a year old! Maybe this was supposed to be directed toward somebody else.

[axilmar]

Originally Posted by defor

Are you talking about OCS or AGA (with some beefed up expensive turbo card?)
Do you know that Amiga blitter doesn't work with separate pixels but with data aligned to "words" only (= 16 pixels)? Pixel zooming is not an easy task for standard Amiga. Especially if you need to scale many objects separately. Don't be fooled by demos (for example by the famous Elysium/Sanity full-screen zoomer).

I know how the hardware works, more or less (bitplanes, dma channels, blitter minterms, copper lists, etc etc).

I was talking about timing, for example, MC68000 code in such a way that when the blitter decides to move and mask word 'x', the cpu (or copper) changes the registers and so it actually moves another word 'y'.

But now that I think of it, I don't think it's doable.

I know the tricks these demos do.

Here is another thought: I wonder if the MC68000 could calculate, on the fly, the scaling of an image, in terms of shifts and ORs. Since the system actually works on bitplanes, each bitplane's shifting and ORing of words would be the same numerically, right? this shifting/ORing could actually be precalculated and applied on the fly for each bitplane.

For example, if we have a 3x3 bitmap that looks like this:

010
111
010

Then in order to make it 4x3, for example, one would have to shift the 2 bits to the right, and OR the mid column (I don't know if the 68000 has one instruction to do that or shift part of a word).

0110
1111
0110

anyway...

[Samurai_Crow]

The 68000 does not have that capability (partial shifting) nor does the 68020, nor 68030, nor 68040 nor 68060. Chunky modes are needed for this type of bitmap scaling and texture mapping helps even more than the blitter. Of course vector scaling is another matter....

[chb]

AFAIK the only meaningful way to use the blitter for zooming is the iterative approach - split the object in two halves, blitt them one pixel apart, fill the gap with a doubled 1-pix column/row, repeat for the next zoom level. Does not work very well for fast zooms where more than 1 pix is added per frame, and needs ofc an intermediate buffer if you want to draw your zoomed object on a background or other objects.

But, if you have a lot of identical objects in a section of the track, it may be possible to keep those intermediate zoomed objects during that section and reuse them, maybe mixed with some pre-calculated zoom levels. The nice thing about an Outrun-style game is the predictability, you always know exactly what's coming next (apart from the other cars), so you could add trigger points to the track for pre-scaling, pre-estimate performance and adapt your track accordingly and so on. All this ofc complicates logic & memory management quite a bit and will not reach the raw perfomance levels of a completely pre-scaled approach. But it may look smoother.

[axilmar]

Originally Posted by Samurai_Crow

The 68000 does not have that capability (partial shifting) nor does the 68020, nor 68030, nor 68040 nor 68060. Chunky modes are needed for this type of bitmap scaling and texture mapping helps even more than the blitter. Of course vector scaling is another matter....

How about precomputing the subroutine that shifts and ORs bits? an external program could be used to create a series of shifts, OR instructions that take a bitplane of a bitmap and scale it to a specific width.

The same subroutine shall be used for all the bitplanes of a bitmap, therefore allowing scaling for planar displays.

The game could then have a table of such subroutines for each combination of image size vs scaled size.

The only question is then how fast will these be executed, within chip ram (in order to allow the resulting bitplanes to be used for blitting).

According to this (http://oldwww.nvg.ntnu.no/amiga/MC68...000timing.HTML), for the 68000, shift instructions take minimum 8 cycles, a d OR might take 8/12 minimum cycles, and moves might take between 16 and 28 cycles.

So, a list of say, 16 move/shift/OR instructions, with average 16 cycles per instruction, it would take 16x16 = 256 cycles for one line of each bitplane of each bitmap.

So if, let's say, we have 16 bitmaps to scale, and each bitmap is 64 lines tall, and has 4 bitplanes, then we have 16 x 64 x 4 x 256 = 1,048,576 cycles taken up by scaling computations on chip ram.

It doesn't seem that far fetched, even for the 68000 working on chip ram. Remember, we don't need to do the same scaling as the coinop, we only need to do a few scales between predrawn bitmaps.

Working on fast ram would allow double or even more scaling, but then I don't know how much time it would take to transfer all these data to chip ram.

And if the target was Amiga 1200 (i.e. MC68020), the results would be even better.

[Bruce Abbott]

Originally Posted by saimon69

Yup, you want zoom you have to follow the Lotus approach and have several pre-scaled assets

Is there a problem with that?

[Bruce Abbott]

Originally Posted by axilmar

Regarding huge sprites and smooth 3d motion, there is a game named Drivin' Force. Not the very best of games, but its huge sprites and 50 fps gameplay are difficult to go unnoticed.

And it runs like that on a stock A500!!!

Proof that 'huge sprites' and 'smooth 3d motion' don't make a good game. What a mess!

[DanScott]

I've investigated lots of methods of realtime bitmap scaling in various demos that I've worked on, and I can say for sure, there's no way on an A500, that you could implement any kind of real-time sprite scaling that would work for multiple on-screen sprites and keep a decent framerate.

The only real way is to use prescaled sprites, but you can look at how the sprites are constructed, and optimise the rendering and storage of the prescaled frames (for example, a palm tree, like in the 1st level of Outrun, could be built from 2 elements, the leaves area, and the trunk, which is slimmer and taller)

Unfortunately, with prescaled sprites, you don't get the "blocky" effect of objects that are passing Z=0 and coming close to the camera, which is evident in practically EVERY amiga sprite based 3d racer

[DanScott]

Originally Posted by Bruce Abbott

Proof that 'huge sprites' and 'smooth 3d motion' don't make a good game. What a mess!

Yeah it wasn't a great game overall in terms of playability, but technically, it was pretty decent for the time

[saimon69]

Originally Posted by Bruce Abbott

Proof that 'huge sprites' and 'smooth 3d motion' don't make a good game. What a mess!

Might be masochism but i dig that! Now, if the street sprites were A BIT cleaner, even better

[saimon69]

Originally Posted by DanScott

Unfortunately, with prescaled sprites, you don't get the "blocky" effect of objects that are passing Z=0 and coming close to the camera, which is evident in practically EVERY amiga sprite based 3d racer

Not a big deal if you are the player, might bother a bit if you are an observer; wonder if it can be faked with a "fake" partial [ok tried to break down things mentally and i think not; a partial masking of the border with sprites might help in theory though]

[gimbal]

Originally Posted by DanScott

Unfortunately, with prescaled sprites, you don't get the "blocky" effect of objects that are passing Z=0 and coming close to the camera, which is evident in practically EVERY amiga sprite based 3d racer

I don't mind it to be honest, it defines that "Amiga look". I'm not going to really call blocky graphics a good thing, it just looked cool to see sprites scale so smoothly (but blocky and jittery) on arcade machines at the time because there was nothing better