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 >_<
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.
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.
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 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 xp = (yp, D) in projection plane space, which corresponds to point (yb, zb) in world space. This is simply rotating point xp 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 yb the rotation gives us:
|
|
where yc is the camera height, yp is a scanline offset (measured from the center of the screen) and D is the focus length.
Now, the point is that while yb 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 xp. 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 yp= 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.
Div(), so the simplest method suffices.
And finally:
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.
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.
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 :
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.
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:
chr4r mode for normal, row-major tiling, but that's unfinished
and will probably remain so.

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
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.
Powered by WordPress