and the winner is “Buffy the Vampire Slayer. Once More, With Feeling”, at least I’m sure it would be if there was such an award.

As a complete series Buffy doesn’t take the top spot on my favourites list, that honour is reserved for Bablyon5 for which other tv shows to date aren’t even in the same league. That said, I’ve still really enjoyed watching it over the years. Somehow though I managed to miss most of season 5, and all of season 6 and 7, but having just had sky put back in and season 5 of Buffy happening to be re-screening I’ve been catching up. Which brings us to Season 6 and the “Once More, With Feeling” episode.

Outside of theme park stage shows I can honestly say I’ve never really watched any type of musical, I’ve tried, but they never hold my attention. This episode however really does stand out, I mean its even spawned fan sites for just this single episode, that’s unusual isn’t it?

If you’re a Buffy fan I’m sure you’ve already seen the episode, what with it been 5 years old and all ;). If however you only watch a Buffy episode now and then, this is one to watch sooner rather than later

A few short samples are available on Amazon who sell the sound track. Although they don’t really do the songs nor the episode justice.

• Under Your Spell
  
• Walk Through the Fire
  

I’ve been coding a basic line buffer renderer for the XGS, I say basic because firstly its black and white only (well black and a fixed colour) and secondly its still in need of a good optimisation.

The current code takes up just under one page (<512 words), however with a lot of spare cycles there's the oppertunity to reduce the code size whilst still meeting the tight timing criteria. The largest chunk of the 512 words is taken up by the numerous uses of the DELAY macro in generating the HSYNC delays, shifting this to a subrouting would make quite a difference.

The buffer itself handles 200 pixels with 4 pixel padding either side, giving a horizontal resolution of 200 active pixels and 8 overscan. Vertically it uses 208 active lines with 48/52 lines for top/bottom overscan and 4 vsync lines totalling 312 vertical lines. Although I'm considering reducing the overscan lines and increasing vsync to 10 lines to provide a greater number of spare cycles in one chunk for gameplay logic.

The line buffer uses 25 bytes of internal RAM (banks 1 & 2) for storage with each byte holding 8 pixels (thus the reason for single colour only support atm)

The line buffer is populated during each of the hsync periods utilising the spare cycles. During the active line period the code generates the required tv signal to output each pixel of the line buffer with only 20 cycles (250ns) per pixel available

Currently the biggest question is whether 900 cycles will be enough time to generate 200 pixels worth of data and cache it to the line buffer banks. With a player sprite, enemy sprites and missiles in the mix the cycle count could be quite tight.

The main rendering loop still has quite a few cycles to spare, around 12 per pixel, however using these will mean tightly coupling the line buffer generation with the rendering, which is something I would like to avoid.

Although not in place yet, the plan is the for game logic to run during vsync, which assuming we use 10 lines would provide just over 50,000 cycles for game logic. A further 420k cycles are available during the overscan generation which means there's plenty of room for gameplay logic and music.

Part way through building the line buffer I attempted to generate a pal signal with the colour GREEN for an on pixel and BLACK for an off pixel. However, my TV would not recognise the signal as PAL with colour output when using the NTSC setting only.

As the following forum thread describes, PAL has a few extra requirements to NTSC.

• 1 - Colour burst on alternative lines must be phase shifted +- 45 degrees
  
• 2 - Each colour output must be phase shifted by 180 degrees on alternative lines
  

With James’ help and a fair amount of time reading the PAL specs and XGS specs, the TV finally picked up on this been a PAL signal and displayed bars in all their colour

Next step will be finalising the hsync callback code to render a player sprite under joystick control.

At a later date I’ll probably look into increasing the size of the line buffer to 100 bytes which would allow 200 pixels at a bit depth of 4. Then up’in the sprites from been an 8bit x 8bit block to support 4 bits of colour information per pixel. Using a palette this would allow for colours 16 colours.

A larger bit depth is plausible especially if its moved out to the external SRAM, however doing so may require some creative thinking in order to meet the timing requirements of 20 cycles per pixel.

Once the code is more functional and rendering a few sprites I’ll get it uploaded, perhaps with a pdf explaining everything for any XGS owners that are interested

Having done a little more reading on the GP2X (GamePark Holdings) I thought I’d check out how the XGP (GamePark) was coming along and came across three videos of the prototype in action on youtube.

From what I’ve been hearing the XGP may still under go further changes before shipping, which with an estimated release date of November makes me wonder if we’ll see further delays. I’d be interested in hearing what the changes are though and how they affect the specs.

I’m in two minds whether to plump for a GP2X which is available now, has a solid community behind it as well as a good set of emulators and homebrew games available. Or, hold out in the hopes the XGP does ship on time (assuming it ships at all) and lives up to its promise. From the brief amount of reading I’ve done, here’s my current pro/con list (of course my pro/cons may differ from yours based on what you want out of the system).

The GP2X VS the XGP

XGP Pros:

• 3d hardware - Aside from anything, it’ll be interesting for homebrew development
  
• Wifi
  
• 16:9 resolution, wide-screen movies
  

XGP Cons:

• More expensive than the GP2X.
  
• 16:9 Resolution of 480×272, not really suited 10+ year old games with mainly 4:3 aspect
  
• Single processor ARM920T, GP2X has an ARM920T and ARM940T
  
• Not truly open, although an SDK will be available, GP2X appears to be more open overall.
  
• Not available yet. November estimate.
  

Both a pro and a con is the addition of an analogue stick on the XGP. Whilst useful for new commercial games and homebrew games a digital stick imho would be preferable for emulators.

Several people think of the XGP as the successor to the GP2X (albeit made by different companies) newer and better in all regards, however, from my pov both devices have their own strengths and weaknesses, so the choice is not a simple one.

On the one hand the GP2X makes for a good emulator platform, on the other hand the XGP has 3d support which would be nice to have available for homebrew on a hand-held and may help improve psx/snes emulators but then the res/joystick isn’t as suitable and I’m still questioning how open the XGP will be aside from allowing homebrew via an SDK.

I imagine the decision will be a whole lot simpler once the XGP finally ships and we get our hands on concrete information/specs. The question is will I still be on the look out for a hand-held by then or will I be busy playing/developing for the GP2X

If you’re interested in emulators check out pdroms.de for a number of public domain roms

I’ve been reading up on the GP2X a very interesting console from a homebrew point of view, why? Here’s a quote

It’s open. You want to develop your own games for the GP2X? Go right ahead. The SDK is included with the system free. Not since the days of the Amiga has a system been so easy to develop for, commercially and for fun

Not many consoles/handhelds that can claim that. The specs ain’t half bad either

Yes that’s right, this hand-held can connect to the TV, console style. Watch your DivX movies on the TV. Play emulated classics on the TV. Try big screen Quake. Or just play them all on the GP2X’s large 320*240 backlit screen. You get the best of both worlds.

It runs the free Linux operating system. This means a whole world of Games, Utilities and Emulators are at your disposal. Quake, Doom, SNES, Megadrive, MAME, Media players and Applications to name just a few.

It’s powerful - Two 200mhz CPU’s with 64meg of RAM, custom graphics hardware and decoding chips. Takes SD cards and has 64M of NAND memory. Plenty to play with.

For £125 the price isn’t that steep either. So far I’ve only read about two commercial games been available, but then most people will probably be buying this for movies, homebrew and emulator use. Still it’s encouraging to see commercial games, hopefully they’ll be a success and bring in more developers.

Been able to transfer movies over without having to re-encode for a specific format is certainly a big boost compared to the PSP. The only things it’s lacking in is 3d hardware support. The XGP (made by the GP2X’s rival company gamepark, or is it gamepark holdings?) is rumoured to have 3d hardware support included, however its not shipping till the back end of the year and I’ve yet to see any full specs to compare against the GP2X in terms of raw power and openness.

Having read that the GP2X’s developers split from gamepark (holdings?) the makers of the GP32 over concerns of openness makes me wonder whether it will be or not. I can’t see it having as much of an impact as the GP2X if it isn’t open, which would then place it in direct competition with the Nintendo DS and PSP.

Craig over at gp2x.co.uk has recently posted a new review of the GP2X and I have to admit it really sounds like a fun hand-held (although I love retro games so it isn’t hard to sell me on the idea).

On a separate note, for all the ball dropping Sony has done recently, at least they’ve made WPA available in newer firmware. Nintendo however appear to be a little more stubborn, that is if the word of a moderator on the Nintendo forums can be taken at face value

We have no plans for WPA at this time.

If your concerned about WEP, turn your computers are OFF after you’ve switch to WEP for the DS. I don’t care if The Lone Gunmen are parked outside your door with a van full of equipment trying to bust in your computer files, they can’t do it if your computers are off. And, yes, your wireless router will still work if your computer is off. Um, unless it’s plugged into the same power strip and you power the whole strip off.

If that’s not an option for you, you may want to get the Nintendo USB WiFi Connector, as it works ONLY with the Nintendo DS, and you can leave your other WiFi router with WPA.

NOTE: The reason the Nintendo DS is compatible with WEP, and not WPA, is that we found WEP to be the most prevalent standard for securing wi-fi connections.

WEP is obviously going to be more prevalent, it has been around for longer, but that doesn’t change the fact that it is also extremely flawed. I’ve not used WEP on my wireless network for some time now, in fact the only reason I delayed switching to WPA for so long was due to waiting on US Robotics to release a firmware upgrade for their wireless gaming adapter that my XBox runs off.

I’m not saying WPA is foolproof either, but at least it does offer a reasonable amount of protection. Hopefully Nintendo will change their minds on this and release a firmware upgrade (assuming the hardware is capable of coping with WPA?), either way I hope the new Nintendo console supports WPA.

As far as I’m concerned,the DS may as well not have wireless support if it remains as WEP only, there is no way I’m allowing WEP access to my network (although it’s a mute point anyway since I’ll probably get a GP2X eventually rather than a DS Hey I like old games and homebrew and favour openness over proprietary systems any day.

CGEmpire, a new forum I’ve been reading, posted a challenge to code a procedural texture generator. After seeing some of the examples in the challenge thread it looked interesting enough to have a go at.

I’ve created a DirectX app with a choice between three different texture generation methods. The first two are very simple, random and linear. Random selects a colour for each x,y pixel randomly and as you would expect is pretty much random noise. Linear draws 5 pixel wide alternating white/black bars, again nothing worth showing.

The third creates a cellular texture. This is my first attempt at generating a Cellular texture and aside from been extremely inefficient in the nearest coord calculation (brute force ) the results are quite pleasing.

I’m going to try a few variations on the default cellular algorithm and will post any that are worth seeing, I’ll probably also add a few more texture generators based on other methods such as Perlin noise etc.

Anyhow, heres a screenshot of the first results.

The Texture Generator Sample App is available for download and includes a few generators not shown in the screenshots. I think the best looking one is the Inverse Cellular

I’ll upload the final source code later on, too busy adding to it at the moment

EDIT:

Source code is now available for anyone that may be interested.

Forum Link updated, thanks Fabricator.