Magellan

[matthew180]

I second the use of PNG. There is no reason to invent a format, and the exact colors do not matter if we use an indexed palette format. Thus, we can retain pixel and color data separately. Also, the pixel resolution should be 1:1 since that retains the original image size without any guessing.

 

Matthew

[+retroclouds]

Oh no, now I getting even more stupid ideas - like loading modified graphics to the VDP while a game or something is running. Hmmm, the Debugger should already do that.

 

Have to check this out. I thought you can't write to (VDP) memory from the classic99 debugger ?

 

This reminds me of openmsx (MSX emulator). They have those TCL scripts for doing "stuff" while a game is running. I seem to remind a youtube video where they demo writing to the VDP from such script while a game is running.

Edited April 22, 2010 by retroclouds

[sometimes99er]

Oh no, now I getting even more stupid ideas - like loading modified graphics to the VDP while a game or something is running. Hmmm, the Debugger should already do that.

Have to check this out. I thought you can't write to (VDP) memory from the classic99 debugger ?

Sorry, you can only write one byte at a time manually. That’s what I read.

 

[The Codex]

Image dump is in. Here's the character set dumped from the citymerge example file.

 

 

I can dump it with the background as truly transparent instead of white, if desired. Easy enough either way. Next up is the import image.

 

Oh, and I fixed the ASM output Filip, thanks for spotting that the maps were identical. Forgot to update that exporter to loop through the map collection when I added multimap. Works as expected now.

[sometimes99er]

I can dump it with the background as truly transparent instead of white, if desired.

Good work.

 

If the image dump could be the suggested 64x256 instead of your 64x128. You would have to add 4 blank sets above (32 pixels) and 12 sets below (96 pixels). And when you load an image, you will have to chop accordingly.

 

Also if you could preserve colors with the image. If possible use the same index to colors as the TI-99/4A as Matthew suggests (post #101).

 

I guess a set (8 characters) that have the same foreground and background color will loose the patterns. Thats just something the user has to avoid then.

 

Edited April 22, 2010 by sometimes99er

[The Codex]

If the image dump could be the suggested 64x256 instead of your 64x128. You would have to add 4 blank sets above (32 pixels) and 12 sets below (96 pixels). And when you load an image, you will have to chop accordingly.

 

Sure, I can do that. What are the extra rows for, the additional free space that exists in TI RAM?

 

Also if you could preserve colors with the image. If possible use the same index to colors as the TI-99/4A as Matthew suggests (post #101).

 

Not a problem. I'll probably do both formats, so that you can save an image in either B&W or color, depending on what you want to use it for later. (I tend to use B&W because I've written other tools to turn those into useful byte arrays elsewhere.) Theoretically I could support loading color images and then derive the colorsets from those as well as the data, though I'd have to figure out (a) how to resolve colors in the image that aren't TI colors and (b) which color is the foreground and which the background.

 

But at the very least I'll support saving color and importing B&W. I also like keeping the export B&W because then you can paint on it directly and re-import it again.

[The Codex]

Monochrome and Color export now built in. Gotta do the loader next.

 

[The Codex]

By the way, this is the color table I use. I believe the hex values agree with those in Classic99 and MESS, but welcome any corrections that make this more compatible with other apps.

 

public static final Color TI_COLOR_TRANSPARENT = new Color(255, 255, 255, 0);
public static final Color TI_COLOR_BLACK       = new Color(  0,   0,   0); // 000000
public static final Color TI_COLOR_GREY        = new Color(204, 204, 204); // CCCCCC
public static final Color TI_COLOR_WHITE       = new Color(255, 255, 255); // FFFFFF
public static final Color TI_COLOR_RED_LIT     = new Color(255, 121, 120); // FF7978
public static final Color TI_COLOR_RED_MED     = new Color(252,  85,  84); // FC5554
public static final Color TI_COLOR_RED_DRK     = new Color(212,  82,  77); // D4524D
public static final Color TI_COLOR_YELLOW_LIT  = new Color(230, 206, 128); // E6CE80
public static final Color TI_COLOR_YELLOW_DRK  = new Color(212, 193,  84); // D4C154
public static final Color TI_COLOR_GREEN_LIT   = new Color( 94, 220, 120); // 5EDC78
public static final Color TI_COLOR_GREEN_MED   = new Color( 33, 200,  66); // 21C842
public static final Color TI_COLOR_GREEN_DRK   = new Color( 33, 176,  59); // 21B03B
public static final Color TI_COLOR_CYAN        = new Color( 66, 235, 245); // 42EBF5
public static final Color TI_COLOR_BLUE_LIT    = new Color(125, 118, 252); // 7D76FC
public static final Color TI_COLOR_BLUE_DRK    = new Color( 84,  85, 237); // 5455ED
public static final Color TI_COLOR_MAGENTA     = new Color(201,  91, 186); // C95BBA

[sometimes99er]

If the image dump could be the suggested 64x256 instead of your 64x128. You would have to add 4 blank sets above (32 pixels) and 12 sets below (96 pixels). And when you load an image, you will have to chop accordingly.

Sure, I can do that. What are the extra rows for, the additional free space that exists in TI RAM?

Excellent !

 

Actually the Video Display Processor (VDP) will happily display 256 in the ordinary graphic mode, but TI Basic and XB uses some of that area for other purposes, so that’s why TI Basic only allows 128 and XB only 112 characters. It could have been avoided by design, but would then leave less program space for TI Basic and XB (without Exp.mem.).

 

With Assembler you have full access or you limit yourself by choice. With Mini Memory you have 128 like TI Basic, but you can CALL POKEV any value 0-255 to the screen locations. Of course strange things will show up on screen, but it won’t crash.

 

Edited April 22, 2010 by sometimes99er

[+retroclouds]

I have a proposal for the binary file format to use when exporting map data.

Note that this proposed file format is only for the map data itself.

For the patterns and colors, I think we have a good solution with the PNG format.

 

The reason I'm proposing this file format for binary export, is because the export format for

the source data statements will be havily depending on the actual player code and the language it's written in (Assembler, Extended Basic, Forth, C99).

 

By using an intermediate binary format the game developer can write his own "converter" for turning the maps into source code focussing on his particular needs.

 

 

Data map export: Proposal for binary file format
================================================

<FILE HEADER>
<MAP 0 - MAP HEADER>
<MAP 0 - MAP DATA>
<MAP 1 - MAP HEADER>
<MAP 1 - MAP DATA>
  .
  .


A) FILE HEADER
==============
byte 0-1	2b: String constant MG
byte 2-3	2b: Magellan version identifier
byte 4		1b: Number of maps in file


B) MAP HEADER
=============
byte  0-3	4b: Magellan option flags for map 
byte  4-11	8b: Size of (C) in bytes
byte 12-13	2b: Number of columns in map
byte 14-15	2b: Number of rows in map
byte 16         1b: Screen background color

C) MAP DATA
===========
byte 0-xxxx	Tile character values (0-255) or RLE encoded data

 

Remarks

* Note that bytes 0-3 in the map header (B) can be used for setting Magellan map status flags.

Would be up to Codex to decide what to put in there. An example could be a status bit

telling if RLE compression is on for (C ).

 

* Byte 16 in the map header (B) indicates the screen background color. I added this as I presume this is not present in the PNG format. We can easily drop byte 16 should the background color be present in the PNG.

[+retroclouds]

Thinking about this: Adding the possibility to run an executable file after the export has finished would make

this a pretty transparent process. You could define the command line options in a Magellan settings file.

[matthew180]

There are a few problems I have with a binary format:

 

1. You have to know and agree on the byte order

2. You have to know and hard code the format

3. It is hard to change, i.e. add new stuff later

 

It seems that this is a perfect example of where something like XML would actually be useful. I'm assuming of course that this universal format is intended to be process on a modern computer, and not the TI (either real or emulated) directly? I'm not clear on that.

 

Matthew

[The Codex]

Thanks Karsten and Filip for the feedback insights, all very useful! The binary output format sounds good to me, let me mull it over a bit and see if there is anything I would add.

 

Matthew raises a valid point as well. I am perfectly comfortable provide XML output of the data, XML processing in Java is something I do quite heavily in my day job. XML is technically more of a text output than a binary format, more flexible but less compressed and less rigidly ordered. There's no reason I can't support both, though if everyone agrees that one or the other is the best case then I'll focus efforts on implementing that one.

 

I hope to have a new version out by this weekend so that you all can play with the image and ASM exporting, plus anything else I get done in the interim.

 

PS - With regards to the binary format that Filip proposed, is there any interest in having this output directly to TI DSK format? I wrote a TI DSK file reader a while back for my ToD work and could adapt that to output DSK format files as well. I've already begun looking at that for Owen and Adam's LOADMAP routines, so I could the same for Filip's binary format if it's useful.

Edited April 23, 2010 by The Codex

[The Codex]

I have a minor amendment to the binary format that I would like to suggest. It should be possible to include the colorset and character data as chunks as well, but optionally so. That gives the developer the option to control how much map is stored in a single file, and how much they wish to obtain from secondary files (or assign programmatically). Here is my proposed version of the binary format, please let me know your thoughts on this.

 

Data map export: Proposal for binary file format
================================================

<FILE HEADER>
<COLORSET CHUNK (optional)>
<CHARDATA CHUNK (optional)>
<MAP 0 - MAP HEADER>
<MAP 0 - MAP DATA>
<MAP 1 - MAP HEADER>
<MAP 1 - MAP DATA>
  .
  .


A) FILE HEADER
=================
byte 0-1        2b: String constant MG
byte 2-3        2b: Magellan version identifier
byte 4          1b: Chunk header *
byte 5          1b: Number of maps in file

B) COLORSET CHUNK
=================
byte 0-15       16b: Full colorset definition table (16 1b foreground/background pairs)

C) CHARDATA CHUNK
=================
byte 0          1b: Number of character definitions
byte 1          1b: Character to define
byte 2-5        4b: Character data
  .
  .

D) MAP HEADER
=================
byte  0-3       4b: Magellan option flags for map 
byte  4-11      8b: Size of (E) in bytes
byte 12-13      2b: Number of columns in map
byte 14-15      2b: Number of rows in map
byte 16         1b: Screen background color

E) MAP DATA
=================
byte 0-xxxx     Tile character values (0-255) or RLE encoded data

 

* The "chunk header" specifies if optional data chunks are included, using bit flags. The colorset chunk is 01 and the character data chunk is 02, so specifying both would be 03 and neither 00.

Edited April 23, 2010 by The Codex

[+retroclouds]

There are a few problems I have with a binary format:

 

1. You have to know and agree on the byte order

2. You have to know and hard code the format

3. It is hard to change, i.e. add new stuff later

 

It seems that this is a perfect example of where something like XML would actually be useful. I'm assuming of course that this universal format is intended to be process on a modern computer, and not the TI (either real or emulated) directly? I'm not clear on that.

 

Matthew

 

Even though I use XML on a regular basis, I think its a bit of overkill for what we are trying to accomplish here.

I understand that when doing an import from XML, it could help you to get the different sections nicely separated into your

programs' memory and may help in terms of extendability.

However, if you are writing a converter, you have to know what to access when for generating your output anyway.

 

Nonetheless, as far as the data structures in the export file itself are concerned, I don't think it will make that much of a difference if they are wrapped in XML or are plain binary, so I'd say let the majority and Howard decide

[matthew180]

Well, I'm not sure I understand the intent of the binary file. Is it intended for use on a real TI (or emulator), so something else?

 

Matthew

[+retroclouds]

Well, I'm not sure I understand the intent of the binary file. Is it intended for use on a real TI (or emulator), so something else?

 

Matthew

 

If you are on a PC, I don't think it's that important. You have XML parsers for about any language you can think about.

I mainly program perl and like to do things myself, that is why I mainly opted for a binary format.

Also thinking that I could dump the binary file directly to ROM (Sorry was more thinking about Colecovision here).

It's not that hard to write a converter for turning the XML structures in binary format, so I won't complain that hard if we get an XML structure in the end

[+retroclouds]

I have a minor amendment to the binary format that I would like to suggest. It should be possible to include the colorset and character data as chunks as well, but optionally so. That gives the developer the option to control how much map is stored in a single file, and how much they wish to obtain from secondary files (or assign programmatically). Here is my proposed version of the binary format, please let me know your thoughts on this.

 

Data map export: Proposal for binary file format
================================================

<FILE HEADER>
<COLORSET CHUNK (optional)>
<CHARDATA CHUNK (optional)>
<MAP 0 - MAP HEADER>
<MAP 0 - MAP DATA>
<MAP 1 - MAP HEADER>
<MAP 1 - MAP DATA>
  .
  .


A) FILE HEADER
=================
byte 0-1        2b: String constant MG
byte 2-3        2b: Magellan version identifier
byte 4          1b: Chunk header *
byte 5          1b: Number of maps in file

B) COLORSET CHUNK
=================
byte 0-15       16b: Full colorset definition table (16 1b foreground/background pairs)

C) CHARDATA CHUNK
=================
byte 0          1b: Number of character definitions
byte 1          1b: Character to define
byte 2-5        4b: Character data
  .
  .

D) MAP HEADER
=================
byte  0-3       4b: Magellan option flags for map 
byte  4-11      8b: Size of (E) in bytes
byte 12-13      2b: Number of columns in map
byte 14-15      2b: Number of rows in map
byte 16         1b: Screen background color

E) MAP DATA
=================
byte 0-xxxx     Tile character values (0-255) or RLE encoded data

 

* The "chunk header" specifies if optional data chunks are included, using bit flags. The colorset chunk is 01 and the character data chunk is 02, so specifying both would be 03 and neither 00.

 

 

Sounds great. Thinking of it more, you could add new sections following (E) as Magellan evolves.

They again would contain a header and a data section. For the first 12 bytes, they could also follow

the same format as the map header. Suppose you are adding a new section for sprites positions per map.

 

F) MAP SPRITE HEADER
====================

byte  0-3       4b: Magellan option flags for sprites in current map  
byte  4-11      8b: Size of (G) in bytes 
byte  12-xx     Some Specific stuff for sprites

G) MAP SPRITE DATA
==================
byte 0-xxxx     Sprite data

Edited April 23, 2010 by retroclouds

[The Codex]

Agreed Filip, additional data chunks could easily come after the maps, since we know the byte length of that segment. As long as new chunks have their own header, they can be supported by later versions of the format without requiring a change to the initial draft, and they won't confuse programs designed to use the first format either.

[matthew180]

Personally I hate XML, it is one of the most abused ideas ever invented IHMO. However, when used for its intended purpose (exchanging arbitrary data between dissimilar systems) it works pretty well.

 

I'm a C / assembler programmer when I have a choice, so binary is good with me. But, I also have a tendency to do things the hard way, and a binary format is something I would come up with, so I figured something more buzz-word-ish would be better. :-)

 

If the files are intended to be read by a TI to get map and pattern data from a disk instead of being hard coded into a program, then a compact binary format is the way to go. Otherwise, if this is just to get the data out of a program and into a universally exchangeable format, something that is text based seems to make more sense (to me anyway.) As for PERL, its very name implies processing text...

 

Also, if XML was used, the numbers and such would not be in raw binary form, but rather the ASCII digit representation (as decimal or HEX.) I think someone mentioned XML was not designed for binary data, and I agree, but I was not suggesting packing the binary data into and XML wrapper, but rather a totally XML based format.

 

Matthew

[The Codex]

Yep, I intend to provide an XML format alongside the binary one. I'll post a proposed schema when I get to that point, though anyone else is free to beat me to the punch with a better one.

[The Codex]

New version is out, lots of changes, including image import and export. Binary export and other features coming soon, but I wanted to get this out there since there are so many mods in it. Feedback encouraged as usual!

[Opry99er]

LOVE the updates!!!!! One favor to ask... when adding new maps to the project, is there a way to add a map that's already made? For instance, I have 6 beryl "Forest" maps rockin right now, and is there a way to import them all into a new "map project?" I have a couple screens with one or two different character definitions, but that can be changed... This thing is really slick man... the intelligent character editor is very nice, and I love the import export features. EXCELLENT!!!!!

[Opry99er]

On second thought--- I don't need that feature--- these maps will all be re-done anyway.... This new version allows for alot of flexibility and I think just starting from scratch is the better idea---- Magellan is easy and fun enough to where it's actually a freakin blast to work in it! One suggestion though--- any way to have a separate screen that you can go to where you can lay out the design of the maps and give them numbers? I didn't see this feature, but then I only spent 10 minutes with the program... Now I gotta do a 4 hour show and then pack up to leave.

[sometimes99er]

Very nice.

 

Here’s one. Start Magellan. Open map project “city.mag”. Export Character Image (Color). New project map. Screen Color unaffected. It’s still grey as in “city.mag”. Import Character Image just saved. All characters have every pixels set (FFFFFFFFFFFFFFFF). Now Import Character Image “characters_demo.png”. Looks fine. Now click a character. It disappears (there’s no pattern).

 

About the Import Character Image. I would like it to import the colors too. From what I’ve seen “png” mess up the palette order at least when all 16 colors are not different and in use. This might differ between applications. I suggest we stick with exact colors, and we’re already using the MAME/Raphael Nabet definition.