ASM - > HLSL re-write
One of the things I didn't like about the old setup was the shadowing. So I wrote up a sort of projected texturing / shadow mapping hybrid. It works on PS1.4 hardware and only uses a single 1024x1024 texture. It also gets the advantage of free hardware filtering since I'm rendering to a A8R8G8B8 surface. This helps to smooth any aliasing, and I don't have to do any expensive filtering in the pixel shader.
Though problems occur with gradual slopes due to the lack of precision in the A8R8G8B8 format. I tried to use the G16R16 format, which keeps the hardware filtering, but loses the alpha channel, which prevents transparency/etc. So I had to implement a clip() instruction in the pixel shader to perform my own alpha test...but you can't use clip() on a temporary/local variable in PS1.4, so I would have had to bump it up to PS2.0 just for a simple clip()...ugh so I left it as PS1.4+A8R8G8B8+some precision issues on slopes. Also there is one other slight artifact with receiving shadows, but it's not very noticeable IMO & is certainly worth the FPS gain.
This whole technique is my 'low end' version...I'm going to re-implement true shadow mapping for PS2.0+ hardware. Probably with a smaller PCF filter (2x2 or 3x3) and some kind of screenspace blur.
Anyways here is screenshot of the PS1.4 dynamic shadows, pretty early on.
![](http://www.radioactive-software.com/gangwar/Oct31/Mesh_receive_shadows.jpg)
Working with HLSL is soooo much easier than messing with ASM shaders...though for some reason the framerates tanked on my secondary computer with a Nvidia 5200FX. I really don't know whats going on....we're talking 30FPS before down to 2-3FPS when using only HLSL for rendering. Something is seriously wrong there.
Though I got a nice speed gain on my computer (w/ ATI X1600)...+10 FPS.
Uh-oh NO-FSAA alert!
![](http://www.radioactive-software.com/gangwar/Oct31/NewShadow1.jpg)
Higher res screenshot of the PS1.4 shadows.
![](http://www.radioactive-software.com/gangwar/Oct31/NewShadowsHighRes1.jpg)
Black Box
One of the other things I implemented is a "Black Box" .dll which tells me extended debug information in the case of a crash. This works by using the .map file generated at linker time, and it tells the exact line of code which the error occurred on, I think this thing is really cool :-) Finally if somebody crashes during a test session we can catalog the bugs, and this really makes solving/identifying the problem almost trivial.
I've injected my own crashes by just setting the contents of a null pointer to something { p = NULL; *p = 32342; }. The "Black Box" got it right every time, telling me the exact line of code on any computer running the game.
Here is a screenshot of the dialog box that pops up in the event of a crash...
![](http://www.radioactive-software.com/gangwar/Oct31/BlackBoxDialog.jpg)
Here is a link to the site I got it from...I'd recommend it to everyone, this will be crucial in catching crash bugs -
Black Box Website on CodeProject.com
Vehicle Networking Code
I've also re-written all of the vehicle networking code...I finally have a workable solution which seems to be great...it uses 5-10% of the bandwidth the previous technique used. I was just browsing and I found this interesting page about the networking in Half-Life 2 ( Valve Multiplayer Networking Wiki ). I'm a huge Source / DOD / HL2 / CS fan so I really found this interesting. Armed with this new knowledge I change my old (temporary, but stable) method of sending updates 8-12 times a second with reference positions/etc. for each vehicle and doing client side prediction...to polling for changes in rotation/movement speed 30 times a second server side and sending reference position/rotation/movement data for that vehicle. It dropped vehicle packet sizes like a rock, and made the bandwidth drop from ~10.0 - ~15.0 k/s down to 1.5-2.0 k/s. Also I have client side prediction / interpolation implemented...I just have to apply it to the new system...it's already lookin' good though.
More screenshots
Well here are some more screenshots of the re-written shaders, everything uses HLSL now -
Random screenshots
![](http://www.radioactive-software.com/gangwar/Oct31/HLSL_Ingame1.jpg)
![](http://www.radioactive-software.com/gangwar/Oct31/HLSL_Ingame2.jpg)
![](http://www.radioactive-software.com/gangwar/Oct31/HLSL_Ingame3.jpg)
Fog of war
![](http://www.radioactive-software.com/gangwar/Oct31/HLSL_FogOfWar.jpg)
I've also fixed a ton of bugs and made lots of changes to every aspect of the code.
Also regarding the possible name change, I don't think Urban Empires is going to work out some of the people at my publisher didn't like it very much, and they're the ones who have to market the thing...soooo...we'll be trying to think of something else.
- Dan
As for your ps_1_4 vs ps_2_0 thing - why don't you just use a simple compile-time switch to toggle accordingly on the different hardware?
As for your FX-5200 problem - try comparing the assembly output from fxc.exe and your original hand-rolled shaders. Chances are they're pretty similar, but you might find that the compiler is doing something the FX5200 doesn't like. The key thing is that the FX5200 is shockingly bad for ps_2_0 - so if you're using SM2 then you might want to try recompiling for SM1..
hth
Jack