Forums

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.

sms_apa_demo_0.01.zip (14.61 KB)

SMS APA Demo v0.01 (source code included)

Nice work! Do you have any plans to build a game around the project? I imagine a golf-style game might work well.

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.

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.

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.

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.

Converted apply_octet(), apply_octet_mask() to assembly. This should give a minor speed bost to all the pixel, line and polygon drawing routines.

sms_apa_demo_0.02.zip (16.88 KB)

SMS APA Demo v0.02 (source code included)

A bit OT... but I have to admit that it sounds rather funny with 'APA', especially since apa in Swedish means monkey...

=D

XD

apa_swing_on_branch();
apa_eat_banana();

Author	Message
haroldoop 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. sms_apa_demo_0.01.zip (14.61 KB) SMS APA Demo v0.01 (source code included)

benryves 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.

Heliophobe 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.

haroldoop 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.

Heliophobe 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.

haroldoop 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.

haroldoop 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. sms_apa_demo_0.02.zip (16.88 KB) SMS APA Demo v0.02 (source code included)

Legerdemain Joined: 02 Feb 2005 Posts: 8	Posted: Thu Nov 23, 2006 2:39 pm
Legerdemain Joined: 02 Feb 2005 Posts: 8	A bit OT... but I have to admit that it sounds rather funny with 'APA', especially since apa in Swedish means monkey... =D

haroldoop 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();

Forums

View topic - Pseudo-APA routines for the Sega Master System