New ST project - Pole Position arcade conversion

[chicane]

Just a quick message to spread the word about a new ST game I've been working on. It's an conversion of the classic Pole Position coin-op by Atari, and it's around half-complete at the moment. No downloads at the moment, but there's a Youtube video (along with some detail on the history of the project) at http://youtu.be/UaEdkuAYYC0 and regular updates on my Twitter feed at https://twitter.com/RetroRacing.

Here are some screenshots if you're not the Twitter or Youtube type:

ppst1.png

ppst2.png

ppst3.png

Comments and feedback most welcome!

[AtariZoll]

Cool This was on my wish list in old times.
I hope framerate will be better in final version. Or at least on Mega STE

[Stefan jL]

Looks great mouse controls is a must i guess?

Maybe DML will give you suggestions on doing PP on ST as i heard he just love programming racing games on the ST (sorry dml )

[chicane]

Cool This was on my wish list in old times.
I hope framerate will be better in final version. Or at least on Mega STE

It's been on my wish line for years as well - I always considered it an injustice that the ST missed out on a Pole Position conversion at the time. Having said this, had it existed, it would probably have been developed by Probe or Tiertex - enough said.

It runs very nicely on an emulated 16Mhz machine - but to rely on the presence of a faster CPU would be cheating . The real CPU hog is the realtime sprite scaling on the cars and billboards - it's something that's only been done a handful of times and I'm beginning to understand why. I'm really, really reluctant to fall back on the usual ST technique of storing a load of pre-sized sprites in memory and simply blitting the appropriate one to the screen as I don't feel that use of this technique would allow enough sprites to be stored to capture the feel of the original arcade game - at least on a half meg machine.

Looks great mouse controls is a must i guess?

Thanks! Mouse controls sounds like a good idea if I can work out how to do it. This is my first ST project (aside from some STOS stuff back in the 80's and early 90's) so I'm on a bit of a steep learning curve!

[FedePede04]

it is looking good, a little slow, but i am sure that you find a solutions to the problem

i will look forward for this, and i hope you keep us update.

[Greyfox™]

Truly amazing work..my man...superb Porting..

[Maartau]

Nice job, always a pleasure to read & see coders are still active on/for ST & co.

[Eero Tamminen]

The real CPU hog is the realtime sprite scaling on the cars and billboards - it's something that's only been done a handful of times and I'm beginning to understand why. I'm really, really reluctant to fall back on the usual ST technique of storing a load of pre-sized sprites in memory and simply blitting the appropriate one to the screen as I don't feel that use of this technique would allow enough sprites to be stored to capture the feel of the original arcade game - at least on a half meg machine.

Would the scaling be only upscaling or downscaling, or both? How many and what kind of scaling factors you need? Have you thought of generating asm code for different scaling factors?

[chicane]

Thanks everybody for your kind words.

Would the scaling be only upscaling or downscaling, or both? How many and what kind of scaling factors you need? Have you thought of generating asm code for different scaling factors?

The scaling is both upscaling and downscaling. Putting aside the billboards (for which I've come up with some rather sly optimizations since the video was posted), there are 12 different car images of 64x28 pixels each representing a slightly different view of the car. Each image can be mirrored (so that the car can face left and right) and displayed in one of four colour schemes. I need the ability to display any given image from 1 pixel wide to around 75 pixels wide, and on a pixel-level horizontal and vertical granularity. Anything less just wouldn't be Pole Position!

Given all of the display permutations, you'll probably be able to see that there's limited scope for precalc - I'm forced to do a certain amount of work on the fly. I currently have a general-purpose part C and part 68000 movep-based c2p sprite scaler doing all of the heavy lifting - I just pass it the x and y coords, width and height, paint job number and mirroring boolean and it does the rest. It's a bit slow but it's remarkably good for an 8Mhz 68000. Happy to share code with you if you'd like to discuss the potential for optimization.

The one thing I am looking at doing fairly soon is optimizing the draw of the player car - it's currently a scaled sprite using the general-purpose routine above. Given that it's always in the same position on screen, there's certainly (memory permitting) scope to either blit a prescaled sprite to the screen or just have a sequence of 68000 instructions that draw the car directly without calling on any data.

[Anima]

Wow, great stuff!

Cheers
Sascha

[AtariZoll]

...The real CPU hog is the realtime sprite scaling on the cars and billboards - it's something that's only been done a handful of times and I'm beginning to understand why. I'm really, really reluctant to fall back on the usual ST technique of storing a load of pre-sized sprites in memory and simply blitting the appropriate one to the screen as I don't feel that use of this technique would allow enough sprites to be stored to capture the feel of the original arcade game - at least on a half meg machine.

Looks great mouse controls is a must i guess?

Thanks! Mouse controls sounds like a good idea if I can work out how to do it. This is my first ST project (aside from some STOS stuff back in the 80's and early 90's) so I'm on a bit of a steep learning curve!

I think that today making game at all cost to work on half Meg machines is not best idea. Most of machines is equipped with 1MB, and many with 4 MB - especially STE. Now, best would be to release different code for 512K ones, and different for machines with more RAM. Then, you can increase available RAM significantly if discard TOS - will get some 40KB more with TOS 1.04 - can start code, data at very low address, right after vectors . Of course, it needs some low level disk access, but it is not so hard, and routines take only couple hundred bytes. I can help in that part. 512K machines go not with hard disks, so work from floppy is certain. Well, at moment I'm thinking about doing game - something new, inspired with level in one Psygnosis game. It will for sure need lot of precalculated sprites because rotation. And I want constant 25 fps. So, I'm thinking about version for 512K machines with simpler game world, to say so. And another, which may need 2MB min. Additionally, whole thing should look good in mono, so maybe high-res version too
Considering control by mouse: surely most of people will prefer joystick in driving game. So, mouse steering as option. In 5-th edition

[Zamuel_a]

Wouldn't it be good to prezoom the sprites in X since that takes the most time. Zoom in Y doesn't take any extra time compared to a regular draw routine. You just copy each line, depending on the zoom factor. This should be very fast and wouldn't take to much memory. 1Mb should be minimum today I think, or make a 0,5 and 1Mb version.

[simonsunnyboy]

Regarding controls, i'd opt for both joystick and Jagpads on STEs. Mouse controlled racers never felt natural for me. Make it a menu selection.

But overall interesting project!

[Zamuel_a]

I have never tried a mouse controlled racer, but I would guess it's best in a polygon game there you have more precise control. Here a digital joystick is probably better (or atleast be able to select what to use in a menu)

[chicane]

I think that today making game at all cost to work on half Meg machines is not best idea. Most of machines is equipped with 1MB, and many with 4 MB - especially STE. Now, best would be to release different code for 512K ones, and different for machines with more RAM.

This is pretty much what I'm hoping to do. I like the challenge of trying to fit a powerhouse arcade machine into 8Mhz and 512K just like game developers had to back in the 80's and early 90's, and weighing up the various compromises available to create the most faithful representation of the arcade machine. Once I'm done with the 512K version, I'll probably look into doing a 4 Meg version with a view to precalculating as much as possible to maximise the frame rate, increasing texture resolution where these were cut down for the 520 version, and perhaps even sampled sound if I can get some help.

Then, you can increase available RAM significantly if discard TOS - will get some 40KB more with TOS 1.04 - can start code, data at very low address, right after vectors . Of course, it needs some low level disk access, but it is not so hard, and routines take only couple hundred bytes. I can help in that part. 512K machines go not with hard disks, so work from floppy is certain.

I might well call you up for help on this - it depends if we can make the TOS stripping trick play nicely with Vincent Rivière's m68k-atari-mint cross-tools that I'm currently using for development.

Well, at moment I'm thinking about doing game - something new, inspired with level in one Psygnosis game. It will for sure need lot of precalculated sprites because rotation. And I want constant 25 fps. So, I'm thinking about version for 512K machines with simpler game world, to say so. And another, which may need 2MB min. Additionally, whole thing should look good in mono, so maybe high-res version too

Sounds interesting - is the game in question "Awesome" by any chance? Not sure if it was ever released for the ST but I remember reading about the rotation effects.

Considering control by mouse: surely most of people will prefer joystick in driving game. So, mouse steering as option. In 5-th edition

I'll definitely be going joystick for the first release. Never done any mouse programming!

[dml]

Nice work

I'll second Zamuel's suggestion about scaling vertically in realtime, but horizontally - pre-scale & store it or use fast c2p 2x zoom.

There are some other c2p-based scaling tricks but not sure if they will be very helpful here - sounds like c2p is a primary overhead?

Anyway, looking forward to progress!

[AtariZoll]

...
I might well call you up for help on this - it depends if we can make the TOS stripping trick play nicely with Vincent Rivière's m68k-atari-mint cross-tools that I'm currently using for development....
Sounds interesting - is the game in question "Awesome" by any chance? Not sure if it was ever released for the ST but I remember reading about the rotation effects ....

If you not use TOS calls in SW, then will work for sure. Just need to do proper relocation to low address space. And no need in games for TOS calls. Usual operations as screen buffer change, V-sync and similar can be done with simple direct HW access, what is even much faster than Trap calls. Reading joystick, mouse is little more complicated, but not so hard, and 100-150 byte code in ASM is enough. Whole science is proper packet handling. Actually, most complicated is disk access. I saw lot of bad input reading code in games - maybe caused by lack of good literature in past, but now we have good sources. Looking in TOS code is also useful
Right, it is Awesome, and there is Atari version, practically same as Amiga one

[troed]

My spontaneous reaction, as one of those ancient demo coders this forum is filled with, supports storing pre-scaled X bitmaps. I don't see why C2P would be needed, and while I haven't done the calculation I don't think it would use up too much memory either. As others have pointed out there's no need to pre-scale two dimensions.

/Troed

[chicane]

Thanks everybody for your feedback. I'll try to reply to all in time. For now I'm particularly interested in the proposals on how to improve the sprite scaling performance:

Wouldn't it be good to prezoom the sprites in X since that takes the most time. Zoom in Y doesn't take any extra time compared to a regular draw routine.

I'll second Zamuel's suggestion about scaling vertically in realtime, but horizontally - pre-scale & store it or use fast c2p 2x zoom.

My spontaneous reaction, as one of those ancient demo coders this forum is filled with, supports storing pre-scaled X bitmaps. I don't see why C2P would be needed, and while I haven't done the calculation I don't think it would use up too much memory either. As others have pointed out there's no need to pre-scale two dimensions.

Apologies if I've misunderstood any of the ideas on offer which I suspect might be the case, but I'm not sure I quite understand why I would choose to prescale sprites along the X-axis but not along the Y-axis. For each single width at which a given car image is drawn, it'll only ever be drawn at a single height. For example, where a car image is drawn at 56 pixels wide, it would always be drawn at 28 pixels high. A car drawn at 56 pixels wide would never be drawn at 14 pixels high, or 100 pixels high - it'll always be 28 pixels high. Also, in the majority of cases, the source sprite image is downscaled to the screen buffer rather than upscaled, so there's limited scope for removing redundancy by only scaling along the X - it could even be a waste of memory.

So with this in mind, I'd therefore probably go down the route of creating a series of bitmaps prescaled along both X and Y axis for each of the 11 "sideways views" of the car sprite in both standard orientation and mirrored orientation. Also, in order to maximise performance (by avoiding c2p and allowing prescaled sprite data to be written directly to the screen buffer without further processing), I'd need to preshift 16 variations of each prescaled sprite in order to fulfil my wish to display sprites at a 1 pixel horizontal granularity. And (the list goes on!) I also need each generated prescaled sprite to be available in four different paint jobs.

I reckon the combination of all the above things would be pretty heavy on memory on a standard 520ST, which (in conjunction with the desire to do something cool!) is why I've gone down the route of realtime scaling. I'm really reluctant to compromise in any way on the display of the car sprites - I want pixel-level display granularity, multiple paint jobs and unlimited scaling factors. Virtually all of the commercial ST racing games I've seen (vector ones aside) compromise in some way to receive the performance gain of prescaled sprites - for example, limited variation in scenery types or car paint jobs, 4/8/16 pixel render granularity on the X axis, large jumps between prescaled sprites and so on. I can't help but think that the moment I compromise in any way in one or more of these areas, the gameplay just won't feel like Pole Position.

I can't help but think that if I can squeeze some further speed from the c2p realtime scaling routines (and I've already made encouraging progress in the last couple of days on the billboards), then I'll have accomplished something that is both technically innovative (at least for the ST) and actually feels like the original arcade game!

Again, sorry for wasting everyone's time if I've misunderstood what's being suggested here!

[dml]

If you are scaling the sprite only down, then yes you'd want to scale on both axes at once if you are scaling up however, store the 1:1 version as the largest y-axis, and generate only x axis scales from there upwards. The y-scaling can just use a DDA with line duplication at runtime. This will save a lot of ram for the 'big' frames.

I'm not sure if you are implementing c2p on the whole window or just the sprites, as part of the sprite drawing. The latter seems wise if using c2p at all for this, and it probably is only effective if the total fill area is kept small relative to the window size (i.e. not much use for big sprites esp. if overlapping).

[chicane]

If you are scaling the sprite only down, then yes you'd want to scale on both axes at once if you are scaling up however, store the 1:1 version as the largest y-axis, and generate only x axis scales from there upwards. The y-scaling can just use a DDA with line duplication at runtime. This will save a lot of ram for the 'big' frames.

That makes sense - thanks. What's a DDA by the way - I've not come across that terminology before?

I'm not sure if you are implementing c2p on the whole window or just the sprites, as part of the sprite drawing. The latter seems wise if using c2p at all for this, and it probably is only effective if the total fill area is kept small relative to the window size (i.e. not much use for big sprites esp. if overlapping).

The c2p is for the sprites only. I first draw the road and the background with pregenerated 16 pixel planar spans, and then overlay these with the car sprite scaler that interleaves the scaling and c2p in a single algorithm.

Surprisingly, it's not specifically the c2p that's causing me particular pain. The billboards are also drawn as a c2p overlay but I can get away with drawing quite enormous billboards at a reasonable frame rate. The pain with drawing cars comes with the combination of c2p, transparent pixels (potential branch for each pixel drawn) and paint job lookups (one memory table lookup per pixel). The per-pixel code looks something like below - it's pretty lean but it's currently a little heavy for the 68000:

Code: Select all

add.w d7,a3; move to next position in c2p lookup table
move.b (a2)+,d5 ; get offset of source pixel and move to next offset
move.b (a1,d5),d5 ; fetch colour of source pixel
beq.s transparentpixel ; transparent?
and.l (a3),d1; clear all bitplanes at destination pixel
move.b (a5,d5),d5 ; get pixel colour from paint jobs lookup table
or.l (a3,d5),d1; set bitplanes at destination pixel

In contrast, the per-pixel drawing code for the billboards is much simpler due to the lack of transparency and paint job lookups:

Code: Select all

add.w d7,a3 ; move to next position in c2p lookup table
move.b (a2)+,d5 ; get offset of source pixel and move to next offset
move.b (a1,d5),d5 ; fetch colour of source pixel
or.l (a3,d5),d1 ; set bitplanes at destination pixel

As always, it boils down to a compromise between CPU time and memory usage. I'll be mulling over this some more before making the decision to eat up more memory.

[dml]

So far I have written 2 replies to this and both times the session timed out and I lost it. So I'll try when I get home something funny going on with my connection here.

[Eero Tamminen]

Surprisingly, it's not specifically the c2p that's causing me particular pain. The billboards are also drawn as a c2p overlay but I can get away with drawing quite enormous billboards at a reasonable frame rate. The pain with drawing cars comes with the combination of c2p, transparent pixels (potential branch for each pixel drawn) and paint job lookups (one memory table lookup per pixel).

I'm assuming you're concerned about transparent pixels because those allow ground to show through, not because of car sprite overlaps (I assume that is handled by drawing sprites closer to viewer later i.e. overdraw).

Player's car is special case, but for other cars I would make also assumption that they're always on road, i.e. transparent pixels are only for letting road to be seen.

If you add one more restriction, that the upper side shape of those other cars doesn't have any holes or dips, you don't need to do any transparency checks. Just opaquely draw a spanline from suitable X-offset with correct length, and pre-calculate that X-offset and length of each spanline.

The lower side shape of the car could have dips and holes where road shows through, but those don't need to be transparent. Underside of the car has shadow, so you can just use an opaque color that's same shade as road, just darker. I.e. those lines can also be drawn with single, non-transparent span.

If you really need some parts to be transparent, add a lookup table for sprite line ranges that can be drawn without transparency, and ones which need to be drawn with transparency. It adds only little stuff around your sprite drawing code:
- lookup whether to use transparency & select corresponding draw method
- call that method with line count from the lookup
- repeat until whole sprite done

[calimero]

Even before I read that sprites are scaled I was thinking:

"Omg, I never saw such smooth scaling of cars in racing game on ST!"

So keep it this way, optimize as much as you can but keep fine scaling sprites!

[dml]

So 3rd try at an answer

I've used 3 ways to scale sprites with 'holes', for c2p-style drawing.

1) store image as sparse posts. i.e. offset, length for each solid run of pixels. drawing involves scaling the offset and length so there's a fixed overhead (2 muls at least) per post. works best on big sprites. pixels don't need transparency tested, 'holes' are free.

2) inverse of (1), using 2 images - one containing the pixels, the other containing a map encoding the remaining pixels in that run, and type of run (+ve for solid, -ve for gap). This lets you run/skip but with simpler addressing of the image. It has some other advantages (like faster clipping, cheaper downscaling) if combined with other tricks but otherwise similar to 1) and costs more to store. one value (0 or 255) encodes 'no more pixels' i.e. early terminator.

3) code generated sprites, where you precalc code each width for each sprite line, but only generate instructions for pixels drawn, and encode skips as instructions for areas skipped. this is probably most appropriate for 68000, but storage cost might be an issue if you have a lot of sprites and very fine scaling. it's also hard to clip such sprites if you're not using a virtual display linewidth (tricky on STF, not a problem on STE)

Notes:

a) I developed method (2) specifically for BadMood since it has properties which work well in that project compared with the alternatives e.g. one piece of code works with all images, and the images can be mipped offline which decreases post count with distance, increasing speed with distance.

b) Despite prefering method (2) for most cases, I still have a fallback which tests pixels and is used for very small sprites - it's cheaper to test a few pixels than to deal with run/skip scaling when the area is small.

Hope something here is food for thought.