The Legend of Beryl Reichardt

[sometimes99er]

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

 

Well, the TommyGun was actually updated to do just that (a prior MSX update), though it is still lacking some functionality to be a blaster. Different MSX and Coleco utilities exists too. Take a look at Daniel Bienvenu's project blog.

 

 

 

[The Codex]

Thanks for all the comments and feedback. I'll try to respond to each with the plans to address them.

 

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

 

Can do. Also, I plan on implementing multimaps, with a navigation tool at top that lets you cycle between them, as well as add new ones. You'll have the chance to give each a simple descriptive name as well.

 

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

 

Will have to look into that once I come up with a solution for scrolling.

 

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

 

Yeah, it's tres annoying. I think the fix for that will go hand-in-hand with the one for scrolling - namely, creating a large buffer canvas that handles the actual drawing and which is refreshed invisibly, making editing seamless and scrolling feasible.

 

Medium red and light red appears the same here.

 

Yep, likewise. I'm using an RGB table of the TI color definitions that I found on the web a while back and those two reds seem awfully close. If anyone knows of a more authoritative RGB value table for the TI palette, I'd be happy to implement that in its place.

 

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

 

That's on my bug list too. I noticed it after I implemented the "smart" refresh of the buttons, and I have a good idea what's causing it.

 

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

 

Probably hard to resolve at that low resolution, but the fill icon is a spilling paintcan and the clear one is a window squeegee. I suspect I could come up with better symbols.

 

Thanks again you guys, and I'll see if I can get another version out soon.

[Opry99er]

Excellent!! Glad to see your tool up... I know it will be a killer app when you're done with it! Have you given any thought to the idea of developing the multi-map page for larger maps? It would save virtually the same, only in sections (1,1),(1,2),(2,1),2,2).... This could be a replacement concept for a "map re-size". . And Karsten's idea about creating 2x2 blocks with stringed definitions--- that's pretty brilliant too.

[Opry99er]

Started my first Beryl map. I'm going to stop where I am, though, because I want to be able to work with larger maps, and I'm afraid that Cart99 isn't doing it for me the way Magellan is. I think Magellan, when debugged and completed, may very well be one of the premier TI related apps, along with Grapefruit, TI99Dir, etc. I will postpone the digital map editing for Beryl until such time as Codex has the time to finish his Magellan beast. I have started doing quite a bit of map design on graphing paper though--- Sometimes might find that cool. I'll post some pix of my graph paper work as soon as I can get back home to take pix. I'm at my family's house doing some yardwork for my mother today-- it's a beautiful day and I could use the exercise!!! But when I get home, I'll definitely get back to the graph paper work.

Edited April 1, 2010 by Opry99er

[The Codex]

Good that you're using it, mate, I look forward to enhancing it further. I'm going to be sporadically on- and off-line this coming week. If I get a new version done in that time I'll post it, otherwise I'll pick it up again the following week. Thanks again for the interest and I hope I can make it even more useful down the line.

[Opry99er]

I think the main thing that gets me is the flicker. I can do up 4 separate maps and integrate them later, but the flicker, especially at high magnification, just kills the feel of the program. I love the layout and the groove of it... Hope the ToD editor has a similar feel when you get that ready for release. You should make up a packaged set of these tools and sell them at the Faire, man. Offer 'em as freeware later on down the line if you wish, but you'd sell out up there if you do a good demo.

[sometimes99er]

Medium red and light red appears the same here.

Yep, likewise. I'm using an RGB table of the TI color definitions that I found on the web a while back and those two reds seem awfully close. If anyone knows of a more authoritative RGB value table for the TI palette, I'd be happy to implement that in its place.

This definition is originally taken from MAME(/MESS)

 

   protected static final Color[] colorPalette = {
           new Color(0x000000), /*  0 transparent/black */
           new Color(0x000000), /*  1 black */
           new Color(0x21c842), /*  2 green */
           new Color(0x5edc78), /*  3 light green */
           new Color(0x5455ed), /*  4 dark blue */
           new Color(0x7d76fc), /*  5 blue */
           new Color(0xd4524d), /*  6 dark red */
           new Color(0x42ebf5), /*  7 cyan */
           new Color(0xfc5554), /*  8 red */
           new Color(0xff7978), /*  9 light red */
           new Color(0xd4c154), /* 10 dark yellow */
           new Color(0xe6ce80), /* 11 yellow */
           new Color(0x21b03b), /* 12 dark green */
           new Color(0xc95bba), /* 13 magenta */
           new Color(0xcccccc), /* 14 gray */
           new Color(0xffffff), /* 15 white */
   };

Edited April 3, 2010 by sometimes99er

[Opry99er]

Neato! Hopefully with this new tool, more richly designed gamescreens will be possible and new TI games will be "all they can be". I know Beryl will be graphically the best thing I've done so far, by far.

[sometimes99er]

I will be looking into this one ...

 

Tile Studio

Tile Studio download

 

[Opry99er]

That's pretty fascinating. I wonder if it's customizable enough to make it TI-compatible with colors, sets, pixels, etc...

[Opry99er]

In an attempt to make this thing look "Less Ultima" I thought about knocking the top of the screen out and using it as the stat bar during exploration. I've got a few screens I'm working with... One that tightens up the exploration screen to a 12x12 screen. But here's just a little thing that shows the top of the screen blocked out. I'll have some better stuff later including the 12x12 expl. screen and the stats typed in. Just testing out a little screen, the bridge is a bit lame, but it'll do for this little tester screen.

 

100 CALL CLEAR :: CALL SCREEN(2) :: CALL MAGNIFY(3)

110 CALL CHAR(104,"2BC0EAF0F8FBF8F9")

120 CALL CHAR(128,"00000000070D1D3575D5D55F5870E0C000000000E0B0B8ACAEABABFA1A0E0703")

130 CALL HCHAR(8,1,104,544)

134 CALL COLOR(10,13,4,3,16,1,5,16,1,6,16,1,7,16,1) :: CALL COLOR(9,15,5) :: CALL MAGNIFY(3)

140 FOR I=17 TO 18 :: CALL VCHAR(8,I,96,17) :: NEXT I

145 CALL SPRITE(#1,128,11,136,129)

150 CALL CHAR(96,"C3241800C3241800")

170 FOR DELAY=1 TO 50 :: NEXT DELAY :: CALL CHAR(96,"1800C3241800C324") :: FOR DELAY=1 TO 50 :: NEXT DELAY

180 GOTO 150

[Opry99er]

Here's another view... this one's a bit closer to what the main screen will look like... I think... I don't know. Anyway--- here it is. Imagine there's stats and status on the right side of the screen. Note that the battle sequences are still slated to be full screen, like the sample pix on earlier pages of this thread.

 

 

EDIT***

 

Just updated the program and re-posted. This one is re-ordered to make more sense, there are REM statements added, and the animation of the water is a bit slower. Enjoy

SCBER.zip

Edited April 3, 2010 by Opry99er

[+retroclouds]

I will be looking into this one ...

 

Tile Studio

Tile Studio download

 

 

I used Tile Studio for my (currently stalled) Time Pilot project.

Had a real basic exporter for handling VDP9918 16x16 sprites.

What I like about Tile Studio is that the source code is available.

 

Don't ask any questions about this, I have totally forgotten how it works

 

; --------------------------------------------------------
; Tile Studio Definition File
; TI994A_sprites_16x16.tsd
;
; Generate 16x16 sprite raw data for the
; Texas Instruments TI-99/4A
;
; by RETROCLOUDS
;
; v0.1   12.07.2009
; --------------------------------------------------------

#file sprites_16x16.raw
#tileset
*--------------------------------------------------------------
* Sprite 16X16 pattern data by Tile Studio <TSVersion>
* <CurrentDate> <CurrentTime> - <TileSetIdentifier>
*--------------------------------------------------------------
* Tiles: <TSTileCount>
#tstile
* Tile: <TileNumber>
#tiledata "\n@SPRITE_16X16@:" "" "" "|" ""
<(Pixel+1) :"%01x">
#end tiledata
#end tstile
#end tileset
#end file

 

[Opry99er]

Awesome--- I'll be needing something full of features--- like Magellan. Love to see what comes out of these projects.

[Opry99er]

Like the SCBER zip I attached to this thread last night, I'm starting to feel very good about the 15x15 exploration screen. It makes the feel "tighter" and whatnot. Here's the problem-- a screen that tight is perfect for a "scrolling" feel but very cumbersome for a "screen by screen" type exploration. What I'm considering is making 4 smaller maps per world and allowing scrolling--- then coming up with some clever way to buy me some time while the next section is loaded from diskette.. Perhaps a big battle or some entrance into a building or something. I don't know--- Karsten, I'm also interested in your concept of defining double sized tiles... Whatever works best here. I need to figure outvthe method so I can move forward.

[sometimes99er]

Well, 160x120 was almost 19K (uncompressed) and apparently not going to fit in RAM alongside XB.

 

Double sized tiles (2x2 chars) would be almost 5K (uncompressed), in principle still 160x120, and would fit with XB assembler support routine in the lower 8K RAM Expansion. Scrolling only 1 character at a time should also be possible.

 

Tile Studio might very well be able to do the job, but other mappers should do to. If arranged properly in the mapper, one could later extract only those 25% of bytes representing the “double sized” tiles (taking every second byte and jumping a line).

 

It might be possible to handle a 15x15 window using a single array of strings. Let’s assume 60x60 (16 screens/windows), that’s 60 strings each with 60 characters - and then a bit of logic in XB to choose and extract 15x15 from the 60x60.

 

[Opry99er]

Just updated the SCBER demo file and re-posted it. I'll post it here again as well, in case you guys don't feel like going back. =) New updates are

 

*Re-ordered code to make logical sense

*REM statements added

*animation of water slowed down.

 

Enjoy

SCBER.zip

[Opry99er]

Wow Karsten--- I don't have the slightest clue how accomplish that, but in theory it looks great!!! I think, since I'll be re-using some characters a hundred times or so each, it should be a simple process of loading tiles into preset or pre-determined positions. That bit can be accomplished, as you say, with some simple logic--- but as it looks now, I'll be beating my head against a wall until I can determine which method to shoot for....

 

1) Full screen, no scrolling, section based exploration (Zelda)

2) 15x15 screen, scrolling enabled, etc. (Ultima IV)

 

your double size string method takes us down from almost 20k to 5k, AND it seems to allow "one-character-at-a-time" scrolling. That should be my focus I think. I want to scroll AND be able to use music... If this is possible in XB, I'll find a way to make it happen!!!! Thanks for your help!

[+adamantyr]

Wow Karsten--- I don't have the slightest clue how accomplish that, but in theory it looks great!!! I think, since I'll be re-using some characters a hundred times or so each, it should be a simple process of loading tiles into preset or pre-determined positions. That bit can be accomplished, as you say, with some simple logic--- but as it looks now, I'll be beating my head against a wall until I can determine which method to shoot for....

 

1) Full screen, no scrolling, section based exploration (Zelda)

2) 15x15 screen, scrolling enabled, etc. (Ultima IV)

 

your double size string method takes us down from almost 20k to 5k, AND it seems to allow "one-character-at-a-time" scrolling. That should be my focus I think. I want to scroll AND be able to use music... If this is possible in XB, I'll find a way to make it happen!!!! Thanks for your help!

 

Whatever method you use, you'll only be loading part of the map into memory at any given time. That's the only way you can have such a large map.

 

I tried this method with my own CRPG, having a "big world map" that reloaded new sections every time you approached a boundary, but the effect was a lot of stops every 8 or so paces in a given direction.

 

The main issue was a single record access had to be made for every row. The TI disk system is pretty fast, but this adds up, especially when it's the user moving the screen and they definitely notice a second or two of delay. I noticed that this issue exists in Ultima IV on a lot of 8-bit systems; it's actually a rather slow and cumbersome game to play on these platforms as a result.

 

If you go with sections, you can greatly minimize this issue. This is what I did with my CRPG; I just have a 4k buffer and a map header record that records height and width. That way I can have maps that are 64x64, 128x32, 32x32, or any size I want. The only reloads occur when you actually exit the map.

 

Adamantyr

[Opry99er]

Fascinating stuff.... I don't know how to implement it yet, but I'm studying. Your game looks damn good, adamantyr. If mine ends up looking anywhere near as nice as yours, I'll be super-excited.

[sometimes99er]

Double sized tiles are one thing. The string method is 60 string variables (MAP$(60)) each having 60 characters (this will take at least 4K of XB memory). Using “DISPLAY AT” you could scroll the 15x15 window one character at a time (no assembler, “just” a loop with 15 DISPLAY AT).

 

Anyways, drop scrolling, drop double sized tiles, and try string arrays for storing screens. You could have a maximum of 6 screens in memory (SLOTS$(6,15)). When you need screen 7 then maybe read and overwrite the memory of screen 1. Reading 15 strings from disk shouldn't take long. You have to know/store information about what screen is in each of the 6 slots. Other information read could be something like DOORS$(6), so you know which screens to go to (north, east, south, west = "02-04-11-14").

 

Just some ideas.

 

Edited April 3, 2010 by sometimes99er

[Opry99er]

Well I have to say, that's quite interesting!! I'll need to find a functional operational map editor that allows me to define my map size and go from there. I'll be trying the Tile program you suggested--- just til Codex finishes his up. Thanks

[Opry99er]

The only tricky thing is that the complexity of the map will depend very much on the method of exploration. Seeing as a 15x15 screen block is much tighter than a 17x30 view, and the viewing aspect will be very different, I would want to tailor my map differently depending on what method I would be using. That's the dilemma with trying to decide what to do next, really. The little SCBER screenshot I posted is how I envision the exploration screen, really. I hope I can make it work.

[sometimes99er]

I’ve attached an XB with a dummy 60x60 map in a string array. There’s a 15x15 window and you can travel it using the arrow keys. There are no bondary checks. All in all about 5K in size.

 

 

 

[+retroclouds]

Just gave it a try. Pretty slick for Extended Basic

Guess if you want to get more out of this you'd have to implement some assembly language routine.

Then again, I'm not that much a fan of hybrid extended basic/assembly programs.

 

But for this type of game (with complex logic) writing everything in assembler seems pretty hard/time consuming/cumbersome.

Wonder if C99 would be the way to go in this case.