Coranac

It seems that a bug in the hiscore entry code that I thought I'd fixed over a month ago got resurrected in setds v1.0. So I fixed it – refixed it – today and we're now at setds v1.01.

Sigh. Gaddammit >_<

I've finally taken the time to add proper saving that works on hardware (at least on my R4, which is the only card I have right now). I've also fixed a very annoying game-hanging bug and did some tweaking here and there, like correcting the decay constant so that I can finally get the scores that I was used to on tatset (2300+, wooo!).

This is pretty much where I wanted to go with this game, so it's now version 1.0. I may add some other things later, but for now I guess it's done.

Changes

• new: FAT saving enabled :D. It's intended for argv-capable cards, though. You can still save without one of those, but you'll have to put in a little work.
• new: Reset/Back buttons for high-score screen.
• fix: Bug in shuffle code. Fixes the occasional hang at start of a new game.
• tweak: I've altered the decay constant slightly; it should be closer to the original tatset now. The upshot is that scores will be a little higher.
• tweak: Slightly bigger buttons.

Links

• setds project page

Okay, so it's only a card game; but a game nonetheless.

The game in question is an NDS implementation of SET. Set is a card-matching game with 81 cards (see below). The figures on the cards have four properties and 3 possibilities for each property. The key is to find three cards for which the values of each property are either all equal or all different. Looking at the color property, for example, a "Red Red Red" combination could (yes "could"; there are still three other properties to consider) form a set. "Red Green Blue" would also work, but "Red Green Green" would not.

Further details can be found in the readme and the game itself.

All 81 Set cards.

The game is mostly finished. There may be some tweaking to do here and there, but right now I don't want to get bogged down in a massive fine-tuning-fest – especially since I'm not sure what parts need fine-tuning … and because there's other stuff I really should get back to.

That said, all important aspects work … with one exception: hiscore saving. Yes, that. I've seen the multitude of threads on the subject but sofar I'm unsure of what would work on both hardware and emulator, so I'm leaving it as is for now. If anyone has a tidy hw+emu solution, please do tell.

Links

• binary: setds-bin.zip (146k)
• source: setds-src.zip (354k)
• readme: setds-readme.txt

Oh, and merry Christmas everybody.

Okay. Apparently, I am an idiot who can't do math.

One of the longer chapters in Tonc is Mode 7 part 2, which covers pretty much all the hairy details of producing mode 7 effects on the GBA. The money shot for in terms of code is the following functions, which calculates the affine parameters of the background for each scanline in section 21.7.3.

For details on what all the terms mean, go the page in question. For now, just note that call to DivSafe() to calculate the scaling factor λ and recall that division on the GBA is pretty slow. In Mode 7 part 1, I used a LUT, but here I figured that since the yb term can be anything thanks to the pitch you can't do that. After helping Ruben with his mode 7 demo, it turns out that you can.

Fig 1. Sideview of the camera and floor. The camera is tilted slightly down by angle θ.

Fig 1 shows the situation. There is a camera (the black triangle) that is tilted down by pitch angle θ. I've put the origin at the back of the camera because it makes things easier to read. The front of the camera is the projection plane, which is essentially the screen. A ray is cast from the back of the camera on to the floor and this ray intersects the projection plane. The coordinates of this point are x_p = (y_p, D) in projection plane space, which corresponds to point (y_b, z_b) in world space. This is simply rotating point x_p by θ. The scaling factor is the ratio between the y or z coordinates of the points on the floor and on the projection plane, so that's:

and for y_b the rotation gives us:

where y_c is the camera height, y_p is a scanline offset (measured from the center of the screen) and D is the focus length.

Now, the point is that while y_b is variable and non-integral when θ ≠ 0, it is still bounded! What's more, you can easily calculate its maximum value, since it's simply the maximum length of x_p. Calling this factor R, we get:

This factor R, rounded up, is the size of the required LUT. In my particular case, I've used y_p= scanline−80 and D = 256, which gives R = sqrt((160−80)² + 256²) = 268.2. In other words, I need a division LUT with 269 entries. Using .16 fixed point numbers for this LUT, the replacement code is essentially:

At this point, several questions may arise.

• What about negative y_b? The beauty here is that while y_b may be negative in principle, such values would correspond to lines above the horizon and we don't calculate those anyway.
• Won't non-integral y_b cause inaccurate look-ups? True, y_b will have a fractional part that is simply cut off during a simple look-up and some sort of interpolation would be better. However, in testing there were no noticeable differences between direct look-up, lerped look-up or using Div(), so the simplest method suffices.
• Are .16 fixed point numbers enough?. Yes, apparently so.
• ZOMG OVERFLOW! Are .16 fixed point numbers too high? Technically, yes, there is a risk of overflow when the camera height gets too high. However, at high altitudes the map is going to look like crap anyway due to the low resolution of the screen. Furthermore, the hardware only uses 8.8 fixeds, so scales above 256.0 wouldn't work anyway.

And finally:

• What do I win? With Div() m7_prep_affines() takes about 51k cycles. With the direct look-up this reduces to about 13k: a speed increase by a factor of 4.

So yeah, this is what I should have figured out years ago, but somehow kept overlooking it. I'm not sure if I'll add this whole thing to Tonc's text and code, but I'll at least put up a link to here. Thanks Ruben, for showing me how to do this properly.

Well that was fast.

Dovoto discovered some quirks in the way names were used under shared data runs and had a nice suggestion to allow images to be added via grit files as well. There was also some other small niggly bits that needed straightening out. So yeah, grit v0.8.3.

• link to grit

Apparently, the GRF format didn't quite follow the official RIFF specs, so I had to fix it (thanks for pointing it out, Daniel). While I was at it, I also changed the names of the meta-tile arrays if a meta-map was asked for. In stead of the -Map affix, it now uses the more logical -MetaTiles. Yes, this probably will break something, but in the long run it's better this way and it's a compiler error, so it's easy to fix.

Usenti's been updated to match.

• link to grit
• link to usenti

The files have need downloadable for a while now as a preview, but I finally put the text up on the main site as well so I guess that makes it official. Tonc is now at version 1.4. As mentioned before, the main new thing is TTE, a system for text for all occasions. I've also used grit in some of the advanced demos, so if you want to see how you can do advanced work with it, check out the mode 7 demos and the tte demo.

This will be the last version of Tonc. It's really gone on long enough now.

Files and linkies :

• Main site : www.coranac.com/tonc
• Tonclib manual : www.coranac.com/man/tonclib/

• Example binaries : tonc-bin.zip (521k)
• Example code + tonclib : tonc-code.zip (1.1M)
• Text + images : tonc-text.zip (1.4M)
• Text in CHM : tonc.chm (1.7M)
• Text in PDF : tonc.pdf (6.9M. No, I don't know where the extra 3 MB came from either.)

Right! Now what …

I'm close to releasing the latest (and probably last; this really has gone on long enough) version of Tonc. As a preview, I'm releasing the PDF a little early in the hope that someone may take a look and offer some feedback before the official release (aw, c'mon, it's only 400 pages).

The changes mostly relate to the new Tonc Text Engine, a text system for all occasions. There's a new chapter describing how TTE works, how to write general character printers for (almost) for arbitrary sized fonts and every type of graphics, and a few other things. It's fairly long and could use sanity checking from someone else.

Also, many of the older demos now use TTE for their text as well. As a result they look cleaner and prettier, but it's possible there are some left-overs from older versions. So have at it.

• Tonc 1.4 preview (PDF, 4.3 MB).
• TTE chapter only (PDF, 584 kB).
• All relevant 1.4 files: here.

I've been building a basic interface for dealing with graphic surfaces lately. I already had most of the routines for 16bpp and 8bpp bitmaps in older Toncs, but but their use was still somewhat awkward because you had to provide some details of the destination manually; most notably a base pointer and the pitch. This got more than a little annoying, especially when trying to make blitters as well. So I made some changes.

I've rebuilt the routines around a surface description struct called TSurface (see above). This way, I can just initialize the surface somewhere and just pass the pointer to that surface around. There are a number of different kinds of surfaces. The most important ones are these three:

• bmp16. 16bpp bitmap surfaces.
• bmp8. 8bpp bitmap surfaces.
• chr4c. 4bpp tiled surfaces, in column-major order (i.e., tile 1 is under tile 0 instead of to the right). Column-major order may seem strange, but it actually simplifies the code considerably. There is also a chr4r mode for normal, row-major tiling, but that's unfinished and will probably remain so.

Demonstrating surface routines for 4bpp tiles.

For each of these three, I have the most important rendering functions: plotting pixels, lines, rectangles and blits. Yes, blits too. Even for chr4c-mode. There are routines for frames (empty rectangles) and floodfill as well. The functions have a uniform interface with respect to surface-type, so switching between them should be easy were it necessary. There are also tables with function pointers to these routines, so by using those you need not really care about the details of the surface after its creation. I'll probably add a pointer to such a table in TSurface in the future.

Linkies

• Demo project: surface.zip.
• Tonclib: tonclib.
• Tonclib manual, TSurface module.

The image on the right is the result of the following routine. Turret pic semi-knowingly provided by Kawa.

Grit 0.8.1 is out now. I've made three somewhat small changes here. First, there was some trouble with shared palettes/tiles if there was no -O or -S option. “Trouble”, as in segmentation fault. This should now be fixed.

I've also reformatted the include guards from __FOO__ to GRIT_FOO_H. GCC uses that format for internal #defines and it is very territorial about such matters. So, say, when you have elf.png, GCC gets cranky because that would hide its own __ELF__, and guess who wins out there? Again, thanks for pointing these things out, Quirky.

The last item is the addition of column-major tiling. This can be useful for horizontal scrolling games, since the data or the columns are all adjacent instead of a whole scanline apart. A second benefit of this mode is that rendering to tiles is made considerably easier (and a little bit faster too).

In case you hadn't noticed yet, I've also put the manual on-line. This shows the basic options for grit and wingrit, and now there's a description of how to use it in makefiles as well. This includes how the building the grit-demo project works. This one's quite interesting, so please check it out.

Project link.