As it happens this Thursday is an NVIDIA holiday. Everyone else I know does not have the day off. So it's kind of a mini-vacation for me. I'll be sure to get in 9 holes of golf, but I'm also doing a day of programming.

As something different I will be posting updates throughout the day. I will likely work on both Chomp and Decaying Orbit. This will last from when I get up until about 3pm - my wife and I are leaving for the long weekend at 4pm.

This will be the longest chunk of uninterrupted programming I have had in a long time. I'll try to make the most of it.

I realized I didn't have the help page for Chomp's level editor linked anywhere. I added it to the main Chomp page.

Game Progress

7:55am I'm starting my day of programming. I'll take a break in an hour or two to go play golf. For now though I think I'll start with some Chomp work. I'm still making the changes suggested by Riff to use the overlay channel for sprites.

9:12am I'm working on the level editor now. While not difficult, changing it to use the overlay channel is certainly time consuming. There are lots of special cases to consider.

I'm leaving to play golf now. I'll update again in a few hours when I return.

12:10pm I'm back. Lunch is beckoning. I'll update after I eat.

12:56pm Golf was awesome! I got my second birdie. This one was a bit different than the last. Before I pitched it close for an easy putt. This time I sunk a 15-foot downhill putt.

I see I only have a couple more hours to program. How disappointing. Oh well, back to work.

1:29pm I switched over to Decaying Orbit and will stay here until I have to quit. I am adding the code that will scale everything down by a factor of 2. I already got the screen to adjust from 640x480 to 320x240. Now I must adjust all the sprite scales and positions so they look correct on the new screen. I'm getting a crashing bug at the moment...

1:46pm The positions are correct. It still hangs when I try to scale them down (although it looks rather cool as is). BTW, the shot to the right is full size. I don't have to scale the images anymore since changing to 320x240.

1:57pm Ah ha! I was scaling them in the wrong place in the code. The way I had it before would make the scales compound on one another. Since I was scaling each sprite down by 2 every frame the sprites were getting successively smaller and smaller until they were so small they hung the library.

With that fixed the game runs properly in all its chunky glory. And I'm happy to report it runs at 30 fps! It looks pretty bad now since all the sprites are getting scaled down from their hi-res counterparts. I'll eventually create new graphics for the lower resolution. This will not only look better, but it should be faster since the sprite lib won't have to do as much work with the scaling.

2:23pm Heh, I've been having fun playing in the level editor. Everything looks like crap since there's no transparency or tinting going on. Those big gray things are nebulas. They are supposed to be transparent and tinted a color other than gray.

Go here for instructions on how to use the editor. Some things are made more difficult by the lack of features. For instance, selecting objects is difficult since you can't tell which ones are selected.

My time is almost done. Let's see what I can cook up for y'all before I have to quit.

2:40pm Now's a good stopping point since I only have a short time until I have to go. I still have to pack and all that.

As a parting gift, here's a new build to try out. It currently crashes for me after completing the first level so you can't really get far. You can still fool around in the level editor and help screens.

This was a lot of fun. A rare opportunity to spend an extended stretch programming. I'll have to see about doing it more often.

I ran across the development diary for Jumpman: Under Construction recently. The guy is updating Jumpman for modern systems. He's doing some phenomenal stuff. Reading through his diary has made me more determined to work on Decaying Orbit.

Game Progress I think it's finally time to get Decaying Orbit to look correct. I have started writing my own sprite renderer inner loops. I will likely need to remove the old ones to make room in instruction ram. So I will eventually end up with a different version of the sprite lib that has Yaroze-like sprite types.

The existing sprite type #0 will remain the same since it's just a simple blit with no transparency. The other three will be removed, however. I'm not sure how many new renderers will fit in the code space that is freed. Ideally I will have a separate renderer for each of the following:

1. No transparency, no translucency, no tinting (this is the existing type #0)
2. No transparency, no translucency, with tinting (hardly used)
3. Transparency, no translucency, no tinting (most sprites use this)
4. Transparency, no translucency, with tinting (fonts & other gray-scale sprites)
5. Transparency, translucency, no tinting (explosions)
6. Transparency, translucency, with tinting (nebulas)

If I run out of code ram I'll have to cut one or more of these.

Transparency allows you to have sprites with non-square borders (like space ships!). You can designate any pixel to be totally transparent. Basically every sprite uses this except the background star field.

Translucency is what allows you to mix the sprite with the background (and other sprites).

Both require the renderer to read the background so the only penalty of doing both versus just one is the execution time of the inner loop.

Note I do not plan to use bilinear filtering. This is unfortunate since it would make the sprites look better. However, the inner loop for this case would consume lots of code ram. Not to mention the increase in execution time.

Game Progress I finished the renderer for transparent sprites without translucency or tinting. Of course this is the easiest one. I'm still working on optimizing it - I think I can shave off a cycle.

Getting tinting and translucency working will take longer. The tint is given as a scale value for each of R, G, and B. It is not straight forward to translate these into scales for Y, Cr, and Cb due to the nature of that color space. While Y represents an intensity, Cr and Cb do not. So I will convert the YCrCb pixel to RGB, apply the tinting and translucency, and convert it back.

Some matrix math and the Aries "dotp" instruction should help in this case. Care must be taken to avoid overflow and underflow.

Game Progress Add one more pixel type to the list I posted earlier. The next one I will write is a sprite with transparency and tinting, but not translucency. This is #4 from the list. However, this type can be broken down into two cases, with one being much faster than the other.

The tinting values are given as scales to R, G, and B and can range from 0 to 2 (the 2 is non-inclusive). So you can scale R by 0.75, G by 1.0, and B by 1.5 if you like. Values that overflow are clamped to the max of 255.

This is the standard flow:

• Convert YCrCb into RGB
• Apply tint
• Clamp the RGB values so none are greater than 0xFF
• Convert the clamped values back to YCrCb

Using matrix math you can combine the first and second steps. The clamping step prevents any further consolidation.

However, if all tint scales are known to be less than or equal to 1.0 then overflow is impossible and clamping is unnecessary. Thus, again using matrix math, you can combine all the steps (conversion to RGB, tinting, and conversion back to YCrCb). This will save like 5-6 cycles. And given that the inner loops are typically less than 10 clocks, that's a significant savings.

In other news, I optimized the inner loop of the second renderer (#3 in the list). The original sprite lib has a cycle time of either 6 or 7 cycles/pixel depending on whether or not the pixel is transparent. I knocked two ticks off both cases. This is restricted to my Yaroze-like sprite lib, but I think I can make a similar optimization to the original sprite lib too.

The time I had targeted for programming this past weekend was instead occupied by a 4-hour gaming get-together. We played Puerto Rico twice, and Medici once. Getting two games of Puerto Rico done in under 90 minutes each was quite a shock to us. Normally this is a 3-hour game. Having only three people sped things up, especially since we've all played it a couple times before.

Game Progress Regardless I managed to get in a few hours of programming. This matrix stuff is causing me headaches. The Aries multiplier is not very flexible regarding fixed-point formats. I have to actually keep different values at two different precisions. Some are at 8.8 while others are 10.6. This works since the values they eventually get multiplied to have the opposite format. So they all come out as 18.14 and get shifted left by 8 bits to put them back into 10.22 (color) format.

The amount of free ram is dwindling due to the matrix storage and multiplications. Worst case, I may have to remove the code that clears the screen. I originally added it to relieve MPE3 from the burden, making the clear faster. I may have to go back to the old method. This isn't too bad for Decaying Orbit since it hardly clears the screen anyway - it just overwrites the old frame buffer.

First, a heads-up that I will be gone Wednesday (tomorrow) through Sunday. I'm visiting some family. If I can get a reliable internet connection I will try to post an update. I will be bringing my Decaying Orbit notebook so I can jot ideas down as they occur.

I'm also bringing the GP32 for some Atari 800 gaming. I just tried the emulator for the first time and it seems fantastic. Rescue on Fractlus never worked for me on the C64 emulator, but it's fine on the Atari one. Joy!

Game Progress I went back and applied the optimizations I did for the yaroze sprite type 1 to the original sprite lib. I also sped up type 0. It was 3 cycles per pixel, but I got it down to 2. That's the limit, though, since you have to do a separate load and store for each pixel.

It still bugs me that the lib must read the background just to do transparency (type 1). It seems to me that if a pixel is transparent you should just not draw it. As it is now, every pixel is drawn. If it's transparent you must draw it with the same color it was before. Since most sprites use type 1 it would be a tremendous speed-up to remove the need to read the background.

I figured out my matrix problems. I just need to implement them.

I've been doing some optimizing with the purpose of reclaiming some code and data ram. I've had some success, so I may not need to cut any features. We'll see how it goes.

I'm still on vacation, but here's a couple photos you might find amusing. They are from a picnic we had at VM Labs in 1998.

1. Super Soaker wars - John, Teju, and Javier gearing up
2. Teju and Francois going at it
3. Various VML employees (spot the Yak?)
4. Yours truly and my wife, Gwen.

I survived my flight back with four strange high-school aged guys sitting in front of me. At first I thought they were pot heads, but I guess they were just odd. They were bouncing around, pushing each other in their seats and generally being annoying. Two of the guys would talk to each other with their faces just a few inches apart. I was waiting for them to kiss, but it never happened (hey this is near San Francisco). From their conversations I think they are in a band. Eventually one of their moms came and sat between them and that ended that.

I had my trusty GP32 with me while away and got in a few games of Jumpman and others. I'm still impressed by the Atari 800 emulator as it can run most games flawlessly. I also had a pair of noise-blocker headphones. Let me tell you it made a world of difference. The background hum on a plane is loud enough to drive you bonkers. The headphones cancel a lot of it out, making playing the aforementioned GP32 all the better.

I did diddly-squat on the game while away, despite having printed out the source code. It was nice to just unwind with the relatives for a few days. I played some golf with my Grandpa and uncles (not too badly I might add), and got about fifteen chapters into Order of the Phoenix.

I got back at 11pm Sunday so I haven't had a chance to do those menial post-vacation things like unpack. Give me a couple days to get back on track with programming.

It was July 18th of last year when I first started work on the NUON port of Decaying Orbit. How time flies. The original took me the better part of three years to complete. I'm determined that this port won't take as long. Of course I have far less free time than I did back then.

What's left?

• Finish the Yaroze-like sprite renderers
• Sound effects & (maybe) music
• Speed optimizations as necessary
• Changes to account for running at half speed compared to the 60fps original
• New graphics optimized for the lower resolution

My goal is to get it done by the end of the year. Let's see how it goes.

This was California Extreme weekend. A good time as always. Turns out xarph from the Llamasoft forum was the one that said hello on Saturday. Good to know other NUONites were in attendance.

Game Progress I did some code cleaning and ram reclamation. Now I'm working on the next pixel type. This is the one I mentioned on July 11. It will be used for sprites that need transparency and tinting, but not translucency. The main hurdle is getting the matrix code set up correctly. Once I have that the other pixel types should follow more quickly.

Game Progress You have no idea how happy it makes me to finally get tinting in. Here's the main menu screen with the title fading in As Was Intended.

Actually "brightness control" is a better term than tinting since you have separate scales that apply to the R, G, & B components of every sprite. I use this a lot by having gray-scale sprites and adjusting them to whatever color I like using the brightness control.

Now that I have it working I can get it optimized. Both the matrix computation and the inner loop itself can be made more efficient.

Here's the play field with brightness applied. Below that is a shot from before. See how the spinning arrows around the planets are colored - green for your starting planet and red for the target planet. Also, the borders around the five guages are color coded appropriately. It's difficult to see since they're so thin.

The top part of the screen seems to get chopped off when I take screenshots. Note the lack of the laser guage along the top. I'll look into that at some point.

With that done I might try to get translucency going just to have the game looking totally correct. I also have some more optimizations in mind to reclaim code space. I will restructure the part that clears the screen to be less complex. Then I can change how transparency is done so that the renderers don't have to read the background every time. That should give a big speed boost.

Game Progress I had an idea that might turn out to be very cool. Since I only need one inner loop renderer for any given sprite I was thinking to load them dynamically at runtime. When starting a new sprite the lib will look at the sprite type and transfer the appropriate renderer from main memory to MPE code ram.

This would eliminate my MPE ram limitations. I would allocate one section of code ram into which the renderer would be loaded. It would have to be big enough to accomodate the largest renderer, but that would be far less than having ALL the renderers in memory at the same time.

There will be some delay while the code is read from main memory, but I'm pretty sure that will be hidden. The lib knows the sprite type very early so it can start reading the renderer right away. Then it does a bunch of geometry calculations and other things to set up the sprite. That should provide enough time to finish the DMA before the renderer is needed.

Game Progress I simplified the code that clears the screen and immediately got rendering errors. I should have known it wasn't going to work. Each MPE can only clear the portion of the screen to which it will draw. Otherwise one MPE may be clearing part of the screen that another is drawing to. Bad news. So I'm back to the original.

This isn't too bad, though, since I started work on the dynamic loader. Once that bad boy is in I could have 100 different sprite types and it wouldn't matter (much). It will definitely allow me to combine my Yaroze renderers with the original libsprite renderers so I won't need to release two different libraries.

I just read about the XGameStation. It is a small hardware kit that acts as a game console. It has a 16-bit processor and comes pre-assembled, although it also comes with a document that tells you how to make one yourself should you wish. It includes an SDK that lets you start writing games for the thing, royalty free.

I think it's an absolutely amazing concept.

And long overdue. This offers a real, affordable opportunity to learn game programming. Sony's Net Yaroze was a step in the right direction, but its $700 price tag was a big deterrent for many.

The only negative I can see is the antiquated hardware. It only contains a 16-bit processor. While that's fine for old school 2D games, it won't cut it for even PSOne-level 3D graphics.

However, high-end 3D graphics is not the point. The point is to provide a vehicle to learn game programming. And the XGameStation will fill that niche quite well. (The low-end processor was also probably chosen to reduce cost.)

The thing that really got me jazzed about the thing is all the expansion modules they have planned. There's even one to let you make true vector games!

I may get one at some point, but I don't plan on switching from my NUON focus.

Speaking of which.

Game Progress The dynamic loader for pixel renderers is in! I have all six renderers included in the same lib (4 original sprite types and 2 Yaroze ones).

It works in Decaying Orbit, although it currently crashes in Chomp. Probably something to do with the blitter routine since Chomp uses it, but DO doesn't. I'll get it fixed soon enough.

Here's what's left for the sprite lib:

• Investigate and fix some minor graphical errors I'm seeing in Decaying Orbit.
• Change the inner loops to use the advanced DMA mode to further reduce how much the code must wait for DMAs to finish.
• Change the transparent-only sprite types so that they no longer must read the background.
• Add more sprite types to cover all the other Yaroze cases. With the dynamic loader I can have a dedicated renderer for every possible combination of sprite type. Yeeha!

Game Progress I changed some of the DMA code to use the advanced DMA mode, as mentioned yesterday. It gained a small, but not insignificant, improvement.

Now I'm ready to eliminate background reading from non-translucent sprites. This should have a tremendous impact for those often-used sprite types.

One thing I'm still worried about is the performance in some later Decaying Orbit levels. Some of them have many nebulas on the screen at once. These will use one of the slowest pixel renderers possible (which I have not yet written). If the game can maintain 30fps even in these I will be oh so happy.

Game Progress You can probably see what's coming. I'm going to tell you how I finished coding the new method for drawing transparent sprites. Then I'm going to tell you how it gave little to no improvement to performance. Sigh

Despite this I'm still happy I did it. Anything that removes the DMA from being the bottleneck is a good thing. As it turns out, the transparent pixels are primarily bound by the MPEs, not the DMA. Just for grins I turned on the 108MHz Aries 3 mode and it nearly doubled the number of sprites in my test program. That's a pretty clear indicator that it's the execution time that's holding things back.

And I'm happy about that.

At least now any code optimization I do will actually help. Maybe I can squeeze another cycle out of one of the renderers. If it were DMA-bound this would produce no improvement. Now maybe it will. (I'm not saying anything will definitely give improvement any more.)

That's the last major change to the sprite lib that I had planned. Now I will fix those weird rendering errors I'm seeing and get some more sprite types written. I'll also figure out why the game crashes at the end of the first level. Then I can release a new demo with all the improvements.

Game Progress I optimized pixel type 1 last night (transparent only). It used to be 4 cycles for a non-transparent pixel and 5 for a transparent pixel. I took advantage of the extra code space the dynamic loader gives me and expanded the loop. Now there are two loops in the renderer. One assumes the current pixel is transparent and the other assumes it isn't. If the assumption is correct then it takes 4 cycles, or 5 if it's incorrect. If it's wrong it jumps to the other loop.

Assume the pixel sequence is as follows (T=transparent, N=normal):

T T T N N N N N T T

Here's the cycle count using old method of 4 cycles for non-transparent and 5 cycles for transparent.

5 + 5 + 5 + 4 + 4 + 4 + 4 + 4 + 5 + 5 = 45 cycles

Here's how the new method works. To start I guess the first pixel is not transparent. Since I guessed wrong it takes 5 cycles. It jumps to the other loop - the one that assumes subsequent pixels are transparent. This is true for the next two so they take 4 cycles each. Then on the fourth pixel it's wrong again. So it takes 5 cycles and the code jumps back to the other loop again. It now assumes pixels are not transparent. This is true for the next four pixels so they take 4 cycles each. Then on pixel nine the assumption is wrong one more time. It jumps back so the last two transparent pixels take 5 and 4 cycles.

5 + 4 + 4 + 5 + 4 + 4 + 4 + 4 + 5 + 4 = 43 cycles

A slight improvement. Obviously this only helps if there are long batches of pixels of the same type. If there's a lot of swapping between transparent and non-transparent then the new method could take longer. Thankfully, that's rarely the case.

But wait there's more! I also unrolled each of the two loops by one iteration. For various reasons this allowed me to shave off another cycle, but only on the second iteration.

So now there's an advantage that the odd pixels take one less cycle than the even ones. BTW, the "odd" and "even" designation is done in backwards pixel order. This is due to a new restriction that it must always end on an odd pixel. That's no problem since it can start with whichever it needs.

That makes the new sequence as follows (affected pixels marked with *):

5 + 3* + 4 + 4* + 4 + 3* + 4 + 3* + 5 + 3* = 38 cycles

Even better! I wanted to unroll the loops even more, but ran out of code space.

Game Progress I fixed two bugs that were causing rendering errors. One of them actually fixed two errors so there's only one left to address. I'm rather pleased with how quickly these have been to track down. I hope this last one follows suit.

Game Progress I found and fixed the cause of the final rendering error. I was quite happy with myself until I tried it in Decaying Orbit. Most of the anomalies were gone, but there was still one annoying glitch. This one looks similar to the other so it's probably related. Either it was hiding behind the other bug, or I inserted this bug while fixing the other. I'm hot on the hunt and should have it cleaned up tonight.

Game Progress The final rendering error is fixed! Yay! It turned out to be easier than I presumed. I had thought of a potential problem while "offline" (that is doing other day-to-day non-programming activities). I didn't think this was the only solution required, but I tried it last night and turns out it was.

I also added one more minor optimization. Before, the code that reads the background for translucent sprites always read the worst case number of pixels (32). I made it only read as many as it actually needs.

I just need to update the last sprite type to use the new non-background-reading method. I tried this morning, but it's hanging for some reason. So I'll debug that tonight and then get started on the first translucent renderer.

I got my hands on a RipFlash Pro 2 MP3 player. It has 256MB of memory (non-expandable, but not a big deal), and it doubles as a voice/line-in recorder. I have several uses planned for this bad boy.

I'm going to record the road noise from my car so that when I start test driving for a new one (which will happen soon) I can quantify the audible difference. I already recorded the stretch of highway between work and home in my current Saturn SL1. Unfortunately the wave form maxes out so it's difficult to tell how loud it actually is. But as long as the new car doesn't max out I'll be happy.

The next use is to grab sound bites and songs from television programs. In the past I've hauled the VCR up to my computer so I could record things, but now I can use the line-in to record straight from the TV or VCR. I want to grab all the songs from the Simpsons, and while I have both Songs in the Key of Springfield and Go Simpsonic, those CDs don't include everything.

Finally, and more Game Progress related, I will use the voice recording to capture sound effects and voices for my game creations. Speaking of which.

So my wife visited here today and then mailed me to let me know what a nerd I am. I guess a game devlopment diary does swing the cool meter more towards "geek". Oh well, not much I can do about that :)

I haven't done anything recently - work has been busy. Hopefully the long weekend will allow me some time to get crackin'. While there's still lots of work to do, the game is close to being in a presentable state.

Be sure to check back during the long weekend. I will try my darndest to get lots of programming done. I would like to do another Programming Day like last time, but I don't think I can commit such a big block of time.

The theme for this weekend is "Get Kev something new to post on the Dome" :)

Game Progress We spent the day running errands and doing house-related things. As a result I'm just now sitting down for some programming. Good news is with all that out of the way the rest of the weekend should be better. Stay tuned.

Game Progress I'm getting some of the infrastructure in place to let me go wild writing sprite renderers (oooo, sounds fun don't it?). It's almost done. It allows me to do things exactly as the Yaroze does, but leaves the door open to more elaborate things.

For instance, there are only four different translucency modes in the Yaroze:

• 0.5*BG + 0.5*FG
• 1.0*BG + 1.0*FG
• 1.0*BG - 1.0*FG
• 1.0*BG + 0.25*FG

Why limit things, though? When I'm done the library will accept any value between 1 and -1 for both foreground and background scales. (The renderer will handle saturation should the resulting pixel overflow or underflow.)

Update 9:50pm I got the first translucent sprite to display! Now if I can just get more than one...

I wrote the One-With-Everything renderer. This thing is huge so I don't expect it to be really fast. It takes about fifty cycles per pixel! Once I get this bad boy running well I will pare it down into the more special-cased versions that are much quicker.

Game Progress Here's a shot from my sprite test program. Right now I have it configured to draw as many of these smilies as it can in 2 frames (30 fps). This amount is rather pathetic, but not as bad as I had feared.

Now to try it in Decaying Orbit...

Update 11:30am Voila!

With translucency in place not only do the nebulas now look correct, but I could finally put back the shadows on the planets. Things are really starting to shape up nicely.

There's a couple annoying crashing bugs in the game. I'm going to focus on getting those fixed next.

Update 10:10pm It ain't happening. That silly bug still eludes me. I'll keep focused on it this week to get it fixed.

Game Progress So the problem was with the pause menu causing the game to crash. This is weird since it was working before. I'm guessing it's because I reduced the resolution from 640x480 to 320x240. At the lower resolution the menu dimensions are small enough that it caused problems in the renderer. Anyway, it's fixed and working great now.

Next I'm going to look into the gravity calculations since they seem to be incorrect. Again, it's probably due to the resolution change. After that I'll throw together a more streamlined renderer to see if I can get the frame rate up. The first level is okay, but the second one is slow as heck due to the nebulas.

Is it just me or is this about the ugliest vehicle that's being made? It makes a Hummer look like freaking Porche by comparison. Every time I see one on the road I either make a face like I just swallowed cough syrup, or I just shake my head and wonder who buys these things. Ugh.

Game Progress The gravity computation problem arose from an endian-ness issue. The fix was so simple, and the new code so much cleaner, that I wonder why I didn't do it that way the first time. Part of the learning process I suppose.

Now that gravity is correct I want to find out why the frame rate in the first level went from 30 fps to 20. I tried turning off translucency, but that didn't help. It must be something I've done recently.

Game Progress I forgot I had disabled two of the rendering MPEs. That's why the performance took such a nose dive. I had done that while tracking down one of the latest bugs.

So now things chug at 30fps in the first level and around 20fps in the second and third. The game crashes after the third level now. That's when you hit the first shop where you buy stuff to upgrade your craft. The game has never worked that far before so it's not unsurprising it crashes.

Game Progress Well of course the game will crash if you try to dereference a NULL pointer. How did this game work on the Yaroze?

So the shop is now functional even if it still lacking in the aesthetic department. Now to make it look correct.

Game Progress Check out NUON-Dome

/.

Nothing like doubling the number of visitors within a day. Guess now I have to follow through with all this huh?

Game Progress

So this is what the shop currently looks like.

And this is what it's supposed to look like. Granted even the correct version is not pretty, but you can see where I have some work to do.

The background is colored all weird, the sprites are over-saturated, and the mini-map is wrong.

I'll get to that later. I've taken a slight detour and done some optimizing to the translucent renderers. I halved the number of cycles for most of them. Using my previous smiley test as a reference, I increased the number of sprites displayed from about 61 to about 85. Not bad, 40% improvement.

However, these optimizations have lead to more code space problems. There's often a trade off between code size and code speed. Now the size of some of the renderers are bigger than the maximum I have set. I really don't want to increase the max since I'm already violating the "only read 64 scalars at a time" rule for DMAs. I think I'll move some of the code that's common to all renderers out into the main routines.

Game Progress I've taken it upon myself to get all the sprite renderers to be their leanest. Even the four that are included with the original libsprite. I've gotten the largest one - the one that does bilinear interpolation and translucency - down to under 256 bytes. That's good since that's below 64 scalars, which as I mentioned before is the supposed limit to how large DMAs should be. Unfortunately my own custom Yaroze renderers are still code-hogs and take upwards of 300 bytes. So there's still work to be done.

Speaking of the built-in renderers. The sprite lib actually has several other sprite types that aren't exposed in the original lib - probably due to code space issues. Now that that's not a problem anymore I will endeavor to put them back in. I don't even know what they do, but I imagine they're some combination of features from the existing types.

Game Progress I managed to get all the renderers under 256 bytes. This makes me feel better since I no longer violate the rule for DMA transfer size.

So now I'm back to working on the shop. I'm trying to figure out why one particular sprite is tinted red. I was making good progress debugging, but had to leave for work. Gotta make money so I can continue to do this geeky stuff in my spare time :)

With all the changes I've made to the sprite lib recently I wanted to verify I didn't break anything. So I tried the new lib with Chomp. Everything seemed fine until the ghost sprites went all wonky. Pisses me off since I know I'll end up wasting a lot of time tracking that one down.

Game Progress This mysterious red tinting is another of those goes-away-when-you-try-to-debug-it bugs. Damn it!!!

Game Progress Bugs of this nature are usually due to a cache coherency problem. My typical solution for this is to flush the data cache. I tried doing this in several places, but that didn't work.

Finally this morning I stumbled on the answer. I needed to declare a variable as "volatile". I'm still trying to figure out why that works where flushing the cache does not. I think it depends on how the compiler treats uninitialized local variables.

The full description of the bug is rather long-winded so I won't repeat it here. I started a thread in the N-D forums about it if you're curious.

I finally sunk my teeth into Metroid Prime recently. What a spectacular game. So graphically rich and lots of interesting things to do. I forsee a lot of backtracking once I acquire new powerups. That's the nature of Metroid games, though.

Game Progress Another one of those bugs has popped up that fixes itself when you try to debug it. That's causing the background in the shop to be the wrong color. After that there's a crashing bug when you try to exit the shop to start the next level.

This is the best I could do with the tools provided to recreate me South Park style. The lads at Yak's forums found it and have been having fun making avatars. I cheated by inserting the logo in there, but really how could I not.

And here's Dave. Heh, he's gonna kill me.

Game Progress The shop is looking a lot better now. I still don't understand the last bug I fixed, but as long as it works...

Next I'll work on the transition from the shop to the next level. It has a neat zooming effect that crashes the game at the moment.

I also need to add support for lines and boxes to the sprite engine. You can see how lines are missing on the sides of the "For Sale" border. Boxes are also used a few places to draw regions of constant color. Thankfully both lines and boxes can be implemented as specialized sprites.

No game progress to report. I've been spending lots of time in Metroid Prime - it's truly a masterpiece. There isn't much of a story, but thankfully the gameplay itself is reason to keep playing. Oh I guess I could read all those boring pirate logs, but who wants to do that? Typical Nintendo to not include voice actors.

We've also been busy at home getting the big house stuff done in preparation for the new arrival. We've redone all the closets and boy did they need it. We're also replacing the windows to try to cut our energy costs. Our current windows are crap.

Look for some Decaying Orbit goodness later this week.