Sigh. Gaddammit >_<

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.

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.

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:

title="\lambda = y_c / y_b," alt="\lambda = y_c / y_b," />

and for y_b the rotation gives us:

title="y_b = y_p cos \theta + D sin \theta," alt="y_b = y_p cos \theta + D sin \theta," />

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:

title="R = \sqrt{max(y_p)^2 + D^2}" alt="R = \sqrt{max(y_p)^2 + D^2}" />

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.

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

Usenti’s been updated to match.

• link to grit
• link to usenti

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 …

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

alt="surface.gba movie" />
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.

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.