Kevin Vance (weblog of)

Tags

:

corneroffice, nintendo ds

That screenshot links to a video of my dialogue system in action. The example script being run is available if you're curious.

Yesterday (Friday), I abstracted the command screen boxes so you could make other kinds of command boxes. Today (Saturday), I combined the new command boxes with the old text printer and the dialogue parser, added an interpreter for the compiled scripts, and ran the example dialogue file!

It works on the hardware too, but it's really hard to film a DS. Anyway, I'm really happy I took the time to do more of this project, and I'm pleased with how it's coming together. I also need to display the character portraits, but I'll add that later. Displaying images is easy, and I don't actually have any character art yet.

The last prototype I need to do is the battle system, which is going to need an animation system (am I going to waste EVEN MORE TIME writing an animation editor?!) and a simple AI.

Tags

:

corneroffice, nintendo ds

Finally had some time to do some corner office work. The last time I was working on this, I was trying to decide if I should hardcode the dialogue. It's a short game, but I think ultimately that ends up being really annoying, and... you know I have this thing about writing editors, right?

The actual editing takes place in an embedded gvim. That way I get syntax highlighting (and vim commands!) for free. Since most of my old "conversation trees" have been written in ZZT, I based the syntax on that.

The preview takes a background image and font file from the game, and uses the standard gdk drawing tools to render the text. It's supposed to render whatever text you are currently editing, but I still have to code that part.

The dialog file will get compiled down to a binary format that will be easier to interpret on the DS. I have a parser for it using pyparsing, which might have been a mistake since that was my first attempt with a parser generator and it's very clumsy.

I haven't even started on the interpreter on the DS side. I need to write some more test dialog, and implement a few #commands for setting flags and such. Once I'm pretty sure I have the right thing, I'll start coding that.

Tags

:

corneroffice, nintendo ds

So much for doing Corner Office in a month, making frequent LJ entries about it! I lost a bunch of days not doing anything on it, but I've been making progress again since last week (starting with the great log entry: "Wrote a bunch of code, not much of it works"). Since I started, a new devkitARM, libnds, etc. have been released. It was fairly easy to update to. I think the only difference was that some register names changed.

I also decided on how to package the game: a single .nds file, with the assets inside the internal .nds filesystem. The EFS library makes this possible, taking care of working on an emulator or actual hardware (by scanning your entire filesystem to find the .nds file!) Unfortunately, the EFS library, the EFS patcher, and libfat all had bugs. Workarounds have been posted on the gbadev forums, but I still lost a few days getting it all to work.

Also, I now have to have a loading splash screen. The first time the game loads, EFS has to scan the card for the game's .nds file since most (every?) loader doesn't fill in argv. Without a loading screen, that is a scary amount of time looking at a blank screen. After that, the game patches itself so it knows where to look next time. This is why EFS would be awesome if it worked out of the box.

For more exciting stuff, I finished the command GUI visuals. Every character in your party has a stat box on the subscreen, which can inflate and deflate to show that character's commands. The inflation, deflation, and the stat bars are all smoothly animated. I think the last prototype I need to do is to combine this command screen with the world view to have a little test battle. Then I can start cobbling it all together and making the levels.

Tags

:

corneroffice, nintendo ds

Here's a blurry video of my effort to combine the text printer and 3D world I was working on earlier. The interface needs a bit of prettying up, but I'm happy with the fade/slide in for the text box (and it's so easy to do using hardware fading and scrolling). I'm currently calling the game Corner Office, since I think just about all of it is taking place in an office building. So my LJ entries about it are now tagged corneroffice.

Tags

:

corneroffice, nintendo ds

I got a bit sidetracked on my DS project, but still making some good progress. The 3D world now renders correctly on the hardware. The sprite was showing up as all black with a transparent background, or color with a black background depending on whether or not I used the DECAL shading mode. Turns out it needed a fake material (emit=100%) and a normal vector.

You can also move around, collide with walls, and collide with sprites. These are using simple bounding box/bounding circle tests. A big box for the room bounds, and smaller boxes for obstacles. And circles for sprites. I also have an additional circle called the "interaction radius" where something can light up on the GUI and you can press a button to interact with it. This will be useful for interacting with sprites, and environmental features.

Then I started getting off track... first of all, I could not find a way to convert 8 bits/channel color images to 5 bits/channel (NDS format) using GIMP, ImageMagick, or PIL. So I wrote my own converter in python, using floating point and floyd-steinberg dithering. It's incredibly slow, but that doesn't really matter. The blue background of the example image has been run through that program.

Then I started looking at compression, since the output of my image depth crusher is in 16bpp NDS framebuffer format... very large. I originally used the LZ77 decompression routines that are conveniently in the BIOS. But unfortunately:

1. They only seem to output to VRAM or WRAM, which is inconvenient.
2. I switched emulators to no$gba in wine, which doesn't emulate that without a copy of the NDS ROM.

So I ended up with zlib instead. Despite some intimidating documentation and header files, there is a handy uncompress() function that does all the work. So that background image is zlib compressed framebuffer data, while the font is a zlib compressed PCX.

The font stuff is an extension of my earlier HexxagonDS text renderer. I nudged it over to C++, added some basic line-wrapping, and now it can draw 2-color fonts (an outline and a fill color).

Next: putting these together to have a 3D demo where you interact with stuff via text boxes!

Tags

:

corneroffice, nintendo ds

I've been playing around with a new DS project, using a little more 3D than I have before. That means even more time spent in Blender, a program one would think I'd be better at using my now. At any rate, I now have a better idea about what happens to UV textures before I would (as a programmer) load them from disk and jam them into graphics memory :P

The image is a visual test running in the emulator, and it's pretty much how I want this to look (sans botched texture coordinates of course). Pixelated character sprites in a 3D environment. Not only is it a good look, but the sprites compliment the low-res, unfiltered textures you get on the DS.

My goal is to crank out a very short game (20-30 minutes of gameplay) in about a month's time. This is a kind of distilled and truncated version of a larger game idea I have, but doing this will (1) get me out of creative stagnation and (2) give me a nice way to see how well that game would work.

...and perhaps get me to write LJ entries more often.