Usenti 1.7.8 and TTE demo

One major and some smaller changes to usenti. The major one is that there is now a font exporter that can convert bitmaps to TTE-usable fonts. I'm not sure if it's final yet, but any later changes should be small. The text-tool has been altered to facilitate creation of fonts by adding an opaque mode, an align-to-grid option and proper clipboard support (so you should be able to just copy an ASCII table into it, at which point the font is practically made already).

Also, there are separate pasting modes: one that matches the colors to the current palette (potentially mixing up the colors) and a direct-pixel paste, regardless of colors. Thanks, gauauu, for finally making me do this. Secondly, Kawa's been badgering me (politely) about editing colors in raw hex rather than via RGB triplets. This can be found, for various bad reasons, under the Palette menu under ‘Advanced color edit’.

Both of these items have … interesting side effects. Through the former, you can replace colors of a given palette-entry by copy-all, swap and paste. The color-edit accepts multiple colors separated by white-space and, later on, by commas as well, meaning that accidentally it's now possible to take previously exported palettes and add them again. Yes, it's feep, but it's interesting, somewhat hidden and cheap feep, so that's alright. I'm thinking about adding something similar for the image itself as well (plus raw image imports), but only when I'm bored enough.

To show off the font exporter and the TTE system itself, there is a little demo of what it can do here. I'm still pondering over what it should and should not be able to do, but most of the things shown in the demo would be in the final version as well.

Oh, RE: that wordpress bug. A v2.3.1 has been released now with the fix. Interesting factoid: the error (#5088) was classified as “highestomgbbq”.

LOL wordpress

Ever since I started my non-university site, I've been meaning to create a nice DB-driven back-end to manage it all, perhaps with some bells and maybe even whistles. However, I never came round to doing so because, well, I'm not exactly fond of building interfaces and there was other stuff to do as well. It also seemed a bit silly to do all that work myself when there are other packages out there that do everything for you. So in the end I decided to follow in the herd down to wordpress.

It's … nice. Changing styles is easy and you can build your own page templates and text filters to customize everything. One of my worries was that it'd limit me in my post formatting, but I can do everything in HTML just like I always did … once I turned off the visual editor and removed the wpautop and wptexturize filters. Of course, one of the downsides of using someone else's system is that you have to learn how everything works. So at the moment everything's still pretty simplistic. I'm not entirely sure if the stuff I have can really be presented the way I want by wordpress, but I seem to get by so far. At least I'll be able to update a little easier now.

So, this is what my site looks like now. Yeah I know, bland site is bland, but at least it works. There's posts over here and a navbar over there . You may notice that there are two links to ‘projects’ there – that's something wordpressy. It makes a division between ‘Posts’, basically journal items with timestamps, and ‘Pages’, which are standalone. Tonc would be an example of Pages. The projects page and documents would be part of that too. Updates on those items, however, would be announced as posts.

Oh, and yes, I have been a little revisionist in the post orders. The past month or so has been a sort of trial run for all this stuff so there are many posts all at once right now. We apologize for the inconvenience.

wordpress 2.3 HTML entity bug

There is/was a rather annoying bug in wordpress 2.3. Normally when editing pages in the advanced editor, the actual text of the post/page has to be preprocessed to convert things like × to × so that it wouldn't show up in the editor as ×, and ditto for angle brackets. The extra ampersands and brackets would then be removed before saving. However, in the 2.3 upgrade a few things in the core structure of post/page retrieval had been changed and the somehow the the page-retrieval didn't do the pre-processing anymore. The upshot was that the amps and brackets got converted to normal ascii and unicode, seriouslycompletely messing up your pages.

I managed to track the problem to get_post() and get_page() in wp-includes/post.php. get_post() did get the upgrade, but get_page() didn't. The latter needs to be updated to carry and use a third parameter, and call sanitize_post() like get_post() does.

Of course, right after doing this I found out that a fix was already present in the SVN. Just update the file with this one. Ain't that always the way.

To see if you are affected as well, make a new page and input the following:

× > entities

Then hit `Save and Continue Editing'. If the text has changed to “× > entities”, you're in trouble: every page you edit in that state will have its entities converted. Get the fixed file as soon as possible.

new tonclib

I've been making a lot of changes to tonclib – mostly adding, but also some removals. The most important changes are:

  • A more unified interface for the base drawing routines. Whereas I used to have something like bm8_foo(...), I now have bmp8_foo(..., void *dstBase, u32 dstPitch) for everything. Although the extra parameters make the routines a little slower, it makes it easier to switch video-modes.
  • A few color routines like blending/fading, convert to rgbscale (like grayscale, but for any color vector) and a few color adjustments.
  • I'm trying to include (well, annex, really) some of libgba's functionality. In terms of shared functionality, the libgba names can be used by including tonc_libgba.h. This is definitely not a finished item yet.
  • Tonc's Text Engine. I already had some basic routines for text on different video types, but this is a good deal better. Instead of having separate foo_puts() routines, TTE uses function pointers for placing glyphs on screen. This means there can be a single interface for all modes, and customizable writers. Already provides are glyph renderers for 8/16bit bitmaps and 4bit tiles, using a 1bpp bitpacked font. In principle, the renderers can handle any sized fixed and variable-width fonts (within reason: 128x128 fonts would be impractical, for example). There are also hooks for the stdio functions (printf, yay!) and some simple commands for positioning, color and font changes. Example of use:
    // Set-up 4bpp tile rendering bg 0 using cbb=0 and sbb=31.
    // The default options set implicitly here are: verdana 9 font, yellow for 
    // text color
    tte_init_chr4_dflt(0, BG_CBB(0)|BG_SBB(31));
    // Init stdio hooks
    // Print something at position (10,10)
    iprintf("\\{P:10,10}'Ello world!, %d", 1337);
    Aside from the initializer, using TTE is basically independent of what you're writing with or on. Of course, all this stuff does have a fair amount of per-character overhead (about 150 cycles, I believe). It shouldn't be too hard to port TTE to NDS; I am planning to do this at some point.

There are more smaller changes here and there, but those are of lesser consequence.

tonclib 1.3 linky.