(opens in same window)
(opens in new window)
(likely 404 error)
July-September 2003 (oldest-to-newest)
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
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
linked anywhere. I added it to the main
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
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...
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
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
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
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
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.
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
- No transparency, no translucency, no tinting (this is
the existing type #0)
- No transparency, no translucency, with tinting (hardly used)
- Transparency, no translucency, no tinting (most sprites use this)
- Transparency, no translucency, with tinting (fonts & other gray-scale sprites)
- Transparency, translucency, no tinting (explosions)
- Transparency, translucency, with tinting (nebulas)
If I run out of code ram I'll have to cut one or more
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
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
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
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
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!
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
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
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.
- Super Soaker wars - John, Teju, and Javier gearing up
- Teju and Francois going at it
- Various VML employees
(spot the Yak?)
- 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.
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.
- 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.
California Extreme weekend. A good time as always. Turns out xarph from
Llamasoft forum was the one that said hello on Saturday. Good
to know other NUONites were in attendance.
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.
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
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.
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
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.
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
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
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
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.
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
- 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.
I changed some of the DMA code to use the advanced DMA
mode, as mentioned yesterday. It gained a small, but not
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.
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
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
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
Here's the cycle count using old method of 4 cycles
for non-transparent and 5 cycles for transparent.
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.
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
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 *):
Even better! I wanted to unroll the loops even more,
but ran out of code space.
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.
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
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
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
related, I will use the voice recording to capture sound
effects and voices for my game creations. Speaking of
Got that last bug squashed. Now that all the rendering
problems are no more I can focus on adding renderers.
This is the fun part :)
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" :)
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.
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
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.
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
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.
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
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
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.
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
Well of course the game will crash if you try to
dereference a NULL pointer. How did this game work on the
So the shop is now functional even if it still lacking
in the aesthetic department. Now to make it look
Nothing like doubling the number of visitors within a
day. Guess now I have to follow through with all this
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
smiley test as a reference, I increased the number of
sprites displayed from about 61 to about 85. Not bad, 40%
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.
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
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.
This mysterious red tinting is another of those
goes-away-when-you-try-to-debug-it bugs. Damn it!!!
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
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
The full description of the bug is rather long-winded so
I won't repeat it here. I started a
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.
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
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.
The shop is looking a lot better now. I still don't
understand the last bug I fixed, but as long as it
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
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.
This web page and all other pages on this site are
© 1999-2007 Scott Cartier