Dev update:30th March 2010

Update and tech notes from the developer

Dev update:30th March 2010

Postby ADMIN » Tue Mar 30, 2010 11:00 pm

Not long ago, the Xors3d team updated their shadow routines (for the 3d engine Xors3d - http://www.xors3d.com).
This meant that implementing and maintaining good looking shadows within the game code became much easier.
For example, setting up shadows becomes as simple as including the following code (not shown complete/in order);

Code: Select all
xCreateDSS(1024, 1024)
   .
   xInitShadows(512 * SHADOW_QUALITY, 0, 0)
   .
   xLightEnableShadows LIGHT, 1
   xSetShadowParams 4, 0.95, True, 300
   xLightShadowEpsilons LIGHT, 0.0001, 0.6

   xEntityCastShadows(ENTITY,LIGHT, TRUE)

   'main loop
   .
   .
   xRenderWorld(1,FLAG_SHADOWS)

Interestingly, setting shadows on all scenery within a level actually detracted from the visual appearance.
This is due to the tiles that make up a level already having some diffuse global illumination 'baked in' via a lightmap (calculated in Giles).
Adding strong shadows to this subtle shading simply looked 'wrong'.

However, setting shadows on the smaller, AI objects such as tanks, does seem to work as it helps to 'pop' out these items from the surrounding geometry. I guess this is in line with TU2's design philosophy that important game elements should be visually more 'explicit' and than background static elements.

Image
Shadow casting on medium tanks.

End of an era?
TU1 was developed using Blitz3d - which has been a great little utility; there's a load of public domain libs available and it allowed me to get the job done and finish my first published game.Viva la Blitz!
However, speed was always an issue. In a game like TU2 where there's a large number of AI units running around doing their own thing, Blitz3d's mediocre performance is a problem.

Xors3d can be bolted onto Blitz3d, which does help to speed up the graphics handling, but this doesn't affect Blitz3d's base code execution speed. So what to do? (apart from optimise as much as possible)

Blitz3d has a sucessor in the form of BlitzMax - which is considerably faster and more sophisticated than Blitz3d (http://www.blitzbasic.com)
It doesn't have a native 3d engine but Xors3d can be bolted onto it and because Xors3d uses Blitz3d's commandset, I could see my way to porting the code.

This took a bit of time - there was a lot of stepping through and replacing changed syntax. Blitzmax does have a Blitz3d import function, but it's not perfect and I had about 60+ project files to work through. Luckily, this kind of grunt work can be done by making judicious use of the find and replace function while keeping half an eye or ear on youtube documentaries, so it wasn't as blindingly tedious as it could have been.

The end result is a considerable speed up in code execution. Haven't done a direct comparision, but possibly up to twice again, which is very nice to have.
Having said that, there are drawbacks. For one, the GUI lib TU2 has been using - SpriteCandy - is not available for Blitzmax.
Hopefully something similar will appear shortly that allows me to avoid having to recode all that functionality.

Image
On patrol...
'I only have one rule. Everyone codes, no-one quits. You don't finish your game, I'll shoot you myself.' http://www.tankuniversal.com
User avatar
ADMIN
Site Admin
 
Posts: 299
Joined: Sat Jun 02, 2007 8:02 pm

Re: Dev update:30th March 2010

Postby dotsquid » Wed Apr 07, 2010 10:45 am

Hi there!
I've just noticed that you might have problems with that code.
Code: Select all
xCreateDSS(1024, 1024)
   .
   xInitShadows(512 * SHADOW_QUALITY, 0, 0)

You are using SHADOW_QUALITY to change the size of the shadowmap. However, the depth-stencil surface (DSS) remains 1024x1024 constantly. Surely it will cause artifacts, if SHADOW_QUALITY is greater than 2. And of course there is no reason to have the DSS larger than the shadowmap (I assume you're using DSS only for the purpose of shadowmapping).

Cheers.
dotsquid
 
Posts: 2
Joined: Wed Apr 07, 2010 10:38 am

Re: Dev update:30th March 2010

Postby ADMIN » Thu Apr 15, 2010 3:24 pm

dotsquid

Any relation to Squid of Xors3d fame?

Regards the shadow code - good point - the shadow quality var needs to be limited to x2 and linked to the DDS creation size.

One thing I did notice a while back though was that a 1024x1024 DSS was insufficient when screen res was set for 1920 x 1650. Needed to create a 2048 x 2048 DDS for shadow mapping to display correctly at this resolution.

I haven't checked if this is still the case with the latest Xors versions however...
'I only have one rule. Everyone codes, no-one quits. You don't finish your game, I'll shoot you myself.' http://www.tankuniversal.com
User avatar
ADMIN
Site Admin
 
Posts: 299
Joined: Sat Jun 02, 2007 8:02 pm

Re: Dev update:30th March 2010

Postby dotsquid » Fri Apr 16, 2010 9:35 am

ADMIN wrote:dotsquid

Any relation to Squid of Xors3d fame?

Regards the shadow code - good point - the shadow quality var needs to be limited to x2 and linked to the DDS creation size.

One thing I did notice a while back though was that a 1024x1024 DSS was insufficient when screen res was set for 1920 x 1650. Needed to create a 2048 x 2048 DDS for shadow mapping to display correctly at this resolution.

I haven't checked if this is still the case with the latest Xors versions however...


Hi.
Yes, that's me :)
Hmm.. I should investigate this disconformity of backbuffer with resolution higher than the size of DSS.

PS. How about a gameplay video? ;)
dotsquid
 
Posts: 2
Joined: Wed Apr 07, 2010 10:38 am


Return to Developer notes

Who is online

Users browsing this forum: Google [Bot] and 1 guest

cron