255 replies to this topic

[Opry99er]

First three screens...



of course this is all subject to change and will probably be changed several times--- I'm just having a bit of fun.

Edited by Opry99er, Wed Apr 14, 2010 7:40 AM.

[sometimes99er]

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.

[Opry99er]

Yea man... That little routine I wrote is slow as molasses in January, but it will draw the screen... Need to change the HCHAR(y,x,CHA) to a DISPLAY AT(y,x):CHR$(CHA); make it a bit faster I think...

[Opry99er]

These screens are VERY simplified right now. I haven't implemented the visible enemies yet, the ruins, watchowers, etc.. These are just ideas and pretty plain ones at that.

[Opry99er]

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



Again--- These are just mockups

[Opry99er]

This is the layout... You enter through #1 and exit at #4... Levels 2,5 and 6 will contain items you need and quest items as well. You will HAVE to enter and clear each screen to exit through the purple door into the mountains. =)

[The Codex]

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? )

[sometimes99er]

Been playing Dungeon Siege for too long ...

Edited by sometimes99er, Thu Apr 15, 2010 12:46 PM.

[Kurt_Woloch]

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

sometimes99er, on Wed Apr 14, 2010 3:39 AM, said:

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

[sometimes99er]

Kurt_Woloch, on Wed Apr 14, 2010 9:56 AM, said:

Wait a minute! There must be something wrong with this memory map...

Yep, something's not right there. It's taken from something called "Extended Basic Assembly Programmers Guide".

[The Codex]

Updated, please grab latest version from first post in this thread. Feedback welcome as always!

[Opry99er]

Will grab tonight!!!! Thanks!!

[retroclouds]

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)

[The Codex]

retroclouds, on Thu Apr 15, 2010 4:46 AM, said:

* 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!

[Opry99er]

Great stuff!!!!!! BTW Codex, I have that draw routine Adam wrote... It's a bit quicker too. It can be adapted to pull straight from data statements instead of from diskette.

[The Codex]

Definitely man, post any kind of "code wrapper" that you think would make a useful export!

[Opry99er]

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.

Attached Files

•  DSK1.zip   1.32K   3 downloads

Edited by Opry99er, Thu Apr 15, 2010 1:03 PM.

[Opry99er]

The nice thing about this is you can just paste the map data into the first program and run it--- it's just a utility. The "binary" it kicks out is the only thing you need to include with the diskette.

[Opry99er]

The INTERNAL format for the MAP DATA in TI99Dir

Edited by Opry99er, Thu Apr 15, 2010 1:17 PM.

[Opry99er]

Can you tell which screen image this is, based on the picture and diagram up above? (Posts 30 and 31)

[adamantyr]

Opry99er, on Thu Apr 15, 2010 1:16 PM, said:

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

[Opry99er]

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.

[Tursi]

adamantyr, on Thu Apr 15, 2010 1:25 PM, said:

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

[The Codex]

Swank, data sources to look at. I like that. Should be able to get DSK map exports going in the next Magellan without too much trouble. Thanks Owen!

[Opry99er]

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

Edited by Opry99er, Fri Apr 16, 2010 1:14 PM.