Jump to content

Photo

Magellan


494 replies to this topic

#26 Opry99er OFFLINE  

Opry99er

    Quadrunner

  • 8,246 posts
  • Location:Cookeville, TN

Posted Wed Apr 14, 2010 7:25 AM

First three screens...

Posted Image

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.


#27 sometimes99er OFFLINE  

sometimes99er

    River Patroller

  • 3,868 posts
  • Location:Denmark

Posted Wed Apr 14, 2010 7:52 AM

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:

#28 Opry99er OFFLINE  

Opry99er

    Quadrunner

  • 8,246 posts
  • Location:Cookeville, TN

Posted Wed Apr 14, 2010 7:59 AM

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

#29 Opry99er OFFLINE  

Opry99er

    Quadrunner

  • 8,246 posts
  • Location:Cookeville, TN

Posted Wed Apr 14, 2010 8:18 AM

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

#30 Opry99er OFFLINE  

Opry99er

    Quadrunner

  • 8,246 posts
  • Location:Cookeville, TN

Posted Wed Apr 14, 2010 9:07 AM

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

Posted Image

Again--- These are just mockups

#31 Opry99er OFFLINE  

Opry99er

    Quadrunner

  • 8,246 posts
  • Location:Cookeville, TN

Posted Wed Apr 14, 2010 9:25 AM

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





Posted Image

#32 The Codex OFFLINE  

The Codex

    Dragonstomper

  • Topic Starter
  • 573 posts
  • Location:Richmond, VA

Posted Wed Apr 14, 2010 9:28 AM

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

#33 sometimes99er OFFLINE  

sometimes99er

    River Patroller

  • 3,868 posts
  • Location:Denmark

Posted Wed Apr 14, 2010 9:36 AM

Been playing Dungeon Siege for too long ...

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


#34 Kurt_Woloch OFFLINE  

Kurt_Woloch

    Stargunner

  • 1,205 posts

Posted Wed Apr 14, 2010 9:56 AM

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:

Posted Image



#35 sometimes99er OFFLINE  

sometimes99er

    River Patroller

  • 3,868 posts
  • Location:Denmark

Posted Wed Apr 14, 2010 2:32 PM

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

:|

#36 The Codex OFFLINE  

The Codex

    Dragonstomper

  • Topic Starter
  • 573 posts
  • Location:Richmond, VA

Posted Wed Apr 14, 2010 8:19 PM

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

#37 Opry99er OFFLINE  

Opry99er

    Quadrunner

  • 8,246 posts
  • Location:Cookeville, TN

Posted Wed Apr 14, 2010 8:22 PM

Will grab tonight!!!! Thanks!!

#38 retroclouds ONLINE  

retroclouds

    Stargunner

  • 1,530 posts
  • Location:Germany

Posted Thu Apr 15, 2010 4:46 AM

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)

#39 The Codex OFFLINE  

The Codex

    Dragonstomper

  • Topic Starter
  • 573 posts
  • Location:Richmond, VA

Posted Thu Apr 15, 2010 7:41 AM

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

#40 Opry99er OFFLINE  

Opry99er

    Quadrunner

  • 8,246 posts
  • Location:Cookeville, TN

Posted Thu Apr 15, 2010 9:20 AM

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

#41 The Codex OFFLINE  

The Codex

    Dragonstomper

  • Topic Starter
  • 573 posts
  • Location:Richmond, VA

Posted Thu Apr 15, 2010 12:03 PM

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

#42 Opry99er OFFLINE  

Opry99er

    Quadrunner

  • 8,246 posts
  • Location:Cookeville, TN

Posted Thu Apr 15, 2010 1:02 PM

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

  • Attached File  DSK1.zip   1.32KB   10 downloads

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


#43 Opry99er OFFLINE  

Opry99er

    Quadrunner

  • 8,246 posts
  • Location:Cookeville, TN

Posted Thu Apr 15, 2010 1:10 PM

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

#44 Opry99er OFFLINE  

Opry99er

    Quadrunner

  • 8,246 posts
  • Location:Cookeville, TN

Posted Thu Apr 15, 2010 1:16 PM

Posted Image


The INTERNAL format for the MAP DATA in TI99Dir

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


#45 Opry99er OFFLINE  

Opry99er

    Quadrunner

  • 8,246 posts
  • Location:Cookeville, TN

Posted Thu Apr 15, 2010 1:18 PM

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

#46 adamantyr OFFLINE  

adamantyr

    Stargunner

  • 1,129 posts

Posted Thu Apr 15, 2010 1:25 PM

Posted Image

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

#47 Opry99er OFFLINE  

Opry99er

    Quadrunner

  • 8,246 posts
  • Location:Cookeville, TN

Posted Thu Apr 15, 2010 4:22 PM

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

#48 Tursi OFFLINE  

Tursi

    River Patroller

  • 4,716 posts
  • Location:BUR

Posted Fri Apr 16, 2010 2:07 AM

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

#49 The Codex OFFLINE  

The Codex

    Dragonstomper

  • Topic Starter
  • 573 posts
  • Location:Richmond, VA

Posted Fri Apr 16, 2010 6:28 AM

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!

#50 Opry99er OFFLINE  

Opry99er

    Quadrunner

  • 8,246 posts
  • Location:Cookeville, TN

Posted Fri Apr 16, 2010 1:12 PM

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, Fri Apr 16, 2010 1:14 PM.





0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users