September 2003

N-D heads to PhillyClassic
9/19/2003 by K3V

Good news for NUON fans who plan on attending next year's PhillyClassic, (March 20 & 21, 2004). I've just purchased a table and have begun kicking around some ideas of what to do/display at the show. Here's what I've got so far:

- Bring along some of my spare copies of NUON games to sell (will help recoup cost of the table). I should have copies of Tempest 3000, Merlin Racing, FreeFall and Space Invaders XL available. Might have a bare IS3 or 2 for trade-bait :)

- Burn a bunch of copies of the freeware NUON games to hand out as freebies. Stuff like Doom, PacMan, Bomb (a Bombuzal clone), Snake and more...

- Set up one TV with a N501 NUON machine, and two controllers to play any of the NUON games I bring (which is all of them)

- Display rarities like the unreleased Bust-A-Move 4, a prototype controller, early prototype game boxes, various NUON/VM Labs promotional materials, Motorola Streamaster with keyboard and remote.

- Display and make available to play the entire NUON library, including homebrew releases which I've got most in DVD cases with artwork that closely mimics the commercially released games.

- Bring all 4 NUON-enhanced DVD movies for display/viewing (Bedazzled, Dr. Dolittle 2, Buckaroo Banzai and Planet of the Apes).

If you've got any other suggestions, I'd love to hear them. Email me if you have any ideas or if you plan on attending the show. Hopefully I'll see you in Philly in March!

More Info on NUON Rotary Controllers
9/16/2003 by K3V

I was just passed along some information from former VM Labs employee Andreas Binner in regards to getting rotary control functioning on NUON for use in Tempest 3000. Here's what he had to say:

All controllers have to have the so-call "Polyface" chip in it. You will find it in any NUON controller. This chip is somehow coded to identify itself to the NUON BIOS as certain type of controller. I believe this is simply done by setting some of the Polyface pins to high or low voltage. In addition the Polyface chip has various input and output pins for different controller parts buttons, pots, rumble pack, spinner etc.).

I believe that every available NUON controller can be turned into a rotary controller with some small HW modifications plus a rotary controller hardware. The NUON BIOS will automatically load the right driver and make it available to T3K.

What's really missing is a documentation of the Polyface chip.
Interesting information. Maybe some other former VML employee is reading that has more insight into this issue? If so, feel free to drop me a line.

T3K with a real Tempest rotary?
9/15/2003 by K3V

According to Jeff "Yak" Minter, it was accomplished at some point, along with a hacked PC Wingman Warrior controller with a rotary spinner, according to this thread on the YakYak forums. This means, of course, that there is already Rotary Control support in T3K and in the NUON BIOS. Here are the more interesting tidbits:

From a chat transcript:

[15:02] [}Yak{] Well, the code to read a rotary controller is right inside Nuon anyway, all you need to do is make the right cable.
[15:02] [z|bandito] reaaaallyy
[15:03] [z|bandito] in the nuon itself or you mean already in t3k?
[15:03] [}Yak{] already in T3K and the nuon BIOS.
[15:04] * }Yak{ has a PC Wingman Warrior with a spinner and a hacked cable that plays T3K.
[15:04] [z|bandito] cool.. so make the right cable to go to what, a jag rotary?
[15:04] [z|bandito] sweeet
[15:04] [}Yak{] I used the aforementioned hacked WW for development. One of the VMLers actually hooked up a real Tempest spinny controller to his Nuon.
[15:05] [z|bandito] =]
[15:06] [z|bandito] }Yak{ you happen to know if the pinout information is on the web somewhere or ??
[15:07] [}Yak{] IDK - I am unaware if anyone in the Nuon community has it; I never had it, they justbuilt me the interface and said "there ya go", and I coded for it.
[15:07] [z|bandito] hmm interesting
[15:08] * }Yak{ twiddles the right analog stick some

And from later in the thread:

Unfortunately it wasn't just an adapter cable; they Did Something inside the beast and the cable isn't detachable. they just told me "here, use this and the OS will recognise it as a quadrature spinner" and lo, it did.

Oh, and I believe Bill Rehbock actually got a *real* Tempest spinner hooked up to T3K at some point!

Decaying Orbit - The Latest
9/7/2003 by K3V

A huge thanks to Scott at DragonShadow Industries for providing NUON-Dome with this exclusive look at the current state of Decaying Orbit, along with where the Yaroze port has been up to this point and where it's headed. Some very exciting news within, along with a new three-level demo, and a load of new screenshots (click to enlarge), so without further adieu...

Grab the latest Decaying Orbit demo here. Or from the new Decaying Orbit page. Some notes about this release:

  • The game has a lot of optimization forthcoming. The final game will be much faster.
  • This demo only has the first three levels. After that the game will play level 3 over and over. Once I get the shops working I will release a new demo that lets you go further (level 4 is a shop).
  • Controls are the same as given in my December 21st update. A quick summary:
    • A - menu select
    • C-left - menu exit
    • A - thrust
    • B - fire
    • R+A - change engine system priority level
    • R+C-down - change shield system priority level
    • R+B - change laser system priority level
    • R+C-left - change cooling system priority level
  • After playing around with it for a while I've noticed quite a few things that need fixing. Don't bother sending bug reports yet. Let's wait until the game is more complete.

Decaying Orbit, a year later
-- by Skah T

The NUON port of Decaying Orbit began on July 18, 2002 [link]. I felt it wouldn't be too difficult a job. At the time, the NUON sprite library already had most of the necessary pieces to accomplish the port. The idea was to create an API that would accept the standard Yaroze graphics calls from the game and translate them into NUON-speak. Not only would this allow Decaying Orbit to run largely unmodified, but any other sprite-based Yaroze games would be relatively easy to port as well.

That was a year ago. What's happened in the intervening months? There are many reasons, but the bottom line is I'm a perfectionist.

The Initial Port

The first task was to create the Yaroze-to-NUON API. I started with the function calls necessary to get the initial Decaying Orbit splash screen. That happened pretty quickly [link]. Then I started writing code to handle the sprites. This was more involved since the sprites in Decaying Orbit are mostly 4-bit CLUT-based. Each one uses up to 16 colors which reference into a color lookup table (CLUT). There's a lot of other setup that is done before a sprite can be displayed. In October I had success [link].

Over the following months I fixed bugs in, and added features to, the Yaroze-to-NUON API. Eventually it did most everything I needed to run the game. Unfortunately the game was dog slow. Resolute to create a perfect port I dove into the source code for the sprite library and started tweaking. Improvements to remove bottlenecks, optimizations to inner loops, and acceleration to often-called API functions. It still wasn't enough. I was only getting 12-15 fps on the first (and least complicated) level [link].
Who knows how slow it would run on the later levels?

With some reluctance I lowered my goals and dropped the resolution from 640x480 to its current 320x240 [link]. The good news is that the game achieves a pretty solid 30 fps on the first level. We'll see how it holds up in the later levels. The bad news is all the sprites must be scaled down. Text in particular suffers from this down-sampling. Additional bad news is that the game is still not as fast as the Yaroze's 60 fps original. Thankfully, both of these problems can be addressed.

Adding Features

Remember how I said that the NUON sprite library had most of the necessary pieces to accomplish the port? It was time to change that "most" into "all".

The biggest pain is the fact that NUON deals with pixels in a different color space than the Yaroze (YCrCb vs. RGB). Conversion between the two color spaces must be done per-pixel and takes a non-trivial number of CPU cycles. There's just no way around it.

More recently I've been tweaking pixel renderers. The sprite library does a ton of stuff to set up each sprite before blasting the pixels out to the frame buffer. While the set up is done once per sprite, the drawing routines are run once per pixel. These are the so-called inner loops of the sprite library. Each one can be tailored for the specific capabilities needed for the sprite in question. That way you only do exactly as much work as necessary for that sprite. Saving a cycle or two in the inner loop has a tremendous impact since it is called for thousands of pixels.

In addition to optimizing the existing renderers, I have also written my own. These custom renderers are designed to make the final pixel look just like the Yaroze. They check for transparency, apply translucency, and scale the RGB values of the pixel by given amounts [link].

With all these additions to the sprite library I started running out of RAM. Each processor (MPE) in the NUON chip has 4kB of memory for code and 4kB for data. With the existing renderers written and many more to come, there just wasn't room to fit them all. One of the last major improvements to the sprite library was to add a dynamic loader for the renderers. Basically each inner-loop is stored in main system memory, of which there is plenty. Then each sprite transfers the inner-loop that it needs from system memory to local memory at runtime. Now I can essentially have an unlimited number of renderers!

Present and Future

That brings the story to the present. The Yaroze-to-NUON library has been stable for some time. The sprite library was enhanced to improve performance and is very solid. All of the features necessary for the game have been added, if a bit buggy.

So what's next? The main thing is lots of optimizations. I will try my best to have the game run at a stable 30 fps throughout. This may be impossible, but I am a perfectionist after all. I will also need to enhance the original Decaying Orbit code to handle this reduced frame rate. Things will need to move & animate twice as fast to compensate.

Then there's sound. That's a whole ball of wax I have yet to consider. It may be drop-dead easy if I can somehow find the file format for the Yaroze sound files. Failing that I will have to replace all the Yaroze API calls with NUON functions. I just don't know.

I'll also try to get streaming background music working. Again, this could be easy or just plain impossible. While I don't consider it a must-have for the port I will include it if at all possible.

One more major time consuming task will be to manually down-sample every single sprite image in the game. Then I can remove the requirement that the library scale everything automatically. Not only will this make things look better, it should give a performance boost since the current sprites have four times as many pixels as necessary. Less pixels to read == faster drawing

My goal is to be done with the port by the end of the year. This is more than just a hand-waving target. Sometime mid-January my wife and I are expecting our first little gamer in the family. He will make whatever free time I have now seem like a summer vacation. If the port isn't done by then it will likely be put on hold for a few months, and I don't want to put the NUON fans through that.

But wait, that's not all! I have big plans for Decaying Orbit even after the port is done. It's too early to give away details, but I am just so freaking excited by what I have in mind! When it happens it will require the full support of the NUON community and then some. You'll read about it first here at NUON-Dome. In the meantime, follow the (somewhat) day-to-day progress through my development diary at DragonShadow Industries.

Cheers, thanks, and all that,
Scott Cartier (Skah T)