The Legend of Beryl Reichardt

[Opry99er]

Well, here's a mockup showing the new screen dimensions. I didn't have time to make it pretty, but you'll get the idea. =)

 

http://www.youtube.com/watch?v=HrTQVXz1jXU

[Opry99er]

Looks like my vid got a little corrupted during upload.... Oh well, it's not the code.

[The Codex]

Looks fab mate, that's quite excellent!

 

You'll be pleased to know, Magellan is now in official first release. Hope you find it useful!

[Opry99er]

Hey buddy, I've started the second Forest World screen--- I'm really loving the interface!!!

[Opry99er]

A few things to share... Started some mockup designs for my screens. Ported my XB program (above) into Magellan and then used Magellan to draw the next 3 screens. I LOVE this program!!! It's exactly what I wanted, and GREAT thanks to Howard Kistler aka Codex aka the Coolest MoFo eva!!!! Below I have a sketch of the map layout (I have 4 of 6 completed) and a pic of the 4 as they sit in the overall world map. The player enter this world in screen 1 and exit through the door to the mountains in screen 4. The player must, however obtain items and a key in the other screens as well. All screens must be cleared of enemies before you can enter the black tower in screen 3. That's where you fight the main enemy and get the key for the door in screen 4. It's all preliminary, but I'm having fun. . Enjoy

 

 

 

 

Thanks for viewing!!

Edited April 14, 2010 by Opry99er

[Opry99er]

Hey--- I bet I could write a VSBW routine to loop 768 times and pass these map DATA values to it--- that would be alot faster than my little XB routine, don't you think?

[Opry99er]

I could just put the DATA statements directly into the AL program, Then CALL LINK (FSC1), CALL LINK (FSC2)

Edited April 14, 2010 by Opry99er

[+adamantyr]

I could just put the DATA statements directly into the AL program, Then CALL LINK (FSC1), CALL LINK (FSC2)

 

Erg... the problem here is that BASIC's data structures and the screen are aligned in just the right way to totally ruin your day.

 

Specifically, strings, the ideal data storage method, can only be a maximum of 255 bytes. (A length byte is at the start of a 256 byte block.) So you would need three strings to represent the data on a full-size screen. Which means your assembly routine either has to process row strings one at a time (which means the display is severely retarded in efficiency since it has to return to BASIC for each row) or accept three or four strings as parameter data.

 

Here's a better idea: How many unique screens do you have? If the count is reasonable (20 or so), you could store them as "program" files, also known as memory-images. I do this myself for various screens in my CRPG. Each screen fits in exactly 4 sectors (1 sector for the record, 3 for the data) and occupies exactly 1K on a disk. The only serious limitation here is that the TI file system only permits 127 files maximum on a single disk.

 

Using this method though, and an assembly program that only takes a single parameter (string for the file name or file path) that just reads it DIRECTLY into the VDP screen memory, bam, instant screen change. Plus you can change your data structure in BASIC to just have a file name for the individual map, instead of hard data, which gives you more room for other stuff.

 

One caveat: The character sets in BASIC are a little whacked. The character set is all offset by 96 because the lower part of the character definition table is used for other purposes. This is why you can't have characters defined past 159 in BASIC (and 143 in Extended BASIC); you're literally AT the end of the table already. And in Extended BASIC, 144-159 are used for the sprite attribute table.

 

Adamantyr

[Opry99er]

If you DL Magellan, you only have definability up to 143. I've only used about 5-10 Redefined characters in these screens. For each world, I'd like to have as manyscreens as possible.. I don't mind an extended load time between worlds--- so I could clear the registers and redefine parameters and load a new XB program that is specific to that world... If I can keep it under 720K, that's the only real need. But if I separate it all out by world, how many screens do you think would be possible per world?

 

((edit)) As it stands, 5 worlds, 6 screens a piece. 30 screens, JUST map data.

Edited April 14, 2010 by Opry99er

[Kurt_Woloch]

I could just put the DATA statements directly into the AL program, Then CALL LINK (FSC1), CALL LINK (FSC2)

Here's a better idea: How many unique screens do you have? If the count is reasonable (20 or so), you could store them as "program" files, also known as memory-images. I do this myself for various screens in my CRPG. Each screen fits in exactly 4 sectors (1 sector for the record, 3 for the data) and occupies exactly 1K on a disk. The only serious limitation here is that the TI file system only permits 127 files maximum on a single disk.

 

Hmmm... as far as I have observed, it's even the STANDARD method of loading PROGRAM files directly into VDP RAM. In fact, I think nearly everything loaded from disk first gets loaded into VDP RAM and then copied over to CPU RAM, the difference being that for PROGRAM files it's done in big chunks (the whole file at a time) while for other file types it's done in small chunks (record by record). This is probably the reason while XBasic changes its file format to something other than PROGRAM for programs over a certain file size, and why machine language programs stored as PROGRAM are saved in several chunks each 8K long (the other reason for that, however, may be that this mimics the structure of cartridges where everything over 8K CPU ROM has to be put in banks).

 

I think the reason for this behavior is the limitation of the peripherial box containing both the disk controller and the RAM expansion, where only one of them can be active (and thus visible to the CPU) at a time, so it's impossible to read something from disk into CPU RAM (other than the scratch pad) from a program residing in DSR ROM, and the VDP RAM has to be used as a buffer.

 

This means that there already has to be a routine in CPU ROM (or in the DSR ROM) which reads a PROGRAM file into VDP RAM. The question is if you can parameterize it so that the file loaded gets loaded into the address where the screen RAM resides...

[Opry99er]

Here's the thing... I have been writing a "draw" routine in XB... here's the routine with some data... I haven't tried this out yet, but it's here as a concept. Is there a way to implement this into AL? I know this method eats excess memory, but this is just the simplest way I have to test and work on this. It'll get alot more efficient as we go, but as is, you've got 16 DATA entries per line, so (2) DATA lines make up one screen row. If this code is bad, someone please fix it for me. =) I'm not on my laptop to test right now. =) iPhones rock

 

100 CALL CLEAR :: CALL SCREEN(4)

105 ROW=1 :: COLUMN=1

106 RESTORE 230 :: READ CHA

110 FOR C=1 TO 768 :: DISPLAY AT(ROW,COLUMN):CHR$(CHA); :: COLUMN=COLUMN+1 :: IF COLUMN>32 THEN COLUMN=1 :: IF COLUMN=1 THEN ROW=ROW+1

111 NEXT C

120 GOTO 120

 

200 REM MAP DATA

200 REM CHA DATA

230 DATA 128,128,128,144,144,144,144,144,144,144,144,144,144,144,144,144

235 DATA 144,144,144,144,144,144,144,144,144,144,144,152,152,152,152,152

240 DATA 128,128,128,144,144,144,144,144,144,144,144,144,144,144,144,144

245 DATA 144,144,144,144,144,144,144,144,144,144,144,152,152,152,152,152

250 DATA 128,128,128,144,144,144,139,136,136,136,136,136,136,136,136,136

255 DATA 136,136,136,136,136,140,144,144,144,144,144,152,152,152,152,152

260 DATA 128,128,128,144,144,144,137,141,141,141,141,141,141,141,141,141

265 DATA 141,141,141,141,141,138,144,144,144,144,144,152,152,152,152,152

270 DATA 128,128,128,144,144,144,137,141,141,141,141,141,141,141,141,141

275 DATA 141,141,141,141,141,138,144,144,144,144,144,152,152,152,152,152

280 DATA 128,128,128,144,144,144,137,141,141,141,141,141,141,141,141,141

285 DATA 141,141,141,141,141,138,144,144,144,144,144,152,152,152,152,152

290 DATA 128,128,128,144,144,144,137,141,141,141,132,132,132,132,132,132

295 DATA 132,132,141,141,141,138,144,144,144,144,144,152,152,152,152,152

300 DATA 128,128,128,144,144,144,137,141,141,135,129,130,128,128,129,129

305 DATA 131,128,134,141,141,138,144,144,144,144,144,152,152,152,152,152

310 DATA 128,128,128,144,144,144,137,141,141,135,129,128,129,129,128,128

315 DATA 129,128,134,141,141,138,144,144,144,144,144,152,152,152,152,152

320 DATA 128,128,128,144,144,144,137,141,141,135,130,130,129,129,128,128

325 DATA 131,131,134,141,141,138,144,144,144,144,144,152,152,152,152,152

330 DATA 128,128,128,144,144,144,137,141,141,135,130,131,128,129,128,129

335 DATA 130,131,134,141,141,138,144,144,144,144,144,152,152,152,152,152

340 DATA 144,144,144,144,144,144,137,141,141,135,128,129,128,128,129,129

345 DATA 128,129,134,141,141,138,144,144,144,144,144,152,152,152,152,152

350 DATA 144,144,144,144,144,144,137,141,141,135,128,131,130,128,129,131

355 DATA 130,129,134,141,141,138,144,144,144,144,144,152,152,152,152,152

360 DATA 144,144,144,144,144,144,137,141,141,141,133,133,133,133,133,133

365 DATA 133,133,141,141,141,138,144,144,144,144,144,152,152,152,152,152

370 DATA 144,144,144,144,144,144,137,141,141,141,141,141,141,141,141,141

375 DATA 141,141,141,141,141,138,144,144,144,144,144,152,152,152,152,152

380 DATA 144,144,144,144,144,144,137,141,141,141,141,141,141,141,141,141

385 DATA 141,141,141,141,141,138,144,144,144,144,144,152,152,152,152,152

390 DATA 144,144,144,144,144,144,137,141,141,141,141,141,142,141,141,142

295 DATA 141,141,141,141,141,138,144,144,144,144,144,152,152,152,152,152

400 DATA 144,144,144,144,144,144,136,136,136,136,136,136,136,141,141,136

405 DATA 136,136,136,136,136,136,144,144,144,144,144,152,152,152,152,152

410 DATA 144,144,144,144,144,144,144,144,144,144,144,144,144,144,144,144

415 DATA 144,144,144,144,144,144,144,144,144,144,144,152,152,152,152,152

420 DATA 144,144,144,144,144,144,144,144,144,144,144,144,144,144,144,144

425 DATA 144,144,144,144,144,144,144,144,144,144,144,152,152,152,152,152

430 DATA 143,143,143,143,143,143,143,143,143,143,143,143,143,143,143,143

435 DATA 143,143,143,143,143,143,143,143,143,143,143,143,143,143,152,152

440 DATA 143,143,143,143,143,143,143,143,143,143,143,143,143,143,143,143

445 DATA 143,143,143,143,143,143,143,143,143,143,143,143,143,143,152,152

450 DATA 143,143,143,143,143,143,143,143,143,143,143,143,143,143,143,143

455 DATA 143,143,143,143,143,143,143,143,143,143,143,143,143,143,152,152

460 DATA 143,143,143,143,143,143,143,143,143,143,143,143,143,143,143,143

465 DATA 143,143,143,143,143,143,143,143,143,143,143,143,143,143,152,152

 

 

 

[Opry99er]

Okay, I just heard this doesn't work.... Someone smarter than me tell me why. =)

[The Codex]

If you DL Magellan, you only have definability up to 143.

 

Actually, Magellan lets you define all character sets, including 15 & 16 which are unavailable in XB (for the reason Adam indicated). I'm fixing that in the next release with two save options - Export To XB Data, which dumps everything and lets you work it out, and Export to XB Exec, which includes screen drawing code and automatically excludes characters above 143. (It also replaces those disallowed characters in the map layout with spaces, so be warned. ) I can include a third export, Export To BASIC Exec, which would include the screen drawing code AND allow the full character set as it is available in regular BASIC, but is anyone really developing in that?

[The Codex]

Okay, I just heard this doesn't work.... Someone smarter than me tell me why. =)

 

You're not doing a READ inside the draw loop, so every character is the first value read into CHA.

[Opry99er]

Duh.... Whatever. I need some sleep.

Edited April 14, 2010 by Opry99er

[Opry99er]

Hmmm--- just got home...darn thing won't run-- I feel like a tool

[The Codex]

If you're running it in XB, it won't like those map tiles with character values of 144 or more. Try running it in plain BASIC and see what you get.

[sometimes99er]

DISPLAY AT(row, column) places the beginning of the display field at the specified row and column. Rows are numbered 1 through 24. Columns are numbered 1 through 28 with column 1 corresponding with what is called column 3 in the VCHAR, HCHAR, and GCHAR subprograms.

 

[+adamantyr]

100 CALL CLEAR :: CALL SCREEN(4)

105 ROW=1 :: COLUMN=1

106 RESTORE 230 :: READ CHA

110 FOR C=1 TO 768 :: DISPLAY AT(ROW,COLUMN):CHR$(CHA); :: COLUMN=COLUMN+1 :: IF COLUMN>32 THEN COLUMN=1 :: IF COLUMN=1 THEN ROW=ROW+1

111 NEXT C

120 GOTO 120

 

Fixes:

- DISPLAY AT only works on columns 3-30, it was adapted from the PRINT statement which only works with those columns because old TV screens tended to cut them off. Use HCHAR(ROW,COLUMN,CHA) instead

- You don't need the second IF at the end of line 110, just IF COLUMN > 32 THEN COLUMN=1 :: ROW=ROW+1

- In fact, you don't need to use IF's at all, just do a loop, you have a finite known value for how many columns and rows you are filling

 

So try this code instead:

100 CALL CLEAR :: CALL SCREEN(4):: RESTORE 230
105 FOR R=1 TO 24 :: FOR C=1 TO 32
110 READ CHA :: CALL HCHAR(R,C,CHA) :: NEXT C :: NEXT R
120 GOTO 120

 

This is going to be INCREDIBLY SLOW, by the way, but DISPLAY AT is no faster. Unless you write an assembly routine, it will always be that way. The most effective way to store data screens in BASIC alone is to use a string array to store rows, and use DISPLAY AT to display rows after they're loaded from disk. This does have the 28-column limitation, though.

 

Adamantyr

[sometimes99er]

If you’re going to use DISPLAY AT maybe something like this would be nice. You have to use ordinary/displayable characters in your DATA statements though. And they should be 28 characters in length (not 32).

 

100 FOR R=1 to 24

110 READ L$

120 DISPLAY AT(R,1):L$;

130 NEXT R

140 DATA ...

 

[sometimes99er]

Come to think of it. I actually put up a program for you Owen, that used this technique plus some. You know the one where you could travel/scroll one character in any direction. Post #199 in this thread.

[Opry99er]

This works... I think the COLOR DATA is erroneous though... Color 0 doesn't exist. =) So I just bypassed those statements and made all the foregrounds white and blackgrounds black. Anyway, Karsten--- I DO remember that program, and haven't looked at it today. I'll study what you did there and see how it can apply here. I was just driving around yesterday and today and thinking and that routine kinda came to me. In my initial post in the Magellan thread, I used the HCHAR design and it seemed to work. Anyway, I know Codex has something worked up, but I wanted to try it on my own. I'll start paying attention to the better programmers like you guys and I'll learn a thing or two. =)

 

 

100 FOR SET=1 TO 14 :: FORE=16 :: BACK=2 :: CALL COLOR(SET,FORE,BACK) :: NEXT SET

106 CALL CHAR(96,"11FF444444FF1111") :: CALL CHAR(104,"001F356AFEB686FC") :: CALL CHAR(112,"00BDFF3C191A3C7E")

107 CALL CHAR(113,"3C66A5A5BDBDA5FF") :: CALL CHAR(120,"0000E0A0BFA5E501817E247EA5244200") :: CALL CHAR(128,"0102044830304880")

108 CALL CHAR(128,"0102044830304880")

222 CALL CLEAR :: CALL SCREEN(2)

223 FOR R=1 TO 24 :: FOR C=1 TO 32

224 READ CHA :: CALL HCHAR(R,C,CHA) :: CALL HCHAR(R,C,CHA) :: NEXT C :: NEXT R

226 GOTO 226

9010 CALL COLOR(1,1,0)

9020 CALL COLOR(2,1,0)

9030 CALL COLOR(3,1,0)

9040 CALL COLOR(4,1,0)

9050 CALL COLOR(5,1,0)

9060 CALL COLOR(6,1,0)

9070 CALL COLOR(7,1,0)

9080 CALL COLOR(8,1,0)

9090 CALL COLOR(9,14,0)

9100 CALL COLOR(10,10,0)

9110 CALL COLOR(11,6,0)

9120 CALL COLOR(12,15,0)

9130 CALL COLOR(13,7,0)

9140 CALL COLOR(14,1,0)

9150 CALL COLOR(15,1,0)

9160 CALL COLOR(16,1,0)

9165 RETURN

9190 DATA 32,32,32,32,96,96,96,96,96,96,96,96,96,96,96,96

9195 DATA 96,96,96,96,96,96,96,96,96,96,96,96,96,96,96,96

9200 DATA 32,32,32,32,96,96,96,32,32,32,32,32,96,96,96,96

9205 DATA 96,96,96,96,96,32,32,32,32,32,32,32,32,32,32,113

9210 DATA 32,32,32,32,32,32,32,32,32,32,32,32,96,96,96,96

9215 DATA 96,96,96,96,96,32,96,96,96,96,96,96,96,96,96,96

9220 DATA 32,32,32,32,96,96,96,32,32,120,32,32,32,32,32,32

9225 DATA 32,32,96,96,96,32,96,32,32,32,32,32,32,96,96,96

9230 DATA 96,96,96,96,96,96,96,32,32,32,32,32,32,32,32,32

9235 DATA 32,32,96,96,96,32,96,32,32,32,32,32,32,96,96,96

9240 DATA 96,96,96,96,96,96,96,32,32,32,32,32,96,96,96,96

9245 DATA 32,32,96,96,96,32,32,32,32,32,32,32,32,96,96,96

9250 DATA 96,96,96,96,96,96,96,96,96,96,96,96,96,96,96,96

9255 DATA 32,32,96,96,96,96,96,32,32,32,32,32,32,96,96,96

9260 DATA 96,96,96,96,96,96,96,96,96,96,96,96,96,96,96,96

9265 DATA 32,32,96,96,96,96,96,32,32,32,32,32,32,96,96,96

9270 DATA 96,96,96,32,32,32,32,32,96,96,96,96,96,96,96,96

9275 DATA 32,32,96,96,96,96,96,96,96,96,96,32,32,96,96,96

9280 DATA 96,96,96,32,32,32,32,32,96,96,96,96,96,96,96,96

9285 DATA 32,32,96,96,96,96,96,96,96,96,96,32,32,96,96,96

9290 DATA 96,96,96,32,104,32,112,32,96,96,96,96,96,96,96,96

9295 DATA 32,32,96,96,96,96,96,96,96,96,96,32,32,96,96,96

9300 DATA 32,32,32,32,32,32,32,32,96,96,96,96,32,32,32,32

9305 DATA 32,32,32,32,32,96,96,96,96,96,96,32,32,96,96,96

9310 DATA 32,32,32,32,32,32,112,32,32,32,32,32,32,32,121,32

9315 DATA 32,32,32,32,32,32,32,32,32,32,32,32,32,96,96,96

9320 DATA 96,96,96,32,32,32,32,32,32,32,32,32,32,32,32,32

9325 DATA 32,32,32,32,32,32,32,32,32,32,32,32,32,96,96,96

9330 DATA 96,96,96,32,32,32,32,32,96,96,96,96,32,32,32,32

9335 DATA 32,32,32,121,32,96,96,96,96,96,96,96,96,96,96,96

9340 DATA 96,96,96,32,32,32,32,32,96,96,96,96,32,32,32,32

9345 DATA 32,32,32,32,32,96,96,96,96,96,96,96,96,96,96,96

9350 DATA 96,96,96,96,96,96,96,96,96,96,96,96,32,96,96,96

9355 DATA 32,32,96,96,96,96,96,96,96,96,96,96,96,96,96,96

9360 DATA 96,96,96,96,96,96,96,96,96,96,96,96,32,96,96,96

9365 DATA 32,32,96,96,96,96,96,96,32,32,32,32,32,32,32,96

9370 DATA 96,96,96,96,96,96,96,96,96,96,96,96,32,96,96,96

9375 DATA 32,32,96,96,96,96,96,96,32,32,32,32,32,128,32,96

9380 DATA 32,113,32,32,32,96,96,96,96,96,96,96,32,96,96,96

9385 DATA 32,32,96,96,96,96,96,96,32,32,32,104,32,32,32,96

9390 DATA 96,96,32,32,32,96,96,32,32,32,32,32,32,96,96,96

9395 DATA 32,32,32,32,32,32,32,32,32,32,32,32,32,32,32,96

9400 DATA 96,96,32,104,32,96,96,32,96,96,96,96,96,96,96,96

9405 DATA 96,96,96,96,96,96,96,96,32,32,32,32,32,32,32,96

9410 DATA 96,96,32,32,32,32,32,32,32,32,32,96,96,96,96,96,96

9415 DATA 96,96,96,96,96,96,96,32,32,32,32,32,32,32,96,96

9420 DATA 96,32,32,32,32,32,32,32,32,32,96,96,96,96,96,96

9425 DATA 96,96,96,96,96,96,96,96,96,96,96,96,96,96,96

[Opry99er]

[+adamantyr]

This works... I think the COLOR DATA is erroneous though... Color 0 doesn't exist. =)

 

Colors are 0-15 in assembly, 1-16 in BASIC, the usual "offset by one" bug.

 

What's your exact goal with this small program? Just to display your screens? If so, speed shouldn't be a problem.

 

If you want to read those DATA statements in and then output that data as a string-readable file for your eventual game, this should do the trick:

 

100 OPEN #1:"DSK1.MF1",OUTPUT,INTERNAL,FIXED 32
110 RESTORE 9190 :: FOR R=1 TO 24 :: FOR C=1 TO 32 :: C$=""
120 READ CHA :: C$=C$&CHR$(CHA):: NEXT C
130 PRINT #1:C$ :: NEXT R :: CLOSE #1
...
9190 {Data here}

 

Then you can read them back in and display them as follows:

 

100 FOR S=1 TO 14 :: READ F,B :: CALL COLOR(S,F,B) :: NEXT S
110 CALL CHAR(96,"11FF444444FF1111") :: CALL CHAR(104,"001F356AFEB686FC") :: CALL CHAR(112,"00BDFF3C191A3C7E")
120 CALL CHAR(113,"3C66A5A5BDBDA5FF") :: CALL CHAR(120,"0000E0A0BFA5E501817E247EA5244200") :: CALL CHAR(128,"0102044830304880")
130 CALL CHAR(128,"0102044830304880")
140 CALL CLEAR :: CALL SCREEN(2)
150 OPEN #1:"DSK1.MF1",INPUT,INTERNAL,FIXED 32
160 FOR R=1 TO 24 :: INPUT #1:R$ :: CALL HCHAR(R,1,ASC(SEG$(R$,1,1))):: CALL HCHAR(R,2,ASC(SEG$(R$,2,1)))
170 DISPLAY AT(R,1):SEG$(R$,3,28):: CALL HCHAR(R,31,ASC(SEG$(R$,31,1))):: CALL HCHAR(R,32,ASC(SEG$(R$,32,1)))
180 NEXT R :: CLOSE #1
190 GOTO 190
1000 DATA 2,1,2,1,2,1,2,1,2,1,2,1,2,1,2,1,15,1,11,1,7,1,16,1,8,1,2,1

 

As you can see, I used HCHAR to populate the four columns ignored by DISPLAY AT. It's a bit hacky, but you could replace this with an assembly-linked routine that would be better later.

 

Adamantyr

Edited April 15, 2010 by adamantyr

[Opry99er]

Thanks adamantyr!! I will be pulling these from diskette, so I will be using a routine very similar to that one. And yes, an assembly routine to draw these as I go is on my list too.