RE: [Tuxnes-devel] Trying to add SDL Renderer
Brought to you by:
tmmm
Menu
▾
▴
RE: [Tuxnes-devel] Trying to add SDL Renderer
|
From: Ben S. <BSi...@Kn...> - 2002-03-11 00:33:20
|
TuxNES team,
Hi, and sorry I've been to busy to reply earlier. I would like to
applaud you on your good work: It's great to see SDL support. Tuxnes now
supports three of the four popular cross-platform display systems (X11,
GGI, and SDL -- VNC support is till to come.)
I believe the palette arrangement used by TuxNES is a relic from Quor's
original Nestra code, about which he may wish to comment (I believe he's
still subscribed.) From reading the code, it seems to me that Nestra was
originally designed for 8-bit palettized display (only) and TrueColor
support was added later, almost as an afterthought. Under X11, a window
using a palettized display does not -- at least by default -- have
access to the full 256-entry palette. Instead, all open windows share a
single palette, and palette entry contention is a common problem. I
suspect Nestra's palette usage may be an attempt to minimize the number
of used palette entries.
Palettized display (PseudoColor under X11) is a very straightforward
choice for emulating the NES, since the NES allows programs to change
the displayed color for each logical tile/sprite color. In palettized
mode, TuxNES changes the video card's palette registers to reflect
changes to the NES palette.
However, this straighforward choice becomes less logical once mid-screen
palette updates are taken into account. On the NES, many programs update
the palette entries for some colors partway trhough the rendering
process in order to increase the apparent palette size. Since these
palette changes are intimately related to the NTSC/PAL video timings,
they are hard to emulate correctly on a modern PC (where beam position
is either difficult or impossible to determine, and people expect
flicker-free high-refresh-rate video modes, not to mention high
resolution and multiple windows visible at the same time.)
To overcome this (and accurately simulate the appearance of NES games,)
the TrueColor renderers in TuxNES allow the color palette to be updated
mid-screen, and render each NES pixel as an RGB triple. When a palette
entry changes, all pixels generated from that palette entry must be
recalculated and redrawn.
In other words:
In palettized mode, TuxNES simulates the NES video hardware and expects
the monitor to accurately simulate an NTSC/PAL television (which it
rarely does.)
In TrueColor mode, TuxNES simulates both the NES video hardware and an
NTSC/PAL television. This is slower than palettized mode, but more
accurate.
The one major bit of NES graphics hardware still unemulated by TuxNES is
the
"color emphasis" feature, which allows a sort of global palette tinting
similar in spirit to the X11 DirectColor visual class. Like other
palette changes, this needs to be pre-rendered into RGB to accurately
simulate mid-screen updates.
Finally, I highly recommend Chris Covell's demos for those experimenting
with the NES graphics hardware (whether real or in TuxNES.)
-Ben
P.S. I'm glad to see that the W Window System code has proved of some
use to someone. When I wrote it I feared I would be the only one to ever
run or use it. ;)
-----Original Message-----
From: Jim Ursetto
Sent: Sun 3/10/2002 8:19 AM
To: tux...@li...
Subject: Re: [Tuxnes-devel] Trying to add SDL Renderer
At 07:41am on 2002 March 10, W. Michael Petullo did write:
> > I'm trying to add an SDL renderer to tuxnes. Eventually this will
give
> > us full-screen support and additional platforms for free.
> > [...]
>=20
> I have the basic renderer working, though I don't really understand
> tuxnes's color code (UpdateColor.* functions). As I understand it,
> the NES is only able to display 24 colors at once. Because of this,
> the emulator's palette must be updated to the appropriate colors for
each
> frame and these colors have to be mapped to a display's 8-, 16-, 24-,
> or 32-bit colorspace.
The palette stuff is confusing. The first time it took me a while to
figure it out. The second time (when I went back and converted it to
use
hardware palette entries) again took me a while, so I took notes that
time:
---- Palette conversion:
paletteDC[] holds the 64 16-bit DC versions of the 64 total NES
colors.
palette[] holds 25 16-bit RGB565 values, all of which are
cornfusing.
The 2 NES palettes have 16 entries each, broken down
into 4 groups of 4.
Color 0 is transparent (letting the background (or
background color) shine through).
Color 0 is mirrored to 4, 8, 12. Also, color 0 is
mirrored between the two palettes.
In this array:
0..11 are the current tile colors.
0,1,2 correspond to colors 1, 2, and 3.
3,4,5 and 6,7,8 are 5, 6, 7 and 9, 10, 11.
9,10,11 are 13, 14, and 15.
12..23 are the current sprite colors.
24 is the current background color, set in UpdateColors.
Methinks this was a (misguided?) attempt to save space.
tilecolor is the 2-bit value from the attribute table.
curpal[] holds 4 16-bit RGB565 values corresponding to the 4
possible colors
for the current tile. The index into curpal is the 2-bit
value from the name table.
curpal[0] is always set to the value in palette[24] upon
entering drawimage.
curpal[1,2,3] are set to palette[0,1,2], [3,4,5], [6,7,8], or
[9,10,11]
depending on the value of tilecolor (2 bits provides 4
selections).
------------------------
The following code does not use hardware palette entries (i.e. not
PseudoColor). The code in InitDisplay that converts the 32-bit
NES_palette
values into 16-bit RGB565 native values is:
for (x=3D0; x < 64; x++)
{
/* RGB565 */
uint8 r,g,b;
r =3D (NES_palette[x] >> 16 >> 3) & 0x1f;
g =3D (NES_palette[x] >> 8 >> 2) & 0x3f;
b =3D (NES_palette[x] >> 3) & 0x1f;
paletteDC[x] =3D (r << 11) | (g << 5) | (b);
}
The update colors function is very simple (except for the unnecessarily
complicated palette array organization):
void
UpdateColorsDC(void)
{
int x;
palette[24] =3D paletteDC[VRAM[0x3f00] & 63];
for (x =3D 0; x < 24; x++) {=20
palette[x] =3D paletteDC[VRAM[0x3f01 + x + (x / 3)] & 63];
}
=20
This should get you started. I have hardware palette code too if you
need
it.
--=20
"closing my eyes, i got a glimpse of several entities moving in front of
a giant complex control panel. the creatures were bipedal and of about
human size. it was impossible to say more other than they did not move
like the giant insect creatures i have seen clearly under the influence
of
stropharia mushrooms." -- zarkov, "a hit of dmt 10/9/84"
ji...@3e... / 0x43340710 / 517B C658 D2CB 260D 3E1F 5ED1 6DB3 FBB9 4334
0710
_______________________________________________
Tuxnes-devel mailing list
Tux...@li...
https://lists.sourceforge.net/lists/listinfo/tuxnes-devel
|
