The Codex

Looks so good I think I fell in.

I'd love to make it to the Faire this year. Is it still tenatively scheduled for some time in the autumn season?

Just added copy-and-paste regions, works nice for duplicating or moving rectangular areas. Going to code up the binary export and that will be it for the first official release, which will be out soon after.

I've seen talk of folks using RLE (run-length encoding) to compress these images, so that may be a possibility. I'm game to implement anything as long as I have documentation or examples to work by.

One more fix in the code. Might add another feature or two, but otherwise I think the next release will be the first official version of the prog. That will mark the stabilisation of the save format as well, so you can count on it remaining relatively stable through any future releases. If there is a must-have feature that isn't in yet, let me know and I'll try to address it before the 1.0 pushout. Thanks again all!

Got an email from the folks who make an actual map program called Ortelius, asking that I change the name of this project since it might confuse folks doing web searches and whatnot. Figured a rename doesn't hurt me any, so the project is now named Tadataka (after Japanese cartographer Ino Tadataka). Probably should do more thorough web searches before I grab names in future. Anyway, didn't find anyone using the Tadataka name, so it should be okay.

Glad you like bro! Here's the data, I think I got the chars in the right sequence. Let me know if it doesn't render right in XB and I'll move them around. Sprite 1 - F83F1C1417190E171B09101C2B30516D000080C0E2F97F3F82F8F000807000D8 Sprite 2 - 205C67205C63201C23371621301061C1EC2A857505807000C03080C0E0669931 Ha ha, that reminds me of the duck-rabbit illusion. The Penguin - Nature's 14th Most Perfect Killing Machine! (ranks right behind the woodchuck with a suitcase full of thermite)

You cannot kill me mortal...

I just realised, perhaps the duck dragons resulted from a simple bit of language confusion? After all, what are both a male duck and a male dragon called? A drake! Or not. PS - When Rich mentioned "a zombie dragon", that reminded me of a sadistic idea for a dragon I had. What if were a dragon skeleton, and could be "killed" (or rather laid to rest) with the sword, but if you removed the sword from the carcass it would eventually become active again? You'd have to make it the last dragon killed, or give up on the sword after defeating it.

I much prefer a solid background in this case, though the castle looks great, as do the sprites. The checkerboard seems to generate visual noise, though some of that is because you have the fairly limited TI palette to choose from, which further hampers the color combinations that look good on both check colors. Still, something like it could definitely be used to assist the depth illusion.

Very nice, I think I like your image conversion the best so far Tursi. It's a good compromise between contiguous colors and smart dithering. It would be a great preprocessor for anyone looking to load images into Ortelius. For these various output formats, I think I have the simple binary down, and the assembler source, since both are ultimately just long lists of color bytes followed by long lists of data bytes. I would be more than happy to support existing standards as well, such as TI Artist. If there are documentation or example files of this output, please post them here and will do my best to implement that as well. Sorry I'm not as up on these as the rest of you, I fear I've always been an XB programmer where the TI was concerned. This is very fascinating, learning about all these formats, and I love the challenge of writing a new data converter, so do bring them on!

Cool, and yeah, I screwed up the data byte in my example, it's way too big. The ASM output sounds reasonable, color table first and then data table. And for the binary file it's easy to add the TIFILES header, with the rest being just the literal bytes of data, again in the color-then-data order. That sound good? If so, I'll make those two output types my target for now. Thanks!

Good comments all, and thanks for the suggestions and tool links. Kurt, you're right, that does look much better, though as you say it would be a lot harder to edit after the fact. I deliberately cartoonised the image when I converted it in PhotoPaint so that it would be easy to edit and modify. Planned tools like the coloriser will work much better on a simplified image. But you could certainly create a well-dithered and processed image like the one you posted if you wanted a photographic type of image in your game. It would be great for Amiga-style intro screens and cutscenes, for example. Matthew, I'll check out Tursi's app. It does sound like it would be an ideal preprocessor for when you want a near-photographic image to come over, of the kind Kurt is talking about. Having left the preprocessing out of Ortelius for the time being means that everyone has the flexibility to create the TI-paletted image however they wish, and Ortelius just does the grunt work of mapping it to byte arrays. Karsten, the TommyGun tools look pretty good. And I like your idea of having the apps be scriptable, so that they can be invoked to do tasks from the command line. I'm a big fan of that kind of usability myself, so I'll add that to the features list for both Magellan and Ortelius. And I'd be glad to work with you to create effective bonding with Strawberry so that all the tools benefit from the synergy. Great ideas everyone! Working on getting a version ready for you all to play with. Also, if anyone has a good spec for what the assembler output should look like, please post that too. Currently I'm thinking byte chunks like A68F, where A6 is the foreground/background color pair (foreground shifted 4 bits high) and 8F is the on-off graphical bits.

Heh, thanks man! It's Java like my other apps. I write code by hand on my own (though at work I use Eclipse). My toolkit for this consists entirely of the JDK, UltraEdit, Corel PhotoPaint, and Cygwin. I know a lot of people use Notepad++ instead of UltraEdit, as it's free and basically as good. I just got used to UE back when it was the only game in town. PhotoPaint is indispensable for creating images from scratch. Far better than Photoshop in my book, though again it's something I have a long history with. Please note that the image in the example above was first converted to the TI palette in PhotoPaint, not (I stress) in Ortelius. So for the first releases you'll probably need to manipulate your own images likewise. At least until I write a convincing filter that does it for you (which actually isn't that hard, just requires some finessing in the last stages). Once I do that, it'll go into Ortelius and you'll be able to load any damn image you please. Though of course you'll still get the most control loading one that's been TI-paletted to begin with. Also on the slate are a few simple brush tools, at the minimum a "char brush" which fills a whole 8x8 area at once. Drawing with pixels gets old quick, even on a 256x192 canvas. I'm also planning a clone tool, which lets you select a char square of the image that you've already painted and use it to paint other parts of the screen. And a coloriser that lets you paint new colors over existing pixels without changing the data bits (that'll make more sense when you see the demo). Once I get the first Magellan release out, this app will be getting the lion's share of the time.

Starting a new thread for the Tadataka project. Yes, it's another editor, this time for TI-compatible bitmaps. And here it is! Tadataka.zip Version 2 Import TI Artist RAW/TIFILES/V9T9 files (tries to automatically select second data file based on name of first) Export TI Artist RAW/TIFILES/V9T9 files Save/Export selected area of bitmap (as Tadataka fragment file or Assembler source) Corrected Assembler output Version 1 Various sized Brush Tools Coloriser Brush Ability to turn foreground/background coloring on and off when painting Copy/Paste and Clone Brush tools Import existing PNGs (monochrome or TI paletted) Pixel locator readout Eight levels of magnification Save assembler data or PNG image Variable canvas size (old original post follows) The bitmap in it was converted to TI colors and then loaded into the app, which does all the "foreground-background" color setting to ensure there is only one pair of colors per 8-bit row chunk. Other features that work are draw/erase (same as in Magellan, only with pixels) and the clickable color dock. Original image Converted to TI palette and loaded into Tadataka Lots of enhancements planned for this, such as a clone brush and a colorise tool. Might also remove some stuff that came over from Magellan, such as multiple images, though I can leave that in if folks think it will be useful. Taking suggestions on asm output format, as well as any other that is desired. Look for a download of this app soon.

Yep, I know, it's the same technique as used in Realms Of Impossibility, unless I misread something. That's the only kind I think is really feasible on the TI, as the draw buffering for genuine iso might be pushing the system just too far.

When I code isometric games, the memory and data side of things is still a standard 2D grid (or occasionally a 3D matrix). It's only the rendering engine that does all the isometric trickery. I find it's a real pain to code as though the isometric landscape is the actual collision space. Given the TI's capabilities and the need to z-buffer real isometric graphics, I think the closest we can get are psuedo-iso landscapes like those in the C64 game Realms Of Impossibility. Not that that's a bad thing, I love that game. But it's a case where the screen looks iso but is really just a bitmap layer, like the original Adventure. To pull off genuine iso rendering, even when the underlying data layer is a simple grid (like the arcade game Crystal Castles), that'd take some clever assembly. Of course, if any group of 99ers can pull that off, it's this lot.

* SOLD * - Thanks again AA'ers! Hello, I'm doing my annual purge and came across my collection of early issues of Retrogamer magazine from the UK. I've got issues 2-21, except for issue 18 for some reason. Also included is the first best-of issue (with lots of material from issue 1), a couple bonus items included with the original mags, and 15 of the coverdiscs. Anyone interested in this, please make me an offer. Shipping will probably be about $20 on these, together they're heavy as heck. Thanks for looking!

* SOLD * - Thanks again AA community! Sega Genesis 3 core system in nice condition, 22 games (plus a duplicate) boxed and with manuals. Shipping will likely be $12-$20, depending on how it's sent and where you are. Make me an offer, and thanks for looking!

Hmm, pretty cool, that. Let me try it out and I just might add it at that if it speeds things up. Of course it would only be for the map rendering program, which doesn't do much, but it's still a neat idea and could catch on here. Sorry, not in Magellan, but something like that does exist in my unreleased sprite editor (Charcot) and forthcoming bitmap editor (Ortelius). You can use the Character Image Import function to load a picture you drew elsewhere and have it convert into characters. The main limitations is that the imported picture has to use the exact same colors as the TI (or be pure black and white), and that it should be the same size as the demo character picture included with Magellan.

Hot dang, glad to hear it! I try to do tests, but inevitably miss things, so thanks for the feedback!

The patched version is up. I have fixed and tested the XB export, plus added in better validation checking for character range exports. Also addressed a couple non-critical bugs while I was in there.

Cheers all, and I'm doing a rush fix of a couple things this morning. I'm going to repair the XB output, and also constrain the character sets on save to only those legal for the target output (so no more saving out-of-range characters and colorsets in BASIC, for one). How great that you know who Ortelius is, Walid! I will indeed try to have something to show you this weekend. My main priority at the moment is converting the underlying data model to bytes in the same format as TI uses. Once that's done it will eliminate a lot of kludgy code I put in the first draft.

Eh, that's what users are for. I do incremental tests, but I will do more rigorous tests before the official release. This one just surprised me because I was pretty sure Owen and others had used the XB output successfully before. Almost sent them a resume once, actually. But I don't think my coding is quite bad enough. (Seriously though, I prefer to work on my own projects game-wise. Doing it for a living would likely kill the fun in it.)

Argh, you people are posting these bugs now, right after I release a new version? Where is the hate smilie... I'll patch that output up shortly, but in the meantime download the new version and see if the rest of the XB output works. The colorsets are handled differently in the latest version.