The Legend of Beryl Reichardt

[matthew180]

This looks really nice, I hope to be able to try it out soon! Personally I'd really like to see support for Graphics Mode II as well, also, Graphics Mode I.V (1.5, a.k.a. half bitmap mode.)

 

Matthew

[sometimes99er]

This one could work as a template. Loads fine with Cart99.

 

 

 

Here's the above as gif and normal size. Well, you have to click them to see the difference (just size).

 

 

 

Remember is has to be resized to 200 percent and saved as bmp format for Cart99 to eat it.

 

I'm using this palette with the above (and my paint program). The extra black (transparent) is made dark gray (for grid use and indication of undefined characters).

 

 

 

[sometimes99er]

Karsten, I totally skipped over one of your questions earlier. My intended use for this program is to be able to design entire world maps for my CRPG and then ...

Ok, I been following the different threads loosely, but was unsure of your limitations. I guess you will be going for XB with assembler support instead of pure assembler. XB would have indicated less characters (112 versus 256), but now Cart99 is handling both anyway.

 

160 x 120 characters, that’s almost 19K. And potential deliciously detailed.

 

An assembler routine for taking out a rectangle of the map and displaying it, is pretty easy assuming the map is located continuously and uncompressed in EXP RAM. So after loading all your stuff, you could have a command like this ...

 

CALL LINK(“MAP”,X,Y)

 

If we assume full screen display (32x24 chars), then X should be between 0 and 127 (160-32) and Y should be between 0 and 95 (120-24). You could walk the map one character at a time. Execution time should be less than 2/60th of a sec.

 

[sometimes99er]

 

 

Hehe, that’s indeed very nice.

 

I thought about how to auto or manually update the different parts. Should altering one character reflect changes instantly in the characters and map/screen. I might swap my pieces around, so the flow is from left to right, having the one character editor, then all the characters and colors, and finally the map. I like the idea of auto update, but performance might not be too good. Maybe only updating the map when the mouse button is released - shouldn’t that leave a gap in the user editing. Maybe a manual update arrow from characters to map.

 

I think you will leave selection of color by name behind one of these days, but again I have to try out your tool before putting it this part down ...

[sometimes99er]

This looks really nice, I hope to be able to try it out soon! Personally I'd really like to see support for Graphics Mode II as well, also, Graphics Mode I.V (1.5, a.k.a. half bitmap mode.)

 

Matthew

Hmm, support for Graphics Mode II (bitmap mode) in a map editor, would mean 256 dedicated characters for the top part, 256 for the middle part and yet another 256 for the bottom part !? Are you sure this is something you want ? It would be impossible to traverse vertically ?

 

The most popular hybrid bitmap mode (half bitmap mode), should be the one with 256 characters available anywhere on screen. And it’s already supported by Cart99.

 

[Opry99er]

Karsten--- 2/60th of a second? Now we're talkin!!! The screen for the map, during exploration, will be decidedly smaller than 32x24... Probably 20x20 or so. . If I could have this thing operational as a scroller, that would shift the whole focus of my map design!!! Looking forward to hearing more.

[Opry99er]

Question from Cart99 guys::

 

<<snip>>

Hiya all

Thanks for the good praise it was easy to adapt the CartPC to use the TI-99 char set I just needed to know the dimensions which pretty much is the opposite of the co64 so instead of the charset sitting on its side 32x8  I switch math around to use 8x32 thats all it was. Yes Eventually I will have a charset editor for the pc version to work with C64 charset that is one of my goals always nice to have one program to do everything in.

Well anyways I have updated the zip file to fix issue in the export feature since the editor by default uses a WORKSPACE of 255x127 always untill you export then you have the correct dimensions in one file.

http://www.arkanixlabs.com/downloads/Ca … dition.zip

One more question though on the commodore side any file from c64 to pc looks like the first 2 Hex bytes are 00 50 does the ti-99 do something similar

? this way I can writeback what it might be looking for.. 

 

Later all

Warlock

<<snip>>

[sometimes99er]

Karsten--- 2/60th of a second? Now we're talkin!!! The screen for the map, during exploration, will be decidedly smaller than 32x24... Probably 20x20 or so. . If I could have this thing operational as a scroller, that would shift the whole focus of my map design!!! Looking forward to hearing more.

Yeah, sure, only my best educated guess. I have done virtually no Assembler for XB, so for this, the educational angle and the fact that my English stinks (Im not the one to do novels), I would hope that Matthew would like to step in and make a series about XB, Assembler and mapping while helping you out !?

 

 

Edit: Ok, I'll write a novel, but it will be in Danish !

Edited March 31, 2010 by sometimes99er

[Opry99er]

I had originally planned to go screen segment by screen segment... Not using scrolling. That would make this thing possible for even lil ol' me to work with. . But your ideas for scrolling the mother... Very groovy. We'll talk more soon--- busy day today, but I'll be popping in as we go. Cheers!

[matthew180]

An assembler routine for taking out a rectangle of the map and displaying it, is pretty easy assuming the map is located continuously and uncompressed in EXP RAM. So after loading all your stuff, you could have a command like this ...

 

CALL LINK(“MAP”,X,Y)

 

If we assume full screen display (32x24 chars), then X should be between 0 and 127 (160-32) and Y should be between 0 and 95 (120-24). You could walk the map one character at a time. Execution time should be less than 2/60th of a sec.

 

 

There's the trick, now isn't it. The problem is, with XB you don't get to use any memory reliably except the lower 8K. The map data could be stored as strings to get XB to "properly" allocate the memory, however accessing that data from assembly is not straight forward, but it can be done.

 

Now, the map data could be stored in the lower 8K. It breaks down like this:

 

8K == 8192 bytes starting at address >2000.

 

CALL INIT chews up >600 bytes from >2000 to >25FF so that leaves 6656 bytes, or just over 6K.

 

CALL LOAD builds the REF table backwards from >3FFF and requires 8 bytes per "function", i.e. anything you can call with CALL LINK. So let's assume we will keep room for 4 assembly routines in the REF table, so that is another 32 bytes.

 

Thus, 8192 - 1536 - 32 = 6624 bytes for map data and the support routines.

 

A 80x60 character map would take 6000 bytes and leave 624 bytes for the draw routine. That could probably be done, but not much else. I don't know if the map data could be swapped out since it would have to be done via another assembly routine in that 624 bytes, and I have never done disk access in assembly.

 

Anyway, that is about the largest "resident" map I can perceive and still have room for the routines. Of course this also means giving up the sound player... Owen? Which do you want, sound or a large scrollable map? Don't these choices suck! :-)

 

Also, using some sort of compression would be recommended, like building the maps from "strips" as Tursi described over on one of the Y! forums, but I don't have time to design that. I'll implement it though, if someone does the ground work of coming up with exactly how it works.

 

Matthew

[matthew180]

Karsten--- 2/60th of a second? Now we're talkin!!! The screen for the map, during exploration, will be decidedly smaller than 32x24... Probably 20x20 or so. . If I could have this thing operational as a scroller, that would shift the whole focus of my map design!!! Looking forward to hearing more.

Yeah, sure, only my best educated guess. I have done virtually no Assembler for XB, so for this, the educational angle and the fact that my English stinks (I’m not the one to do novels), I would hope that Matthew would like to step in and make a series about XB, Assembler and mapping while helping you out !?

 

 

Edit: Ok, I'll write a novel, but it will be in Danish !

 

I didn't notice any language issue... I certainly would not have known you were Danish! Let's just put it this way, your English is better than anyone's Danish on this forum, and I'm grateful that you took the time to learn English so we all benefit from your sacrifice. :-) Oops, getting a little religious here, better get back on topic!

 

As for helping Owen with an assembly supported scrolling map, he has not asked for any help on that yet...

 

Matthew

[Opry99er]

I'll keep the music and forfeit the scrolling. =) I can just use my previous concept of going map segment by map segment. That way, it won't be totally necessary to have the entire world map in memory at once. The segments can be called up from diskette as required. If the map segments are done via assembly, the draws won't take any time, really. This way, I have my music, I have the proper sized map, and still have plenty of room for user interface. =) Yes, the choices suck, but there's no real "choice" here. Music is absolutely necessary while scrolling (while super cool and very nice) is not... for this game. =) Thanks for the info Matthew... very informative!!!

[matthew180]

Hmm, support for Graphics Mode II (bitmap mode) in a map editor, would mean 256 dedicated characters for the top part, 256 for the middle part and yet another 256 for the bottom part !? Are you sure this is something you want ? It would be impossible to traverse vertically ?

 

The most popular hybrid bitmap mode (half bitmap mode), should be the one with 256 characters available anywhere on screen. And it’s already supported by Cart99.

 

 

It is not so much the unique characters as it is the ability to color each 1x8 row of each character. The extra color can make all the difference and with half-bitmap you get the speed of Graphics I. Although, XB can't use the Graphics II mode due to the way it uses VDP RAM. But I would like an editor, character or otherwise, that supports the 1x8 color ability.

 

Matthew

[The Codex]

Thanks to feedback from Karsten and everyone, I think I've got the interface streamlined to a pretty usable form. All the tools are in one place and appropriately sized, plus I've added in the Set Char function and the ability to fill the map area with any selected character.

 

Still have to work out the save/load code and get transparency working properly, but I'm quite happy with how it's coming together.

 

[Opry99er]

Awesome work Codex!!! Can't wait to see 'er in action!

 

 

BTW, I've been playing with this Cart99 program... It's very cool, but no character editor really handicaps it. I can't make my Paint program do anything I want. I can't make it do anything, really. It's just a piece of crap.... In my hands anyway. I'm sure its just user error... but I'm anxiously awaiting your program... It'll make my life so much easier. =) You rock man.

Edited March 31, 2010 by Opry99er

[The Codex]

Swank, just about done. Got transparency working properly and the save/load/export code is good. The app is a bit flickery, but otherwise stable and should be available for testing later this evening.

 

 

PS - I heeded the call for better color selectors, so the ones in the character editor now display the actual colors as the background for the color name. You'll see what I mean when the code is posted.

Edited March 31, 2010 by The Codex

[Opry99er]

Very exciting, brother... Can't wait to see what you've baked up here. Such cool stuff going on. Your map editor looks like the kicker of 'em all!!!

[The Codex]

Alright, here's the first draft of Magellan. It's Java based and requires that Java 1.5 or higher be installed, which is already the case for most computers. Windows users can download the Magellan-EXE.zip file, which uses an executable wrapper to launch Magellan. Otherwise you can download Magellan-JAR.zip, which has a JAR file and a simple shell script to start it.

 

No documentation yet, some of the functions should be obvious, and please ask questions about the rest.

 

Please note that in the interface, the "transparent" TI color is indicated by a pale blue in the editors. This is truly transparent on the main map panel and the map image should look much as it does on the TI. Also, the "Magnification" dropdown lets you expand the map editor so that you can see the image better, but at some resolutions the higher magnifications will lead to the image bleeding off the edge of the screen.

 

Let me know what you think, and there are still some enhancements coming, plus proper docs once the finished version is done.

 

Windows: Magellan-EXE.zip

 

All Systems: Magellan-JAR.zip

[Opry99er]

I'll be DLing this in just a few minutes!!! Thank you very much my friend.

[Opry99er]

Codex, you son of a b****!!! How cool is this thing??? The "Export to XB" is superb!!! I'm truly taken aback at how quickly you accomplished this! I'm still trying to make the map "size" bigger, 160x120... Perhaps that feature is not yet in this BETA version? Anyway, I've been playing with this program, and it's really supreme. Thank you very much for making the effort, and I can't wait to see how far you push this thing. It is already the best thing available for us... We're coming dangerously close to an IDE, you know that? =)

[Opry99er]

Okay, few small suggestions on first thought/first glance.

 

*Id like to see a "New Map" or "Clear Map" in the dropdown menu

 

*Maybe a "re-size" feature to change the size of the map.

 

*The "flashiness" in the full-map editing is a bit debilitating. Every time I move my mouse, the screen redraws/resets itself. It makes it difficult to edit.

 

As far as this thing goes man, it's superb. My suggestions are intended to improve what is already an excellent program, and being that this is the first BETA release, the first time it has seen the light of day, I'm very impressed!!! Thank you for your work brother--- Codex strikes again!!

[Opry99er]

Thinking on the "re-sizing" thing--- what if the user could just make 4 maps (let's say) instead of making a 4x grid... Just allow the 4 maps to be viewed simultaneously---maybe on a second page. These 4 maps would make up a large map that can be viewed and edited at the same time, only at SAVE time, it would save "MAP(1,1), MAP(1,2), MAP(2,1) and MAP(2,2). It wouldn't require much additional code--- much less than rewriting it to include 160x120 editing!!! It can be done now, theoretically, but manually--- I'm suggesting perhaps an automated method, wherein the user can select to work with the large map on a separate page, or one map at a time on the integrated page. Do you think that sounds useful enough to consider adding to the program?

 

<<edit>>

Essentially it would save as a "project" instead of a straight ".mag" file--- it could even be a .mag file, but the parameters of your saved programs could be changed to suit the expansion...

Edited April 1, 2010 by Opry99er

[sometimes99er]

Gosh, I thought we'd be able to tell XB to use VDP in general and have the 8 and 24K RAM blocks much to ourselves. There must be a way to do the trick.

 

This is not going to any help, but paragraph 2.3 in the Extended Basic Assembly Programmers Guide says:

It is possible to use part of the 24K block for machine language as well. Basic allocates space to itself from high end of memory, so you may place machine language code and data at the low end. In order to load code here, it should be assembled in absolute mode (e.g. AORG >A000) rather than relocatable. A pointer to the beginning of free (unallocated memory may be found in location >8386 (RAMFRE).

 

Edited April 1, 2010 by sometimes99er

[sometimes99er]

Another way to go around mapping could be something like for example using 2x2 character building blocks instead of 1 character only. 2x2 characters could be tied together like sprites as in using consecutive characters (40, 41, 42 and 43 only needs 40 as index). A complete map for a screen size would not be 768 bytes, but 192 bytes (768/4).

 

160x120 is almost 19K. Same overall size but with the technique above would be 80x60 blocks (still 160x120 characters) is almost 5K (80*60/1024 = 4,6875K). That would fit in the 8K block with XB, and we could still scroll the map one character at a time !?!!

 

[sometimes99er]

Alright, here's the first draft of Magellan.

Ah, what a delight to play around with TI graphics and screen like that.

 

Medium red and light red appears the same here.

 

Hovering or painting within the same dot in the editor or within the same character on the screen/map generates a lot of flicker. I guess you know if the mouse state and pointer calculates to the same as before (within the same dot/character), an update is unnecessary.

 

Some of the pre-indicators of characters have a question mark while others are blank.

 

The fill and clear canvas icons are a bit misleading. I would have expected nice flood fill and paint brush instead.

 

Edited April 1, 2010 by sometimes99er