|
Sega System 16b Sprites (e.g. Out Run)
#254113 - 05/09/11 06:33 PM
|
|
|
Hello,
I'm trying to get to grips with the way drivers work, with a view to perhaps writing my own in the near future (if I can ever get the hang of all those crazy macros!). I've had a look at the different ways in which tile sets can be stored, but now want to look at actual variable-size sprites.
As a visually impressive (for oldies  ) game I have always been impressed by the fluidity of the graphics on Out Run. Although my Atari ST nearer the time had the same CPU, it did not have any coprocessors nor did it run quite that fast, so the same game was a damp, chirpy squib.
My understanding of the "gfx2" memory region defined by the driver so far is thus:-
- It consists of the ROMs mpr-10371.9, mpr-10373.10, mpr-10375.11, mpr-10377.12, mpr-10372.13, mpr-10374.14, mpr-10376.15 and mpr-10378.16 (in that order);
- The ROMs are byte interleaved in groups of four (first 512KB = 10371/3/5/7, second 512KB = 10372/4/6/8);
- The sprites are in a 4-bit (16 colour) packed format, such that e.g. pixel 1 = (byte >> 4) and pixel 2 = (byte & 0xF);
- A sprite scanline ends with a pixel with the colour 15, in either half of the byte;
- Pixels with the colour 0 are not drawn (transparent).
Based on what I had learnt, I sought to make a kind of sprite viewer in C, which loads the first four ROMs in the list, interleaves them in memory and then attempts to draw based on the rules above.
Unfortunately, I seem to be "off" slightly. It looks like some pairs of pixels are reversed for some reason, and I get a blank scanline between each sprite scanline.
I can't really see where I've gone wrong. I thought it might be some sort of endian issue, so I tried mixing up the interleaving but this only produces either slightly better or slightly worse results. I think I'm missing something fundamental. 
Can anyone with experience in System 16B sprites help me out?
|
|
|
|
Re: Sega System 16b Sprites (e.g. Out Run)
[Re: SMurf]
#254357 - 05/12/11 01:24 PM
|
|
|
I'm not intimately familiar with this sprite hardware but if you'd mind posting your code I'll look to see if there's anything you've missed.
|
|
|
|
|
The code is split into three programs, the first interleaves the four ROMs, the second expands the 4 bits per pixel packing into 8 bits (raw bitmap viewers tend to only go as low as 8bpp) and the third actually draws the sprite data. It's like this at the moment for debugging purposes (as it doesn't work).
You'll find them in the attached zip file, along with a PNG image illustrating what the chain generates as it stands.
Note that the first program (interleave) requires the names of the four ROMs to be specified on the command line and produces a file called "out.raw", the second (4to8) requires the name of a file and also produces "out.raw" and the third (orunspr) assumes that the input is "out.raw" and produces "sprite.raw".
I know it's messy but again, this is just the logic testing phase. 
|
|
|
|
Re: Sega System 16b Sprites (e.g. Out Run)
[Re: SMurf]
#254670 - 05/16/11 02:13 PM
|
|
|
You need to process 8 pixels per iteration of your drawing loop, so you should be reading 32-bits at a time from your interleaved file.
After drawing 8 pixels (treating those equal to 0 or 0xf as transparent), check the 7th; if it's equal to 0xf then you should start drawing on the next line.
|
|
|
|
Re: Sega System 16b Sprites (e.g. Out Run)
[Re: Phil Bennett]
#254715 - 05/17/11 01:36 AM
|
|
|
I'll be honest with you, I thought that doing eight pixels at a time was just some sort of "optimized" way of drawing the sprites. I didn't think Sega would be that crazy... (two transparent colours? Abritary end of scanline markers?)
I tried again, combining the three programs into one and taking your advice. It was (almost) right, bar massive empty spaces between some scanlines, so I introduced a check at the beginning of the drawing loop:-
Code:
if (*pPtrIn == 0x000000F0 && usX == 0)
{
printf("Missing blank scanline\n");
pPtrIn++;
continue;
}
Works perfectly now! 
|
|
|
Previous 
Index 
Next 
Threaded 
Sega System 16b Sprites (e.g. Out Run)
Reply
) game I have always been impressed by the fluidity of the graphics on Out Run. Although my Atari ST nearer the time had the same CPU, it did not have any coprocessors nor did it run quite that fast, so the same game was a damp, chirpy squib.
[Re: 
