[OT] Can anyone recommend a good game library?

Discussion in 'C++' started by Steven Green, Dec 24, 2003.

  1. Steven Green

    Steven Green Guest

    Hi,

    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?

    Thanks,

    Steve
     
    Steven Green, Dec 24, 2003
    #1
    1. Advertisements

  2. Steven Green

    Jeff Schwab Guest

    http://www.thefreecountry.com/sourcecode/games.shtml
     
    Jeff Schwab, Dec 24, 2003
    #2
    1. Advertisements

  3. Did you try freshmeat.net ?
     
    Gianni Mariani, Dec 24, 2003
    #3
  4. Steven Green

    Phlip Guest

    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.
     
    Phlip, Dec 24, 2003
    #4
  5. Try ClanLib - http://www.clanlib.org
    Not so sure about Mac support though, but it works great on *nix &
    Windows. Good luck!

    Seth

    ~ Let us linux ~
     
    Seth Morecraft, Dec 24, 2003
    #5
  6. Steven Green

    Rolf Magnus Guest

    What about SDL, Allegro, (for sound) OpenAL? For 3D graphics, OpenGL.
     
    Rolf Magnus, Dec 24, 2003
    #6
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.