Arcade / Console --> Amiga conversion discussions

[zero]

I count six words moved per scanline for three sprites. No sprite bitmap DMA at all.

So in total you need 6 moves for the sprites, 2 for the road fill and two or three to change the palette. That's 11 per scanline.

Compared to blitting which needs you to wait for the blitter to complete, re-load address registers, calculate shift values and load them, then write the control registers. And do the colour palette changes, the same as my scheme. And on multiple bitplanes if you want grass/road/road markings.

In the best case you need 2 bitplanes, assuming you use dual-playfield to avoid having to share bitplanes with objects. And for the next frame you have to clear at least part of what you previously copied if you have hills.

Oh, and while the blitter is running the CPU is losing memory access slots to DMA, and the blitter isn't available to draw objects.

[redblade]

Originally Posted by dlfrsilver

A 6 buttons joystick can be used on Amiga. What's the problem ?

Wouldn't it be rather difficult to read all 6 buttons and the control stick for combos? I'm guessing reading the forward, down, down forward + punch would be a struggle on a standard A500. Might be ok on a CD-32 though? a standard direction + 1 of the 6 buttons would be rather easy, but check maybe 3 buttons at once??

[TuRRIcaNEd]

Originally Posted by redblade

Wouldn't it be rather difficult to read all 6 buttons and the control stick for combos?

Why would it be? There were a whole bunch of beat-em-ups which handled combos on the A500. At a guess it'd be a case of setting up a timeout based on the first input from dead-centre, then reading the sequential inputs into a data structure (an array or queue) and testing for specific sequences, triggering an animation sequence if it matches.

The CD32 controller used the same joystick port plug as all other Amigas (which in turn goes all the way back to the Atari 2600 VCS!), so it follows that 7 data pins are enough to read a D-pad plus 6 buttons.

The Amiga Hardware Reference Manual states that the Amiga handles two buttons (equivalent to left and right mouse), but given that the CD32 controller worked just fine with CD32 games on my A1200 back in the day (and I even wrote a little AMOS test program to check the values from the pad/button/pin combinations), I'd say it could always technically use at least 6.

[TuRRIcaNEd]

Originally Posted by zero

Compared to blitting which needs you to wait for the blitter to complete, re-load address registers, calculate shift values and load them, then write the control registers.

But the whole point of the Lotus method was that the CPU could be set to calculating the next line of the triangle (quite tricky maths for the humble 68k to do quickly as I understand it) while the blitter did the drawing work on the current line. I guess what I'm trying to say is that you may be right that the method for each individual drawing operation might not necessarily have been the most efficient, but it certainly used a "big picture" approach for all of the operations combined to be as efficient as possible.

And do the colour palette changes, the same as my scheme. And on multiple bitplanes if you want grass/road/road markings.

Nope, you can do the sky (minus the horizon/background bitmap), the grass, road and markings with a single bitplane image using the copper's ability to palette switch every 4px, plus alternating the overall palette every few scanlines.

[I have some images which demonstrate how this works, but I need to ask the permission of the person who gave them to me]

...assuming you use dual-playfield to avoid having to share bitplanes with objects.

I reserve the right to be wrong, but if I understand things roughly correctly I think dual-playfield mode is a bit too restrictive for this application, and here's my thinking... In dual-playfield mode, we're talking two playfields with 3 bitplanes (i.e. 7 colours + 1 transparent) each. This has quite a bit of potential in terms of nifty side-scrolling and parallax tricks, but it has the drawback of keeping each playfield's palette in a silo (i.e. neither playfield can access the other's palette).

Because the sky/grass/road/markings can be done in a single bitplane using copper palette changes, my feeling is that this makes using one playfield for the sky/horizon/road and the other for objects impractical, as the theoretical foreground (object) playfield needs to display the player's Ferrari, the traffic and the roadside objects and would thus require significantly more palette entries available than the background playfield.

From an aesthetic standpoint, I don't think I can remap the Ferrari into less than 7 palette entries without compromising the look-and-feel more than I'd like to. Admittedly using 7 palette entries for a single object sounds somewhat wasteful on the face of it - but on the one hand that sub-palette contains black (universally useful elsewhere), light grey (certainly re-usable) and 3 red/pink shades which could also probably be pressed into service elsewhere on the screen. If worse came to worst, the vast majority of the time those colours aren't required until about Y-co-ordinate 175 (or thereabouts) and you could poke them in with the copper at that scanline - though this would make the high-speed crash animation (where the car is drawn vertically above that line) a bit of a headache.

In general I'm thinking roughly along these lines - single-playfield 4-bitblane mode, with COLOR00 and 01 used for the sky/road/markings, 02 through 09 used for the Ferrari (including the black and light grey which can be used extensively for other objects), 10 through 12 for roadside objects and 13 through 15 for the traffic. I'm hoping to use sprites for the HUD and the couple in the player's car, which will use various combinations of COLOR16 through 31.

Admittedly I haven't worked out the best way to deal with the horizon graphics yet, but frankly we've got many bridges to cross before that becomes a showstopper!

And for the next frame you have to clear at least part of what you previously copied if you have hills.

Using a variant of the Lotus method you're redrawing the whole frame every time anyway.

Oh, and while the blitter is running the CPU is losing memory access slots to DMA, and the blitter isn't available to draw objects.

Two passes - one for the road, the other for the objects.

Obviously if anyone can spot any gaping flaws in my approach, please tell me!

[zero]

Originally Posted by TuRRIcaNEd

Why would it be?

Because you don't understand how the CD32 6 button controller works.

To read the extra buttons it uses a serial protocol. That serial protocol has very significant overhead.

What are these A500 games that support it?

[zero]

Originally Posted by TuRRIcaNEd

But the whole point of the Lotus method was that the CPU could be set to calculating the next line of the triangle (quite tricky maths for the humble 68k to do quickly as I understand it) while the blitter did the drawing work on the current line.

No. On an A500 only the CPU or the blitter can access memory, not both at the same time. So if the blitter is copying data then you have a choice: stop the CPU until it finishes or share bandwidth between the CPU and blitter and both run slower.

The blitter is not free. Using it slows down the CPU. Even on the A1200 you only have a small instruction cache.

The calculations are actually not too bad at all. Lookup tables make it pretty fast. It's the rendering that makes it slow.

Nope, you can do the sky (minus the horizon/background bitmap), the grass, road and markings with a single bitplane image using the copper's ability to palette switch every 4px, plus alternating the overall palette every few scanlines.

That scheme would waste half the colour palette and only give you a horizontal resolution of 80 for the road.

[I have some images which demonstrate how this works, but I need to ask the permission of the person who gave them to me]

Please do.

In general I'm thinking roughly along these lines - single-playfield 4-bitblane mode, with COLOR00 and 01 used for the sky/road/markings, 02 through 09 used for the Ferrari (including the black and light grey which can be used extensively for other objects), 10 through 12 for roadside objects and 13 through 15 for the traffic.

How are you going to make the road use only two colours if you are only rendering into one bitplane for it?

[TuRRIcaNEd]

Originally Posted by zero

No. On an A500 only the CPU or the blitter can access memory, not both at the same time.

So you load the values required for the calculation into the data registers, no? Based on what I've been told, the Lotus code was structured such that the next thing to be blitted would always be held in address register a4. That way the CPU should barely have to touch the memory (if at all) whilst the blit is being performed.

That scheme would waste half the colour palette and only give you a horizontal resolution of 80 for the road.

With respect, how would it waste half the colour palette? The dual-playfield method would waste more by snaffling two palette entries for transparency (one each per playfield) and restrict each playfield to 8 palette entries which can't be shared.

As far as using the copper to change palette entries horizontally for the road, presuming COLOR00 is being used for the "tarmac" and COLOR01 for the "markings", it's only COLOR01 you'd need to change, and because most of each strip is COLOR00, that can be done inbetween the markings without sacrificing resolution, if I'm not mistaken...

How are you going to make the road use only two colours if you are only rendering into one bitplane for it?

Single bitplane is effectively two colours, no? Strictly speaking it would be taking single bitplane data and rendering it into a 4-bitplane display buffer.

As far as the CD32 controller goes, thanks for the heads-up on the serial data feed. Note that I didn't say A500 games used the CD32 controller, I specifically said that some games I had on my A1200 used the CD32 controller (Gloom is one that springs to mind). I might be mis-remembering what I tested with my AMOS program on the A500 (we are talking about 24-25 years ago now...) and later on the A1200 - it could have been a 3-button Mega Drive joystick we had lying around.

[zero]

Originally Posted by TuRRIcaNEd

So you load the values required for the calculation into the data registers, no? Based on what I've been told, the Lotus code was structured such that the next thing to be blitted would always be held in address register a4. That way the CPU should barely have to touch the memory (if at all) whilst the blit is being performed.

Holding the data values in registers doesn't help much because the CPU still needs to fetch instructions from RAM. It also means you can't use a lookup table so how are you going to perform this floating point calculation efficiently without an FPU?

I think what that comment about Lotus means is that A4 is used to communicate with an interrupt triggered when the blitter finishes or something like that. Otherwise it makes no sense.

With respect, how would it waste half the colour palette? The dual-playfield method would waste more by snaffling two palette entries for transparency (one each per playfield) and restrict each playfield to 8 palette entries which can't be shared.

It's simple binary mathematics. Say you have 3 bitplanes, 8 colours (to keep it simple). So each pixel's colour is determined by 2 bits, one from each bitplane. And you want to draw the road using only one of those bits.

Here is every possible combination of bitplane 0, 1 and 2:
210
---
000
001
010
011
100
101
110
111

As you can see, changing any bit narrows the choice of the other bits to half the available colours. This is true no matter how many bitplanes you have, each bitplane will always "select" half the palette.

For example, if you render the road on bitplane 0. A 0 is grass, road is 1. Then everything drawn over the grass (0) will use even colours and every drawn over the road (1) will use odd colours. If you switch to bitplane 2 then everything drawn over grass will use colours 0-3, and everything drawn over the road will use colours 4-7.

Strictly speaking it would be taking single bitplane data and rendering it into a 4-bitplane display buffer.

So you want to do 4x blitter copies per line, plus copperlist for colour changes... And you think that will be faster than just a copperlist for colour changes a sprite positioning (no bitplane DMA for sprites).

[TuRRIcaNEd]

Originally Posted by zero

And you think that will be faster than just a copperlist for colour changes a sprite positioning (no bitplane DMA for sprites).

I didn't say that, I was simply saying that my intention is to start with tried-and-tested methods which, frankly, I stand a chance of understanding.

With a bit of luck we'll have the basis for a simple tech demo sometime early next year - I certainly intend to stick it up on GitHub, so if you want to take it and try implementing your idea, you'd be more than welcome to!

[PS. I do understand how bitplanes work, sir... As I said, the idea is to do it with multiple passes, drawing the road first (while noting object positions), then blitting the horizon/sky, finally drawing the objects in reverse. The objects blitted over the road will reset the planar values in that case I believe...]

[PPS :

Originally Posted by zero

Please do. [show the images demonstrating the Lotus road technique]

OK, so in my earlier post I showed the single-bitplane image used as the blit source (this is Lotus 2, but the principle is the same):

Originally Posted by TuRRIcaNEd

If I understand this correctly, the following two images show what is generated with the alternate-scanline copper switch turned off. Firstly with a white kerb (COLOR01 = white or light grey) :

Then with a red kerb (COLOR01 = red, then dark grey for the tarmac, then red again for the opposite kerb):


With the copper alternating those values at the required number of scanlines you get this :


Note that the "kerb" is relatively thick horizontally compared to the road markings (at least 4px until some way into the distance). As I understand it this is probably to allow for the OCS/ECS copper's 4px "resolution" when it comes to mid-scanline palette changes.

]

[zero]

Your solution ultimately isn't that dissimilar to mine, the main difference being that you want to use bitmaps and I want to use sprites for the road markings and edges.

So if you just changed to using sprites instead of bitmaps you would save a massive amount of blitting, and get some extra colours for free potentially due to sprite palette mapping.

[TuRRIcaNEd]

Originally Posted by zero

Your solution ultimately isn't that dissimilar to mine, the main difference being that you want to use bitmaps and I want to use sprites for the road markings and edges.

The question is how you propose to use the sprites for that. I may be misunderstanding, but it seems like a hell of a lot of complexity any way I see it. Could you elaborate on how you'd use them?

[coder76]

This problem is probably possible to solve with sprite multiplexing, under OCS/ECS you can cover whole screen with a single sprite, by writing manually each 16 bit spritedata into sprite POS and DAT registers. But there is only time for the copper to change one of the DAT registers, so only 1 color is possible, and in lores, only 4 bitplanes can be used, or else bitplane DMA starts using too many cycles, and copper is slowed down to much.

The copperlist would look as following, for one sprite (spr0datb is set to 0 somewhere else)

dc.w waitY,$fffe ;first line of spritedata
dc.w spr0pos, yposxpos
dc.w spr0data,data00
dc.w spr0pos, yposxpos
dc.w spr0data,data01
...
dc.w waitY,$fffe ;second line of spritedata
dc.w spr0pos,yposxpos
dc.w spr0data,data10
dc.w spr0pos,yposxpos
dc.w spr0data,data11
...
end of copperlist

Here, ypos and xpos must be filled in with CPU with correct values, and gaps can be left, so that the sprite doesn't need to cover every pixel on screen. Only one sprite can be multiplexed in this way at a time, and the rest of sprites should be still available for normal use. There should also be time for color changes with copper on start of each line, before sprite data starts.

The idea with 3 sprites and attempting to cover all road markings with those won't work well, as they are just 16 pixels wide and the road is bending in x-direction. Reusing sprites in y-direction leaves a gap of 1 pixel between sprites, if done with spriteDMA, so you will possibly get holes in road markings.

[zero]

Look at the road bitmap. The edges and road markings are just lines of a given width. The width doesn't even change between most lines, only occasionally. So all you need to draw them are some 1 pixel high sprites that are the width of the line, and a copperlist to set the X coordinate every line.

You don't need bitmap DMA for them, when you want to change the width of the line you can just write that data directly into SPRxDAT with the copper.

coder76 has the right idea. I'd use multiple sprites though, as none of the road markings or edges are ever more than 16 pixels wide anyway.

[sandruzzo]

On Aga, we can use copper only for changing shift register and bitmap pointer for each roads' scan line! If we use a pre animated road, we can archive full texture road!

[TuRRIcaNEd]

Originally Posted by zero

So all you need to draw them are some 1 pixel high sprites that are the width of the line, and a copperlist to set the X coordinate every line.
...
coder76 has the right idea. I'd use multiple sprites though, as none of the road markings or edges are ever more than 16 pixels wide anyway.

Understood, that makes more sense now. The issue I see is this:


I'm intending to use sprites for the couple in the Ferrari and quite a chunk of the status HUD. Won't that be too many for the sprite hardware to handle (to say nothing of having to poke a lot of data in with the CPU)?

In actual fact, the method you're describing sounds very similar to how Pole Position was implemented on the Atari 2600 VCS. IIRC it used a hardware trick which re-utilised the two "missile" graphics on each subsequent scanline for the kerbs, and the "ball" graphic for the road marking.

[coder76]

Originally Posted by TuRRIcaNEd

Understood, that makes more sense now. The issue I see is this:


I'm intending to use sprites for the couple in the Ferrari and quite a chunk of the status HUD. Won't that be too many for the sprite hardware to handle (to say nothing of having to poke a lot of data in with the CPU)?

In actual fact, the method you're describing sounds very similar to how Pole Position was implemented on the Atari 2600 VCS. IIRC it used a hardware trick which re-utilised the two "missile" graphics on each subsequent scanline for the kerbs, and the "ball" graphic for the road marking.

The road marking sprite uses up only one sprite, if multiplexed, but it can have only one color. The rest of sprites can still be used with spriteDMA as usual. I would make whole car with 4 sprites, so you can have 15 colors and 32 pixel width. Not a good idea to waste sprites for only couple. Then a few sprites left for HUD, which is not really enough for what you want. Instead you could arrange those vertically on both sides of screen, this would work better with amiga sprites, as they can be as tall as whole screen. Better make some compromises, instead of being too faithful to original game, the Amiga can't anyway produce a faithful copy of original Outrun game. For the player, it is most important that car looks good and colorful, and that it has good animations when turning car.

[TuRRIcaNEd]

Originally Posted by coder76

I would make whole car with 4 sprites, so you can have 15 colors and 32 pixel width.

I don't want to resize the car, so I'll be trying it with a bob first.

Instead you could arrange those vertically on both sides of screen

The aim is to get as close to the arcade visual as I can, hence why I want to do them as an overlay.

...the Amiga can't anyway produce a faithful copy of original Outrun game.

Maybe so, but the intent of the project I'm trying to kick off is to get things as close as possible. Have you tried my tunes yet [ http://psychodelicacy.net/modplayer.php ] ?

[coder76]

Originally Posted by TuRRIcaNEd

I don't want to resize the car, so I'll be trying it with a bob first.


The aim is to get as close to the arcade visual as I can, hence why I want to do them as an overlay.


Maybe so, but the intent of the project I'm trying to kick off is to get things as close as possible. Have you tried my tunes yet [ http://psychodelicacy.net/modplayer.php ] ?

Ok, then if car is done as a bob, there should be enough sprites to make both sides of status HUD, maybe you need 2 x sprites for each, and 3 colors only.

Yes, I listened to the tunes, seems like good, but these tunes, they do take up maybe too much memory. If the target is 1 MB of memory, then some optimizations need to be probably done on samples, maybe reuse same instruments in the tunes, and load in samples separately. .mod files won't let you do that, as all samples and pattern data is saved into a single file.

[TuRRIcaNEd]

Originally Posted by coder76

Yes, I listened to the tunes, seems like good, but these tunes, they do take up maybe too much memory. If the target is 1 MB of memory.

We're starting with 2MB ChipRAM (AGA setup). I figure it's best to aim for the best fidelity possible, then optimise/downconvert where necessary. I'm going to try to get them down to 150k or thereabouts - which is still pretty big for ingame music (traditionally they tended to be around 50-80k max), but because I'm not worried about squeezing the executable into 1MB or fit on floppies (yet) it shouldn't be too much of an issue.

[zero]

Just move the HUD off the main play area.