An example of AGA sprites in OutRun
 

I took some source graphics from the coin-op because I was curious what you could do with AGA sprites. The palm trees needed to be trimmed down a bit to 64 pixel width but they don't use more than 13 colours so I got this far.

https://youtu.be/4bYvoeECrMQ

Clearly not enough to match the Megadrive with sprites alone but you could use the blitter for smaller trees further in the distance and then use the faster sprites to move/update 4 largest tree objects in view.

I don't know if you could re-use the sprites to make 4 trees per side as the graphics are mirrored for left/right trees. I suspect this is as helpful as they can get in this situation where the sprites need to share the same scanline at any distance.

The idea of mixing sprites and blitter objects might work in some special cases. For "Out Run" this needs a lot of additional thoughts, because almost all other stages in Out Run paint wider objects into the landscape. This kind of prevents the use of sprites.

Also, video priority is always an issue in 3D games, and this is no exception. For example, sprite-based large trees need to have video top priority almost all the time. But not always: For example in case the car crashes and bounces, sprite-based trees need to be painted on top of blitted trees. But at the same time, they need to stay behind the bouncing car. But the car has to be blitted just like the smaller trees, since sprites are in use by trees. So what to do now? Can be solved, with some very clever cookie cutting, etc. But such code is difficult to manage and maintain if we are talking about a complete game.

For practical reasons, I would probably go for Dual-Playfield, blit the landscape, do some coppermagic to paint the road. Sprites would perfectly fit the Ferrari, scoreboards, and text overlays. Not sure if 50 fps can be achieved like this. Probably more like 25 fps.

I would use sprites for the car and the scores. Things that are on-screen all the time and in front of everything. The rest would be pre-scaled bobs.

(now I read buzzybee post and no I didn't copy it, 2 people are just telling the same thing :))

I'd use sprites for all the cars, lorries and player.

Blits for everything else.

The cars in the road are such a major part of the game and are often overlooked in many conversions.

If you're going AGA and 32 colours then you could do some clever palette work to increase the number of roadside objects with half the blits...

Alt dual playfield would also have some good advantages.

Yeah it's not really going to help an actual conversion of this entire game, you could do part of the first level with these modified palm trees. as I mention in the YT vid description these are the most narrow objects and I still had to trim 33% off them but it does show just how impressive AGA sprites are.

So it's really just to show how massive the AGA sprites can go (16 colour 64 pixel wide/screen height) in a way people can identify with. Would save a massive amount of blitter time in a 2.5D racing game as the AGA blitter isn't a massive improvement when you consider the 8 bitplane method of generating 256 colour displays and using the blitter efficiently is something only a handful of Amiga coders ever did in game engines sadly.

If it's not going to be 128 colours minimum + sprites personally I don't see the point.....I have MAME installed on my PC :)

The idea about dual playfield mode was something else I was toying with on an idea for a rally game to save blitter time. My idea was a static background with lots of copper help that is moved horizontally/vertically along with the associated copperlist and the top layer would be 15 colour dirt road/ground layer and 4 cars max on screen as AGA 64 pixel wide 16 colour sprites. Generally in rally games you hardly see any other cars on the road. This would mean all the background movement is a simple case of moving the bottom playfield around with smooth scroll hardware rather than messing about with blitter and restoring backgrounds etc, if I am only updating one playfield then all I need to do is blind blits and build up the road from moving 'textured dirt' bobs to make up the screen possibly. I am NOT a coder, I will NEVER be able to do game engines as chipset efficient as Beast 1 or Lotus II and sadly all the ideas I have graphically would need that sort of coding talent to be worth taking further. They are just interesting ideas. Lateral thinking is 100% required when making gobsmacking game engines for OCS so same must be true for AGA.

On an AGA machine you could do a nice fast Afterburner type game in dual playfield and just cheat with 8 pre-rotated 16 colour backgrounds on bottom playfield panned around the screen that you just swap out and build up the ground with blits on a 320x128 pixel area only of the top playfield etc as a super efficient way of using chipset bandwidth. It's just ideas of how to use the unique bits of Amiga vs the very easy to develop for consoles with massive copious sprites and very very colourful and copious parallax layers and hardware bitmap rotation in hardware but bugger all RAM to play with like PCE/MD/SNES has.

AGA sprites are 100% ideal for something like SF2/MK (did some vids on that years ago) but they can do some of the heavy lifting to help the blitter in some other cases, ditto for dual playfield for 2.5D racing games with moving horizon/background. Just interesting to see what you can do in the AGA chipset toolbox, as always with the best Amiga game engines you have to get creative and use every advantage possible.....a bit like how they cheated on Saturn conversion of VF2 (creative use of various hardware tricks the Saturn did well vs lack of polygon grunt over PS1 GPU).

@ImmortalA1000

You could use some precalculated frames in order to let the road move, and have it textured

Here My simple test:

https://www.youtube.com/watch?v=4Z-r...ature=youtu.be

Interesting. I am going to build it up using 2.5D bobs like Drivin Force does and Sega Powerdrift arcade etc rather than actual textured 3D.

I did actually make some nice images for the Lancia Delta in Martini trim so I could see about making them 15 colours. Bit busy working on my house again these days....probably shouldn't have stripped it bare as soon as I moved in but the smell of dog pee and fur was not to my liking :)

@Thats' 2d, I use the road as lookup table. I think with interleaved bitmap and some fast bob(non restoring background), you can archive a very good results

I am trying to make something like Sega would have done for Sega Rally if they only had access to Afterburner/Super Monaco GP type sprite scaling 2.5D arcade hardware. Think of non tilting floor from arcade Powerdrift type effect but with no roadside objects. Looking at what genius coders squeezed out of Drivin Force and Lotus II on my A1000 it is not technically impossible for an A1200 to manage something impressive probably.

As it's not really feasible on OCS/ECS sprites to do even 1 car on screen, they are just too limiting as a 64 pixel wide group of 4 15 colour sprites is just too small so I plumped for AGA sprite spec.

It took days just to get one decent looking Lancia Delta Integrale sprite layer. Any less than 128 pixels wide and the 3D rendering looks like crap before you even split it down into a pair of 64 pixel wide 15 colour blocks for each sprite. I have 4 more to do for both the Lancia and Toyota Celica GT rally car. 9 sprites in total, 4 mirrored left/right sprites and a centred sprite. Really horrible job, real donkey work, and I am mega busy with hard labour renovating my kitchen for the next few weeks then many more rooms to plaster etc. Not good.

It won't make sense until I have finished all the graphic assets. After the cars are done I have to work out in 2.5D what I want to do and then find/create suitable 'texture' bobs for drawing the Sega Rally easy level knock off style muddy track.

I may just make it using a looping IFF anim as a proof of concept, half screen 3 bitplane anim playback on upper playfield of a "turn" in the track, scrolling lower playfield of seamless 640 pixel wide background scrolled left to right constantly and a few frames of the car sprite adjusting its tail slide round the bend. Maybe by Xmas I will get that far!!

For now I have only done 1 sprite each for the 2 cars of Sega Rally, not even a fake background.

https://www.youtube.com/watch?v=y8Oo1e1-2hs

I was thinking, for a power drift kind of game we should be able to calculate how many bobs can be positioned per frame per machine and use that number as a base to display approximately on the screen - ok some elements might need priority but in example road elements can be selected from a detailed map

I do have a question for you regarding that video. Is that running on an AGA system while using hardware Sprites? If so, I'm curious how you got around the problem of having only one 15 colour palette to use for all attached Sprites (which is one of the more annoying weaknesses of the AGA chipset - they fixed the colour issues in the case of 3 colour Sprites by offering odd/even palettes to choose, but didn't do anything to make 15 colour ones better other than a choice which 15 palette registers they all get to share).

Now, I know you can change which 15 colours are used for attached Sprites on the fly using BPLCON4 and it's certainly doable to repeat one or more BPLCON4 changes per scanline to generate a split on a given X position, but timing that correctly is a pain. Mostly as it both has this odd one-hires-pixel delay before the changes take effect and it has to fit around the display fetch blocks (considering the target screen mode).

I suppose that if the cars never move, or rather the X position of the split using BPLCON4 never has to change, it probably can work, but if you're proposing to move these cars arbitrarily on screen this is going to be an issue. In particular, you can't overlap Sprites using different palettes like this.

Talk about black cat in the matrix, I was sure somebody told me you defined a quad of 16 colour palettes above palette entry 191 for the sprites. Actually makes little difference for the 2 paired AGA sprites whether you split them into two 15 colour palettes or one. I think only one colour was chosen different between both palettes in my paint program, you wouldn't really notice the difference at all. I did them as a single palette for the entire 128 pixel sprite first anyway, they look the same, you get the 'Martini stipes' colours on both halves of the middle 64th pixel point but I did it both ways out of curiosity. I am more worried that 9 frames is not going to be smooth enough but I only rendered 9 positions.

I didn't plan on having more than 1 car ever on screen, a bit like WRC on the PS2....just you and the road and a timer on screen. Your car sprite never moves, I just change it to 1 of 9 frames from far left to far right steps depending on your turning angle, the dirt track and the background playfield scrolling is all that moves. The demo would not even move the road, it's just going to be a pre-calculated 'turn' that is rendered, so I could give up and just use a Blitz IFF anim playback of 320x160 x8 colours and a static copperlist.

I suppose you could have two Lancias or two Toyatos on screen to overtake if that's what you wanted to do but let's be honest I am no Shaun Southern and the textured bit is going to be not very efficient, we are talking n00b blitter coding by me in about 4-6 months the way my DIY is going :)

I already picked dual playfield so I can do blind blits using rectangular bobs that overlay on just half of the top playfield so the blitter is doing nothing more than the dirt track. Maybe it will turn out interestingly nice for a demo segment type thing that just fades in and runs for 10 seconds and fades out :)

What it does mean is that there is not going to be any SF2 demos for AGA sprites lol so good to know if it is one global 16 colour palette for all AGA sprites :)

To be completionist about it (more info is always good :D): you have two palettes for AGA Sprites. One for even Sprite channels (unattached) and one for odd Sprite channels (unattached). The palette for odd Sprite channels is also used for all attached Sprites.

You can select a 16 colour block for these two Sprite palettes, which can be any of colour registers 0-15, 16-31, 32-47 ... (etc) ... 240-255.

I would only ever use 16 colour sprites, I tried so hard to make something with Amiga 1000 sprites but it just wouldn't work, the cars need to be a minimum of about 80-90 pixels wide or they no longer look like Sega Rally cars sadly. Spent a week but finally gave up.

On the plus side I get 16 colour + copperlist underlying playfield and more subtle copperlist palette for depth cueing on playfield with road.

I had some Street Fighter 2 arcade sprites converted to two sets of 16 colours per player sprite based on what I was told. If I can't have two separate 16 colour palettes for two different SF2 characters on screen it's not worth doing any more work on it sadly. Shame because with two 128 pixel AGA sprites you could do a superfast SF2 demo if you ditched the parallax floor (as SF2 did on SNES).

SF2 SNES has parallax floor.

Why not using sprites for one character and bobs for the other one? Converting the graphics from bitplane/interleave to player 1 sprite graphics before starting the level.

You can use a reduced screen depth (not necessarily 8 planes) because the 16 colors of the sprite character doesn't have to be set in bitplanes. So maybe with 64 colors + 2 sprites you can make that work fast enough.

Or even 1 sprite, dual playfield so no need to cookie-cut the bob character (if the number of colors is good enough, not sure about max number of colors in DPF AGA)

ECS version doesn't/can't use those tricks and still runs reasonably. With a faster machine, AGA and sprite/DPF feature, chipmem bandwidth can be reduced greatly.

I already proved a SNES SF2 was doable on an A1200 a while ago, when that daft crazy polished video came out of them claiming the arcade version was possible.

https://www.youtube.com/watch?v=LYZdho3DDX8

Sorry yes it does on the few levels I just checked, must be thinking of the PC Engine port I also had back then. oops.

A much better port of SF2 on even the Amiga 1000 is possible if you look at some of the other beat 'em up game engines that are OCS compatible. Can't remember if Shadow Fighter is 1mb or 512k Chip RAM but there was Elfmania which is technically impressive on some of the levels and it runs in full PAL resolution.

Shadow fighter is 512KChip / 512k fast

It shows that an excellent A500 SF2 is perfectly feasible. One could imagine what SF2 would have looked like made by the Shadow Fighter team. But we won't make history again and again and there are a lot of thread that spoke already, again and again, about that.

On a 1200, with 2mega chip, a dual playfield 16/16 colors and a hard disk, a sf2 arcade version would be almost easy for this dev team.
And with all those "huge" sprites, it's almost cheating... :-)

There was an improved version of Megadrive Mortal Kombat recently, a port of that to Amiga 1200 would be nice :)