Dual playfield mode and the racing game engine

[ImmortalA1000]

If you look at early 3D racing games, like on PS1 or Saturn rally games, you notice it has a more cinematic look due to a dual layer display where the road and cars are on the foreground layer and the background layer is just that, a panning [and sometimes zooming/perspective shifted] background image of some mountains.

I was wondering if you could still get the speed of Lotus II engine using dual playfield mode with 6 bitplanes being required?

I read the absolute maximum DMA exclusive (ie CPU blocking) chipset bandwidth was 7mb/s which is a lot considering a 16 colour screen is 32k of data BUT I need some technical assistance at the 'ideas stage'. I suspect this mode would prevent you achieving Lotus II levels of framerate even with Shaun Southern levels of genius because of the extra 2 bitplanes in play but I am no expert, I've forgotten waaaayyyy to much thanks to the stress of potentially being killed every time I go to the shops to do food shopping!

Any help appreciated

[paraj]

Assuming OCS PAL, each frame you have 69486 (313*222) usable DMA slots (at 5O fps that's where the ~7MB comes from as 313*222*50*2 = 6948600 bytes/second = 6.6 MB/s).

6 bitplanes at 320x256 uses 30720 (320 * 256 * 6 / 16) each frame, leaving 38766 for everything else (disk access, audio, sprites, copper, blitter and CPU in that order).

To give you something to compare to, 38766 slots is enough to copy a little less than 4 bitplanes at 320x256 using the blitter (note: copy, not use cookie cut).

Of course if you lower the resolution you'll have more available, or drop the update frequency to 25 fps (though most of the above mentioned DMA uses still need to run every frame).

[ross]

Who stole a cycle !? (usually 227-4 are available, per line)

Hi paraj!
I'm glad to see you around here more often lately.

[paraj]

Originally Posted by ross

Who stole a cycle !? (usually 227-4 are available, per line)

Hi paraj!
I'm glad to see you around here more often lately.

Hi Ross, Thanks


You're most likely right, I was just going by what HRM (http://amigadev.elowar.com/read/ADCD.../node012B.html) says (minus the refresh slots):

The total of 227.5 cycles per horizontal line
includes both display time and non-display time. Of this total time, 226
cycles are available to be allocated to the various devices that need
memory access.

Is that the NTSC short/long line stuff or HRM being inaccurate? So many details...

[ross]

For PAL:
- 313 or 312 lines (dependeng on LOF, 313 is the Amiga default for 'progressive' mode), 625 in interlace mode (LOF auto-toggle)
- 227 DMA slots per line, 4 of which are unusable, for memory refresh

NTSC:
- 262 or 263 lines (depending on LOF, 263 default), 525 in interlace mode (LOF auto-toggle)
- 227 or 228 slots per line (LOL auto-toggle in NTSC mode), alternating, 4 unusable; 227.5 is only a 'physical' thing, hsync is generated at constant time for the display device

[rothers]

I don't quite understand why this needs dual playfield, just adjust the mountain picture as you draw the screen. I think some Amiga racing games already do that.

[ImmortalA1000]

Originally Posted by rothers

I don't quite understand why this needs dual playfield, just adjust the mountain picture as you draw the screen. I think some Amiga racing games already do that.

The reason I was wondering about it was if you have a low altitude part of the track and 75% of the screen is background then you have to shift 320x150 pixel block of 3 bitplane graphic data in smooth pixel movements with the blitter. If you have dual playfield mode you can just move the screen around using scroll registers, using less bandwidth.

Didn't say it was a good idea on Amiga, just that it's a trick employed on first gen 3D racing games using 2 layers of parallax so your eye is drawn to lovely pixel art backgrounds and away from the wonky textured polygons in that 1994/95 sort of era. Thought maybe if the 68000 CPU is used to draw say a shadow layer for a night driving game is would mean you are only drawing polygons on a low bitplane screen which I assume helps as few 32 colour polygon engines exist on the Amiga.

I was just thinking about it based on what is already provided by the hardware feature set and if using it makes sense, or not

[zero]

I've been thinking about this kind of things for a few years. I think the fastest way might be to use the copper and sprites to generate the track, so they use zero bitplanes.

The copper would basically draw wide stretches of tarmac per scanline, and then sprites would neaten up the edges with pixel accurate positioning. Sprites could also do road markings.

Then you can use whatever optimized blitting you like for stuff on the bitplanes like track side objects and cars.

One day I'll get around to trying it.

[ImmortalA1000]

I was thinking of a rally game so only 1 car, and doing that via the hardware sprites (palette entries being unused for colours 17 to 32) but 64 pixel wide block of sprites might look stupidly small.

For the rest having an oversized copperlist rich 'photorealistic' background which is just panned/scrolled around as the lower playfield and a simple texture map engine for the overlaid road/mud layer with maybe just 1 bitplane for actual mud/dirt track and the 2nd and 3rd bitplane maybe for patches of green or something and again copperlist for fake depth cued palette.

Think of it as a 16bit version of Colin McRae 1/Sega Rally.

Basically it hinges on whether the 3D texture mapped stuff on foreground playfield would be as fast as if you used a 3 bitplane regular screen to draw on, hence the question. Also hinges on how much time is wasted 'scrolling' copperlists to match vertical movements of background being moved (which some 3D/2.5D racing games never bother to do for backgrounds) and change in height of drawn road/dirt track.

Might be obviously a dumb idea, I am not a coder let alone Shaun Southern exceeding demo coder, which is the sort of coding the idea hinges on and some very lateral thinking in the graphic design department.

(textured is not textured polygons like on a PS1/Saturn game but more like the dirt road effect in Lotus III/Lotus RECS...ie something a step above raster bars of flat polygon roads done before).

e.g. half way between Lotus II on Amiga and Racer 2 on the Falcon, not the quality of the texture mapped road engine but how the road is drawn in isolation over the panning separate photorealistic background underneath. Sega Rally does this as does Colin McRae 1.

[rothers]

Is there a 3D game on the amiga which uses dual playfield?

It seems like a really good way to mix 3D and 2D graphics...

[redblade]

Originally Posted by rothers

Is there a 3D game on the amiga which uses dual playfield?

It seems like a really good way to mix 3D and 2D graphics...

I assume flight simulators? With the front playfield being the cock pit and the 2nd playfield being the 3d vector gfx? I can't imagine them writing the cockpit every frame, I guess writing words wouldn't be too hard on the 68k to update the cockpit, or just update the part of the cockpit with changed status.

[ImmortalA1000]

I think from memory Flight Simulator II by Sublogic or other flight sims of the late 80s just draws into a rectangular area of the same screen in full screen mode so cockpit/status panel isn't overlapping so may just be a copperlist change of screen memory location midscreen. Not sure.

Not just polygons though, the 2.5D "3D" scaling levels on Unreal seem to have 3 colour blocks of scaling graphics so I assume that lack of color helps keep the speed up.

1.2.3.
*music starts*
#all I want for Xmas is a coding brain like Southern, like Shaun Southern

(lol and of course only if you can have the speed of 3 bitplane/8 color graphics in the 6 bitplane dual playfield mode on an Amiga 1000)

[sandruzzo]

With copper and bitplane shift you can have full textured road whitout wasting any blitters' and sprites' DMA. I did some test, very effective way!

[zero]

Originally Posted by sandruzzo

With copper and bitplane shift you can have full textured road whitout wasting any blitters' and sprites' DMA. I did some test, very effective way!

You can, but then you need dual playfield which uses lots of DMA too. That's why I think sprites+copper for the road is a good idea, uses less DMA than all other options.

[sandruzzo]

@zero

You'll have faster bliting and even faster screens' restore!

[zero]

I know what you are getting at, what I'm saying is that if you use a single playfield you get the fast blitting and fast restore, and draw the road with the copper and sprites.

Do you understand what I mean about the road?

You use the copper to set the background colour to green for grass, and to black for part of the scanline for the road surface. The copper can only change colours every 8 pixels, so the edges of the road are just drawn up to the nearest 8 pixels.

Then to make the edges smooth you put sprites over them. The sprites can have a pattern like alternating red and white stripes. You can use another sprite for the centre line road marking too.

Now you don't need dual playfield, and you only have to clear areas you blitted to because there is no background. I think with a driving game you could probably optimize the clearing a lot because many objects will overlap.

[sandruzzo]

You can do road animation by bitmap so you'll have it fully textured, and with copper you have to change only bitplanes' pointers and shift register. Thats' it

[Jobbo]

Zero

I see what you're saying and I think it's a really excellent idea.

Likely much better use of bandwidth than dual-playfield.

I could imagine Lotus2 might even manage to squeak out 50hz with such an approach.

[sandruzzo]

What I was talking about:

[ Show youtube player ]

[ImmortalA1000]

Originally Posted by sandruzzo

What I was talking about:

[ Show youtube player ]

I don't want a Pole Position looking road at all, Shaun Southern already did the best OCS 2.5D racing game engines possible so that would be a thread about "why isn't anybody hacking the Lotus II engine to make a rally game?")

You know when you take the wrong turn in level 1 of Chase HQ driving on the dirt road for ages...that is exactly the look I want, combined with a travel sickness inducing opposite direction moving background playfield with MANY copperlist so an 8 colour 'photorealistic' background in the distance effect works. Ideally I would like it to be a bit like a mountain side road, think of the later level of Sega's original F1 game Turbo when you are going round the blind corner done with Sega's Turbo OutRun sprite scaling hardware type look.

General response to rest of the replies here.

There is no point using the restore on blitter as the blitter in my idea is just copying your 1-3 bitplane copper enhanced 320x100 static area 'road' on the foreground playfield on a rally game with only the 'road' being drawn on that foreground playfield so no need to save backgrounds before blitting. The 'photorealistic' 3 bitplane background of just 8 colours is on the background playfield and is just scrolled around the screen. I haven't decided on how to fake the textured road, could go with my original 16bit refreshed Buck Rogers Arcade way of doing it (sets of 2 bitplane 8 frame repeating anims for say 5 or 7 positions of road curve from left, straight ahead, right turn), some sort of Sega 2.5D scaling overlaid bitmap engine like powerdrift, or CPU and/or blitter hack of manipulating a 2 bitplane 320x100 area to make the road. Maybe it's better to do a 3 bitplane 320x100 area and draw various curves in the road (first level/course type on Lotus III in RECS track menu) but make them slightly irregular for an Amiga 1000 version of the muddy ground texture of PS3 Motorstorm. Either way we are going for the look of colin mcrea rally muddy floor not a F1 racetrack grey solid tarmac road.

All the Amiga hardware sprites will be used (4x 3 colour sprites and 2x 16 colour sprites for where I have to draw tail lights) to draw your Lancia Delta, negating the need for anything other than maximum speed blind blits overwriting the same 320x100 pixel area on foreground playfield. I assume blitter performance and blitter setup time is better efficiancy/low impact via blind blits.

If you want other cars on the road we have a problem, but this is a rally game and WRC 5 on PS2 had no other cars on the road

That was my idea anyway

On AGA I would just make the bitmap screen 256 pixels wide and use the AGA 64 pixel wide 16 colour sprites as a 16+ colour background with copperlist on top and use the blitter/020 for the 256x100 pixel 'textured road'

There may be zero advantage to doing blind blits to fixed 320x100 pixel area on a foreground playfield with a background playfield of at least 352x100 pixels just being wrapped around via a scroll register left and right 16 pixels on repeating image. Not even sure you could make a decent sized and not shit looking Lancia Delta Martini rally car sprite even using all the OCS Amiga sprites, they are very limiting (no horizontal expansion, only 16 pixels wide, you only get 4 if you want 16 colour sprites like a megadrive etc etc).

Imagine if some nutter coded Sega Rally Medadrive edition, think along those lines of VF2 for Megadrive expectations and you get the idea, which may be a doomed idea.

If we were talking C64 I have all sorts of things I know can/can't be done technically but the real ins and outs of OCS (the only chipset that interests me as I am only interested in making stuff that will run on my Amiga 1000 lol) are a complete unknown quantity beyond the most BASIC way the system works as a whole.

PS textured road simply means it doesn't look like the road drawing routines of things like Lotus 1 or OutRun tarmac bits....something more like dirt road in level 1 of chase HQ or something else to give a dirt road effect via 2.5D or even just various 2 bitplane anims (your car is moved left/right on screen as you are thrown round the corners if you take the turns slow/fast like most 8/16bit racing games do). It doesn't mean 50fps fractal/voxel/actual polygon texture mapping perspective fuelled routine as such.