nanogui: X-games, doom, hexen ...
Subject:
Re: [nanogui] X-games, doom, hexen ...
From:
"Greg Haerr" ####@####.####
Date:
15 Aug 2001 16:16:14 -0000
Message-Id: <086901c125a4$aa067a20$3aba46a6@xmission.com>
: > nxdoom has really ugly colors, the STB supports truecolor. Can I utilize
: > that?
Doom runs only in 256 color palette mode. You could translate the colors
for 16 or 32bpp, but then it would be even slower.
: > nxdoom in the version we have is 320x200, and we run nano-X in 640x480. Can
: > we get fullscreen out of nxdoom? I have tried to change 320 to 640 in
: > doomdef.h (etc), but to no avail. When I grep for 320 in the code it
: > appears everywhere, so maybe I cannot get around it.
Doom will only run in 320x200, but you can double the pixels when
doing the final scene copy. Look at the code I wrote in i_video.c,
I have a double pixel blitter in there.
> We have nxdoom running on out Set-Top Box (powerpc, 75 Mhz), it seems a
: > little slow in updating the scene. Is that reasonable? Can we tweak more
: > out of doom ya think?
:
: Sorry... The way that Microwindows currently works is that we have to do
: lots of memory copies in the client program, and that takes time. We
: probably could get a little more performance if we started optimizing for
: specific processors, but we have always favored compatability and portablity.
: Microwindows will soon provide a client side framebuffer for speed, but thats
: still a couple of releases away.
Actually, this is mostly the way that Doom works, not Microwindows. Doom
always creates its scenes in 320x200x8bpp. If your screen isn't running
256 color (most STB's aren't), then you'll have to do a memory copy, which
is exactly the way I had to implement it for the iPAQ since, it runs 16bpp.
The client-side framebuffer mapping is in the CVS, and could possibly
speed up your copy, rather than using GrArea. But it's still pixel-by-pixel,
and will likely require 8bpp->16bpp translation per pixel.
Regards,
Greg
