jchase1970

So I came out with 23 different screens and all of them can be linked either top or bottom except 1. That means 22 screens need 12 bytes and 1 screen needs 14 bytes. Making it 278 bytes! Now for the record there is 3 bytes of wasted space per screen, but laying it out this way makes it easier to program. But If I did pack it as tight as possible it could be packed into 209 bytes. Here is a small section, excluding the hex values cause I have not done that yet. SOUTH *0000 0111 1111 1111 *0000 0010 0000 0000 *0000 0010 0000 0000 *0000 0010 0000 0000 *0000 0010 0000 0000 *0000 0010 0000 0000 NORSOU *0000 0111 1111 1100 *0000 0010 0000 0000 *0000 0010 0000 0000 *0000 0010 0000 0000 *0000 0010 0000 0000 *0000 0010 0000 0000 NORTH *0000 0111 1111 1100 *0000 0010 0000 0000 *0000 0010 0000 0000 *0000 0010 0000 0000 *0000 0010 0000 0000 *0000 0010 0000 0000 EWS *0000 0111 1111 1111 Oh and Sometimes you are right the path is always grey, but in the black castle and the dark maze the foreground is also grey. The area lite by your torch is orange. Not sure how we are going to implement that? The torch lights a 9x9 character square around the player showing the path as grey.

I was looking at the way they stored the room data and they have another space saver that I never thought of. Rooms are arranged in memory to share the top or bottom line in memory. IE using 2 Hex values for example only *ROOM1 TOP EXIT ROOMS ROOM1 DATA >FE *11111110 DATA >80 *10000000 DATA >80 *10000000 DATA >80 *10000000 DATA >80 *10000000 DATA >80 *10000000 *NEXT LINE SHARED IN 2 ROOMS *ROOM2 BOTTOM EXIT ROOMS ROOM2 DATA >FF *11111111 DATA >80 *10000000 DATA >80 *10000000 DATA >80 *10000000 DATA >80 *10000000 DATA >80 *10000000 DATA >FE *11111110 So anytime a pattern is needed for room type 1 point to ROOM1 and read bytes for 7 rows Same for room 2 point to ROOM2. 13 lines of data drawing 14 rows I'm excited to see how small I can make the room data, lol.

That's great, and very close to what I was guessing at, only difference really is the keys. Black key 1st 18 screens White key can be in black maze Yellow key anywhere I can work up a perfect layout from this. Thanks

So about screen layout. Based on game three which is random item locations. Keys cant be in castles or you might not be able to get in Keys need to appear in first 16 screens outside of castles Screens outside of castles are 1-16 Chalice should be in black castle or white castle 17-24 Black castle room 25 nothing will be in screens higher then 25 3 Castle screens 26,27,27 Inside yellow castle 29 Secret room 30 This will make random locating ranges easy Random locate keys 1-16 Random locate Chalice 17-24 Random locate Dragons,Magnet,Bridge,Bat 1-25 Now 2 screens change, the room in the black castle, which according to this drawing stays in game 2,3 but has 2 exits instead of 1 and 1st of 3 dark maze screens, in game 1 it is just a room. At first I was just thinking relocate memory based on game selection, but if this is a cartridge we cant do that so now I'm thinking add to more screens. 31 black castle single room 32 dark maze single room nothing will random locate in these as they don't exist in game 3. This now gives me a screen map looking like this, Any thoughts.

Looks to me as if the border is always black and the background is gray. If that's the case then 30 rooms need 15 bytes of foreground color info. So you wanted to have color info all located separately ? Inside the white and black castle the colors are inverted. Foreground is grey and path is orange. These are only in games 2 and 3.

Lets break this down, cause I am lost. 1st can we use the object code I posted above for the charset, or does it have to be saved special? DEF CHARDF,VMBW VMBW EQU >2024 CHARS DATA for all the char patterns CHARDF LI R0,1008 LI R1,CHARS LI R2,768 BLWP @VMBW 2 set pointers. Lets do this in XB not thru classic 99 cause I want to see how to do it and not short cuts that are above my understanding. This step here just confuses me. I loaded the patterns at decimal 1008. But I dont think that is where we point to? Maybe I have to write a AROG at the beginning of the code to set it to a hard location? So help me with this first step and then we will see about the rest of it. Thx John

I to was thinking about just coding 10 bits per line and wasting the 6 bits. Increasing the screen data from 9 bytes to 14 bytes, but I dont think it is to much. I think the duplicate screens will read the same byte map. Here is how I am thinking to pack the bit 15 bytes per screen Byte 1 FF screen color info. We need it somewhere was going to put it with the screen map but decided to locate it somewhere else cause duplicate screen will be using the same byte map but need a different color. So we need 30 bytes for foreground/background colors. In my demo I didnt set background but the game has different background colors in the black and white castle areas So for the bit packing for the screen I'm going to draw the screen from left to right top to bottom but Im going to read the bits right bit first one Word per line FEDCBA9876543210 There is 2 pieces of info I need for each screen, 1) How does the 2 half of the screen draw, same or mirrored. This will be bit A of the first word, 1=mirrored. 2) Is it a castle map. This I need to know to add the arrow slits and it will help when adding sprite for the gate. The castle is the only screen with "Bling" added to it. This will be bit B of the first word, 1=castle. Words 2-7 (bytes 3-14) will be straight 10 bit of screen info. Doing it this way leaves 4 bits in first word and 6 in next 6 words of space, that is 40 bits. I dont know of anything to use these for atm....... No to the next issue, what to number the screens. I need some kind of order to the layout of the 30 screens to code the data. I'm going off this image here for my work map. So do I start top left and number the screens left to right top to bottom, number them in sets according to the castle they are with, or what? Maybe there is some shortcut logic here that makes it easy to know what screen to load next when you exit a certain spot to the next? Guess I'll look at this for a while and see if I see any pattern.

I read the link but didnt see how to do it, I guess I need to go read it again. Maybe I over looked it.

Well my assembly no how is lacking to say the least so I want to run this by here before I spend the time to code it. I am rewriting the basic example I had using bit packing to store the map. The best way I can figure out to do this in assembly is 1 place word in register 2 add 1 to register to perform operation on it and set status bits 3 do a JOP based on odd or even to draw map section 4 do a SRL to remove bit after done 5 JMP back to 2 and repeat until done I am guessing there might be a better way, but I can find little to tell me how to read bits in a byte or word. So I'll let the gurus set me straight before I proceed. John *edit I guess I could also to a COC and a JEQ to do about the same thing as add 1 and JOP

I'll have to look at SYSTEX, as I spent a fair amount of time trying to figure out how to embed and so far for it I have no more of an idea now then I did when I started. John

Unless I'm wrong..... A CF7 or NANO PEB does not co-exist with the PEB at all (which would be needed to read the floppies.) IDE or SCSI requires the same (IDE or SCSI) on the other end to "UN-PeeCee". Duh.....

Maybe send them to one of the guys on here that have a CF device for the TI.

Ok, so I ripped out the charset from this program, cause I do like it. I then created a assembly program to load from XB. CHARDF.zip A demo program 10 CALL INIT 20 CALL LOAD("DSK1.CHARDF") 30 CALL LINK("CHARDF") 40 FOR I=30 TO 126 50 PRINT CHR$(I); 60 NEXT I 70 GOTO 70 Now I have a few questions about linking. I know when I use CALL LINK("CHARDF") then charset will define much faster then if written in XB. and this is a plus as I normally use 2 sets and switch between them. But this file is 3456 bytes. So where is that loaded at in basic. Is it in the stack and does that give more space to the code? Depending on how much stack you needed that could be good or bad. I was going to ask about if it mattered if the user didn't have the PE but then I realized that it is on disk and I guess they have to have a PE to have a disk drive . So 2nd question is about embedding. I don't know how to for one. But bigger question is, is there any advantage to embedding if we are planing the program to be ran from a disk. I'm guessing embedding saves no space and only difference is a longer load time up front as opposed to loading the assembly after you run the XB program? No matter what I did learn some new stuff from this project. I never wrote a assembly sub for XB before and I understand alot more about that now.

I got to thinking about just switching the pointer to the screen location. So I guess I was thinking right I was going to code a little something list night and try it, but never got around to it, I was thinking to refresh the screen(all 768 characters) take 2 cycles. Does that still apply when changing the pointer to another screen? I here what your saying about the bits not being compression. I guess in assembly it would not be it would be just reading a line of bits. but in my basic example it was a little more complex to decode the bits.

It's two very different machines. Generally the 9900 code has like twice the footprint, but should also be stronger, faster and maybe more flexible. Fast room swapping is essential if anybody is going to compare it with the original. I'd like to do double buffering to achieve instant swapping, but then this requires just a bit more code. Also I'd like this 4th level in there. I hope 8K will do it. Double buffering will be needed if we use some type of map compression like I used above. Do you have any example code to show how to do that on the TI. I read about it somewhere but not sure where now?????

I too think is needs to be in assembly for one reason, or two embedded routines in XB. Since we are not storing the maze in anything and because the maze is made up of whole and half characters then to check for valid move to locations I see us having to check the pixel for weather or not its a background or not, ie is the bit off. This is easy to do but is XB is slower then molasses. 1 get new location character. 2 plot bit moving to 3 check 4 bits for the boundry box of the player 4 if any of the 4 bits are on in the char def then exit move 5 move char to new location It needs to be a little more involved cause if you move vertically you need to grab 2 screen locations in the direction your moving cause you might collide with a wall in either corner of your player. same for horizontal. Diagonal you are moving 3 boundary boxes and need 3 checks. It could be made to check the tile and if it is a solid wall then skip move, or if it is solid path then skip check. But if we want to keep it as small as possible then this just adds additional code. I small procedure that check all instances the same will be reduced code even if it does work it doesn't need to some times . That could be a embedded routine in XB with a true/false return Other item if done in xb would be a screen draw, XB just doesn't have the speed to draw a screen fast and if we use a bit pattern storage method like I code in the example, We would have to include a book for people to read while the screen loads. Again could be a XB routine that accepts a 10 byte input and draws the screen. XB is probably fast enough to handle the rest of it. Nothing moves really fast anyway. The only enemy is the dragon which only moves to the character, no checking for anything but if it hits the character. I still think Assembly would be best and a cart should be a must as we should be able to code this in 4K just like the original. I can see alot of people wanting it. I am in the process of moving and cant get to involved for atleast a month maybe 2, but I want to see this done. And it really is a simple program.

Well the character set is real nice, but it is just that, a character set and it's not hard to code in basic or assembly. I just thought this would be a good clean example to use for my question. I have never tried to embed anything in an XB program but can see how nice it would be to have the charset definitions in assembly would be. especially the way I normally need to sets, one for graphics and one for letters at the end of the game. john

Ok So I was looking though some programs on the gamebase files and I come across one that got me thinking about this. First off I know nothing about how to imbed ML in XB, the only time I have done it is with a loader that loads in the compiled basic progams I make. So Im looking at the file DRAGON[fix].zip in the disks folder in gamebase and the XB LOAD file on that disk is this program 0 !********************** 1 !* * 2 !* Generated By * 3 !* SysTex V1.0 * 4 !* (C) 1985 * 5 !* By Barry Boone * 6 !* * 7 !********************** 8 CALL INIT :: CALL LOAD(8196,254,0) 9 CALL LINK("SLOAD") 100 CALL CLEAR :: CALL SCREEN(9) :: FOR I=0 TO 12 :: CALL COLOR(I,16,5) :: NEXT I :: CALL LINK("CHARDF") 120 DISPLAY AT(1,1):"This program may be freely distributed. I translated itfrom Microsoft Basic to TI Extended Basic. Although" 130 DISPLAY AT(5,1):"many hours of typing and translation were expended, I do not ask for money.": :"I would ask, however, if you" 140 DISPLAY AT(10,1):"have any programs which you have written or translated, and would like to share,":"I would appreciate a copy. I am particularly interested" 150 DISPLAY AT(15,1):"in UTILITY type pgms. in anylanguage(Basic, Assembly, Forth, Pascal)." 160 DISPLAY AT(20,1):"Ken Woodcock":"4701 Atterbury St.":"Norfolk, Va. 23513": :" <press any key>" 170 CALL KEY(0,K,S) :: IF S THEN RUN "DSK1.STORY0" ELSE 170 The CALL LINK("CHARDF") is a program to redefine the char sets. So the question is, is there a way to pull that out save it and reuse it in another program? DRAGONfix.zip

Wow, I like that alot!

I dont know if you need to worry about sprites going out of the boarded because once it hits a certain area it will load in the next map. So take the last blue map you have a picture of, now take the top right exit. It is at rows 17 to 48. And column trigger can be set to anything we want. so if we keep the map width 30 like I did then we trigger the next map when the sprite hits column pixels 244. The sprite will never travel out of the area. Background color. If you have the boarder a different color that means you have to draw the blank path areas in the map. Thus adding to the time to draw each level, and extra code. Extra code not really a issue, all 30 maps at 10 bytes each is only 300 bytes. But now as I think of it quick draw of the whole screen to a single character is the same speed as clearing the screen to we could wipe the screen with blank tiles of grey. so lets try that in my program, change these lines 40 CALL SCREEN(1) 5 FOR I=1 TO 13::CALL COLOR(I,1,15)::NEXT I 6 CALL VCHAR(1,2,132,720) 100 CALL VCHAR(1,2,132,720) Yeah that is alot nicer to the eyes.

I have a 10 byte string to hold the map data including the color info. There is 4 bits to store info in left over. The castle doesnt have a gate as that is a game object. 10 CALL CHAR(128,"FFFFFFFFFFFFFFFF") 20 CALL CHAR(129,"F0F0F0F0F0F0F0F0") 30 CALL CHAR(130,"0F0F0F0F0F0F0F0F") 35 CALL CHAR(131,"C3C3C3C3C3C3C3C3") 40 CALL SCREEN(15) 50 HEX$="0123456789ABCDEF" 60 BIN$="0000000100100011010001010110011110001001101010111100110111101111" 70 DEF HEX2BIN$(X$)=SEG$(BIN$,POS(HEX$,SEG$(X$,1,1),1)*4-3,4) 80 DEF HEX2DEC(X$)=(POS(HEX$,SEG$(X$,1,1),1)-1)*16+POS(HEX$,SEG$(X$,2,1),1)-1 90 INPUT "ENTER CODE:":SCREEN$ 100 CALL CLEAR 110 COLOR=HEX2DEC(SEG$(SCREEN$,1,2))+1 120 CALL COLOR(13,COLOR,15) 130 REM MAKE BIT STRING 140 BITS$="" 150 FOR LENGTH=1 TO 18 160 BITS$=BITS$&HEX2BIN$(SEG$(SCREEN$,LENGTH+2,1)) 170 NEXT LENGTH 180 CASTLE$=SEG$(BITS$,2,1) 190 INVERT$=SEG$(BITS$,1,1) 200 POSITION=2 210 REM DRAW SCREEN 220 FOR ROW=1 TO 7 230 IF(ROW=1)+(ROW=7)THEN HALFROW=0 ELSE HALFROW=1 240 IF ROW=7 THEN LASTROW=2 ELSE LASTROW=0 250 FOR COL=1 TO 10 260 POSITION=POSITION+1 270 IF SEG$(BITS$,POSITION,1)="0" THEN 460 280 CALL VCHAR(ROW*4-HALFROW*2-3-LASTROW,INT(COL*1.5)+1,128,(HALFROW+1)*2) 290 IF INVERT$="1" THEN 320 300 CALL VCHAR(ROW*4-HALFROW*2-3-LASTROW,INT(COL*1.5)+16,128,(HALFROW+1)*2) 310 GOTO 330 320 CALL VCHAR(ROW*4-HALFROW*2-3-LASTROW,32-INT(COL*1.5),128,(HALFROW+1)*2) 330 IF COL=10 THEN 460 340 IF SEG$(BITS$,POSITION+1,1)="1" THEN 350 ELSE 410 350 CALL VCHAR(ROW*4-HALFROW*2-3-LASTROW,INT(COL*1.5)+2,128,(HALFROW+1)*2) 360 IF INVERT$="1" THEN 390 370 CALL VCHAR(ROW*4-HALFROW*2-3-LASTROW,INT(COL*1.5)+17,128,(HALFROW+1)*2) 380 GOTO 460 390 CALL VCHAR(ROW*4-HALFROW*2-3-LASTROW,31-INT(COL*1.5),128,(HALFROW+1)*2) 400 GOTO 460 410 CALL VCHAR(ROW*4-HALFROW*2-3-LASTROW,INT(COL*1.5)+2,129,(HALFROW+1)*2) 420 IF INVERT$="1" THEN 450 430 CALL VCHAR(ROW*4-HALFROW*2-3-LASTROW,INT(COL*1.5)+17,129,(HALFROW+1)*2) 440 GOTO 460 450 CALL VCHAR(ROW*4-HALFROW*2-3-LASTROW,31-INT(COL*1.5),130,(HALFROW+1)*2) 460 NEXT COL 470 NEXT ROW 480 IF CASTLE$="0" THEN 520 490 FOR LOOP=1 TO 3 500 CALL VCHAR(1,10+LOOP,131,2) 505 CALL VCHAR(1,19+LOOP,131,2) 510 NEXT LOOP 520 CALL KEY(0,K,S) 530 IF S=0 THEN 520 600 GOTO 90 TRY THESE CODES 0AFFC8721F83E0E803FC YELLOW CASTLE 01FFC8721F83E0E803FC BLACK CASTLE 0FFFC8721F83E0E803FC WHITE CASTLE 05BD41137CC03C0103FF BLUE MAZE 05BD515357143DF003FC BLUE MAZE FROM SOMETIMES POST 2 UP 093FF007FD0133F0C6B5 RED MAZE press any key after the screen draws to enter another code

Marc, I'm still putting around with Assembly but have not put much effort in to it this year. Maybe next year will be better for me. I hope

Guillaume, I have looked at MLC and it's not for me. Same with forth, great work for both but not something I feel like learning atm. John

compiled TIBASIC, no sprites

Thank you. I tried to animate everything I could. There is no limit to how much you can find but you can only carry 6 pearls and 6 gold pieces at a time. This limit really only affects the first few levels. Each time you go back to your boat the game gets harder and once the pirate ships starts coming out you will run out of time before u find a full amount of treasure. To make it a little harder you can not search the same piece of kelp or ship 2 times in a row. You must move around. I now remember one thing I forgot to implement that was a changing sky color for every level to show a change in the game state. But it is complete and playable!