nanogui: Arrangement of memory in a PixMap
Subject:
Re: [nanogui] Arrangement of memory in a PixMap
From:
Pierre Tardy ####@####.####
Date:
25 Apr 2002 19:39:41 -0000
Message-Id: <20020425213011.5c05bdf9.tardyp@free.fr>
On Thu, 25 Apr 2002 10:54:19 +0100
Alex Holden ####@####.#### wrote:
> Simon Wood wrote:
> > I'm not sure I fully understand the principle of Nano-X 'giving' a frame
> > buffer. I assume that requires that the Nano-X server is itself running
> > on the frame buffer, and passes control of part (or all) of the screen
> > to another application.
>
> The client side framebuffer support works by remapping an area of the
> framebuffer into the clients memory space. Of course it only works on
> Linux, if you're using the framebuffer for video output, and if the
> client and server are on the same physical machine. As such I'd always
> recommend implementing some other more portable method first (typically
> using GrArea()).
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)
Then, I think it is better to do a gnuboy gui, in Nano-X, and keep the gnuboy core app without Nano-X support.
you can control it by sending some signals..
> > I thought GnuBoy managed to cope with much slower screen refreshes, I'll
> > just have to see what happens.
>
> I was thinking that too- 50Hz is a lot. I'd try to implement it in such
60Hz :)
> a way that you update the screen as often as you can and it doesn't
> matter if some frames get lost.
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..
but as said laguna, the main coder of gnuboy:
> 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...
> You could try implementing some kind of
> dirty rectangles based solution too (where you keep a list of rectangles
> that specify the areas where pixels have changed and only do a GrArea()
> on the modified areas) if the frame rate proves to be too slow.
Yes, it will work for Tetris.. But a majority of games uses scrolling..
Pierre
--
c'est quoi ce quatre et ce huit, dans mon adresse email ???
