nanogui: Arrangement of memory in a PixMap
Subject:
Re: [nanogui] Arrangement of memory in a PixMap
From:
"Greg Haerr" ####@####.####
Date:
29 Apr 2002 16:40:06 -0000
Message-Id: <01be01c1ef9b$2c7ea070$6401a8c0@gregnewport>
> > > 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)
The is a driver entry point for setting the palette, and this
should be handled through the engine layer, rather than
directly by an application. When Microwindows starts,
and it's determined that it's running on palette-based hardware,
then the linked-in initial palette, based on the current BPP,
is used to set the HW palette.
Currently, Microwindows allocates additional colors, based
on those requested/used by an application (usually only the
GdDrawImage routine does this) and sets the HW palette
accordingly. What is needed here is a direct "set the system
palette" API call that allows an application to set any
palette immediately.
Note that Microwindows doesn't currently attempt to handle
palette-sharing between applications: it will only work until
no more colors are available in the hw palette.
Take a look at engine/devopen.c and drivers/scr_fb.c,
search for Palette.
Regards,
Greg
> >
> > 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 ???
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ####@####.####
> For additional commands, e-mail: ####@####.####
>
