New ST project - Pole Position arcade conversion

All about ST/STE games

Moderators: simonsunnyboy, Mug UK, Doctor Bob Gordon, ICS, Moderator Team

chicane
Atari freak
Atari freak
Posts: 69
Joined: Mon Jul 02, 2012 11:25 am
Location: Leeds, UK

New ST project - Pole Position arcade conversion

Postby chicane » Sun Feb 09, 2014 4:03 pm

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!
You do not have the required permissions to view the files attached to this post.

AtariZoll
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2797
Joined: Mon Feb 20, 2012 4:42 pm
Contact:

Re: New ST project - Pole Position arcade conversion

Postby AtariZoll » Sun Feb 09, 2014 6:01 pm

Cool :D This was on my wish list in old times.
I hope framerate will be better in final version. Or at least on Mega STE :wink:
Negative feedback has usually positive effect.

User avatar
Stefan jL
Atari God
Atari God
Posts: 1235
Joined: Thu May 09, 2002 3:21 pm
Location: Sweden
Contact:

Re: New ST project - Pole Position arcade conversion

Postby Stefan jL » Sun Feb 09, 2014 6:05 pm

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 :wink:)
Image

chicane
Atari freak
Atari freak
Posts: 69
Joined: Mon Jul 02, 2012 11:25 am
Location: Leeds, UK

Re: New ST project - Pole Position arcade conversion

Postby chicane » Sun Feb 09, 2014 8:02 pm

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


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 :D. 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.

StefanjL wrote: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
Atari Super Hero
Atari Super Hero
Posts: 951
Joined: Fri Feb 04, 2011 12:14 am
Location: Denmark
Contact:

Re: New ST project - Pole Position arcade conversion

Postby FedePede04 » Sun Feb 09, 2014 8:25 pm

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.
Atari will rule the world, long after man has disappeared

sometime my English is a little weird, Google translate is my best friend :)

User avatar
Greyfox™
Captain Atari
Captain Atari
Posts: 341
Joined: Thu Jul 24, 2008 10:27 am
Location: Dublin, Ireland
Contact:

Re: New ST project - Pole Position arcade conversion

Postby Greyfox™ » Sun Feb 09, 2014 8:36 pm

Truly amazing work..my man...superb Porting..;)
↓↓Click Banner to See More↓↓
Image
-== Making Atari great once more ==-

User avatar
Maartau
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2588
Joined: Thu Dec 15, 2005 2:15 am
Location: France

Re: New ST project - Pole Position arcade conversion

Postby Maartau » Sun Feb 09, 2014 9:19 pm

Nice job, always a pleasure to read & see coders are still active on/for ST & co. :thumbs:
Member of :
- aTaRi LeGeNd ,
- eLiTe ! ,
- NoExTrA .

Don't hesitate to visit http://www.atarimania.com/ & http://www.atarilegend.com/ :D

-> Slowed due to serious health troubles <-

User avatar
Eero Tamminen
Atari God
Atari God
Posts: 1542
Joined: Sun Jul 31, 2011 1:11 pm

Re: New ST project - Pole Position arcade conversion

Postby Eero Tamminen » Sun Feb 09, 2014 9:36 pm

chicane wrote: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
Atari freak
Atari freak
Posts: 69
Joined: Mon Jul 02, 2012 11:25 am
Location: Leeds, UK

Re: New ST project - Pole Position arcade conversion

Postby chicane » Sun Feb 09, 2014 10:20 pm

Thanks everybody for your kind words.

Eero Tamminen wrote: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.

User avatar
Anima
Atari Super Hero
Atari Super Hero
Posts: 653
Joined: Fri Mar 06, 2009 9:43 am
Contact:

Re: New ST project - Pole Position arcade conversion

Postby Anima » Mon Feb 10, 2014 6:12 am

Wow, great stuff!

Cheers
Sascha

AtariZoll
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2797
Joined: Mon Feb 20, 2012 4:42 pm
Contact:

Re: New ST project - Pole Position arcade conversion

Postby AtariZoll » Mon Feb 10, 2014 7:46 am

chicane wrote:...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.
StefanjL wrote: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 :D
Considering control by mouse: surely most of people will prefer joystick in driving game. So, mouse steering as option. In 5-th edition :mrgreen:
Negative feedback has usually positive effect.

Zamuel_a
Atari God
Atari God
Posts: 1218
Joined: Wed Dec 19, 2007 8:36 pm
Location: Sweden

Re: New ST project - Pole Position arcade conversion

Postby Zamuel_a » Mon Feb 10, 2014 3:22 pm

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.
ST / STFM / STE / Mega STE / Falcon / TT030 / Portfolio / 2600 / 7800 / Jaguar / 600xl / 130xe

User avatar
simonsunnyboy
Moderator
Moderator
Posts: 4849
Joined: Wed Oct 23, 2002 4:36 pm
Location: Friedrichshafen, Germany
Contact:

Re: New ST project - Pole Position arcade conversion

Postby simonsunnyboy » Mon Feb 10, 2014 4:32 pm

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! :)
Simon Sunnyboy/Paradize - http://paradize.atari.org/ - STOT: http://www.npoi.de/stot/

Stay cool, stay Atari!

1x2600jr, 1x1040STFm, 1x1040STE 4MB+TOS2.06+SatanDisk, 1xF030 14MB+FPU+NetUS-Bee

Jabber: simonsunnyboy@atari-jabber.org

Zamuel_a
Atari God
Atari God
Posts: 1218
Joined: Wed Dec 19, 2007 8:36 pm
Location: Sweden

Re: New ST project - Pole Position arcade conversion

Postby Zamuel_a » Mon Feb 10, 2014 5:09 pm

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)
ST / STFM / STE / Mega STE / Falcon / TT030 / Portfolio / 2600 / 7800 / Jaguar / 600xl / 130xe

chicane
Atari freak
Atari freak
Posts: 69
Joined: Mon Jul 02, 2012 11:25 am
Location: Leeds, UK

Re: New ST project - Pole Position arcade conversion

Postby chicane » Mon Feb 10, 2014 8:14 pm

AtariZoll wrote: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.

AtariZoll wrote: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.

AtariZoll wrote: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 :D


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.

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


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

User avatar
dml
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3472
Joined: Sat Jun 30, 2012 9:33 am

Re: New ST project - Pole Position arcade conversion

Postby dml » Mon Feb 10, 2014 11:05 pm

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
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2797
Joined: Mon Feb 20, 2012 4:42 pm
Contact:

Re: New ST project - Pole Position arcade conversion

Postby AtariZoll » Tue Feb 11, 2014 7:47 am

chicane wrote: ...
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 :D
Right, it is Awesome, and there is Atari version, practically same as Amiga one :D
Negative feedback has usually positive effect.

User avatar
troed
Atari God
Atari God
Posts: 1197
Joined: Mon Apr 30, 2012 6:20 pm
Location: Sweden

Re: New ST project - Pole Position arcade conversion

Postby troed » Tue Feb 11, 2014 8:06 am

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
Atari freak
Atari freak
Posts: 69
Joined: Mon Jul 02, 2012 11:25 am
Location: Leeds, UK

Re: New ST project - Pole Position arcade conversion

Postby chicane » Tue Feb 11, 2014 11:43 am

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:

Zamuel_a wrote: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.


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


troed wrote: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!

User avatar
dml
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3472
Joined: Sat Jun 30, 2012 9:33 am

Re: New ST project - Pole Position arcade conversion

Postby dml » Tue Feb 11, 2014 12:16 pm

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
Atari freak
Atari freak
Posts: 69
Joined: Mon Jul 02, 2012 11:25 am
Location: Leeds, UK

Re: New ST project - Pole Position arcade conversion

Postby chicane » Tue Feb 11, 2014 12:48 pm

dml wrote: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?

dml wrote: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.

User avatar
dml
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3472
Joined: Sat Jun 30, 2012 9:33 am

Re: New ST project - Pole Position arcade conversion

Postby dml » Tue Feb 11, 2014 2:10 pm

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.

User avatar
Eero Tamminen
Atari God
Atari God
Posts: 1542
Joined: Sun Jul 31, 2011 1:11 pm

Re: New ST project - Pole Position arcade conversion

Postby Eero Tamminen » Tue Feb 11, 2014 3:28 pm

chicane wrote: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

User avatar
calimero
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2047
Joined: Thu Sep 15, 2005 10:01 am
Location: STara Pazova, Serbia
Contact:

Re: New ST project - Pole Position arcade conversion

Postby calimero » Tue Feb 11, 2014 5:55 pm

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! :)
using Atari since 1986.http://wet.atari.orghttp://milan.kovac.cc/atari/software/ ・ Atari Falcon030/CT63/SV ・ Atari STe ・ Atari Mega4/MegaFile30/SM124 ・ Amiga 1200/PPC ・ Amiga 500 ・ C64 ・ ZX Spectrum ・ RPi ・ MagiC! ・ MiNT 1.18 ・ OS X

User avatar
dml
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3472
Joined: Sat Jun 30, 2012 9:33 am

Re: New ST project - Pole Position arcade conversion

Postby dml » Tue Feb 11, 2014 6:12 pm

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.


Social Media

     

Return to “Games - General”

Who is online

Users browsing this forum: No registered users and 3 guests