nanogui: Arrangement of memory in a PixMap
Subject:
Re: [nanogui] Arrangement of memory in a PixMap
From:
Pierre Tardy ####@####.####
Date:
26 Apr 2002 17:11:34 -0000
Message-Id: <20020426190203.7117d689.tardyp@free.fr>
On Fri, 26 Apr 2002 09:55:41 +0100
Alex Holden ####@####.#### wrote:
> 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?
Yes, it work. Gnuboy has differents blitters for truecolor framebuffer (like nano-X).
The one that display on 4bpp and 8bpp needs to optimise the palette.
> In that case I
> agree your implementation is going to be so non-portable that you may as
> well just use the framebuffer directly.
yes.
>
> > 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
[snip]
It is an idea, if he dont forget to set a low priority for the emulation core.
(if the 2 threads are 50/50, the cpu can not have enough cpu to run at full speed)
>
> >>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.
For having played some time the snes9x emulator, with a not so powerfull PC, and variable frame skipping, I can say you that vfs is not the ultimate solution to these problems.
for exemple:
fb 1 fb 2
cpucore draw nx waits
cpucore finish nx waits
nx draw cpucore draw
nx draw cpucore finished, fb1 is accupied, take fb2 again
nx finished cpucore draw
nx waits cpucore draw
nx waits cpucore finished
cpucore draw nx draw
etc.
In this case, the nx core take a bit more time to finish its drawing.
it wont draw the first fb2 frame. nx will draw at 30Hz. no flicker :(
If the nx core take more than 2 times than the cpu core.
it wont draw the first and second fb2 frame. nx will draw at 20Hz. correct flicker :)
and so on..
It is very probable that the cpu core needs p percent (+ or - 10%) of the host cpu.
and the nx core will be stabilised at 60/n Hz ..
Pierre
--
c'est quoi ce quatre et ce huit, dans mon adresse email ???
