Game Progress 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 that checksum.

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.

Game Progress 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.

Game Progress 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.

Here's a beta 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 graphics.

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 far.

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 decipherable.

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 :)

Game Progress 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. Here's the latest.

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.

Game Progress 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.

Game Progress

• Binary (including sample data file)
• Source

UPDATE (2006-02-08): The latest version can be obtained from the links to the left.

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.

Game Progress 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 aliased.

Stay tuned.

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 actually.

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.

Game Progress 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 when necessary.

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 NUON-speak.

Game Progress 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.

Game Progress 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 WAV instead.

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 already have...

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.

Game Progress 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 try:

• 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.

Game Progress 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 constant 30fps.

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 things :)

No kid update today. I suspect I'm the only one that enjoys them anyway :)

Game Progress 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 last time?

• 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 library.
• 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 necessary.

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 priority.

So anyway, here's the 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 up.)

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 stable.

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.

Game Progress 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.

Game Progress 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 it.

Game Progress 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 problem.

Game Progress 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 space.

Game Progress 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 it over.

Game Progress 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.

Game Progress 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.