Jump to content
IGNORED

Tadataka


The Codex

Recommended Posts

Starting a new thread for the Tadataka project. Yes, it's another editor, this time for TI-compatible bitmaps.

 

And here it is!

 

post-25494-127550706062_thumb.png

 

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.

 

post-25494-127404144239_thumb.png

 

Original image

 

post-25494-127404141258_thumb.png

 

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.

Edited by The Codex
Link to comment
Share on other sites

Starting a new thread for the Ortelius project. Yes, it's another editor, this time for TI-compatible bitmaps. Early days yet so no downloads, but they'll be here once they become available. Here's a screenshot of the app running. 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.

 

post-25494-127404144239_thumb.png

 

Original image

 

post-25494-127404141258_thumb.png

 

Converted to TI palette and loaded into Ortelius

 

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.

 

OK now I'm officially hyperventilating! I have been waiting for a long time for this. Looking forward to trying out the beta and I'm already thinking of future projects for this. What development environment are you using?

Link to comment
Share on other sites

OK now I'm officially hyperventilating! I have been waiting for a long time for this. Looking forward to trying out the beta and I'm already thinking of future projects for this. What development environment are you using?

 

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.

Link to comment
Share on other sites

Hmmm... one thing I notice about the converted image is that it's rather sparse in color... the colors used differ considerably from the original. Most noticeable is that the original contains a lot of grey, but the converted version doesn't use that color. It also never uses blue or cyan. Furthermore, the image quality could be greatly improved if dithering was used... as it seems, this conversion only converts each pixel to the nearest color (or another one). If the image was dithered, it could look roughly like this:

 

post-8393-127407130136_thumb.png

 

The question is, of course, if that result would be editable that easily.

Link to comment
Share on other sites

The TommyGun retro development toolkit paints beautifully with 9918 restrictions. Never got around to doing any output (which should be customizable/programmable). Try it out, there might be tons of good ideas for the Codex Suite. Would be nice if Strawberry could hook into Codex on a CLI basis or something. Daniel Bienvenu has a few utilities too - some more game hybrid bitmap oriented.

 

:cool:

Link to comment
Share on other sites

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.

Edited by The Codex
Link to comment
Share on other sites

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.

 

Well... I don't think the last chunk makes sense, at least if it should be processed by a program afterwards and written to the VDP. In the VDP, the pattern table and the color table are separated, so I think it would make more sense to separate them in the assembler output too instead of pairing them together. I think the ideal format would be in the order they need to appear in VDP RAM, at least if you adher to TI's recommendation. The whole bitmap consists of 768 character positions, and each of those positions has 8 bytes for pattern and 8 bytes for color which are listed top-down. I would put each character cell, consisting of 8 consecutive bytes, into an assembler line, which I think is the most logical grouping since after those 8 bytes the definition "jumps" to the next character cell which starts from the top again.

 

As an example, I've attached the source code my converting program generates for the image posted above... though I don't know if that's the correct format for TMS9900 assembler. My converting program currently puts out code for DASM, and the lines look roughly like this:

 

               .byte $62, $2C, $C6, $2C, $1C, $26, $2C, $C6

 

Maybe in TMS9900 assembly they need to look differently. I think the "byte" command there is written in uppercase without a dot before it, and there are greater-than signs instead of dollar signs before the bytes, so the line above, written in TMS9900 assembly, would look like this:

 

   BYTE >62,>2C,>C6,>2C,>1C,>26,>2C,>C6

 

Ortelius_Test.zip

Link to comment
Share on other sites

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!

Link to comment
Share on other sites

Well... I don't think the last chunk makes sense, at least if it should be processed by a program afterwards and written to the VDP. In the VDP, the pattern table and the color table are separated, so I think it would make more sense to separate them in the assembler output too instead of pairing them together. I think the ideal format would be in the order they need to appear in VDP RAM, at least if you adher to TI's recommendation. The whole bitmap consists of 768 character positions, and each of those positions has 8 bytes for pattern and 8 bytes for color which are listed top-down. I would put each character cell, consisting of 8 consecutive bytes, into an assembler line, which I think is the most logical grouping since after those 8 bytes the definition "jumps" to the next character cell which starts from the top again.

 

 

Yes, that is likely the most logical output format.

Link to comment
Share on other sites

My converter (http://www.harmlesslion.com/cgi-bin/onesoft.cgi?102) has got a lot of time invested to making the images look good, also have a look at my document about it, available here: http://www.harmlesslion.com/text/Modern%20Graphics%20on%20the%209918.pdf

 

My tool uses perceptual color matching as well as Floyd-Steinberg dithering, though you can change the dither pattern yourself, as well as tweaking the resize filter and turning various optional settings on and off, even 'nudge' the image to work around the horizontal blocking if you like. It's about as plug-and-play as it gets - to convert an image, just drag it to the window. It resizes automatically (and has several options for dealing with images with a non-4:3 aspect ratio). It even has a secret 'random slideshow' mode... double-click on the empty window frame, and the 'Open' button becomes 'Next'. Click it, and select any file in the folder you want to slideshow. Each time you click 'next', it will randomly choose a file from that folder and convery it. ;)

 

As for the output format, the standard most widely used is "TI Artist format", which is two separate files, one containing a raw 6k dump of the color table, one containing a raw 6k dump of the pattern table. It's assumed in this format that the SIT contains the usual arrangement of three sets of characters 0-255. If you name them with the extensions TIAP and TIAC, I actually have a Windows-based Photoshop filter that can read (not write) the files (I use it with ThumbsPlus for organizing the hundreds of images I have converted and kept with my tool) here: http://www.harmlesslion.com/cgi-bin/onesoft.cgi?112

 

Since there's no requirement for which comes first in VDP (color or pattern), and because there is 2k of unused space between them, and because the normal TI image file loaders manage 8k blocks at a time, two files was probably a reasonable compromise. Personally I prefer to keep existing formats unless they actually don't work, than to introduce new formats at such a late stage, but I seem to be in the minority there.

 

My converter can also RLC compress the tables, though I've more used this in my own software. ;)

 

As an example, here's what my tool with the "Perc"eptual option and default filter does with the sample pic from the top:

post-12959-127413626929_thumb.pngpost-12959-127413623589_thumb.png

 

(note that my tool scales the image 2:1 for display on the screen, that's why the pixels are large, but it is 256x192 ;) )

Link to comment
Share on other sites

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!

Link to comment
Share on other sites

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.

It definitely is. I used it for the splash screen of Ultimate Planet.

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!

TI Artist outputs a color table file and a pattern table file. Using them is simply a matter of loading the file contents into the appropriate VDP color and pattern table areas based on the initial bitmap setup. This is the same as Tursi's converter.

The value of Ortelius, at least as far as I am concerned, is the ability to look up absolute pixel coordinates, pattern table byte and bit offsets, and color table offset along with color information for any selected pixel. This is essential for coding bitmap screen objects. That information does not necessarily need to be exported to the assembler, and it is probably sufficient to have it displayed on the screen.

One interesting feature however would be the ability to select a rectangular section of the image and be able to export the pattern and screen tables data. We could make it simple and allow selection only along the 8x8 character boundaries or really be masochistic and allow free selection. In the former case, one would need the pattern table byte offset for each 8x8 character with corresponding character definition, color table offset for each 8 bit character row and color information. For the latter case, this will need to be done bit-wise, i.e. one would need the pattern table byte and bit offset for each pixel and corresponding color table byte offset and color information. That's a lot of data, but one could apply a simple offset to it and thus place that sub-image section anywhere on the screen within a program.

Link to comment
Share on other sites

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.

Edited by The Codex
Link to comment
Share on other sites

----> Taking suggestions on asm output format, as well as any other that is desired. Look for a download of this app soon.

 

The standard has always been to dump the PDT as a raw binary with "_P" at the end of the file while the color table is suffixed with a "_C". If you duplicate this then the files will be immediately usable by most TI art programs and screen loaders. They need to be in program image form.

 

What would be a very useful add-on would be the ability to generate DV80 files that had data statements preceding the raw data. The format would look like this....

 

DATA >EF05,>5656,>610C etc. I have a project I was working on recently that needed a bitmap image for the top 5 screen lines. It was doable using Mikes Convert program but then I had to jump through all kinds of hoops to get it into source statement form. I would truly love some automation here.

 

My two cents....

Link to comment
Share on other sites

Is there any source for compressing/decompressing these images available? I think it would be valuable to offer a completed routine to decompress the images on the TI so people could integrate it into their own source. Then the _P files could be converted or even directly exported as compressed data that could be include in projects.

Depending on the source data, you could save more space than the decompressor takes on just one or two screens.

It would make it much easier to fit games with several screens on a cart.

Link to comment
Share on other sites

One interesting feature however would be the ability to select a rectangular section of the image and be able to export the pattern and screen tables data. We could make it simple and allow selection only along the 8x8 character boundaries or really be masochistic and allow free selection.

 

I agree - this is something I actually have a (relatively) current need for. The character boundaries are enough for my needs, but anything along those lines would be very handy. ;)

Link to comment
Share on other sites

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. :thumbsup:

 

The docs included with my conversion tool should cover the RLE format I used in that. It's simple but works well enough -- if I didn't include source code I can paste the code I used here. I don't know what Sometimes used in his RLE - there's no fixed standard for HOW to use RLE so everyone tends to be a little different. :)

Link to comment
Share on other sites

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. :thumbsup:

 

The docs included with my conversion tool should cover the RLE format I used in that. It's simple but works well enough -- if I didn't include source code I can paste the code I used here. I don't know what Sometimes used in his RLE - there's no fixed standard for HOW to use RLE so everyone tends to be a little different. :)

 

As long as a current developer package includes the decoder that works with the current compression I really don't see a problem. In other words, if you improve/alter the compression in the tool, include source for an updated decoder to go with it. As long as you don't change the API people can just drop in the new decoder.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...