(opens in same window)
(opens in new window)
(likely 404 error)
April-June 2004 (oldest-to-newest)
I got the gui portion of the boot loader working with the
new data file. It bombs out when actually trying to load
a coff, but I just haven't debugged that part yet. I have
a checksum for each coff file to ensure it gets loaded
properly. Probably something wrong with the generation of
Whew! Who would have thought having a kid would take so
much work :) He's great though - a very easy baby compared
to some of the horror stories we hear from others. He even
gave us eight consecutive hours of sleep last night!
I want to say a quick "Hi!" to the Trimble folks reading
this. My wife mentioned that you stumbled on this space.
Guess I *really* need to watch my tongue now. Heh.
I did manage to squeeze in a couple hours on the boot
loader. It's shaping up to be quite awesome if I say so.
The data file works like a charm, both reducing disc
access time and increasing stability.
The gui is also a lot faster now. I made it so that it
only paints the parts of the screen that have changed.
It's sooo much more responsive.
I was hoping to get a beta version in your hands today.
However despite working just peachy on my dev system,
running on my 501 causes a crash. Give me a day or two to
work out the kinks.
Gotta like finding bugs by inspection. Especially when the
alternative is the vicious compile-burn-try cycle. Since I
found that bug so quickly I went ahead and added support
for the remote so people without joysticks can use it.
version of the new boot loader. Please put it through
the wringer as only my legion of faithful readers can. Oh
heck, who am I kidding. Kev, could you try this?
Here's how it works. Burn the nuon.cd and
bootload.dat files to a disc to try it out. It
contains my usual assortment of three apps and lousy
If you feel really inspired you can create your own
bootload.dat. Simply set up a directory similar
to how the boot loader used to work. Basically put an
applist.txt and optional bg.jpg in a
directory along with a subdirectory for each app. Each one
must have a cd_app.cof and can optionally have a
img1.tga, img2.tga, app.txt, and
intro.jpg. Then run the enclosed bootpack
executable. If it completes successfully you will have a
new bootload.dat file to use.
Let me know if you find problems with either the packer
or the boot loader. I've only done rudimentary testing so
Once I feel comfortable with it I'll release a final
version including the source code for the packer and
loader - this time fully commented so it's actually
I'm excited about next week. My wife is going back to
work for the first time after having the baby. I'm taking
her place and will be Mr. Mom for four weeks. It'll be
weird to be away from work for that long.
Naturally it won't be a true vacation because I will be
caring for Gavin (now three months old). I expect the
first few days to be pretty rough as he gets used to taking
a bottle regularly.
I want to have the boot loader polished off this week so
I can focus on Decaying Orbit during my leave. After my
long winded post about the game I figure I better deliver.
So much for being done by the end of 2003 :)
I've been periodically updating the beta version of the
boot loader and posting new revs on the
ND forums. I am assuming that everyone that downloads it
from here also goes there. In fact I've just been updating
the same zip file as I go so those of you that downloaded
recently probably got a later rev. Anyway, it's probably
worthwhile to give the link again.
I'll remove the beta status by the end of the week and
have a full package with updated README and everything.
I'll also get the
Boot Loader page fleshed out with
screenshots as was intended.
And go Phil! I was riveted to the television Saturday and Sunday
watching the Masters. Exciting doesn't even touch the
emotions that were felt. I cannot imagine the nerves he
must have had on that last putt. Good for you, Phil. You
truly deserved it.
I tried to get it done by today, but I just can't quite
make it. Look for the full 2.0 release on Sunday.
The latest version can be obtained from the links to the
The source link includes the source for the boot
loader, the boot packer, and all the app files needed to
recreate the data file that comes with the binary.
The included data file has several demos from the NUON
SDK and also Chomp v1.4. A couple of the demos I intended
to included don't work on the 501 for some reason, although
they work on the 504.
This isn't the last release as you can tell by the
"to do" list at the bottom of the README. However, unless
there are major problems I will be putting this one on the
shelf for a while in favor of Decaying Orbit. It's about
time I got back to that one.
Please post comments and bug reports in this forum topic.
This has been a busy week to say the least. I have new
respect for single parents. Taking care of a child is more
work than my normal job! It's physically and mentally
taxing what with the picking up, putting down, crying,
eeding, changing, etc. It's one thing when your partner is
there with you to share the work, but another entirely when
it's just yourself.
I dove straight into Decaying Orbit for the first time in over six months. The image to the right is the last one that I posted back in September. Notice that there are no lines connecting the border around the sets of pictures "For Sale", "Extras", and "Ship Systems". When last I left the code I had started implementing lines as specialized one pixel wide sprites.
By Tuesday I had them working. Here's the latest image.
They still look kind of strange because all the sprites
are scaled down by a factor of two, while the lines are
not. This puts their coordinates off by a pixel or so.
Also, you can't draw half-pixels so the lines look thicker
than the corners.
You'll also notice that the colors are not as vibrant.
This is a result of another bug that I fixed. It's
actually more correct this way, but I'll try to find a
better solution since the sprites look washed out now.
The last two days I've been fighting a heck of a bug.
One of my _DMABilinear() calls was dying for no reason.
Turns out that it wasn't the fault of that function. Rather
it was an earlier _DMABilinear() that had been passed bad
parameters. It worked just enough to run for a while, only
to die later. I hate those kinds of bugs.
Next up I plan to implement auto down-scaling for the
images. The sprites are being scaled down 50% horizontally
and vertically due to the resolution reduction. At the
moment the sprite library is doing this in real-time as the
sprite is drawn. This means the it must traverse four times
the number of pixels than it actually draws. I will move it
so the scaling is done when the sprite is first loaded. Not
only will this save pixels, but I can do a much nicer job
filtering so the resulting sprites don't look so
D'oh! I overwrote the previous update. If anyone
has it in their cache could you send it my way? I don't
think I have a backup anywhere. Update: Nevermind,
Google had it in its cache. I find that kind of unnerving
Gavin seems to have discovered the full potential of
his lungs. Whereas before he would cry when he was
hungry or tired, now he'll just screech for (what seems
like) no reason. Let me tell you, it's great on the ears
when you're holding him over your shoulder.
Lots of progress this week. I implemented the image
pre-scaling as described last time. Guess what? It
didn't solve the slowdown problems. Story of my life.
I eventually tracked the slowdown to an inefficiency
with the original Decaying Orbit code. I was reloading
some sprite images every frame. This is fine on the
Yaroze since it just pulls the sprite data straight from
VRAM. On NUON, however, whenever VRAM is overwritten,
even by the same data, all the relevant sprite images get
flagged as dirty and are regenerated. Not the speediest
of algorithms. I fixed that and the shop seems much
happier for it.
Overall I haven't noticed a significant speed-up due to
the image pre-scaling. I have it disabled for now since
it degrades the image quality quite a bit. I can add it
back later if necessary. I also added the ability to
apply the scaling selectively on a sprite-by-sprite basis.
That will let me keep certain images at higher quality
I have started changing the Decaying Orbit code to match
the NUON target of 30fps. First, I locked the frame rate
so that it won't go above 30fps. It's very jarring
watching something swap between 30fps and 60fps. I'd love
to get 60fps throughout, but it just ain't happening.
Uh, the boy's squawking. Be back in a bit.
4 Hours Later My goodness that boy can put out
some noise. We went out to dinner and had to cut it short
because he woke up and started crying. He was so good at
restaurants before this. We just put him down for the
night. No more screaming until 5am tomorrow :)
Continuing from where I left off. So in addition to
forcing the max frame rate at 30fps I also started making
changes to speed up the game by 2X so that it moves at the
intended speed. I've only begun with this. It must be
coded explicitly everywhere it's necessary so it may take
me a while to get working everywhere. Still, for what
I've done the game plays much better.
Next week I will be continuing the speed up changes.
I will also look into finally getting the sound effects
implemented. I have the file format for the Yaroze sound
files and I'm hoping it's easy to convert them to
As it turns out I do not have the file format for
the PS sound files. Rather I have the format, but within
the file there's a block labeled "data" and the format of
that data is not given. It's proprietary to Sony.
So I'm stuck doing sound the hard way - with the original
WAV files. Well, this is actually pretty easy to get going,
but I had hoped to make it more generic since other Yaroze
games for which I have the source code do not include the
original WAVs. This means sound for Decaying Orbit, but not
for any other Yaroze games I get ported.
The game is just so much better with the sound effects.
I got them implemented in the most generic way I could
think of. It requires an extra table that maps the PSX
sound effects to their corresponding WAV files. When the
game calls the Yaroze library to play a sound it uses the
Next I'm going to address the slowdown that happens on
the more complicated levels. It dips down to 20fps during
play. It goes even lower after finishing a level while
displaying the bonus summary. It may be time to start
hacking the original source. I mean even more than I
We discovered the wonders of the pacifier to quiet down
Gavin's screeches. We never had a need for one before and
have heard mixed things about whether to use one or not.
Screw it, he'll wake up the neighbors if we don't stop him
from screaming at 6:30am.
As I mentioned earlier this week I got sound implemented.
It's a bit of a hack as it doesn't use the original
Playstation sound data files. Rather, every time a sound
is played it uses a table to look up the appropriate WAV
sample and play that instead. This isn't perfect since it
cannot do pitch bending yet, but hopefully it's possible
to get that in eventually.
As the game gets closer to completion these kinds of
hacks will become more common. I just want to get the
game done at this point.
The rest of the week I have been focusing on how to
get the framerate at a solid 30fps throughout. I'm using
level 2 as my test bench since it has lots of translucent
objects that stress the sprite library. It's currently at
20fps. Here are some of the things I have tried or will
- Sprite image prescaling. As described many times
before, I enabled a way to automatically scale sprite
images down by a factor of 2 in each dimension. To keep
them the same size in the game I then scale them up 2x.
By using a smaller source image the sprite library reads
fewer pixels, speeding up rendering. Contrary to what I
said before, this does work. The speed up is not
insignificant. However, the visual fidelity loss is too
great to be worth it.
- Speeding up the background. Drawing the stars in
the background is very time consuming since they cover the
entire screen. To alieviate this I split the rendering
into two layers. The background is now drawn in the main
channel while the planets, player, and other objects are
in the overlay channel. Thus I only need to draw the
background once at the beginning. It can be many times
larger than the visible screen and with the built-in
capabilities of the video routines I can make it scroll
around. This saves a lot of rendering time. I'm about
80% done with this.
- The second big time sink while rendering is with the
nebula sprites. They are translucent, meaning they use a
longer renderer. Plus, there can be quite a lot of them
visible at once. I'm still experimenting with how to fix
this. I'm optimizing the renderer as much as I can. I
am also thinking about keeping the nebula sprite images in
RGB color space rather than YCrCb. That would save the
renderer from having to do the YCrCb-to-RGB conversion.
- I want to try adding triple buffering. With double
buffering you must wait until rendering completes before
continuing. You're potentially wasting a lot of time
waiting for the video sync event. This is especially bad
if you happen to just miss the previous sync. It can make
the difference between taking 2 fields to render (30fps)
versus 3 fields (20fps). Using triple buffering will let
the game continue rendering to the third buffer. When the
video sync happens it will trigger an interrupt and execute
a callback routine that swaps the buffer.
- I'm also open to modifying the level contents, but
that's a last resort. Eliminating a few nebula sprites
won't have that dramatic an impact on the final game, but
I'd still like to keep the game intact if possible.
Next week will be lots of polishing. Hopefully I can
tame the frame rate problems to some degree. After that
I will start fixing any remaining bugs. I'm sure there
are plenty, especially related to the shop or transitioning
to and from the shop and the level.
After fighting a silly stupid bug (calling a non-re-entrant
bios function from within an interrupt service routine) I
got triple buffering working. It did everything I was
hoping. The frame rate on level 2 is now a relatively
Next I will finish implementing the stary background.
At the moment it does not scroll, but that should be easy
enough to add.
Guess I need to find a new level to use to stress
No kid update today. I suspect I'm the only one that
enjoys them anyway :)
My latest crisis has been the background. I'm using the
main video channel for that and rendering everything else
on the overlay channel. The hope was that I could scroll
the background without having to redraw it. Alas that was
not to be as the scroll offsets only work in 8-pixel
increments in the X direction.
So I changed it to a static background. Not as exciting
I know. I have ideas for getting it to scroll again, but
those will wait until later.
So how am I doing on the various fronts I mentioned
- Sprite image prescaling. I am using this
selectively on sprites that do not get magnified since
there's no visual quality loss in that case. On the
contrary, due to the filtering I just added the scaled
images look better than when the sprite lib does the
scaling. I do this for the HUD sprites, enemy turrets,
and anything else that is always drawn at 1x scale (or
smaller). I gained a couple milliseconds doing that.
- Speeding up the background. This is partly
described above. It's still not final because none of the
sprites on the overlay channel are translucent where
appropriate. This will likely require modifying the sprite
- Speeding up the nebula sprites. I made great
strides in this, shaving off about 10ms of rendering time
on the second level. Since achieving 30fps requires
drawing to be done in 33ms you can see how this is a great
improvement. I optimized the sprite lib renderer that
handles the nebulas. It used to take 21 cycles per pixel
and now takes 13. I never thought I'd get it down that
far. This VLIW thing is pretty nifty.
- Triple buffering. Done and works like a charm.
This was the best thing I could have done. The frame rate
is much smoother now. I will be implementing this on all
my future games.
- Modifying the level contents. Not yet
I also changed some of the HUD sprites to remove their
translucency. It's a nice perk to have, but not really
necessary and just slows down rendering.
There are still a few places where the frame rate takes
a dive - the end-of-level bonus tally being the obvious
one. I haven't tried the upper levels yet. They are more
complex, but I think it really depends on the number of
nebulas. I also need to revisit the shop. I may need to
move the shop background to the other video channel like
I did with the stars.
Sorry for the lack of screenshots. Splitting the
rendering into separate channels made my current screen
grabber next to useless. I plan to write a new and
improved one, but obviously that has been lower
latest demo. Please note that I've had it crash on my
N501 (but oddly not my dev system nor N504). This has
only occurred when colliding with a planet. So drive
safely out there. Update: I think
I know what causes the crash. I updated the zip with
the latest. Let me know if it still happens.
The controls are still the same. Basically all you
need is the stick to rotate, A thrusts and B fires. The
demo is currently limited to the first three levels.
After that it will repeat the third level. I will be
unlocking more in future releases. (It also keeps you
from seeing the shop until I've had a chance to clean it
There are lots of little things that need fixing. For
instance, the messages that appear in the lower left can
be a bit messed up, the beacon pulses aren't quite right,
and more I'm sure. At some point I will ask people for
bug reports, but let's wait until things are more
Thus ends my four weeks at home. I will be returning
to work next week and so updates will be less dramatic and
more sporadic. However, with the great strides I made
during this past month I feel more energized than ever to
get the game finished.
I'd like to thank my son, Gavin, for giving me the
opportunity to take the time off and for taking the
occasional nap to allow me to work. How could you
not like that guy. Mmmmm hand...
Sorry for the lack of updates (two weeks?!) - my mom's
been staying with us helping with the baby. Not a lot of
time for coding now that I'm back at work. Has anyone
tried the demo? Haven't heard a peep about it.
I finally started Beyond Good
& Evil. I must have played that initial battle
five times - every time something would come up and prevent
me from playing to a save point (baby crying, etc). Now
that I've finished the first "dungeon" I can truly
appreciate how much I will love the game.
After a long break I did a bit of programming last night.
Just cleaning up some of the code to do frame-rate
management. I'll start playing through the game from the
beginning and fix whatever issues I see. Getting the
level-to-shop and shop-to-level transitions clean will be
the next big goal.
I finished Beyond Good & Evil
last weekend. I can't say enough good things about it.
Truly a spectacular game if you're into that adventure game
genre thingy. It's a bit on the short side, but I'd rather
have that than have the quality suffer.
I fixed a bug with the player messages that appear in the
lower left corner. There's still another lurking, but I
haven't had a good string of time to sit down and nail
I fixed that annoying corruption bug with the player
messages. Turns out that calling _MemAlloc() with a size
of zero will happily return an address, even though it
didn't allocate any memory. One could argue that I
shouldn't be trying to allocate zero bytes in the first
place, but...er...bite me.
One more small thing to fix and the player messages
will be perfect. Then it's off to find the next
I fixed that little problem - the player messages are
peachy keen. Interestingly I think the bug was there
in the original Yaroze version too.
A quick play through the first few levels
showed me the next couple problems to address. First,
when transitioning between levels there's a frame when
the level does not get drawn. It's kind of annoying -
hopefully it's a quick fix. Another problem deals with
how some of the sprites in the shop are not being drawn
when they're supposed to, leading to some flicker.
Finally, when exiting the shop to start the next level
I get memory allocation errors. I don't remember if I
ever implemented memory reclamation for unused sprites.
If not then it's likely just running out of image
I fixed the various transitions between game states so
they are very smooth now. Also, the flickering in the
shop is gone too. That last one started happening when
I added triple buffering. In the shop I only draw things
that have changed frame-to-frame - kind of like the boot
loader. The old code assumed double buffering so it was
only drawing things in two successive frames. Changing
it to three fixed it.
I'm currently working on the memory allocation problem
in the shop-to-level transition. I think I know what the
problem is. The fix is a bit involved so I need to think
The game now manages image memory pretty well. The old
method was rather limited. Basically if the amount of
used memory went above a threshold then it did some house
cleaning to deallocate the images that haven't been used
recently. This was a bit too restrictive and didn't help
in case I was seeing.
The problem was with the transition from shop to game.
You can see the minimap in the bottom right of the shop
image here. It's the big black box with the small gray
rectangle. When you exit the shop the minimap zooms up
and fills the screen. It keeps zooming until the objects
in the minimap are replaced by their actual in-game
objects. This continues zooming until it settles down
into the starting position for the level.
Due to the way this is handled the minimap image gets
regenerated many times during the zooming process. It'd
be complicated to explain why, but was done to keep
the speed up on the Yaroze. Every time the image is
regenerated new memory gets allocated. Since it's a big
image the system eventually runs out of memory.
Before, the game would just complain about not having
enough memory, which would crash on a real system since
printf's don't work there. Not very elegant. I made it
so that if the allocation fails it will deallocate other
unused images and try again.
With that in place the transition works. A new issue
is that the minimap is butt ugly when zoomed in so far.
This wasn't as big a problem when everything was 640x480,
but at 320x240 it is very chunky. I tried enabling my
whiz-bang filtering, but that slowed things down to a
crawl. Regenerating that large an image with
filtering takes too long.
Two more bugs reared their heads. First, the minimap
contents are garbled. I traced that down to an
endian-ness issue, but haven't fixed it yet. The second
involves incorrect colors on some sprites that get used
during the transition.
Fixed the endian-ness problem. The mini map is generated
correctly now, but it still suffers due to the image
scaling that's done. One more for the todo list. Also,
the elements on the minimap do not line up exactly right
when the new level's planets appear. This is likely due to
the scaling too.
This web page and all other pages on this site are
© 1999-2007 Scott Cartier