Jump to content
IGNORED

Magellan


The Codex

Recommended Posts

Thanks buddy!! yea, with the output method Adam developed for storing screen data, it will take up 816 bytes per screen... Wonder if we could get that down? I need to try to get this whole game into 180k if I can, including all map data, game program(s) speech, etc. It may need to be a 2 disk game, but hopefully I can get it into 180k, standard for a DSSD diskette--- which would allow the vast majority of TI users to use it on their PEBs. Anyway, I'm working on some ideas. :)

 

Well, RLE compression may work... I'll explain it for you.

 

All data on the screen is, in fact, a linear array. A full screen is basically 768 bytes of data, from beginning to end, each byte representing a character on screen. All compression algorithms are essentially this: Find patterns to your data that allows you to define the data form in a smaller amount of space.

 

RLE means "Run-length encoding", and it's the simplest and easiest compression format to use. It works very well with a very small set of discrete data patterns (number of unique characters on your map), but breaks down if you have a lot of changes from pattern to pattern. My own maps for my CRPG, for example, are very jumbled with a lot of pattern differences, which makes RLE much less efficient.

 

Let me show you an example, one of your maps converted to raw color for simplicity. Note that with 28x18 characters, it takes up 504 bytes:

 

post-17978-127179329054_thumb.png

 

Okay, now how RLE would break this down is as follows:

Gray - 8

Black - 1

Gray - 7

Black - 3

Gray - 11

...

 

For RLE compression, you can either have a count/character pattern repeated, or you mix data and infrastructure using part of the byte to indicate a count value instead of an actual character. That lets you do singletons, like your keys and swords, without them taking up more dataspace than the actual character does.

 

On this map, doing a rough hand count, there are 178 pattern changes from top to bottom. So if you used a two-byte storage system with a count/byte structure, the map would take up 178x2 or 356 bytes, about a 30% compression rate. There are 63 singletons, so if you did the data/structure embedded format, that would make it 293 bytes, about a 42% compression rate. Note that on the TI disk system, sectors are 256 bytes long. So if you're looking to save disk space, you need to keep things below/above 256 byte increments. So for this map, either method takes up the same disk space.

 

The main problem with RLE is it works great when you have maps that have a lot of identical patterns running horizontally... do a map with a vertical style and suddenly it doesn't compress nearly so well. An area with a lot of singletons would also be a problem; the data embedded form at least guarantees that your map never takes up MORE space than uncompressed. Also, the time to decode the map from RLE would be some work... you could nearly use HCHAR to build the screen for you except that it self-corrects to the same ROW when over-flowing.

 

Adamantyr

Link to comment
Share on other sites

That's very helpful... However as this world changes and becomes more complex (see the Beryl thread) it might make RLE too much trouble... My original "Screen1" for Beryl was done without Magellan and LOADMAP/DRAWMAP, so I had to draw it all by hand. It's available for DL in the Beryl thread. Anyway, your RPG is looking fantastic... Thanks for the new blog update today!

Link to comment
Share on other sites

Good info Adam!

 

Another version of Magellan is out the gate. See the first post for download link and new feature list. The main highlights are multimap editing (at last) and the ability to export to assembler data. I hope the assembler output is okay Filip, I had to get creative with the 6-char labels for multimap data lines. Basically it supports unique labels up to 100 maps, each with up to 1000 lines. Hopefully that's enough on the TI. :)

 

Feedback welcome per usual, and thanks again everyone for continuing to help shape this tool!

Edited by The Codex
Link to comment
Share on other sites

Eh, I already realised I made some mistakes in the ASM export. I think the map line labels are actually one character too long. With regards to that, I'd like to ask if it's necessary to have labels for each line, or is it just enough to label the start of the whole map. I thought about adding a few more data variables so that your assembly program knows what to expect. Something like this:

 

MCOUNT  DATA  2     ; Map Count - there are 2 maps (#0 & #1)
* == Map #0 ==
MS0000  DATA  >2018 ; Map Size #0 - 32 x 24
* -- Row #0 --
MD0000  DATA  >1014, >1812, ... ; Map Data #0 - start of map data block
       DATA  >2412, ...
* -- Row #1 --
       DATA  >1413, ...
* == Map #1 ==
MS0001  DATA  >1818 ; Map Size #1 - 24 x 24
* -- Row #0 --
MD0001  DATA  >1014, >1812, ... ; Map Data #1 - start of map data block
       DATA  >1413, ...

 

This provides a variable for how many maps are in the data array, which can also be used to get the Map Size and Map Data label names since those are labelled sequentially. And since the Map Size tells you the total number of rows and columns, you can read the Map Data from a single label (I believe) into an array of that size. Then the Map Data labels become simple, and can support up to 10,000 maps. :ponder:

 

I also have some questions about the pattern data as it is saved. I used labels which contain the ID of the character for the pattern (ex. PAT135), but I realise now that this may be difficult to read in, since the program may not necessarily be aware of these label names in an interactive manner. So perhaps the pattern data should be two rows of data - an integer for the character value, followed by the byte list of the character data. Like so:

 

PCH001  DATA 135; Pattern CHar - the first pattern definition is for character 135
PAT001  DATA >FF81,>8181,>8181,>81FF ; PATtern - the character data for the first defined char (135)

 

I'm still coming to grips with the assembler data format, so please let me know if there are even better ways to do this and I'll get a quick fix of release 4 out which addresses the exporter.

 

Thanks!

Edited by The Codex
Link to comment
Share on other sites

You only need 1 label per set of data. If you are going to stick with TI's assembler for compatibility, then labels can only be 6 characters max and must start with a letter. Label "space" does not interfere with opcode "space", so a label *can* be anything as long as it is unique. This is legal, however I do not recommend it:

CMP  BYTE >00,>01
BYTE BYTE >02,>03
MOV  DATA CMP
DATA DATA BYTE,MOV

. . .

    LI R0,MOV
    MOV @MOV,@DATA
    CMP @CMP,@BYTE

 

Stuff like that would drive you nuts when you started working with the labels. Anyway, I digress. Labels can be 6 characters max. I usually have a start label, and then and end label with the same name but with an 'E' on the end:

MD001  DATA >0123,>4567,>89AB,>CDEF
      DATA . . . more data . . .
MD001E
MD002  DATA . . . next set . . .

 

Keep in mind that MD001E and MD002 are NOT necessarily the same address! In asm994a they are and it is a bug. In the real TI assembler they are not necessarily the same. If the data was defined with BYTE instead of DATA, the end address might be odd and would be assigned to MD001E, but the following DATA statement would be even. However, if the data is defined with BYTE, the addresses associated with the label will be whatever they are, odd or even. You have to be careful with asm994a though.

 

Also, you can use labels in DATA statements and the address of the label will be the final result:

MDREF1 DATA >1234   ; some reference label 1
MDREF2 DATA >4567   ; some reference label 2

. . .

MD001  DATA >ABCD,MDREF1,>0000

 

The MDREF1 will be replaced with whatever *address* is assigned to MDREF1 (not the data associated with the label.) Remember that addresses are 16-bit, which is the same size data you are defining with DATA. You can not include labels as parameters with the BYTE directive.

 

Thus, using the above example, you can make jump tables too, and save on the 'E' labels. You can have a table that has the start address of the data and the length:

MAPJMP DATA MD0001,503
      DATA MD0002,768
      DATA MD0003,10

MD0001 DATA . . . 503 bytes . . .
MD0002 DATA . . . 768 bytes . . .
MD0003 DATA . . . 10 bytes . . .

 

This way you only have to know the MAPJMP address and use an index into that jump table to get the start address of the data. The jump table size is known, i.e. 4 bytes (two 16-bit values), so indexing it is easy. I use something like this in the sound player to reference the sound data. If you are using the DATA directive and the data ends up odd, then you can pad with >00 values, since the length is known they will be ignored. You can also use the BYTE directive, just put EVEN before each MDxxxx label.

 

As for the character defs, no, the executing assembly program has no knowledge of the label names. Also, having the character byte designated would effectively waste a byte for every definition, since definitions are 8-bytes and fit on even boundaries, the extra "I'm defining this character" byte would make all the definitions odd. And, since you only need 1 byte to designate any of the 256 characters, I can't think of anything you would use another byte for to make the whole definition an even 10-bytes.

 

However, in assembly, you typically don't go around assigning individual characters like that, you want to do it in one (or a few) blocks and write all the patterns in one go. You would typically set up the VDP address of the pattern data, set a pointer to the patterns to be copied to VDP RAM, then loop through all the bytes. So, just set up the consecutive patterns in blocks. Anyone making patterns for assembly use should know to use consecutive patterns where possible. Otherwise, make a jump table and group consecutive patterns so they can be written as efficiently as possible. Something like:

PTNCNT 2           ; The number of entries in the PTNJMP table

; "set" address (1 "WORD"), start character (1 BYTE) number of characters defined (1 BYTE)
PTNJMP SET01,>411A ; Start character 65 (>41, ASCII 'A'), 26 (>1A) definitions
      SET02,>8080 ; Start character 128, 128 definitions

SET01  DATA >0180,>FFFF,>CD55,>1234,>9876
      DATA  . . . all 26 ASCII character . . .

SET02  DATA . . . character 128 to 255 . . .

 

In my assembly code I would use PTNCNT to know how many "sets" are in the jump table. I would read each entry in the table to get the start address of the pattern data, the start character (which lets me calculate the start address in VDP RAM), and the number of definitions to write.

 

Of course all this is only a few ways it could be done. I'm sure adamantyr, tursi, retroclouds and others will have suggestions as well. I Hope this helps.

 

Matthew

Edited by matthew180
Link to comment
Share on other sites

Holy crap!!! Great work man. The multimap thing is very cool... I haven't had time to really play with it much yet as far as looking through the export features, but am I correct in assuming that each map screen can be exported seperately? Or is it an "all-on-one" kinda deal? I was in Nashville all last night until 4:30 am this morning when I arrived home and I just had enough time to look at the multimap screen. Today is a big nasty day of work work work because I leave out for the road tomorrow morning at 7, and yard needs mowed and gear needs to be unpacked and repacked, etc. Can you program the next release of Magellan to mow my yard and do all the crap I don't want to do?

Link to comment
Share on other sites

am I correct in assuming that each map screen can be exported seperately? Or is it an "all-on-one" kinda deal?

 

The latter. But I could certainly add an "Export Current Map Only" checkbox to the export dialog if you are interested in saving maps as one-off files. Wouldn't be that much more work honestly.

 

Can you program the next release of Magellan to mow my yard and do all the crap I don't want to do?

 

I can do, but unfortunately that change requires support code that also makes Magellan drink all your beer, so not exactly a winning solution.

Link to comment
Share on other sites

Nice work. You apparently brought down the CPU consumption. There’s still that annoying flicker on the character editor. And the grid toggle should push an update.

 

I think an assembler game programmer often make use of the wider range of characters. That’s 32 sets opposed to the 16 currently available. And when it comes to sprites, an assembler programmer would probably also have the patterns for sprites elsewhere in memory. That would be no overlap between character patterns and sprite patterns. And that’s a 2K dedicated to sprites patterns.

 

:)

Link to comment
Share on other sites

If you are looking for the critical feedback, these are my thoughts when I use the app:

 

* The flicker in the character editor drives me crazy. There has to be a way to avoid that in Java, I would think...

 

* Drop-downs for the color selection is a bother, and they are so far away from where they are needed (up by the character editor). It would be nice to just have a palette row or column of the colors (like your typical graphics app) and a left click sets the foreground, right click sets the background.

 

* Having to select "drawing" or "erasing" gets in the way. Just toggle the pixels when the user clicks, i.e. if the pixel is off it turns on, if the pixel is on it turns off. If you click and drag, all the pixels you move over will turn on or off depending on what the first pixel did that you clicked on to start the dragging. Just like sometimes99er's flash editor: http://sometimes.99er.net/patterns.html

 

* The grid is too fat. A single pixel width would be nicer. Also, toggling the grid should be instant.

 

Other than that it is looking nice! Also, the stuff sometimes99er just mentioned is a requirement for total support of the 9918A's possibilities. The full 0-255 ASCII range is needed, all color sets, plus separate sprite pattern data, which is essentially another set of 255 characters (2K). Also note that sprite color data is not bound to a "color set". Each sprite has its own color code in the sprite attribute table.

 

Hmm, now that I think about it, it might make more sense to have the color sets shown and you assign the foreground and background colors to the sets instead of the individual characters in the pattern editor area. That way you could see what characters will be affected by the color change, since the characters are grouped by their sets.

 

Oh yeah, the assembly generation feedback... ;-) My nit-picky comments:

 

* Your first column width is 1 character too long. The DATA statements and such should start *on* the 8th character, i.e. 6 spaces for the optional label, one space, then the directive / opcode field starts.

 

* Drop the flower boxes and end of line semicolons. Personally the first thing I would do is delete them.

 

* If I maintain the map data via the editor, and regen the code when I make changes, then the comments delimiting the map's rows are unnecessary.

 

* Instead of having the length and character indicators, using a table driven solution would be better IMHO (as discussed above).

 

Oh, and is there an ASCII set that comes with it? I was clicking like crazy on the "A" character but the pattern never showed up in the editor or on the screen. I guess I don't get how you use the predefined characters, either as starting points for other characters, or to modify directly?

 

Matthew

Link to comment
Share on other sites

Feedback doesn't bother me, it only makes me stronger. So thanks for the comments! I'll address each in turn.

 

* The flicker in the character editor drives me crazy. There has to be a way to avoid that in Java, I would think...

 

There is, and I did it for the main map editor panel. I figured the character editor was too small and the flicker to minor to bother doing it there as well, but clearly it remains noticable on some systems. I'll fix it next.

 

* Drop-downs for the color selection is a bother, and they are so far away from where they are needed (up by the character editor). It would be nice to just have a palette row or column of the colors (like your typical graphics app) and a left click sets the foreground, right click sets the background.

 

Do you mean like a little grid of color boxes below the character editor, which when clicked set the colors for that character's set? I can give this a go if that's what you mean. If not, can you clarify?

 

* Having to select "drawing" or "erasing" gets in the way. Just toggle the pixels when the user clicks, i.e. if the pixel is off it turns on, if the pixel is on it turns off. If you click and drag, all the pixels you move over will turn on or off depending on what the first pixel did that you clicked on to start the dragging.

 

That's doable, I'll give it a try as well.

 

* The grid is too fat. A single pixel width would be nicer. Also, toggling the grid should be instant.

 

This is due to a trick I use to handle the magnifications. The map editor is a bitmap at the normal resolution and I simply scale the image (and the mouse input) to the desired resolution. This has the unfortunate side effect of scale the grid up as well, since it is drawn directly on that memory image. If I figure out a way to do it post facto then I should be able to make it render more pleasingly.

 

* Your first column width is 1 character too long. The DATA statements and such should start *on* the 8th character, i.e. 6 spaces for the optional label, one space, then the directive / opcode field starts.

 

Sorry, based in on the posted sample from Filip, didn't realise another space was unneeded. I can yank that out toot-sweet.

 

* Drop the flower boxes and end of line semicolons. Personally the first thing I would do is delete them.

 

Again, easy to revise. I can either make comments optional, or remove them entirely if no-one feels they'll use them. They were included in the example from Filip and I tend to annotate my data files as well, hence their initial inclusion.

 

* If I maintain the map data via the editor, and regen the code when I make changes, then the comments delimiting the map's rows are unnecessary.

 

Makes sense. Would be part of the changes mentioned in my reply above re: comments.

 

* Instead of having the length and character indicators, using a table driven solution would be better IMHO (as discussed above).

 

It does look good. Once I come to grips with it I'll see how it stacks up against other people's approaches and implement whatever most folks thing is the optimal solution.

 

Oh, and is there an ASCII set that comes with it? I was clicking like crazy on the "A" character but the pattern never showed up in the editor or on the screen. I guess I don't get how you use the predefined characters, either as starting points for other characters, or to modify directly?

 

Yep, load the "default.mag" file that comes with the distribution. It contains the complete default XB character set.

 

Thanks again!

Edited by The Codex
Link to comment
Share on other sites

Do you mean like a little grid of color boxes below the character editor, which when clicked set the colors for that character's set? I can give this a go if that's what you mean. If not, can you clarify?

 

Yup, that's what I mean. Having the colors and their names shown somewhere would be nice too, just for reference, but when editing the characters, just the color boxes in a palette close to the character editor would make the flow faster and more natural IMHO.

 

Also, my other thought was to group the characters in rows according to the set they are in (you might already be doing this), then having the colors (fg and bg) for the set shown to the right of each row of characters. Then you can quickly see what characters would be affected by changing the color. It would also help to quickly locate characters that can go in the same color set, etc. I'm not sure which would be better, but just some things to think about anyway.

 

Matthew

Link to comment
Share on other sites

Also, my other thought was to group the characters in rows according to the set they are in (you might already be doing this), then having the colors (fg and bg) for the set shown to the right of each row of characters.

 

Yes, they are grouped by set (there is also a small label to the left of each row with their set number from the Extended BASIC manual). Currently I change the character selector buttons directly with the foreground and background color choices, the primary deviation being that "transparent" is difficult to display so that is rendered as a pale blue instead. Since all buttons start out undefined and with transparent backgrounds, it's easy to overlook the set coloration at first.

 

I'll give that clickable color dock idea a go, sounds like it might be a definite improvement.

Link to comment
Share on other sites

ok, I took the assembler export output of citymerg.mag and was able to make it work in editor/assembler after tweaking it a bit.

I used the winasm99 cross-assembler and did the testing with the classic99 emulator.

 

For testing you can just drop the MAGELLAN.obj file in your classic99 DSK1 folder and load it using EA#3.

**WARNING** This is not an actual player. It's merely a dumb assembler program for testing the export functionality.

 

magellan_asm.zip

 

I made some adjustments that I'll try to explain below.

 

Before we get into the details; Here is how I did the VDP setup for graphics screen mode 1.

 

***************************************************************
* VDP graphics mode 1 
********@*****@*********************@**************************
* VDP#0 Control bits
*       bit 6=0: M3 | Graphics 1 mode
*       bit 7=0: Disable external VDP input
* VDP#1 Control bits
*       bit 0=1: 16K selection
*       bit 1=1: Enable display
*       bit 2=1: Enable VDP interrupt
*       bit 3=0: M1 \ Graphics 1 mode
*       bit 4=0: M2 /
*       bit 5=0: reserved
*       bit 6=1: 16x16 sprites
*       bit 7=0: Sprite magnification (1x)
*
* VDP#2 PNT (Pattern name table)       at >0000  (>00 * >400)
* VDP#3 PCT (Pattern color table)      at >0380  (>0E * >040)
* VDP#4 PDT (Pattern descriptor table) at >0800  (>01 * >800)
* VDP#5 SAT (sprite attribute list)    at >0300  (>06 * >080)
* VDP#6 SPT (Sprite pattern table)     at >0400  (>80 * >008)
* VDP#7 Set background color to gray
***************************************************************
VMODE1  DATA  >0000,>01E2,>0200,>030E,>0401,>0506,>0680,>070E

 

 

Color definitions

* In assembler you only need 1 byte for setting both the foreground and background color of a color set.

* Also the colors start with base 0 instead of 1

* This is my colorset statement. Note that I used BYTE instead of DATA here.

 

CLRSET  BYTE >10,>10,>10,>10,>10,>10,>10,>10,>00,>BA,>3C,>45,>61,>10

 

 

Patterns

* I did a raw dump to the VDP in a continious block. This means I first stripped the character code and inserted some empty patterns in the assembly source. Actually the idea of having the character code in front of the pattern code isn't bad. However it would be best to make this optional and go for a table driven solution as suggested by Matthew.

 

 

Map data

* I noticed that even though there are 3 screens, it repeatedly exports the same screen.

 

 

Anyway, great job Howard! :thumbsup: :thumbsup: :thumbsup:

Edited by retroclouds
Link to comment
Share on other sites

If you are interested you also might want to checkout the TECH MANUALS section in the development resources sticky thread.

Look for the "VDP Programmer's guide" for further details on the VDP.

 

The thing is that the tables in VDP memory which are responsible for holding characters definitions, colors and tiles, sprites etc.

are controlled by a bunch of VDP registers. In assembler these tables pretty much can be located according to the programmers' needs.

Now in Basic and Extended Basic there are a lot more constraints as far as the size and location of the tables is concerned.

 

And I have to mention it again, after having played with Mangellan a bit, this is a mighty fine tool ;)

Edited by retroclouds
Link to comment
Share on other sites

Hey you other TMS9900 assembly language programmers out there :)

 

What format would you guys propose ? For starters my proposal would be to go for a basic export format. Something not too complicated nor optimized.

This would keep both the Magellan exporter and the assembly player code easy (as long as no final format has been established).

That is why I also requested the possibility to export color/map/pattern data as a raw binary file.

That way if a developer sees a need, he can write his own converter for his specific needs.

 

Any thoughts on that ?

Edited by retroclouds
Link to comment
Share on other sites

I know that for me--- the LOADMAP/SAVEMAP converter that Adam built and that I have modified is going to be very specific to my needs when it's done... I am keeping a pretty basic version of it for others to modify for their needs--- essentially the one Adam built but with a couple of mods that make it more compliant with the actual format Magellan uses to export the XB code. The one I'm working up sets an automated label for the world you're working on--- you input your world name ("Forest") and it will generate the DSK files in order and sets up the "loader" for your XB program. Pretty cool stuff. Codex and Adamantyr have opened my eyes to some cool stuff. So, the reason I say all this, a cookie cutter converter wouldn't work for me... Retroclouds's idea of building a custom converter is great.... Of course a very general converter that's available as a starting point is a good idea. :)

Link to comment
Share on other sites

It would be nice if we could share the same character patterns (and sprite patterns) across utilities.

 

Simply making them an image file (gif and maybe png), 64 pixels wide, 256 pixels high (that’s 8 characters wide and 32 sets high = 256 characters). And of course 16 colors. Would be nice if we could stick with the MAME palette.

 

Grapefruit changes everything to black and white, so it’s not compatible with the above. Yet.

 

CartographPC TI-99 Edition needs the input to be resized (pixel magnification by a factor of two). It doesn’t care about any use of colors, as it’s a screen designer/mapper only.

 

Magellan could support it and for now just chop off and add empty characters. It’s a matter of adding two new menu items ... something like “load” and “save character patterns as image”.

 

If I released a screen designer(/mapper) it will of course support it. I’ve mostly been experimenting with different programming languages, design, user interface and features. It’s not high on my list as I think Magellan is going in “my” direction. Nice.

 

Anyways. The real benefit for me would be creating graphics for the TI using the big and heavy graphic artillery like PhotoShop. Maybe this explains ...

 

0013chr.gif

 

:cool:

Link to comment
Share on other sites

Classic99 already has a few ways of ”ripping” graphics. You can take a screenshot (Video menu). You can see the current character set by pressing F9 (Scroll Lock on). Or you can do a VDP memory dump from the Debugger. Here’s a demo of the F9 effect (set repeated on screen) ...

 

classicchr.gif

 

Maybe this could be the basis of a converter utility or a format with 256 pixels in width and 64 in height. Loader(s) could just ignore the bottom 128 pixels generated by a Classic99 screenshot. Even better (my opinion) Classic99 could save character and sprite patterns in the 64 wide 256 high format proposed earlier.

 

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.

 

And I guess Magellan could create some RAW/RLE file output to fit Forth before I could even think of it.

 

:cool:

Link to comment
Share on other sites

Good thinking on the image dumps! I agree, the 64x256 format sounds ideal, and would very easy to output from Magellan. Support for loading a 1-bit bitmap would be doable as well, converting it back into char images. (If I ever get around to adding the sprite editor, that could do the same, or even take a second image for loading into higher RAM.)

 

PNG gets my vote for the initial format, and RAW/BMP/RLE wouldn't be a problem to support either. PNG is handled natively in Java and I've written a number of image encoder/decoded filters and utilities already, including the one for ToD that rips the graphics out of the original TI files. :)

 

This is going onto the list for the next version. Thanks!

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