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.
I've been working on a few functions for rendering onto tiles recently. Yesterday was the turn of a rectangle filler. The traditional routine of double-looping over a pixel-plotter would be slow in every case, but for tiled surfaces it's positively evil, so I made something that divides the rectangle in 5 areas and fills them using by words or better. Yes, this is a little tricky but I figured the speed increase of up to 300 would be worth it.
For testing purposes, I filled each region with a different color so that ifwhen something went wrong, I could easily identify the problem. When playing around with the test app, I more or less accidentally came up with this:
Hmmm ... Mondriaany.
Anyway, it seems that this thing went alright. So now tonclib also has plot, hline, vline, line, rect and frame functions for 4bpp tiled modes. No, there's no blitting yet. In anyone wants that, I'm going to insist on some mental hazard pay.
It's time for another Grit release. There are three important changes compared to previous versions.
First, palette merging is in (and there was much rejoicing). If you use the -pS option, a shared palette will be created and used in the graphics. Note that I still think palette merging should be performed on the images themselves and not in the output phase. If anyone's interested, I do have a small app that can do just this.
Another big change is that handling of shared data is now done correctly. The previous version required two runs for this: one for the non-shared stuff, and then another for the tileset itself. You also had to take care to disable the shared item for the individual runs, otherwise the (useless) intermediates would be exported as well. Grit 0.8 fixes all this. You can provide multiple images and request a shared tileset and/or palette (with -pS, -gS, or -fx) and it should work right. Grit will export the individual parts first and save exporting the shared data for the end. For example, if you have 5 files to be converted to maps with a shared tileset, you'll get 5 maps, and one tileset and palette (instead of 5 of each like 0.7 did). You can tune the shared output names with -S and -O (uppercase s and o) if necessary.
Thirdly, there is a new binary file-type available. I'm calling it GRF, for Grit RIFF File. This places the graphics, maps and palette in RIFF chunks. The idea behind this was to have related data in a single file instead of three different binaries. The chunked data-format also allows easier extension and it's easy to make a generic loader for it too. For details (including such a loader), see the the manual. The -ftr option creates a GRF file, and you can also create GRF-formatted C/asm arrays using -fr.
I've also added something I like to call ‘fake’ compression, -Z0 (Z zero). This adds a header word to the data similar to the ones that the compressed data have. This consistency of data-formats is essential for the generic data-loader.
As I mentioned before, there is also a proper demo project to show how you can use grit and its various options. Take note of how it uses a separate makefile to prepare the graphics. This way you can keep the main makefile pretty clean and it makes it easier to insert customized conversion rules. Note: to build the demo project, make sure GRIT points to the updated binary.
Linkies
Finally got round to updating Tonc's dev setup page. It finally mentions devkitPro's template makefiles and the basics of how to use them. I've also added a list of potential problems you may encounter when installing/upgrading devkitARM or just building projects. I have not updated the downloadables yet because there's still a few unfinished edits there. I just wanted to get this one out of the way because it's so very, very overdue.
The standard C functions for copying and filling are memcpy()
and memset(). They're part of the standard library, are easy
to use and are often implemented with some optimizations so that they're
usually faster than manual looping. The DKA version, for example will fill as
words if the alignments and sizes allow for it. This can be much
faster than doing the loops yourself.
There is, however, one small annoying fact about these two: they're not VRAM-safe. If the alignment and size aren't right for the word transfers, they will transfer bytes. Not only will this be slow, of course, but because you can't write to VRAM in bytes, the data will be corrupted.
The solutions for this have mostly come down to “so don't do that then”. Often, this can be sufficient: tiles in VRAM are word-aligned by definition, and source graphics data can and should be word-aligned anyway. However, now that I'm finally working on a bitmap blitter for 8bpp and 16bpp, I find that it's simply not enough. So I wrote the following set of functions to serve as replacements.
My main goal here was to create smallish and portable replacements, not to
have the greatest and fastestest code around because that's rather platform
dependent. Yes, even the difference between GBA and NDS should matter,
because of the differences in ldr/str times and caching.
There are 5 functions here. The main functions here are
tonccpy and __toncset for copying and
filling words, respectively. The other 3 are interfaces for __toncset
for filling 8-bit, 16-bit and 32-bit data; you need these for, say, filling with a color
instead of 8-bit data. For the rest of the discussion, I will use the name
“toncset” for the internal routine for convenience.
I think I finally have a nice demonstration of the capabilities and use of grit again. The figure on the right shows its main menu. Each entry shows one or more capabilities of grit and how to make use of the data it outputs. Pressing start returns to the menu.
The source for the project is included in the demo, as is the most recent tonclib because the demo would not have been possible without it (at least not with a lot more code in the project itself). In a sense, it's a tonclib demo as well.
The way that grit is invoked and how its output is made available is pretty neat. I'm running a separate makefile called gfxmake which runs grit, assembles its output into a library called libgfx.a. It also collects all the separate headers into a main header file called all_gfx.h, so there will be no need to include dozens of graphics headers – just the one. I also have three sets of grit rules in here: for bitmap+.grit pairs, for .grit-less bitmaps (which use the directories main grit file) and fully custom rules for really special occasions. Like I said, pretty neat ^_^. I am pulling a few Clever Tricks in gfxmake to get all of this done and I hope to discuss these in more detail at a later time.
I'll probably add a few more examples in this demo (feel free to suggest some), but the way grit's invoked here will probably stay. Using a secondary makefile means a minimum of interference with the template makefiles and it also makes it easy to customize your projects w.r.t. graphics. As far as I'm concerned, this is the recommended path … until anyone informs me of a better plan.
Download link: /files/gritdemo.zip
Note to quirky: sorry, no palette merging in this demo yet. It will be in its follow-up.
Powered by WordPress