Questions/Comments/Driver/DLL/Source?
Send it to me. I'll post it (for download)... immediately!!!
HazarD just sent me a full g3d Glide distance fog tutorial 11-7-1999:
Glide Fogging Tutorial Download
This is a WOG tutorial concerning HazarD's fogging:
http://www.gameznet.com/genesis/tutorials/tutorial52/tutorial52.html
There's a D3D driver patch 11-3-1999 concerning mipmapping support from http://www.rabidgames.com
'This modification fixes a problem in the D3D driver in the selection of mipmaps for large pieces of world geometry. The original driver makes its mipmap decision based on the FIRST EDGE of the polygon to be drawn, causing problems when that edge is distant and other edges are closer. This patch to PCACHE.CPP computes the average of all edges and then performs the mip computation on that number. The ZIP file contains a release compile of the patched D3DDRV.DLL, a README.NOW file, and the source for the modified PCACHE.CPP. '
Matthew Ellis modified the D3D driver to get 32 bit support in EasyGen3D
http://www.magmagames.com
'EasyGen3D (C) 1999 Matthew Ellis The new 32 BPP Direct3D driver reads a config file (bpp.e3d) and decides what the bpp and z-buffer depth should be based on that config file. The config file must be placed under the root directory of your application. '
(I made a zip only with the driver and it's source, i hope that's ok for you Matthew. Martin)
Jeff K's linear fogging D3D driver with source 09-19-1999:
Bobtree and charlie_x made mipmpping alot better 11-2-1999:
'Author Topic: mipmapping with the much maligned D3D
driver charlie_x Veteran posted 11-02-1999 01:16 PM
--------------------------------------------------------------------------------
I changed the engine last night to display different marked textures for
each mip level, instead of the normal, Ie it displays 1, 2 and 3 as the
texture. Anyway this showed me that mipmapping (at least in the squid
level) isn`t doing what it ought to be, less than 2% of the polygons were
mipmapped. So I tinkered around with it, firstly this is just a hack to
make it mipmap more, the mipmap selection isn`t that great, i`m in the
process of recoding it however as a quick fix scale the MipScale. goto
pcache.cpp in the d3ddrv around line 216 after the MipScale = ((du*du)) *
etc put MipScale *= 15.0f; I used values between 20 and 10, 20 did just
over 3/4s of the screen. Once i`ve written the screenshot code for
d3ddriver i`ll post examples on my web page of how it affects it. Now also
since it doesn`t care about MipScale less than 1 for all you Visual C
users you might want to convert it to an int, i`m not sure if VC will do a
call to ftol each time it does that comparison, it might save a little,
but maybe not. Adding that simple change means you get more that 5 or 6
mipmapped polys 8) regards charlie IP: Logged Bobtree Veteran posted
11-02-1999 03:09 PM
--------------------------------------------------------------------------------
hey, glad to hear it! the mipmapping problems have been a thorn in
everyone's sides for a long time. thanks for the info. i fixed some bugs
with the Glide driver, where it wasn't using mips for MiscTexturePoly,
which i guess is anything not rendered by the world, which includes stuff
done with geTClip_, and which is why it was buggin me, (and got my name in
the 1.0 source! hehe). and i pointed this out, but they neglicted to fix
the Glide mipmap-bias (similar, i suspect, to the MipScale you mention),
so unless you fix it yourself you still get minification artifacts
(sparkling!) before mips are used for a texture. they used -1.0, which is
really terrible, and should be something like 0.5 or 0.75 (this looks good
for GTest on a v2 card) or 1.0 for decent mipmapping. its on line 254 of
GMain.c. never got around to messing with the D3D drivers (dont have any
D3D experience myself), so its good to hear that you're working on this.
could you help me out and figure how to get mipmapping in D3D with
RenderMiscTexturePoly? because although i fixed it in Glide, iv not a clue
where to start looking to fix it in D3D. mipmaps are not used if you
render with this call, but they should be, and it makes GenScape look
worse than it could (moire effects really get me). IP: Logged Bobtree
Veteran posted 11-02-1999 03:22 PM
--------------------------------------------------------------------------------
ah. per your suggestion regarding PCache, im looking at
PCache_InsertMiscPoly(), and i see they just set Mip = 0; in there. doh.
guess fixing that with a nice equation would do the trick. probably the
same as whatever would be best for PCache_InsertWorldPoly(). now we just
need an algo for proper mip-level selection. any ideas? im not familiar
with D3D, but im sure there are sites around that'd explain this. IP:
Logged charlie_x Veteran posted 11-02-1999 03:25 PM
--------------------------------------------------------------------------------
doh!, i was just about to post something like that *) Yes i have ideas
for correct mipmapping, i`m playing with it this week.. I`ll post my
findings, its not a hard thing really. IP: Logged charlie_x Veteran posted
11-02-1999 03:33 PM
--------------------------------------------------------------------------------
after a quick snoop theres no TexInfo passed into miscpoly, so its not a
cut n paste. I`m not setup with a build env. here so i`ll have to look at
it later. At first guess it looks like it might have to be added to a few
levels. IP: Logged Bobtree Veteran posted 11-02-1999 04:17 PM
--------------------------------------------------------------------------------
miscpoly doesnt need texinfo. it's not a world-poly, so it doesnt have
texinfo stuff related to it. it's just verts, a texture, and renderflags.
you dont need the drawscale from texinfo like a world poly does (where
this can be set in the editor, etc), because it's not a world poly and
whatever is using it thru this call is expecting it to be rendered
_as_is_. so youd use basically the same eq as in WorldPoly(), but leaving
the texture coordinates alone. ie, just ignore whats done to the uv coords
with the DrawScale stuff. so its almost a cut&paste (once theres a
good eq for WorldPoly), you just skip the DrawScale stuff. IP: Logged
charlie_x Veteran posted 11-02-1999 04:37 PM
--------------------------------------------------------------------------------
ok that seems fine, like i said i dont have my build with me so i wasn`t
really looking at it too hard.. I prefer to select mipmap based on the
area of the poly. '
Bobtree posted the following in g3d prog. forum 10-2-1999:
'i don't know how this one slipped thru, but there's an obscure bug i found which manifests itself if you try to SetFormat() on a non-palletized bitmap to make it GE_PIXELFORMAT_8BIT (palletized). the call i was using is geBitmap_SetFormat(texture, GE_PIXELFORMAT_8BIT, GE_FALSE, 0, (geBitmap_Palette *)NULL); on a GE_PIXELFORMAT_24BIT_BGR format bitmap. and at runtime i'd get this error: "Unhandled exception in GSTest.exe: 0xC0000005: Access Violation." took me a while to figure out what was causing it. when i hit the Access Violation, and break into the debugger, the callstack looks like this (most recent call first): GSTEST! createOctTree line 771 + 21 bytes GSTEST! createPaletteGoodSub line 317 + 19 bytes GSTEST! createPaletteGood line 294 + 13 bytes GSTEST! createPalette line 130 + 16 bytes GSTEST! createPaletteFromBitmap line 152 + 13 bytes GSTEST! @geBitmap_Palette_CreateFromBitmap@8 line 4539 + 13 bytes GSTEST! @geBitmap_SetFormat@20 line 3181 + 10 bytes it happens during the palette creation, in palcreate.c, on line 772. if you look, this section is in the 4-bytes per pixel (32bpp) color octree creation section, and it happens no matter WHAT the bpp of the bitmap passed to _SetFormat() is. why? well, in the createPaletteFromBitmap section, the bitmap is locked for read in GE_PIXELFORMAT_24BIT_RGB, and what reaches the createOctTree call is this Lock's Info and (void*)Bits. what's happening is that the 3-bytes per pixel (24bpp) section of the switch statement is missing a 'break;', so the 32bpp section is also run and BAM, instant access violation. the same thing happens around line 870, for the non-YUV converting sections, with an identical missing 'break;'. so, all it takes to fix this is to add the missing 'break;' statements at the ends of the two (YUV and non-YUV) 3-bytes per pixel conversion sections (i guess after lines 759 and 870). i think they were missing because the different 24bpp formats are handled individually with another switch() statement, and the final 'break;' in there looked like it was the missing 'break;' between the 3-byte and 4-byte sections. recompiling the engine with this fixed makes my _SetFormat() ->8bpp palettized calls work fine now (hooray for Open Source!). '
'just countach' sent me the following lines:
There's a simple trick to enhance D3D performance
define USE_ONE_CACHE in THandle.cpp it gained me about 10fps (Riva TNT2),
which is to say a large increase. still d3d is not as fast as it could be,
over 40fps is nearly impossible on my computer(Pentium 2-333 64Mb Riva
TNT2)
hope you get some better drivers soon
Jeff Mossontte sent me a fix for the glide driver:
'Attached is a text file that describes how to fix
the Glide driver so it can use the 1024x768 graphics mode. I posted this
on the Genesis3D forum about a month after the release of version 1.0. You
are welcome to do anything you wish with the attached text file.'
GlideFix.txt
VERY MUCH MORE TO COME IN FUTURE......
Questions/Comments/Driver/DLL/Source?
Send it to me. I'll post it (for download)... immediately!!!(C)opyright 11/1999 by Martin Haverland, all tutorials and drivers are copyright of their authors or legal owners
"Eclipse Software" and "Genesis 3D" are Trademarks of their legal owners.