Steven said:
I know this is off topic, but I am not sure where else to ask.
I am tring to find a good game programming library.
Preferrably a cross platform library that will work on windows, linux,
unix, and the mac.
Can anyone recommend a good library?
Generic library recommendations are on-topic, unless if we want to trust
some other group with the answer.
My family just gave me a tiny Sony Ericsson T226 cell phone, with a 101x80
pixel 512-color Liquid Crystal Display. Many of these newfangled
contraptions' specifications exceed those of last decade's microcomputers.
The second thing I did with that new phone was switch the ringing sound from
"The Ride of the Valkyries on Crystal Meth" or whatever to an audio sample
of a real phone ringing with an oscillating hammer between two bells.
My regular readers can easily guess the first thing I did with it. I wrote a
test:
#include <vmgp.h>
#include "resource.h"
VMGPFONT FontA;
void
test_vPrint()
{
FontA.width = 4;
FontA.height = 6;
FontA.bpp = 1;
FontA.palindex = 1;
FontA.chartbl = CONSOLEFONT + 16;
FontA.fontdata = CONSOLEFONT + 16 + 256;
vSetActiveFont(&FontA);
vClearScreen(40);
vSetForeColor(255);
int x(8);
uint16_t background = vGetPixel(x, x);
vPrint(MODE_TRANS, 2, 8, "HELLO WORLD");
vFlipScreen(1);
uint16_t pixel = vGetPixel(x, x);
if (pixel == background)
DbgPrintf
(
"pixel(%i,%i) is still background color %x\n",
x, x,
pixel
);
}
int
main()
{
test_vPrint();
return 0;
}
That test runs in a cross-compiling environment, based on GNU gcc,
supporting a gaming library with the trade name Mophun, technical name VMGP
(Virtual Mobil Gaming Platform), by Antony Hartley and Anders Norlander of
Synergenix Interactive AB.
Click:
www.morphun.com
That comes with an emulator that works on Win32 and Linux. The latest
version supports 3D rendering. This means Doom-like games are in the pipes
for your cell phones, folks.
In the above code, vSetActiveFont() selects a font, vClearScreen() blanks
the screen, vGetPixel() samples a pixel, vPrint() writes in the smallest
font possible, and vGetPixel() samples that same pixel. (vFlipScreen()
swapped the video memory's double buffers. The one we wrote on appears on
the screen - without flickers - and the former one flips back into writeable
memory.)
If vPrint() worked (and if the font geometry did not change), then the pixel
should change color. If it did not, we send a complaint into the debugging
trace channel - DbgPrintf() (note the missing v) - and the Mophun.exe cell
phone emulator writes this into its output debugging window. (And note
Mophun.exe could have linked with /subsystem:console to log into the native
MS Windows console, like our WTL project does.)
Consoles on full-featured platforms are both display devices and streams.
Most tests on consoles need only test their streams. Cell phones can't
output text as streams, only as graphical operations. Testing here will be
interesting. But at least we can always sample pixels, right?
When I switch the Mophun Emulator from the T610 emulation profile to the
T226 emulation profile, my first test fails with an (emulated) hardware
error: "Unresolved symbol access: vGetPixel". A T226 uses Mophun version
1.10; vGetPixel() needs versions >=1.50. It seems somebody did not start
their library with a test.
Here is a SPRITE:
SPRITE sprite_face =
{
0, // palindex - a Palette offset
VCAPS_RGB332, // format - of pixel data
4, 4, // centerx, ~y - the hotspot
8, 8 // width, height - a square here
};
uint8_t raw_face[] = // the pixel data
{
0, 0,0xE0,0xE0,0xE0,0xE0, 0, 0,
0,0xE0, 0,0xE0,0xE0, 0,0xE0, 0,
0xE0,0xE0, 0,0xE0,0xE0, 0,0xE0,0xE0,
0xE0,0xE0, 0,0xE0,0xE0, 0,0xE0,0xE0,
0xE0,0xE0,0xE0,0xE0,0xE0,0xE0,0xE0,0xE0,
0xE0,0xE0, 0, 0, 0, 0,0xE0,0xE0,
0,0xE0,0xE0,0xE0,0xE0,0xE0,0xE0, 0,
0, 0,0xE0,0xE0,0xE0,0xE0, 0, 0,
};
If the SPRITE structure did not depend on implementation-defined C features,
such as the padding inside and between sequentially declared aggregates, it
would be a "variable sized structure", to allocate only on the heap. In
embedded land, however, we can put two data aggregates "next to each other"
in global storage, and users of sprite_circle will simply know that the
SPRITE's raster image always begins at &sprite_face + 1. Our Sane Subset is
shifting!
Squint at the 0xE0 pixels. They form the surprised face of the intrepid hero
of our next adventure.
To prove she or he is worthy of entering (whatever) game I'm about to write,
here's the first test the adventurer must pass:
#define ASSERT_(x_) if (!(x_)) \
DbgPrintf(#x_": %i\n", (x_))
#define ASSERT_EQUAL(x_,y_) if ((x_) != (y_)) \
DbgPrintf("failed: " #x_": %i " \
#y_": %i \n", (x_), (y_))
void
test_moveAsprite()
{
uint32_t q = vSpriteInit(1);
ASSERT_(q);
int x = 15;
for (x = 15; x < 50; ++x)
{
vSpriteSet(0, &sprite_face, x, x);
vUpdateSpriteMap(); // Draw background & sprites
vFlipScreen(1);
}
uint16_t shouldBeRed = vGetPixel(49, 49);
ASSERT_EQUAL(0x7C00, shouldBeRed);
vSpriteDispose(); // free the slot array
}
int
main()
{
test_console();
test_moveAsprite();
return 0;
}
This test demonstrates the SPRITE library in action. This C-style API
manages an array of SPRITEs as "slots". Libraries on full-featured platforms
decouple their own storage systems from applications' memory. MS Windows'
HANDLE architecture provides this capacity. When my code passes a block of
data into a function, after that function exits ownership passes back to my
code. The OS then returns only HANDLEs, not pointers, to objects it manages.
Embedded systems have no room for all this paranoia and redundant
bookkeeping. Between the call to vSpriteSet() and the call to
vUpdateSpriteMap(), if I call memset(raw_face, 0, sizeof raw_face), the face
disappears from the test (and the test fails). The test calls vSpriteSet()
and vUpdateSpriteMap(), right next to each other, so this effect seems
obvious. But the "slot" architecture intends to permit arbitrarily complex
code to move the SPRITEs around, and one Update call to rule them all and
bind them. Then mistakes with the raw data won't be so obvious.
VMPG does not copy my sprite into its memory, it simply remembers the
address of the one I provided. My code can get clever, but not so clever
that it abuses any objects after I pass their addresses into the API.
Our new, primitive ASSERT_EQUAL() macro, at failure time, only reports
"failed: 0xE0: 224 shouldBeRed: 0". It can only do integers, it does not
print __FILE__ or __LINE__, and it does not invoke a debugger. Because our
WTL chapter already showed assertions with more features, and because adding
them to a printf()-style trace statement would create horrid cruft without
hope of elegance, we will let this slide until we actually need
full-featured debugging. Fat chance.
I like writing tests, instead of debugging. It helps coding go faster. Even
when cross-compiling executable images for a cell-phone, and emulating
these.
