Here's the first meaningful image from the new D3D9 renderer, which still uses the original software transformation, projection, and clipping. Textures are not implemented yet, since that system will require extensive re-engineering.
(http://i1020.photobucket.com/albums/af321/kdmiller3/Battlezone/BZ1_D3D9.png)
Wohoo! DX9 ftw! I almost liked it less detailed, you couldn't see all the ugly moles and facial oddities characteristic of high-def face shots.
:D
It's hard to see because it's black, but all the geometry is there.
Now with textures!
(http://i1020.photobucket.com/albums/af321/kdmiller3/Battlezone/BZ1_D3D9_Textured.png)
It's like different, but the same (or vice versa). :-D
bloody hell. Everyones gone DX9 crazy!
Didn't you have the white/grey blocks before with your Nvidia card? Looks much improved.
Direct3D has featured automatic texture management for years now, so I just let it take care of everything. I don't even have to worry about reconstructing textures after a device loss. There's still a vestigial "texture cache" associating software textures with hardware textures, but it does a lot less work than it did before.
I still need to figure out why the ground shadow is messed up.
Wowsers, that was quick. :-o
"I'm being bothered by a mooooon shadow; mooooon shadow moon shadow." :-)
That is AWESOME.
The main disappointment is that the average frame rate is higher than that of the software renderer, but not by as much as I would have expected. Profiling revealed that polygon setup and software transformation, projection, and clipping are relatively costly even in a release build.
I fixed the shadow ground sprites and enabled anisotropic filtering for improved texture detail.
(http://i1020.photobucket.com/albums/af321/kdmiller3/Battlezone/BZ1_D3D9_Anisotropic.png)
I see better definition of the small craters and bumps on the ground. :-)
Aniso FTW. 8-)
I may just enable anisotropic filtering and linear mipmapping permanently since it reduces the number of vertex buffer flushes and makes sky sprites look a lot better. The sprite half-texel shift eliminates the need for point sampling.
I may replace the filtering control flag with a multisampling control flag, since fonts and screen sprites need to turn that off to avoid fuzzy edges. Updates as events warrant...
It's nice to see bz1 isn't dead. Will be nicer to get some decent performance in bz1 too. The bz1 seemed to suffer from the same pausing every 10th of a second that bz2 suffered from before it's dx 9 rewrite. At least it did for me.
Quote from: Commando on December 03, 2009, 12:05:26 AM
It's nice to see bz1 isn't dead. Will be nicer to get some decent performance in bz1 too. The bz1 seemed to suffer from the same pausing every 10th of a second that bz2 suffered from before it's dx 9 rewrite. At least it did for me.
Whoa! Other than Navbeacon and myself, this is first time I've heard of anyone else mention that!
One reason I stayed with 98se is because I couldn't stand the stuttering in XP.
I was very excited when BZE came out because it doesn't have any of the stuttering at all.
Quote from: Commando on December 03, 2009, 12:05:26 AM
The bz1 seemed to suffer from the same pausing every 10th of a second that bz2 suffered from before it's dx 9 rewrite. At least it did for me.
I saw that but it was about every one second in my case, for me the culprit was the nic card/driver.
Out of curiosity, do you have the TRO source code too or just the 1.4 code?
I don't have either of them. I have the 1.3 source code used to start the BZ2 revision control database. Unfortunately, I lost the corresponding game assets and processing tools.
Support for full screen rendering is nearly done, though resolution switching doesn't work yet and the application hangs on device lost instead of recovering properly.
I also found out that getting the shell to work in full screen was as simple as turning on GDI support with IDirect3DDevice9::SetDialogBoxMode. Of course, I discovered that after spending six hours trying to get the shell to draw into the back buffer... :x
Will your renderer be able to support some of the new resolutions we have on LCD's etc.. without squashing the 3D objects?
That's "just" a matter of setting the projection matrix correctly. I recently changed the calculation to assume square pixels instead of a 4:3 screen, which isn't perfect but should reduce stretching in widescreen views.
(There's the slight complication of monitors and/or graphics cards stretching normally 4:3 resolutions to fill the entire widescreen view. That kind of thing is impossible for the game to detect automatically.)
How are you handling the beta process for the bz1 patch? Are you going to be running a public beta type test or using a bz2 1.3 type system?
So far it seems public, and seems to be working, alot of feedback.
feedback is good :wink:
GSH was able to rewrite the bz2 renderer for 1.3 to support the widescreen format. He may be able to give you some useful hints regarding widescreen support.
It was never a hard problem, just an easy one to neglect or get wrong in the days when 4:3 was the only monitor aspect ratio. :)
Well, I hope it works on my wall of 12 linked 50" plasma displays...
Oh, wait, that was a dream.
Never mind... :evil:
-Av-
You slay me, dude. :lol:
Pretty sure it was a dream, but I took a quick snapshot...
(http://www.gizmowatch.com/images/big-wall_48.jpg)
Can you imagine the firefights on this baby? And sniping? lol...
-Av-
(And no, she's not a tiny little woman, it's a REALLY big screen...)
Too much is never enough!