Author |
Message |
- Joined: 25 Feb 2006
- Posts: 874
- Location: Belo Horizonte, MG, Brazil
|
Pseudo-APA routines for the Sega Master System
Posted: Fri Nov 10, 2006 1:46 am
|
This is a pseudo-APA (All Pixels Adressable) library for the Sega Master System.
It includes routines for plotting pixels, drawing lines, circles an filled polygons.
It's not exactly what one would call fast, since all of its routines were implemented in pure C, but it's still faster than I had expected.
|
|
|
- Joined: 12 Apr 2005
- Posts: 391
- Location: London, United Kingdom
|
Posted: Tue Nov 14, 2006 6:35 pm
|
Nice work! Do you have any plans to build a game around the project? I imagine a golf-style game might work well.
|
|
|
- Site Admin
- Joined: 25 Oct 1999
- Posts: 2029
- Location: Monterey, California
|
Posted: Tue Nov 14, 2006 8:23 pm
|
Yeah, that is faster than I would have thought.
This might be a good place to use a bit of assembly to speed up the critical bits, like the actual pixel plotting.
You could also apply the dynamic tiling system used in Lemmings & Nine Pixels to allow you to draw anywhere in the screen, albeit only to the first 256 (or so) tiles addressed. Might work for some specific applications, like the aforementioned golf idea where most of the screen might be green but there would be some detail over a couple hundred tiles.
|
|
|
- Joined: 25 Feb 2006
- Posts: 874
- Location: Belo Horizonte, MG, Brazil
|
Posted: Wed Nov 15, 2006 3:30 am
|
Quote Nice work! Do you have any plans to build a game around the project? I imagine a golf-style game might work well.
Well, to tell the truth, I had initially planned to do only a pixel-plotting routine and a circle-drawing for the starmap screen of a game I'm currently programming, but then I got carried away and ended up making routines for drawing lines and solid polygons too. =P
Anyway, I'll take your suggestion into consideration ( no promises, though ;) )
Quote Yeah, that is faster than I would have thought.
Yeah, I was quite surprised too.
Quote This might be a good place to use a bit of assembly to speed up the critical bits, like the actual pixel plotting.
Very true. apply_octet(), apply_octet_mask(), apa_put_pixel() and apa_hor_line() would be very good targets for optimization.
Quote You could also apply the dynamic tiling system used in Lemmings & Nine Pixels to allow you to draw anywhere in the screen, albeit only to the first 256 (or so) tiles addressed. Might work for some specific applications, like the aforementioned golf idea where most of the screen might be green but there would be some detail over a couple hundred tiles.
Not a bad idea.
|
|
|
- Site Admin
- Joined: 25 Oct 1999
- Posts: 2029
- Location: Monterey, California
|
Posted: Wed Nov 15, 2006 6:03 pm
|
It occurs to me you could also have an apa mode that truly is fullscreen, albeit only in 4 colors:
Set the top 12 rows of tiles (384 tiles) so that each tile has a unique tile number (probably sequential, counting down from the upper left) and set them all to use the regular palette.
Now, set the bottom 12 rows of tiles to the same tile numbers as the above, but have them use the sprite palette.
Then set up CRAM like so, where 0, 1, 2, and 3 are the four colors you want to use on your display:
$c000 - 0
$c001 - 1
$c002 - 2
$c003 - 3
$c004 - 0
$c005 - 1
$c006 - 2
$c007 - 3
$c008 - 0
$c009 - 1
$c00a - 2
$c00b - 3
$c00c - 0
$c00d - 1
$c00e - 2
$c00f - 3
$c010 - 0
$c011 - 0
$c012 - 0
$c013 - 0
$c014 - 1
$c015 - 1
$c016 - 1
$c017 - 1
$c018 - 2
$c019 - 2
$c01a - 2
$c01b - 2
$c01c - 3
$c01d - 3
$c01e - 3
$c01f - 3
In other words, on the top half, the top two bits of the pixel do not affect the display, and in the bottom half, the bottom two bits of the pixel do not affect the display.
Then, when plotting a pixel, first determine if the pixel is in the first 96 pixel rows of the screen. If it is, plot it into your tile-bitmap, using only the first two bitplanes, leaving the other two intact. If it's below the first 96 pixels, subtract 96 from the y coordinate, then plot it only on the second two bitplanes, again leaving the first two intact.
The disadvantages of this are: sprites are also limited by the four color limit (three really, due to transparency), and it hogs up most of VRAM and doesn't allow for page flipping.
But it's an option. Note that there might be better ways to arrange the tile map than the top-half/bottom-half sequential arrangement though, another configuration might allow for quicker coordinate-to-address conversion.
You could even adapt the above idea into a single color bitmap mode that does have page flipping, by doing a palette swap between frames to 'hide' the bitplanes that shouldn't be displayed. Other than that the same restrictions apply.
|
|
|
- Joined: 25 Feb 2006
- Posts: 874
- Location: Belo Horizonte, MG, Brazil
|
Posted: Wed Nov 15, 2006 10:42 pm
|
Yes, it would work, although the library would first have to be modified to access the screen directly. The current version draws everything in the main RAM, and, after everything is drawn, it sends everything at once to the VRAM.
Of course, even without this modification, it would still be possible to use this trick to double the number of accessible pixels.
|
|
|
- Joined: 25 Feb 2006
- Posts: 874
- Location: Belo Horizonte, MG, Brazil
|
Posted: Thu Nov 23, 2006 2:14 am
|
Converted apply_octet(), apply_octet_mask() to assembly. This should give a minor speed bost to all the pixel, line and polygon drawing routines.
|
|
|
- Joined: 02 Feb 2005
- Posts: 8
|
Posted: Thu Nov 23, 2006 2:39 pm
|
A bit OT... but I have to admit that it sounds rather funny with 'APA', especially since apa in Swedish means monkey...
=D
|
|
|
- Joined: 25 Feb 2006
- Posts: 874
- Location: Belo Horizonte, MG, Brazil
|
Posted: Fri Nov 24, 2006 1:43 am
|
XD
apa_swing_on_branch();
apa_eat_banana();
|
|
|