A surprisingly productive day considering I was avoiding doing any work for the Man. Coffee withdrawals are pretty bad. I can't concentrate on anything much and have an overpowering urge to fall asleep at a moment's notice.

The game now ends - which is nice - and starts up again from the title screen. After a few tweaks here and there, such as making sure all the gidrahs were removed for the next game, it's worked just fine. Todo: "Game Over" and a high-score entry / display screen.

Jellies, blobs and bubbles are all behaving properly and interacting as they should. I notice the Gunner has dissappeared. I wonder where it's got to.

Messed around with Ant for a few hours as well, trying to get it do do what I want from Eclipse, but it persistently refused to obey my instructions. In the bin with it for now. The new version of Eclipse has better Ant support but it's got a fatal bug and won't compile any of my code

Got hold of Chaz, who says he's up for doing sprites. Hurrah! I'll be seeing him weekend after next. Sent him a demo but his shitbag Voodoo3 system failed to run. In fact it bluescreened which says a lot about the drivers considering at the point it bluescreened all it was trying to do was change display mode... hopefully that'll be resolved in LWJGL at some point...

Put the player beam-in effect back in. It's still rather dull; I'm hoping Chaz will think of something cool to put in as well.

I'm really having some awful trouble with OpenAL. I found a bug in the code whereby it calculated the pitch of a buffer to be 0.0, and then proceeded to do a divide by zero with it, which in turn caused an endless loop in the OpenAL driver (and hence a lockup at 100% CPU which was tricky to get out of thanks to Windows XP's awful multitasking capabilities). It took absolutely ages to pin down with loads of printfs - I don't know how to debug .dlls when they're loaded by Java - and then I recompiled the AL drivers and now I've got crackly sounds. Like they're being badly overdriven. I wonder what's up. The source is straight from the OpenAL CVS.

Fixed a bug whereby if the last blob was mutated the jellies didn't arrive (which is the whole point...) Also added a suitably unpleasant sound effect and horrible strobe when the the jelly incursion begins.

I noticed a sprite glitch occurring; when new gidrahs are spawned they flash for one frame at 0,0. Hmm. I bet it's one of those really annoying bugs that take ages to find and then have you bashing your head on the wall.

I'd like to alter the behaviour of jellies to make them a bit madder. Eventually, due to the fact that they home in on the player, they all end up in a huge wobbling cluster, which makes them a bit easy to zap. I think every now and again I'll adjust their movement randomly.

Caffeine withdrawals now very, very serious. This is unlike anything I have experienced before. I see movement in my peripheral vision, and hear noises that aren't there. Urge to sleep is stronger by the minute. I feel like killing everybody that comes near me. Good thing I'm writing a nice relaxing game of destruction then!

I suppose you might want to see some more screen shots... well, they can wait until Chaz beautifies the current sprites, I think. It's very difficult to get an interesting screenshot in the game because everything happens so fast.

Put the player beamin sound in. Once again experimented with positional audio in OpenAL and once again was greeted by sounds which inexplicably fail to occur. Must hassle Brian once more. So I put it back. It still sounds pretty awesome if I say so myself Remember when you were small and walked around the arcades trying to get near the Defender machine? You couldn't see it because of the crowd of geeks clustered around some hero or other but you could tell where it was because that's where all the evil noises emanated from.

Put the Jelly incursion into a separate Feature so I can dick with it in XML. Also moved difficulty factors into XML now so the gidrahs can get harder as the levels increase. Some gidrahs won't even be appearing on later levels.

Those mischevious Danes had me doing funny things with LWJGL and one of them was putting a drag bar on the debug window. Inexplicably this causes the application to hang if the window loses focus. Grr. If anybody's got any ideas why it freezes (on a wglSwapBuffers() call) having lost focus, please get in touch.

So XAP is more or less playable now - I've actually found myself just having another go instead of actually looking for bugs. That's quite a good sign. Let's have a ToDo list to keep me focused!

Do the control panel with score, lives, bombs, and shield indicator

Go to the next level when this one's cleared

Put up the end-of-level bonus screen

Smart bombs - nice and easy

Bonus indicators for rescuing Blobs from Bubbles

Find out where the Gunner's got to

Fix positional sound

Tweak sound priorities

Adjust background parallax so it's right

Think about doing a radar

Do a high score display

Do high score entry

Fix the title screen so it isn't a big bag of shit

Do title screen sequence to run through the gidrahs

Do help screens - just static instructions, no point in animation

Resist coffee

Make Bubbles slightly more aggressive and chase Blobs a bit

More sound effects for all sorts of little things

Consider adding gidrah's velocity to bullets fired

Shrink sound effects down to 11khz mono where necessary or Ogg

Start thinking about nicer game background again

Consider possibility of a little pseudo-3D so I can do fancier particles

Fixed an annoying bug in the PriorityPool which meant that lower priority sounds could pre-empt higher priority sounds. I'm going to put the sound priorities into the XML data files so I don't have to hunt around in Java code for them. It's easier to balance and assess the priorities of different sound effects too when they're all in front of you in one place.

Downsampled everything to 11KHz mono today. Some of the sound effects actually sound better! Some of them are a tiny bit worse. I played the game through my stereo and it still sounded like the house was under attack by aliens so no worries there. The tool I used is Sound Gadget Pro - shareware costing only a tenner - from http://www.compsoc.man.ac.uk/~nigel/SGPro.html (I bet the URL changes because it looks like he's at University). This is another tool worth every penny of the ten quid I haven't yet paid him Rest assured it's something I'll definitely register when I can be arsed to.

Chaz is hopefully coming over to visit on Sunday. I think he's starting at Rage in Bristol next week doing contract monkey work for them on some of their 3D models which don't look right. They actually have the nerve to pay him £8 an hour for this. You can get £8 an hour cleaning windows. He's one of the most genius talented artists I have ever met, and really ought to be earning about £40 an hour, which is what I'd pay him if I were hiring him Instead I get him for free! Well, 20% of the royalties. That could be a fair old chunk though considering he's only got about 1 months' work to do on XAP.

Showed Brian a WIP demo of XAP last night, and he seemed to like it. We talked about the design a little and three main things came to light:

1. The laser would be better if it fired and stopped where you actually targeted rather than a fixed length.

2. Powerups. Brian really wants powerups in the game. I was umm-ing and ahh-ing over having powerups because they have a tendency to screw up balanced gameplay, but Charlotte chimed in as well and said she wanted powerups too. So Powerups there shall be.

3. Big bosses. Brian wants end-of-level-gidrahs as well (and the moon on a stick). Once again Charlotte backed him up. Grudgingly it looks like I will be adding eolgs as well then.

The laser took all of 5 minutes to change. I also added an autofire; hold it down and it repeats every 10 ticks. You can still whack the mouse button over and over to get it to shoot faster but the real reason I put in the autofire is because I fear for my mouse's longevity...

On powerups: I think that I will basically use the same powerups that were in XAP. In the original XAP, powerups beamed in randomly at the same time as an attack wave. This time however I think I will limit their availability somewhat; perhaps they will appear every 7,500 points or so. Extra lives and smartbombs also appeared as powerups instead of being automatically awarded when your score reached a certain threshold - currently every 10,000 points.

You can collect multiple powerups of the same type to stack them for even greater effect. When you die, you are stripped of one level of each powerup (to prevent 'stranded-on-level-16-with-a-weedy-gun' syndrome).

The bosses (eolgs) will appear at the end of every 4th level. I plan to have 32 levels in the game, so I'll have to have 8 eolgs. After level 32, I won't describe the attack waves in XML any more, you'll just get 8 waves of 8 random gidrahs per level thereafter and a random eolg every four levels, until you die.

I have to consider these factors when adding features to the game:

1. How long does the feature take to develop, and hence how much money does it take to develop it?2. How much more of an incentive does the feature have to purchase the full version of the game?3. Does this work out in turns of return on investment?

In the case of powerups, it makes the game more satisfying when you get a few good ones as you really get a feeling of invincibility (illusiory, of course, as it still only takes one bullet with your name on it). The player benefits are clear, and it might result in, say, an increase of 0.1% to the number of people registering the game, and that might result in another £1,500 profit on a (guesswork) registration rate of 1% on 100,000 downloads over the years at £15 for the full game. As the powerups are likely to take only a week to implement that will probably pay off so I'm pretty happy to be doing it. Of course I won't know until it's too late, but I've got to start somewhere.

The case for the eolgs is harder to pursue. Eolgs take, typically, about 2-3 days to design, animate, and program or so, being complex as they are. Therefore we're looking at approximately one month to do the eolgs. Now if having eolgs every four levels is a registration incentive - "ooh, I must get to see the next one" etc. - then it's got to be a pretty powerful one. Remember, Space Invaders, Galaxians, Pac Man, Defender, Scramble - none of them had bosses, but people got hooked playing them just the same, because they got into the "Zone" and became one with the machine. Man. Then of course there's the fact that half the people who register the game may never see past level 16 anyway because they get bored or because they're just too crap at playing it, in which case that's a load of time and effort wasted because most people will never see these gidrahs anyway.

If eolgs only give me another 0.5% conversion rate then that's £1,500 for one months' work, and that's no bloody good. Not to mention they'll add a megabyte to the size of the download (actually not so bad as it's the size of the demo that usually puts people off buying games). On the other hand if the combination of eolgs and powerups makes the game twice as compelling as it was without them - say, a fantastic 2% conversion rate - then it'll mean £15k for 5 weeks' work and that looks like a reasonably safe bet.

All based of course on whether I publish the game or someone else such as Dexterity or Garagegames publish it, in which case we get a far, far smaller cut. Dexterity offer 35% (so we'd only make £5k on it) and Garagegames offer 65% (so we'd only make £10k on it). On the other hand, Dexterity and Garagegames will probably give us ten times the downloads we otherwise might have. I'll be looking into this at the end of February when hopefully XAP will be at ready to start a wider (read: public) test phase.

What I'd like to do now is ask for your opinions on eolgs:

- Do you consider them to be an important part of the game to break the flow up?- Or do you just like getting sweaty palms and blasting ever more ferocious swarms of little gidrahs?

You can see it's sprinkled with assertions about the way I think state should progress. I've used this method in Entities, Gidrahs, the Player, the Game, the GUI, etc. to make sure that everything is done in the correct order, and it's trapped quite a few logic bugs so far.

There's a nice way to do state machines in Java that involves modeling each state as a class with an operation to switch to another state defined in it; this is the proper OO way of doing things but it's not really necessary for my little game as I have so few states to worry about.

Stuff done:

Game now progresses to the next level when the gidrahs are all dead

End of level GUI now shows your bonus. Need to do a blob animation in it though to count them in one by one.

Smartbombs are implemented. They're quite psychedelic at the moment, being rainbow coloured. I rather like them like that.

XAP has gone pseudo 3D! Wait! Before you get excited it's not 3D at all, it's still 2D, except that I've changed the view frustum from a glOrtho to a glFrustum and currently I'm fiddling about trying to get the right range of values which leaves the original orthographic projection plane at z=0 intact.

Using the new projection I'm able to do 3D particle effects, which will be nice. The backgrounds have also got some proper depth now, and they look better for it. In fact, good enough to keep instead of replacing them with something else (which would have a very poor return on investment anyway).

Stuff done:

XAP has gone 3D ish, which fixes the background parallax perfectly.

Found out where the Gunner's got to - had an extra zero on a timer, so he just slept in is all.

Resisted coffee all last week! Hurrah!

Make Bubbles slightly more aggressive and chase Blobs a bit: now they pick a Blob to molest and 30% of their moves will be towards it instead of wholly random. If there are no Blobs they start menacingly wobbling towards the player in an unconvincingly deadly display of terror.

Shuink sound effects down to 11khz mono where necessary. Some of the sounds are actually better than before. Strange! Not tried Ogg yet.

Thrilling eh? Unfortunately all the exciting stuff happens in the Interface class which is the entry point to my GUI library The general gist of it is that the Interface works out what the mouse and keyboard are up to this frame, and manages all the little controls and windows and things that I have on the screen (one of which is a Panel running the game). Then, after all the thinking's done, it all gets rendered in one go, and I swawp the buffers and play any sounds that are waiting to be played.

However if there's any newless clewbies reading take note of two things going on in this loop:

1. There's a frames-per-second counter. A lot of people ask about this very simple piece of code - no idea why as it's beyond trivial, but here it is, if you're still stuck.

2. If there's no fixed vertical blanking rate from the monitor (from WGL_EXT_swap_control on Win32, no idea about Linux and OSX yet), there's a thread-based sleep hack in there to keep things at the right rate. It's not guaranteed to work (although it just happens to on my laptop) but it's the best you can do without busy-waiting on the hires timer which is a nasty thing to have to do.

Chaz has done a Bubble! It looks about, ooh, 100x better than my bubble. I have written a packing routine which takes a directory of PNGs and squeezes them all into a legal OpenGL texture - that is, one with side lengths that are powers of 2. It trims off any blank space in each PNG first and then uses a recursive subdivision algorithm to try and fit them in as best it can. It also writes out an XML file containing details of where it stuck all the sprites and their new hotspots as well. When CVS at sourceforge is working I'll upload the new tool to SPGL.

Created a new particle feature today - the Explosion particle. Very similar to a SimpleParticle except every few ticks an Explosion particle spawns some smoke behind it - the smoke itself is just a plain old SimpleParticle like I was using before.

The explosions now occur in X, Y, and Z - as in fact do all sprites as I've updated the SPGL sprite engine to work in 3D now!

The 3D effect is quite noticeable.

Chaz has also done me a player ship! I'm just waiting for that to turn up in a .zip sometime this evening.

I am using Remote Administrator to control Chaz's computer now and again (don't worry - he knows ). It's a godsend for getting non-developer types up and running with Eclipse and CVS. He can now get the latest code straight out of my CVS repository. Remote Administrator is by far and away the best remote admin tool out there; I even paid money for it, so it must be good!

Can't resist a couple of screenies:

[size=0]At last, lovely bubbles![/size]

[size=0]A Jelly Incursion! It incurred right on top of me so I died though.[/size]

Chaz did the player ship and committed it via CVS. I plugged it in and suddenly XAP no longer looks entirely shit!

The player ship consists of 64 different rotations. It constantly faces towards the mouse pointer. I have a funny feeling there's a lot of newbies who would like to know how to do this, so here's the code that does it:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22

// target is a Vector2f which has the mouse position in world coordinates in it// (not screen coordinates). position is a Vector2f with the player's world// coordinates in it. We subtract position from target to get the 0,0 based// direction vector.Vector2f.sub(target, position, scratchVector);

// Then we find out the angle in radians of this vector using a built-in Java// function:doubleangle = Math.atan2(scratchVector.y, scratchVector.x);

// Sometimes spriteAngle is negative, so to ensure it's in the range 0..63 we// add 64 to it, plus a small offset to match the angle versus the angle of my// sprites (they happen to be 90 degrees out as they're drawn) and then use the// modulus % operator to get us back to 0..63:spriteAngle = (spriteAngle + rotation.length + 16) % rotation.length;

// And that's the sprite image we want:sprite.setImage(rotation[spriteAngle]);

I put in a little smoke trail from the ship's thrusters which looks nice. It needs a pair of glowing jets as well which I'll figure out tomorrow some time. I suppose it'll need a little quiet "whooshy" noise for when the jets are firing too.

Here's a pic of the ship:

Did some adjustment of some of the sound samples today; the gidrahs' bullet is less annoying, and the gidrahs' explosion now echoes, just like the original Defender did. Lovely.

Discovered a garbage collection glitch today. After running for a few minutes, the game starts to stutter and jerk. I was rather perplexed by this at first but then I realised that the humble fps counter was creating about half a megabyte of garbage a second. You have been warned! I have cured it by using -Xincgc and -Xconcgc but the irritating thing is these aren't turned on by default. It's not such a huge issue really because a) it won't be in the released version and b) I'm deploying it as an .EXE anyway so I won't have -Xincgc and -Xconcgc - just whatever Jet 3.0 has in it.

Chaz sent me a new player ship and new bubble. The player ship is now ever so slightly larger. The bubble now has a subtle oily film to it - looks nice. Wobbles a bit wrongly though. Can't put my finger on it.

Tried the game in 32 bit - much subtler shading - nice. Can't really rely on 32 bit though because the performance will start to suffer once there's a lot going on.

Discovered a bug in my sprite packer that screwed up sprite hotspots. This caused the bubble to reel around the screen a bit drunkenly.

Tweaked the smoke so it looked more even - much better. The player now has 3,000 smoke particles allocated for death! The gidrahs by comparison only get 2,048 between them.

I noticed a little bit of a slowdown when twatting the gidrahs with a smartbomb. The sheer number of particles generated seems to drop the framerate somewhat - to about 45fps or so. It's barely noticeable because the smoke dies in 2/3rds of a second but it was still enough to make me go in search of tweaks.

First up, the SPGL sprite renderer now uses NV_vertex_array_range if it can find it. Anyone know what the ATI/Matrox/S3 equivalents are? That seems to have sped it up a teeny fraction.

Secondly I tried running it with the server VM again, and it's quite a bit smoother when a smartbomb goes off. Later I shall compile with Jet and see how that fares, as it's the crucial decider.

I think it's fill-rate bound now rather than vertex bound which bodes ill for sticking a nicer background in the game. 5,000+ alpha blended particles is quite a lot for a card to handle. I wonder how I might scale it down for older cards? I'm still hoping that it'll all run smoothly on a TNT. I might be cunning and write a frame rate analysing thingy. This thingy will watch for frame rate drops and start to lower the ceiling on particle creation accordingly. Particles are just eye candy after all, and if they get in the way the most important bit of eyecandy, which is graphics that are smooth as a baby's bum, then they've got to go.

Chaz can't do any work today on the game but apparently he's got all Wednesday to do sprites. Hurrah! I'll set him to work on the Tringles, Jellies, Gunner and Blob, which will be the complete complement of sprites for the alpha tests to come.

Speaking of which, I'll be needing some alpha testers soon - preferably with diverse hardware. I've got the following hardware to hand and I need some volunteers with freaky hardware that's different to what I've got - particularly, I'm interested in older processors and graphics cards.

Using the server VM (which approximates the performance of Jet), I'm only getting a mere 40-odd fps when I generate hundreds of particles - and this is on a 1.2GHz P3. To get 60fps, my frames have to take no longer than 16ms or so. Currently they're taking 25-30ms when there are a lot of sprites on the screen. At first I thought it was fill-rate but a closer look at the native side of things shows me that in fact the limiting factor is my own compiled code at 58% CPU (15ms or so).

This is bad.

As usual the main culprit is in a library that someone else has written. The mergeSort is probably a perfectly fine routine, and here in fact we can deduce that the figure of 21.7% given includes the inlined comparator that I use to compare the sprites with. First off - can I replace it with a radix sort? Will that be any faster? Can I do something cunning so that I don't have to sort my sprites in the first place?

Secondly, there's writeSpriteToBuffer. This has actually got its work cut out for it as it has to scale and rotate the sprites itself in order to take advantage of glDrawArrays. I'm not doing any rotation but quite a few sprites are being scaled using floating point maths when really they could probably be done using integer maths somehow. Instead of specifying a scale in terms of 1.0f being 1:1 scaling I should specify an absolute width and height for the sprite to be rendered at (which would default to the actual width and height of the image for sprites which aren't scaled).

Thirdly, the SimpleParticleInstance.doTick method looks like it could do with some optimising as well. All this has to do is add vectors together. Perhaps particles need to be moved into fixed-point integer maths because this is just far too slow. There's only a thousand or so particles whizzing around, and that's just not acceptable performance.

Finally, ColorSequence getColor is taking a strangely long time, which is odd because it's quite trivial - so it'll need investigating.

It's worth stopping tweaking the game now and getting these bits optimised now because they're "finished" - the code works and will be in the game in this state, so now's the time to tweak it and make it faster whilst it's easy to check that it's working properly.

Surprisingly, performance optimisation is actually quite a fun aspect of games programming, and it doesn't get much of a mention.

Ooh! A visitor!Yeah, hopefully I'll be releasing it through an indie publisher of some kind (I mentioned a couple of favourites earlier) and I expect it to cost about £15 or so (gowaaaaaan! the price of a takeaway curry! cuttin' me own throat etc.) and if I end up making enough out of it to quit the day job - I will! And write another one. I've got 3 games lined up, all very thoroughly planned.

Intrepid beta testers can of course expect their own copy

Oh yeah of course - there's a 4 level demo too.

Right then, I'd better get on putting the radix sort into the sprite engine...

Sorting now takes a mere 7% of the processing time instead of 22% - so I've just speeded up the whole process by a huge amount. Now the frame rate only begins to drop when there are thousands of particles on the screen. I've still got to figure out what's killing my dual P3/700 GF1 Win2k system when anything explodes. I mean, just a single explosion slows it down to 15fps, but you can have tons of other stuff going on and it doesn't bat an eyelid. I'm wondering if I haven't picked a mode which requires a software path on the GF1 but to my knowledge it's all pretty trivial blending going on. Odd...

writeSpriteToBuffer might still be tweaked but I don't think it's worth the effort - if I can handle 1,000 sprites without performance degration on the target system I'll be happy. There are a number of issues concerning floating point performance that I'm worried about though, and I'm thinking it might be wise to try and move to ints where possible. Once upon a time floating point was a supreme luxury that scientists and other incredibly patient users used to do clever things. Now they're just an easy peasy way of moving gidrahs. How times change

The moral of the tale: [size=3]Never trust anyone else's code![/size] This was actually something I learned from Michael Abrash's Graphics Programming Black Book (an excellent book - dated but entirely relevant).

Other things I have done - there's a fps watcher in the main loop now. If the fps drops below 35 for longer than a second or so then it tells the game to cut back on the special effects. Right now this is a rather simplistic reduction in the number of particles allowed in the game. It'll probably do the trick. The end result is that the game tunes itself slightly to your system.

There's also a gidrah queue now. I've limited the maximum number of gidrahs in the game to 32 (it gets too crowded otherwise and runs the risk of slowing down heinously). When a gidrah is spawned and there's no free slots it sits patiently in a queue waiting for one of its brethren to get the finger, at which point it appears as normal. Some gidrahs bypass the queue and will appear even if there are no free slots - these are the ones that appear dynamically in the game rather than ressing in, like Mad Jelly mutations or worms. Oops, gave one away there

Chaz has done me a Mad Jelly and a Tringle. What can I say - they are absolutely fantastic. You've never seen lime jelly look so mean. It's like evil flubber. Hopefully he'll do the cute purple blobs tonight. I think he wants to make them furry with big googly eyes. It'll be a sin to pop a cap in one that's for sure.

I'm thinking that to reduce the size of the final executable I may have to skip every other animation frame Chaz has done as we've already grown a megabyte in size with just four sprites done. I doubt whether anyone will be able to tell the difference as everything's so fast anyway.

Also put in the skeleton code for the powerups, and the other supporting code for rotating orbs and homing rockets. I don't think I'll include powerups in the demo as a little bit of an incentive :-p

I have spent all day today replacing nearly all of the floating point calculation in the game with fixed point (16:16) arithmetic in an attempt to get greater performance. What an absolute nightmare! It's still not perfect because I need a fast fixed-point multiply and fast fixed-point divide (I still cheat and convert to floats) which are accurate without overflowing. A fixed-point sqrt would be nice too; there's one in Allegro I might try and figure out.

I've also abandoned WGL_EXT_swap_control - probably a good thing as it's not cross-platform - and now resort to timing frames. I had to do this because as soon as a frame exceeded 17ms I missed the vertical blank, and had to wait for another one to come along 17ms later. The result: instant 30fps slowdown. At least with frame rate capping it degrades very gradually; I very rarely see less than 60fps now on the GF1/P3-700/Win2K box now even in full catastrophy mode. Even Brian gets 60fps on his cranky 500MHz celery/GF2MX rig. However, it tears a bit now when you zoom around. Bugger. Still, it can't be helped.

The good news is - performance is nearly doubled thanks to this gargantuan 14 hour effort, including all sorts of other tiny tweaks. What's the moral? Well - don't use floating point, that's what. Modern computers can handle floating point all right - the laptop never saw a slowdown but it's got hardware T&L and a 1.2GHz P3-M in it - but hardly anyone actually owns fast hardware. The vast majority of people are still using wanky 500MHz beasts with TNTs. I'm excluding totally casual gamers from my target market by the way - maybe a bad business decision, but ultimately, it's not a very casual shoot-em-up. It's very, very, hardcore

Of course, when I get hold of a system without T&L in hardware it's back to doing millions of floating point operations per second again. This might not be good. I will have to include an option to disable eye candy and such. Bah.

It's 1:20am again. Yawn. Chaz is coming over tomorrow all the way from sunny Brighton to put in cute purple blobs and mutation animation, and the Gunner graphics. And... that's the core game! So it'll be time to start adding stuff like title screens and score panels etc. Public alpha test in 2 weeks' time. Still looking for volunteers to try it out....

Chaz arrived this evening. Instead of doing any work though we got pissed and played a few indie games to see what we were up against. Mutant Storm - pheweeee, now that is a fine game. (PomPom are insanely good). There's Galaxy Force, Gridrunner++, Space Tripper, BrainWave (!), Strayfire, and of course, the original Defender running in MAME32.

The good news is, XAP is beginning to look like a proper pro competitor. The gameplay is very solid, and it turns out people are actually really enjoying whizzing around shooting stuff. I even catch myself at it for no good reason when I should be working for The Man.

Charlotte slagged my laser off again. Chaz doesn't like it much either I'm gutted, because I really like it. I might possibly replace it with a single elongated quad though because drawing 400 sprites to render a single laser is serious overkill. You can have 12 of them on the screen which can amount to an awful lot of processing for not a lot more effect. But then - what should the laser look like? Answers by email please...

Particles have now been subdivided into two types - sprite based particles and GL_POINT based particles. Gidrah and player explosions together accounted for nearly 1,000 sprites in sparks alone; that's 4,000 vertices to process. Now they're rendered using GL_POINTs, which is only 1,000 vertices and a corresponding 4x speedup in processing. Always trying to get those low-end systems performing acceptably. They don't look quite as nice as the sprite based sparks but after a little while I didn't notice any more.

Talking of which - we all noticed that no-one ever looks at the player's ship. It's so obvious of course that no-one has ever mentioned it - but you're always looking at the target, not the avatar. It's been the same since the very first Space Invaders of course - right after you've marvelled at the graphic for the first time you stop looking at it and worry about the things that are whizzing around the screen trying to kill you, and never really look at it again! (Just like riding motorbikes in London) We saw, for example, that the player's ship in Mutant Storm is crap! But it doesn't matter, because you don't look at it!

Chaz didn't manage to finish the cute purple blobs but he did do the Gunner, which is an angry, throbbing, slightly translucent red ball with spines. I'm going to make it smoke a bit while it chases you, and try to create a sizzling sound effect like frying bacon. The gunner is now faster than the player - you can't outrun it - but it's slower to accelerate, so it tends to shoot past you. I might stop it from shooting as it travels faster than bullets anyway.

We've started work on the new background for XAP as well to replace my naff circuit board patterns. There's a bottom, repeating texture layer, which just scrolls away and never ends, and over the top of it, there's a transparent layer drawn as a grid (indexed GL_TRIANGLES, if you're interested). I'm a little worried about burning fill rate on older cards as this effectively means blitting the whole display and then blending the whole display as well as drawing all the sprites and points. We'll have to see how it goes.

The top texture sees the return of the classic water rippling effect to perturb it. When I put some lighting on it it will wobble and ripple when things get blasted on it or res-in.

Technical Fact Time

Once upon a time using an indexed GL_TRIANGLE_STRIP was all the rage, and it was important that you figured out how to draw everything by stitching it together as a triangle strip, naively believing that this was the fastest way to do stuff in OpenGL (or D3D for that matter).

Since then of course I've sat and had a think about how drivers and hardware work when using indexed primitives.

And driver worth its salt will cache the last couple of vertex transformations it has done. This means if you are just drawing with GL_TRIANGLEs, and draw an adjacent triangle (eg. 1, 2, 3, 2, 3, 4) then only one vertex actually needs to be transformed. Furthermore, in these days of T&L and on-card vertex caches (I believe even the lowly TNT has a 3-vertex cache) it's very likely that the transformed vertex won't even need to be sent down the bus again. In other words, using GL_TRIANGLEs is, in general, no slower than using GL_TRIANGLE_STRIP. What's more, because you've avoided the headache of trying to turn a bunch of discrete triangles into strips, you've probably made your overall code even faster. There's only one downside, and that is you need a slightly larger indexing array.

There is of course a whole other thing about optimising triangle rendering order to maximise the use of on-card vertex caches (the GeForce range has a 16 vertex cache, which is, it turns out, almost the perfect size for nearly all geometry). But I'm drawing sprites, and they're quads, and they're not connected to each other anyway. So I'll maybe talk about that another time

All work and no play makes caspian a dull boy. All work and no play makes Caspian a dull boy. All work and no play makes Caspiana dull boy. All work and no play makes Caspian a dull boy. All work and no pla ymakes Caspian a dull boy. All work and no play makes Caspian a dull boy. All work and no play makes Caspian a dull boy. All work and no play makes caspian a dull boy. All work and no play makes Caspian a dull boy. All work and no play makes Caspian a dull boy. All work and no play makes Caspian a dull boy. All work and no play makes Caspian a dulll boy. All work and no play makes Caspian a dull boy. All work and no play makes Caspian a dullboy. All work and no play makes Caspian a dull boy. all work and no play makes Caspian a dull boy. All work and no play makes Caspian a dul lboy. all work and no play makess Caspian a dull boy. All work and no play makes Caspian a dull boy. All workand no play makes Caspian a dull boy. All work and no play makes Caspian a dull boy. All work and no play makes Caspian a dull boy. all work and no play makes Caspian a dull boy. All work and no play makes Caspian a dull boy. All work and no play makes Caspian a dull boy. All wwork and no play makes Caspian a dull boy. All work and no playmakes Caspian a dull boy. All work and no play makes Caspian a dull boy.All work and no play makes Caspian a dull boy.

I've been feckin' around with backgrounds again, trying to make the water effect look a) not shit and b) not slow but sadly I seem to be failing in the shitness department. Slowness is probably going to be a problem too as it relies on drawing every triangle twice - thanks to the fact it's transparent I've got to do a depth buffer write pass first - and I've got to use lighting, which has always been a fairly slow affair on cards without T&L built-in as the computation has to be done one what is probably also a very slow CPU.

In other words, it would gobble up all that optimisation I've already done to make it run acceptably on the baseline system.

It looks like that the backgrounds are once again up in the air for a complete rethink.

To distract me from hair-pulling antics we've been trying to think of a proper name for XAP. "Alien Flux" is looking to be the favourite. I think I might start a new thread too as it's getting to take a very long time to reply to this one.

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org