Make your own free website on

17 Mar, 2003:


Whoah, cool!The turret rotation is working finally!Cill gave me the idea when he separated the turret from the hull in his rotations.I created two more values in the UDT Sprite; 2 tmp_Offsets.The old code didnít have it and was using Hull offsets to store the turret values.A mere three hours later of looking at the code funny, it started rotating around the turret offset from the centre.After that, it was a snap to check the input variables and perform transformations on them to make sure they would work as expected.I still have to check the Y offsets, but Iím kinda assuming theyíll just work :)


The turretís centre of rotation connects to the Hullís turret point, as in Close Combat.I might have to check a div/0 error in some circumstances, and Iím going to move the tankís Select point to the turret centre, as in CC.


After thatís all done, I might take a look at the sprite generation code to see if I can input odd-shaped sprites and output even-edged rotation-friendly sprites. But to be honest, I reckon enough is enough with the vehicles.Set an arbitrary limit of 64x64 for the vehicles and get the spaghetti code tidied up.I also need to draw all the shadows, then all the hulls, then all the turrets, to deal with collision weirdies.I want to be left with a simple DrawVehicle command, passing only the unit number, and maybe the current map offset.Iíll need to set up a unit with a type to differentiate between vehicles and squads as well, but that also can wait until there are infantry in.


Next up, after the tidying is to get a map with some primitive elements drawn on it.Iíll stick with the grid map for the moment, but Iíll paint on some CC elements and retain the Grid for default terrain.


Elements are drawn as a new layer over the painted map.The colour signifies the type of terrain.Iíll use hardcoded Hex values and see if I can get a correspondence between Photoshop and VB.(NOTE:The Height Map is an additional layer and Iíll leave it for the moment.)There will be 10 pixels to one element square, meaning that the elements map should be much smaller and capable of being stored as a 2d array for quick lookups.This means that the main maps must be exact multiples of 10, a better granularity than CC, where itís 120 pixels (probably for their tiling algorithm).Once some basic elements are in, I can check Peterís path-finding routine.Iíll start with a solid blocking element (water) and see how the tanks do at navigating it.There could be up to 300 units doing pathfinding at any one time, so the routine has to be fairly damn fast.


After some basic terrain elements are in, it might be time to get the vehicle details out of text files and into an Access database.For an hourís coding, itíll be a lot easier to add new items to each vehicle without writing a cleverer file parser.Also, all hard-coded elements have to be taken out of the game and the initial rotations of tanks taken care of in their drawing routine (that probably doesnít make much sense, but thereís a hack in at the moment that I want to remove).


After basic elements:Infantry teams.Theyíll involve flocking and very basic cover AI.No real idea how to make sure they go on the right side of a wall, unless itís easier that I think.This will hopefully fall out of the flocking.


Code is here.


11 mar, 2003:


Well, the turret is offsetting correctly to the vehicle rotations.The next step is to have the turret rotating in relation to its own internal offset centre.Iíll explain.













The red dot above is the offset turret rotation.As the hull rotates around the centre, the turret attachment point has to rotate in a circle around the centre point.So, for a 64x64 sprite, with the turret connected at 32,48, the turret actually moves in an offset circle around the centre point.


Half of that is working now, but the turret is still centre rotating with the wrong offset.Look at the two tanks below from the test code.One has a turret offset of 32,48.The other is 32,64.See where the offset is wrong on the extreme one?And only when the turret is not at the same angle as the hull.To be honest, this stuff is melting my head, so I need to sit down and think about it for a while.





















The good news is that the graphics are drawing pretty damn quick.Thereís a slight speed hit when rotating, but itís containable.The other good news is that the infantry wonít be even 1% as much grief to draw.


Code is here.




4 Mar, 2003:


Okay, Iíve spent the last few days looking at the rotational algorithm, trying to make it faster.Youíll notice that it takes almost 50ms to display about 10 tank hulls.With a tank being four blits, this isnít fast enough for the game.


I investigated using direct3d to draw the vehicles, but, to be honest, youíd have to build the game as a direct3d game from the ground up.You run into other problems with the vehicles having to be square bitmaps and the map having to be tiled into smaller sections to fit into graphic cards memory.


So, I ran tests on the rotation.Itís fast enough compiled, maybe 20ms per rotation.Seeing as infantry will be pre-rotated, this should be fast enough for the numbers of tanks (up to 30 per game).The slowdown was caused by the TransparentBlt function.It takes 4.5ms to perform, compared to about .5ms for a regular blit.So, that means we have to go back to masks and a new shadow file (to get a grey-type overlaid shadow.


The next step is to ignore the sprite resizing for the moment.Limit vehicles to 64 by 64 for the moment, although it would be good to try and set up different sized arrays.They still have to be square though for the rotation algorithm.


Non-square vehicles mean that the collision detection will be a pain in the arse, as each sprite is surrounded by a big, invisible border.We will need to store the tank dimensions and perform collision detections off that.Also, non-centred rotation points will feck up the rotation.


To rotate non-centred sprites:


We need to rotate around the centre, but also rotate the centre point to hook the turret onto the hull.God knows how to do this, I reckon I might actually have to understand the rotation algorithm.


Code is here.




29 Feb, 2003:


okay, there is now an array of units, all selectable and moveable (select and press Z to move).There's a selection sprite to see what's selected.The background is scrollable (right mouse button). They're also culled if not visible. Code is here.


The vehicle graphics are set up in text files.


The Battle directory sets up which map we'll use and which units are on the map (and where theystart)


The Graphics directory has three subdirectories:


††††† Maps:where the Battle\mapdetails.txt looks for the scrollable map

††††† Misc:contains the backbuffer(needed?) and the select sprite

††††† Units:††††† contains the unit graphics (turrets coming soon)



Next step:


We're restricted to even-sided, multiple of 4 pixel sprites for the units.But units will not be even'll also be easier in the long run to just draw the sprite and tell the program how big it is, so that it can blit it into an appropriately sized even-edged sprite.We should also perform some kind of stretching to the bitmaps before they get to the screen.CC seems to stretch vehicles by 150% or so, probably more for infantry.This will make the rotating more efficient.




vehicle sprite:41x25

game sprite:64x64 (maximum edge+40%, into even edged sprite 16b16,32x32,64x64,96x96)


vehicle sprite: 64x46

game sprite:96x96


Big sprites take longer to rotate due to the way the code operates.It converts each bitmap to an array (x3 for colour information), so a 10x10 sprite is 300 bytes of info.The rotation is only performed when's needed to be rotated.There's an array buffer which stores the rotated version if the vehicle is stationary, so we don't need to rotate it again.



Also, it might be more efficient to tile the map into sections of 120 pixels.It might stop the big blit and give us 10ms or so, which might come in handy.