More silliness. Generated with the C64 Charset Logo Generator, so I can't take any credit whatsoever...

Download TAFA for free

-----

April 14, 2025.
I've been wanting to do hex-map based games, and I've been trying for some considerable time to get the densest map possible, without color clash, and without having to resort to an 8kB multicolor bitmap. The problem, of course, is that a hex map requires offsetting the odd rows (or odd columns, but that doesn't help anything) by half a cell. As long as cells are at least 2x2, that's just simple software logic. But I wanted to push down to 1x1 cells for density, and that means that every other row of the logical cells are not aligned with the hardware cells, and that makes coloration very complicated and/or impossible.

Except...

I can use raster interrupts, and I can set XSCROLL to provide pixel-level offsets, as used for smooth scrolling. Games use different XSCROLLS on different raster lines to provide parallax scrolling, so different XSCROLLs on different lines are used in many games.

If I use raster interrupts to set even/odd offset XSCROLL values for alternating lines, then the hardware cells line up with the logical map cells, and I can use free per-character coloring to set colors for each hex cell, without any concern for neighboring cells.

The timing got a lot trickier than I was initially expecting, because we're playing around at exactly the same time that the VIC-II is stealing ~40 cycles from the CPU so that it can load all of the information it needs to display the next 40 characters. That means that we have to interrupt on the preceding line, then NOP our way into the right-hand border, and then immediately store the desired XSCROLL. We can't do any kind of logic that polls the current raster line, because that's too slow and we end up inside the line before we detect and exit the loop. This is the kind of silliness that is required at 1MHz CPU on an NTSC signal. I got it stable, and it works on PAL just as well. Here's what it looks like:

Now, here's the fun bit. That family of raster interrupt handlers (there's one for even lines, one for odd lines, one for the "panel" at the bottom, and one for VBlank that sets up for the top of the screen) just runs merrily along. If I exit to BASIC while they're running, I can write new programs and run them, and get things like this:

-----

Trying to get my mojo back. Starting to feel some more "go". Not enough to tackle TAFA2 yet, but have been making my inner 18-year-old a bit happier by hacking around on C64 programming with some of the new C cross-compilers that are available (KickC in this particular case).
The following is just graphics and layout testing. Nothing interactive at all. But still fun, and getting a little excitement about trying to make a tactical hex combat game for my old C64 friend.

-----

A bit of silliness: I'm just a beginner with Unity, and this is just the result of one of their tutorials (they provide all the assets), but it's kind of fun that you can build WebAsm/WebGL builds. Not sure if the timing is reliable enough for TAFA-in-a-browser, but it's a thought...

John Lemon's Haunted Jaunt

Just to be clear, this has effectively nothing to do with TAFA, except by the barest tangent, which is that I am at least poking around at 3D development again, however tentatively...

-----

Happy 2020!

Something I should have done long ago... Hope those of you who purchased TAFA so long ago don't mind, but I think it's best if I just let it go free:

Share and Enjoy!

Oh, while this is a Windows-based application, it runs fine under Wine on Linux. In case it helps: here's a guide to installing Wine and dependencies on several common Linux distributions

Yes, this is really me. No, my site hasn't been hacked again. I've been out of touch so long, and I just found out that people are still recommending TAFA and even digging through archive.org to get to it. It doesn't support the newer LWO3 format, but I guess it's still workable with old LWO2 or OBJ files. If I can't seem to get my act together for TAFA2, I can at least let TAFA help more people.

At that link, you can find a readme, the trial setup and the activation file. Print out the readme first, because it has the serial number you'll need. Then install the trial, then run the activation file to unpack the full version of the program.

You may get some antivirus warnings because I used an EXE packer, which makes heuristic antivirus scans paranoid. You'll have to use your own judgment. I scanned and kept everything as clean as I could before I ran the EXE packer, but ultimately it's your own call. Feel free to run the file(s) through VirusTotal, which is probably a good idea for anything you download from the Internet.

Hope I get to see some new work from people! My email is just 'mac' at this site.

-----

(Long overdue) Update June 6, 2019:

Maybe I'm slow, but I just now found out about Emscripten. C++ to Javascript compilation with OpenGL and OpenAL support, and near-native speed. Has been used to port various things, including both Unity and Unreal Engine to the web. Hmmm... So, TAFA is written in (ancient) C++ and OpenGL.

Its audio handling is finely tweaked Win32 multimedia code, so that would all have to be redone (I looked briefly at OpenAL back in the day, so I'm not opposed).

Possibly more problematic is that all of the non-3D windows are currently Win32 GDI code, which would require a lot of rework.

And, of course, there's the whole issue of 'files'. How would I load or save them? Would I have to require cloud storage? Don't want to force storage on my servers... And the resulting code would all be running locally in your browser anyway. Just have to see how the file system inside Emscripten works with local files and browser sandboxing.
If I can recover some of my earliest morphing code via an archaeological expedition into old hard drives, I might be able to find a simple OpenGL-only morphing codebase that I could used to test just that core against Emscripten...

Not sure if any of this is worthwhile. I mean, it would be cool to see TAFA running under Linux, on a Mac, and on phones/tablets. But as time marches into the future, I keep seeing so much more advanced technology for facial animation -- automatic face tracking to match a performer's behavior, or engines that can take text and generate both natural speech audio and natural facial expressions. Very cool, but I can easily see how these kinds of tools could render traditional facial animation tools irrelevant within the next few years.

And, clearly, I'm not so speedy at creating products in my 'free' time these days. But I'm still curious. If I come up with anything, I'll make sure to put it up here for others to play with.

-----

Hello everyone.

A recent malware scan noticed that my MediaWiki had been compromised and malware installed. I've needed to do something with the site for a long time, anyway, so rather than just trying to clean up and go back to my stale old style, I thought I'd take this opportunity to experiment with some newer website techniques and systems. Hopefully, if I stick with stuff that my hosting provider sets up, their auto-update systems will keep me protected :) In the interim, this low-key placeholder will have to do.

I guess this also serves as a way -- not a great way, admittedly -- to show that I (and TAFA) are still here. No real news at this time, which is part of why the website got so dusty. 1.2.2.8 still works, though I've heard that the new Object file format in LW2018 isn't supported. Fortunately, saving as the older style still works. Just another impetus to find a way to make something happen with TAFA 2, I guess.

As always, thanks for your interest! I'll try not to let the garden get so weed-covered again.

Mac

P.S. Wow, has this trivial exercise reminded me how much I hate HTML. Pointed two different mobile browsers at this page. One has unreadably small text, even after I jumped the font size to 4 (mid-range), and if I zoom in it won't re-wrap the text. But at least the paragraph breaks are visible. On the other, the text is nice and big, but didn't change when I set the font size. Unfortunately, it barely shows any paragraph break at all, making the text hard to read in a different way. Hopefully whatever browser you're using isn't choking too badly.

Heh. So, someone on a forum pointed out that I didn't have a viewport meta tag 'coz I'm out of touch with web development. I think anyone who ever saw my old site would know that I was never particularly "in touch" with web development. But I went and learned about viewport meta, and it just confirms my general hatred of the web development ecosphere. The "you should always add this meta tag" version of the viewport meta (at least, according to w3schools) just tells your fancy new HTML5 browser to do what any dumb-as-dirt HTML1-3 browser would have done anyway. HTML was ALWAYS supposed to wrap text to the device's viewport. It's only because mobile browsers decided to break HTML layout to show bad web page designs shrunken to unreadability on tiny screens. So now, unless you specifically tell them to do what they were always supposed to do, they break your page. I get it, really. I don't even blame the mobile browser people, particularly. Web designers have made a truly astounding number of bad web sites -- technically. Oh, they look spectacular and do amazing things, as long as you're viewing them on a device close enough to the one they were designed on, but they're not flexible at all. Advent of phones has raised awareness, so now there's a whole "thing" about reactive web pages. Which is laughable, because HTML 1 was already reactive. The designers who created it KNEW that you should focus on content, not layout, and that it is ALWAYS the browser's job to present the information in the best way it can. But web designers / graphic designers had to be able to control every pixel and make web sites that work like posters, so they had to break HTML to turn it into PageMaker.

*Deep*breath* OK, got that bit of "grumpy old man" out of my system... The war is lost, on we go with this wobbling tower of mismatched poorly designed technology...