nanogui: Arrangement of memory in a PixMap
Subject:
Re: [nanogui] Arrangement of memory in a PixMap
From:
Alex Holden ####@####.####
Date:
26 Apr 2002 09:04:00 -0000
Message-Id: <3CC9160D.6070709@linuxhacker.org>
Pierre Tardy wrote:
> My first idea was to use nano-X's framebuffer sharing, but the problem is that gnuboy needs to modify the palette of the fb..
> for that, we need to have an fb fd, ( for ioctl)
So it won't work at all on truecolour hardware then? In that case I
agree your implementation is going to be so non-portable that you may as
well just use the framebuffer directly.
> I ve some discussion with the author of gnuboy.
> Nothing is implemented for frameskipping, Well, I implemented a basic (limit hacked) frameskipping with no problems..
I didn't mean use a fixed rate frame skipping, I mean divorce the
emulator core from the GUI display part and have the display draw frames
out as fast as the hardware is able to cope with. The core draws onto
one of two buffers (alternating between them), and the display code
copies frames out to the display as fast as it can (always picking the
one which the emulator core isn't currently drawing on). If it manages
to draw a frame before the emulator core has finished drawing the next
one it waits for it (that'll happen if it manages to keep up with the
frame rate).
>>You won't be happy with 30 fps once you find a game that make s
>>transparency effect by toggling a sprite on and off every other
>>frame. At 30 fps it'll just appear solid (always visible) or
>>invisible...
With the variable rate skipping, if it isn't able to keep up, it'll
probably flicker at a lower rate than normal (and somewhat erratically).
It's unlikely to lock in sync with exactly half the real frame rate and
produce the described effect.
--
------------ Alex Holden - http://www.linuxhacker.org ------------
If it doesn't work, you're not hitting it with a big enough hammer
