Dwarrendelfm 1/27/11

Discussion in 'GBAtemp & Scene News' started by Another World, Jan 29, 2011.

Jan 29, 2011

Dwarrendelfm 1/27/11 by Another World at 9:06 AM (1,525 Views / 0 Likes) 2 replies

  1. Another World
    OP

    Former Staff Another World Emulate the Planet!

    Joined:
    Jan 3, 2008
    Messages:
    10,476
    Location:
    From Where???
    Country:
    Colombia
  2. Ron

    Member Ron somehow a weeb now.

    Joined:
    Dec 10, 2009
    Messages:
    2,837
    Location:
    here
    Country:
    Canada
    Does this work on NDSGBA 1.3?
    EDIT: Tested, NO, Crashes NDSGBA.
     
  3. DanTheManMS

    Member DanTheManMS aka Ricochet Otter

    Joined:
    Jun 2, 2007
    Messages:
    4,325
    Location:
    Georgia
    Country:
    United States
    Unfortunately, as was pointed out on GBAdev (in another forum than the "Project Post" link here), he's using Mode 3, a bitmapped mode. Good for showing large numbers of colors for still images, but terrible for gaming. While I admire the sheer amount of work that went into this project, as evidenced by the very large number of lines of code, doing things in Mode 3 is typically a very bad idea because you get the flicker that you'll notice if you actually run this *.gba file.

    The fact of the matter is that the GBA only has a certain amount of time to update the screen every frame before it starts redrawing it (to maintain the 60 frames-per-second refresh rate), and in Mode 3, copying data to the video memory takes up so much time, even with DMA, that usually you run out of time. That's why you get the flickering. With rare exceptions (like Tony Hawk's Downhill Jam), pretty much all games use Modes 0, 1, or 2, all of which are tiled modes that are much more suitable for designing games.

    What's sad on the hardware side of things is that in theory Mode 4 should have been able to be much faster because it only requires half the amount of data per pixel that Mode 3 requires[*]. Unfortunately the VRAM is set up in a way that you have to read and write in two-pixel increments. Thus updating a single pixel means that you have to read in two, mask off the one you don't care about, modify the one you DO care about, and write both bytes back into memory. The only way Mode 4 can be more efficient is if you don't care about your smallest pixel size being two pixels wide for everything, effectively halving the horizontal resolution from 240 pixels to 120.

    And that's my rant on rantingness. Looks like a good game, but the flickering is too distracting to attempt to play seriously.

    [*] footnote for those who care why this is: In all bitmapped modes, the screen is defined by a single large chunk of RAM. Changing the values in memory will change the appropriate pixel on screen during the next pass-through. In Mode 3, each pixel is represented by 16 bits: 5 for red, 5 for green, 5 for blue, and the last bit is unused, for a total of (2^5)^3 = 32768 possible distinct colors on screen at once. In Mode 4, each pixel is represented by 8 bits. Attempting to do the same sort of thing would only leave 2 bits for each color, or (2^2)^3 = 64 distinct colors at once, which is rather low, so instead the 8 bits combine to represent one of (2^8) = 256 possible palette entries. The palette must be defined prior to using, either generated with software or manually loaded in or whatnot. The point is that in Mode 4 it's 8 bits per pixel vs 16 bits per pixel in Mode 3, meaning it would take half the time to update the same amount of the screen if it weren't for the fact that you have to read and write in 16-bit increments.
     

Share This Page