Jump to content
IGNORED

Magellan


The Codex

Recommended Posts

Nice.

 

These maps consist of not too many different characters and large areas are of the same character. I can’t help thinking RLE (1) and HCHAR (2).

 

1)

Implementing RLE (Run Length Encoding = simple compression) could reduce the size of screens and overall executing time. Both loading and drawing might very well be quicker with pure XB. We’re probably not going to see any real speed change with pure Assembler, but still size matters.

 

2)

If the mapper could analyze a screen and produce somewhat optimized XB FOR NEXT, HCHAR and VCHAR, then a screen would take up less room and less time to draw.

 

:cool:

Link to comment
Share on other sites

Okay, here's the 4 screens--- have 2 more for this world and I think that's all I'll be able to fit in there. If my knowledge of "size" in XB is right, without significant in-game DSK access, I won't be able to fit anymore in here. 6 screens a world... Just have to make them difficult and fun. =)

 

4pages.jpg

 

Again--- These are just mockups

Link to comment
Share on other sites

Righteously cool stuff, man. And I'm using your DISPLAY AT(y,x):CHR$(CHA); idea in the next draft to make the screen dumping quicker. I'll have a new version ready tonight, though it still might be a CPU hog this time around. (Hey, like you'd be using anything else anyway? ;) )

Link to comment
Share on other sites

Wait a minute! There must be something wrong with this memory map... according to it, the screen (pattern name table) goes from >0000 to >0200, which would be 512 bytes. But the screen is 32 columns x 24 lines = 768 bytes, so it would have to take up more than that. On the other hand, the sprite attribute table only should contain 4 bytes per sprite (x, y, pattern and color), so 4x32 = 128, but it takes up 256 bytes in your memory map (from >0200 to >0300).

 

Almost anything is possible.

 

The XB layout in VDP should be as follows. The space for character patterns are >400 thru >780. The sprite motion table can’t be relocated (I believe it’s hardcoded in the ISR/kernel). But if you wouldn’t use auto sprite motion etc.

 

>780 - >400 = >380 bytes

>380 / 8 = >70 characters

>70 / 8 = >E = 14 sets

 

:cool:

 

xbvdp.png

Link to comment
Share on other sites

Played around with Magellan during my lunchbreak, and it looks very promising. Well done!

 

For Tutankham I'm thinking of doing some additional levels. Perhaps even make a little contest out of it

where folks can submit a screen and the best ones get included. I was thinking of building a map editor myself,

but after seeing Magellan ... :-)

 

Here are some more ideas:

* It would be nice if you could toggle a mode where you don't set a character tile in the map.

Instead if you move over a grid cell it could highlight the matching character in the charset and show its pattern.

 

* Possibility to have multiple screens in memory where you can jump from one screen into the next one.

* Possibility to set number of columns/rows on a per screen basis.

* Example: Screen 1 = screen of 22 rows with 60 columnsm, screen of 22 rows with 100 columns, ...

 

* I know that adding more and more features can easily make a tool unusable for novice users, perhaps a menu

level "novice" or "pro" could then be set for hiding the more advanced features.

* Would be cool if you could "import" screen data into Magellan, e.g. raw VDP dump.

Guess that the map file format is not yet finalized, would you mind sharing details how it is setup ?

* Export functions for assembly language usage (I'd love to do something for SPECTRA)

Link to comment
Share on other sites

* It would be nice if you could toggle a mode where you don't set a character tile in the map.

Instead if you move over a grid cell it could highlight the matching character in the charset and show its pattern.

 

* Possibility to have multiple screens in memory where you can jump from one screen into the next one.

* Possibility to set number of columns/rows on a per screen basis.

* Example: Screen 1 = screen of 22 rows with 60 columnsm, screen of 22 rows with 100 columns, ...

 

* I know that adding more and more features can easily make a tool unusable for novice users, perhaps a menu

level "novice" or "pro" could then be set for hiding the more advanced features.

* Would be cool if you could "import" screen data into Magellan, e.g. raw VDP dump.

Guess that the map file format is not yet finalized, would you mind sharing details how it is setup ?

* Export functions for assembly language usage (I'd love to do something for SPECTRA)

 

Great suggestions Filip! I'll respond to each in kind.

 

  • Character Selector - I like that, I'll put it into the next release. Probably with a hand or spyglass kind of icon, unless anyone has a better suggestion for a "get this character" visual mnemonic.
  • Multimap - This one is on the cards. I wanted to get the basic app done and get everyone's feedback on the general functionality. Now that it's done in a large part, I can continue with the idea of adding a "map navigation" component that lets you flip through maps. In all likelyhood it will only support one character set for all the maps, which works for games like Beryl and possibly Tut, but it would mean loading separate .mag files when you want to change character set.
  • Variable Map Size - Another one I hope to implement sooner rather than later. For maps above the standard screen size I'll definitely need to get a scrolling canvas working, so this will probably come after the above changes.
  • Standard vs Advanced Mode - I like this too, provided I add enough features to warrant the difference. For now the only change that seems like it might belong in Advanced Mode would be the variable map sizes. But as the app grows there may indeed come a need for presenting two levels of complexity.
  • Import - I'm game to give it a try if someone can post a source file as an example. I can reverse engineer that into a readable format within Magellan if so.
  • New Exports - Definitely desirable. Again, if I can be given an example of the kind of output wanted, I can code up a export routine for it. In fact, I may eventually add an optional menu that supports a number of "native" exports - Export To Beryl, Export To SPECTRA, etc - that could be expanded to support any project that wants to use Magellan as a dedicated editor.

 

Thanks again for the very useful suggestions, I'm looking forward to coding them in! :thumbsup:

Link to comment
Share on other sites

OKay... the first program is called "DRAWTEST2". You must run this program to load the DATA onto DSK1. The second program (DRAWSCRN2) pulls the DATA from diskette, defines the characters, and colors the sets. It essentially splits the Magellan output "in half" or into two programs--- the first operates on the MAP DATA, the second program operates on the colors and character definitions. Run the first and it will create a new file in DSK1. Run the second, and it draws the screen. pretty quickly, no less. Combine these two programs and modify to create a new Magellan output if you wish. =) Thanks Adam!!!!

 

BTW, the color outputs had to be modified to work in this method, and I changed Adam's character draw routine to match your original one in the Magellan Output. Hope you enjoy... this was fun to do.

DSK1.zip

Edited by Opry99er
Link to comment
Share on other sites

scrnbin.jpg

 

The INTERNAL format for the MAP DATA in TI99Dir

 

Yeah, INTERNAL is the best option for what you're doing. I tried using DISPLAY, but it auto-truncates to 28 characters in BASIC. And it won't permit characters above 127 either, I think.

 

If you do a hex-edit on the binary file created, you'll note that each line is actually 34 characters or bytes. That's because the internal format is using a two-byte header on each line. It's been awhile since I worked with files in BASIC, but I think one is a length byte and the other is a type byte. (numeric or string) It could be worse; numeric variables in BASIC are always Radix 100 floating point numbers, so they take up 8 bytes apiece. If I was going to revise TI BASIC at all, I'd add an integer type so you could ditch FP entirely. (Writing all the type-casting tools would be a pain, though.)

 

In assembly, you have absolute control. Using FIXED determines record size, so you just put what you want into a buffer in VDP and write it out or read it in. That makes it much more efficient, since you can define your own file data structures. The memory-image of the screen is really simple, just a straight 768 bytes that's dropped right into the screen memory.

 

Adamantyr

Link to comment
Share on other sites

We could even mod this further to replace the name of the internal file that is created would take the name of the .mag file... Have Magellan kick out a ::

 

10000 DATA "FOREST1"

 

or

 

10000 DATA "FOREST2"

 

Then read that in the first program in place of what's there now. Or you could just do it by hand... Takes 3 seconds. I just like automation. :)

Link to comment
Share on other sites

Yeah, INTERNAL is the best option for what you're doing. I tried using DISPLAY, but it auto-truncates to 28 characters in BASIC. And it won't permit characters above 127 either, I think.

 

Is this actually true? I've always been under the impression it doesn't actually do anything but set a flag... have you tested that?

 

Damn it, I have too many things to test... ;)

Link to comment
Share on other sites

Okay Codex--- got an idea... You can choose to implement or not--- is there a way to standardize the DATA line numbers? For instance, in the current output, each section of DATA follows the previous one--- therefore if you have more character deinitions, the MAP DATA lines move down to accomodate the other data... I.e. 9210 can become 9220 if there's additional DATA lines preceding the MAP DATA. Maybe we could do like:

9100- Chatacter def DATA

9300- MAP DATA

10000- Color DATA

 

the reason is to allow for LOADMAP/DRAWMAP to be a static program without having to check for line numbers and reprogram it.

 

Additionally, is there a way you could add another unrelated line of DATA that changes the format for CALL COLOR to be just a DATA line of 28 numbers separated by commas? no character sets, just foreground/background color codes. This would also make import into LOADMAP/DRAWMAP easier... Just a thought. :) Thanks again for Magellan. It has a desktop shortcut on my PC now. :) LOVE IT :lust:

Edited by Opry99er
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...