Bones-69

WOW.

Wow. Disc access. Downloading.

* Watching in excitement.

Is disk file access something that is eventually likely Harry? I have had some ideas kicking around for some time but I haven't been able to work around the challenge of requiring a lot of text data.

Amazing Harry. Thank you so much for this contribution.

The crazy thing was - I hadn't forgotten this at all. You know - because a GOSUB command has a line number, it just never occurred to me that I was breaking the rules. By the way Senior, thanks again for your work. I am having an amazing amount of fun with this compiler!

Hey - loving this. Good wholesome XB fun! I am fooling around with some stuff at the moment and the player action in mine is kind of similar to yours. I didn't use any CALL MOTION though and instead used CALL LOCATE which has its own execution speed challenges (running too fast!). I am using X / Y coordinates and trying to take advantage of the way the compiler forces integers. In other words - I update screen positions using CALL LOCATE (#1,Y/10,Y/10). The sprite position will not change unless there is a minimum increase/decrease of +/-10. This means I can add smaller amounts to the coordinates and slow things down by up to 10 times if needed. I guess I am just re-creating a decimal point which has one position....... I have attached my compiled version so you can see the effects. You might enjoy playing with the Custom Menu numbers by entering different values and seeing the speed change - there is some flexibility there to go very fast or very slow using this method and CALL LOCATE. If the XB listing is of interest I can post. There are no brakes in my controls. Left and right arrows change the direction you are facing and the up arrow pushes you in that direction, a little like Asteroids I guess.... I like that you can rotate while power sliding then hit the thrust to get going again! SLIDES-C.zip

After many hours I *think* I have found where the compiled error is coming from. I felt the nature of this one was a little odd because under normal XB everything worked as expected, but when compiled things went wrong. Anyway, I am putting it out there for contemplation. Old version; 340 IF YI=0 THEN 370 350 IF YI<0 THEN GOSUB 440 :: GOTO 370 360 IF YI>0 THEN GOSUB 450 370 IF XI=0 THEN 400 380 IF XI<0 THEN GOSUB 470 :: GOTO 400 390 IF XI>0 THEN GOSUB 480 Re-written which when compiled now runs. I think the drama was due to the GOTO commands in lines 350 and 380 which appear after an IF/THEN/GOSUB command. 340 IF YI=0 THEN 390 350 IF YI<0 THEN 360 :: GOTO 370 360 GOSUB 500 :: GOTO 390 370 IF YI>0 THEN 380 :: GOTO 390 380 GOSUB 510 390 IF XI=0 THEN 440 400 IF XI<0 THEN 410 :: GOTO 420 410 GOSUB 530 :: GOTO 440 420 IF XI>0 THEN 430 :: GOTO 440 430 GOSUB 540

Harry - or other smart guys... I am fooling around trying to get a little routine working but when compiled it seems to randomly crash (I am sure it isn't random). I have gone over and over the program and can see nothing that should cause the compiled version to crash - it does do the right thing when testing under standard XB. It's probably something obvious but after hours and hours and just can't find it so I thought it worth checking I hadn't found an unknown bug. Any ideas? Only controls are the L, R and Up arrow keys and there is no error correction for reaching the screen boundary so leaving the screen will give an error - but this isn't the one that is an issue Thanks guys.. 100 CALL CLEAR :: CALL SCREEN(2):: CALL MAGNIFY(3) 110 X=1000 :: Y=1000 :: XI=0 :: YI=0 :: D=3 :: DIM D$( 120 C1=10 :: C2=20 :: MT=12 130 RESTORE 490 :: FOR I=1 TO 8 :: READ D$(I):: NEXT I 140 CALL CHAR(128,D$(D)):: CALL SPRITE(#1,128,16,INT(Y/10),INT(X/10)) 150 FOR I=1 TO 14 :: CALL COLOR(I,16,2):: NEXT I 160 C=C1 :: E=0 :: CALL KEY(0,A,B):: IF A=-1 THEN 250 170 IF A=8 OR A=9 THEN 180 ELSE 250 180 ON A-7 GOTO 200,220 190 GOTO 240 200 D=D-1 :: IF D<>0 THEN 240 210 D=8 :: GOTO 240 220 D=D+1 :: IF D<>9 THEN 240 230 D=1 240 CALL CHAR(128,D$(D)) 250 DISPLAY AT(3,1):"D(I)=D(";STR$(D);")" 260 IF A=11 THEN 270 ELSE 330 270 C=C2 :: E=2 280 ON D GOSUB 450,450,430,440,440,440,430,450 290 ON D GOSUB 460,470,470,470,460,480,480,480 300 YI=MIN(MT,YI):: YI=MAX(-MT,YI):: XI=MIN(MT,XI):: XI=MAX(-MT,XI) 310 DISPLAY AT(4,1):"YI=";STR$(YI);" / XI=";STR$(XI) 320 CALL LOCATE(#1,INT(Y/10),INT(X/10)) 330 C=-C1 :: E=1 340 IF YI=0 THEN 370 350 IF YI<0 THEN GOSUB 440 :: GOTO 370 360 IF YI>0 THEN GOSUB 450 370 IF XI=0 THEN 400 380 IF XI<0 THEN GOSUB 470 :: GOTO 400 390 IF XI>0 THEN GOSUB 480 400 DISPLAY AT(4,1):"YI=";STR$(YI);" / XI=";STR$(XI) 410 CALL LOCATE(#1,INT(Y/10),INT(X/10)) 420 GOTO 160 430 Y=Y :: RETURN 440 YI=YI+E :: Y=Y+C :: RETURN 450 YI=YI-E :: Y=Y-C :: RETURN 460 X=X :: RETURN 470 XI=XI+E :: X=X+C :: RETURN 480 XI=XI-E :: X=X-C :: RETURN 490 DATA 0000000103070101010101010100000000000080C0E080808080808080000000 500 DATA 000000000000000103070E0C00000000000000783878E8C08000000000000000 510 DATA 000000000000001F1F0000000000000000000000002030F8F830200000000000 520 DATA 000000000C0E070301000000000000000000000000000080C0E8783878000000 530 DATA 0000000101010101010107030100000000000080808080808080E0C080000000 540 DATA 000000000000000103171E1C1E000000000000003070E0C08000000000000000 550 DATA 0000000000040C1F1F0C04000000000000000000000000F8F800000000000000 560 DATA 0000001E1C1E170301000000000000000000000000000080C0E0703000000000

Here is a list I was working on some time back (hope the formatting isn't too painful.). There are quite a few duplicates compared to the OP but also some additional stuff. It was a work in progress so descriptions are a little on the rough side. * Edit - Sorry. Formatting went crazy. I will attempt to import differently and re-post when sorted.

My interest was mainly in the scroll sub programs and having these available in compiled code. But I completely understand what you are saying, especially as if a general rule XB256 hasn't been well embraced.

Hey Senior, Seeing as though this thread has been bumped.... Thought I would ask a feature question. I *think* I remember reading that some of the awesome stuff from XB256 was going to be made availble for XB compiled programs. Is this something that is still on the horizon?

That's mad. I really didn't think our little TI was anywhere up to the task. Fantastic!

Rygar! http://en.wikipedia.org/wiki/Rygar

I haven't read the thread, just did the download and wanted to try it and WOW. This is fantastic! Bloody great work on this one. Now to go back to page one...

I would suggest playing around with the fun stuff that gives instant gratification. CALL HCHAR, CALL CHAR, CALL SOUND. All easy to grasp, then start changing numbers and plugging values into loops etc. You will have fun!

>Command me: EAT KEY >OK. >YOU BEGIN EATING IT AND START TO CHOKE. YOU SELF HEIMLICH AND PUKE IT BACK UP. YOU DON'T FEEL VERY WELL"

I had some ideas that were working very well with an adventure game I started writing. Right from the start the environment was huge, which probably killed off the later enthusiasm because although everything was working as I hoped - It ended up just going on and on and I ran out of energy. It just never ended! But anyway, because of the size it was always designed to use huge disk files. Because I used a lot of disk access the basic program ended up being surprisingly small. So anyway... Right from the start I decided to limit commends to one or two words only. The first thing that was checked is that more than one space did not exist in the command. I pulled it right up there so down the track I had some control. To start, every verb I could think of I put into maximum strings (stored in arrays), in a form like this; V$(A)="#GO-01#GET-12#JUMP-02#KILL-78#OPEN-15#LOOK-03#EAT-32#SWIM-17....etc " And I made the strings as long as possible. To confirm a verb was valid I would search for the term in the strings (I found this better than assigning every verb its own unique array value and searching for a match - especially as the number of verbs grew). The hash prevents finding partial words within other words as I always forced the search criteria by VERB$=HASH CHAR & COMMAND$. The "-" acted as a marker for the end of the word and the 2 digit number gave the verb a value. This value could then be inserted into inventory or objects to create the illusion of a huge response vocabulary . For instance you might say - "eat key". "eat" would be identified as having a value of 32 in this example. The key would have variables that confirmed things like if it was visible or hidden, if it was steel or plastic, would it burn, would it break, could it be eaten... etc. I stored these values in single strings which I read/wrote to files so the values were somewhat dynamic. I would create more strings for the environment and ALL objects. For instance you are in a room with the key (every item has its own location value), and attached to the key is a string with stuff that might look like this; "#12-455#03-322#01-122-#32-555.... etc". In the instance of EAT (32), I would search for #32. When/if found,I would then read the next 3 digits which referenced a disk record where the response could be retrieved. I found this worked very well, it was extremely easy to edit/add/change on the fly. This is a pretty quick overview of the method I was using.

Hey Manic, not really on topic - But I am interested in your Mame cabinet as I also built one. Care to post a link or picture of your creation?

Wow - You guys really run with stuff quickly around here! If this ever eventuates it would be quite remarkable, considering Wolf/Doom came out more than a decade after the TI!

For some time I have been thinking about a sprite catalogue program. Something where you can store sprites, search them, categorise them and store collections for animations etc. I would write it in XB and have it use disk access (because this is all I know), but it would be cool to have a real TI community solution though….

I have had an idea for some time. Never seem to get around to putting my ideas into practice so thought I would share. This one seems like a doozy and maybe it is just too far out there. I always imagined a first person type shooter for the TI99/4a, possibly even something that would run in XB or now perhaps potentially be XB Compiled (would require disk access though). My idea would be to make a simple world in 2D then have a program assemble the world in 3D. With character limitations the world would have to be quite basic. Maybe as complex as it can get would be just 3D blocks, or a hallway/Tunnel Of Doom type view, or maybe something like Atari Battlezone with very simple wire frame graphics. My idea is to have a program assemble the players view in advance from every possible position of the game, along with every direction they can look and save each view to disc. Perhaps for the player to do a 360 turn it would require 8 different views (N,NE,E,SE,S,SW,W,NW) from every potential position in the game so every possible position would require 8 individual files or "screen shots". Each of the thousands of potential views would be sent to a disc file and called everytime a player commands their character to move or turn. A single disc read for each file consisting of 252 characters would allow DISPLAY AT to create a player view measuring 9 x 28. More than enough space I think to make it interesting. I am just throwing ideas around…. But say you had a game grid 100 x 100 and in that grid was “Blockworld”. Using emulation (because of physical disc space limitations), you could tell your trusty “TI 3D world creator” to start deciphering the 2D map and start writing files (the drawn images). Once file 80,000 was written you would have a 3D world with 1000 positions all with a view from 8 directions which could be explored. As updating the world during game play should be as simple as a single disc read and a DISPLAY AT statement, this would leave all remaining grunt to run sprite routines and give the world some action. The same idea could be used for pretty much any game where a first person perspective was required. Perhaps there is also some potential here for car racing games where a similar pricipal could be used to display the upcoming track... I have to confess - I really wouldn't know where to start in regards to writing the program which initially creates and writes all the views. Would be a great challenge though! Possible or just the result of too many late nights?

I downloaded XB256, read through the documentation and tried the demo. This is bloody fantastic!! Only problem is now that this does everything I ever wanted, I don't know what to do with it! Looking very forward to messing around more with this and additionally excited if/when the XB compiler can handle these new commands. Great work Senior. For the dedicated XB programmers amongst us that could never get our minds around assembler, we can finally produce stuff that is somewhat comparable with the assembly guys. AWESOME.

Program is attached. Look forward to if anyone finds it useful. Now I can get on with some cool compiling. Edit - Sorry to anyone who downloaded, I had some old stuff in there I didn't tidy up. Attached is the corrected file. XBSDUMP.zip

I am a big fan of Magellan and pretty much everything I do these days starts of with a Magellan screen. As I am sure everyone knows, Magellan will export the screen to XB. When it does this it uses a draw method to put each of the 768 characters in its place one at a time (pretty slow). Each of the 768 characters are exported by their ASCII value. The amount of data required to define a full screen is therefore anywhere between 1,536 bytes and 2,304 bytes depending on the mix of character values. For some time I have been using Magellan to draw a screen then attaching a little program to scan the screen and turn it into actual characters which were saved to disk. So it basically took screen data originally drawn by; DATA 33,33,65,33 and turned it into DATA "!!A!". To draw a screen I would use DISPLAY AT and then fill in the blanks for column positions 1,2,31 & 32 with the same type of data (consisting of 96 characters), but using CALL HCHAR here. Excited by the XB compiler I realised I can not use this method to get a screen from Magellan into the XB Compiler due to it not currently supporting disk files. The problem didn't seem difficult to overcome because I was happy to copy/paste this data into a text editor and get it sorted from there (I just can't go back to programming complicated screens with endless call HCHAR/VCHAR statements only to spend hours trying to get it right, I just won't!). So when I started to copy/paste my data from the disc files across to Notepad (using Ti99Dir) in order to prepare it for copying into a program to be XB Compiled, I realised that it was corrupting all characters from 127 onwards. If I wrote a file which contained character 128 and above it would bring it over to my text editor as character 46 and my data was lost. In order to overcome this problem I wrote a program I have named XBSDUMP. It will scan the screen and remove any character under 32 and over 128 (and also character 33, the quote). These excluded characters are put into a string/s for writing to the screen with an additional process. Initially I decided that each excluded character would need to take up to 7 bytes to in order to be redrawn (2 for the row, 2 for the column and up to 3 for the actual character being excluded). When I started to work this it became apparent pretty quick it was not beneficial. If for example there were 200 excluded characters found in a single screen then it would take up to 1,400 additional bytes just to record this additional data, potentially there exists the opportunity for the entire screen to be filled with exempt characters so I needed something a little better. To get around the problem I shifted characters above 126 ASCII down in value by 33 and saved the character this reflected instead. Character 127 became 94, character 159 became character 126 - these are characters which can be copied/pasted with no problems. At the other end of the scale for characters 0-31 (and character 34), these were shifted up 43 positions so again they could be accurately preserved. For ROW/COLUMN, a value of 1 is represented by character 78 through to 32 which is represented by character 109. This results in data which rather than looking like DATA 10,22,134 now becomes DATA "Wc=". So I was at least able to store 3 values into the space occupied by no more than 3 bytes. The reason for the explanation is that while the program works in every instance I have tested, Screen shots with a lot of excluded characters will result in larger files, which may or may not be a issue. For each additional excluded character in any screen there are 3 additional bytes of programming space that will be taken. In a native XB environment this will also add additional processing time drawing the extra characters, but once compiled it becomes very smooth and depending on the screen, somewhat instant. How to use. -This program was designed with Magellan in mind. To use with Magellan, copy/paste the program into the exported Magellan XB program. -To capture any screen, either import into the current program or execute a RUN "DSK1.XBSDUMP" once the screen you wish to capture is displayed (it can also be run at the prompt). Originally I had planned for this program to be smaller so MERGING into any program wouldn't be much of a concern but it quickly grew to a few hundred lines of program so in many instances RUN "DSK1.XBSDUMP" will be the best option if memory is getting tight (The program itself uses almost nothing to run). -Once the screen has been processed a file is created with the name you choose. In this file are two programs which can then be viewed/copied with Ti99Dir and then pasted into Classic99. These programs and are ready to be XB compiled and contain no illegal Syntax. OR - the results can be pasted to a text editor without corrupting those problem characters. User settings Because this program processes the screen it is presented with, all user setting can be found in lines 8009 - 8018 (The default setting for these values are listed in line 8008). LN = Program line number start LI = Program number Increment DLN = Data line start (LI is used for data line increment) SPE = This value will allow you to choose is character 31 should be reproduced as character 31 (more programming space/data required), or if it can be recorded as character 32 which saves programming space. LM = Magellan line number for CALL SCREEN data. Only useful if merging into Magellan exported program. For a 24x32 exported Magellan XB program using defaults, this line number is 900. CDR = Choose if character definitions are required in exported program/s. WC = Gives the option to reduce programming space by shrinking char characters down where possible. ie- "00FF0000000000" is recorded as "00FF". This setting is only applicable for the Program #1 in the exported file. Program #2 defaults to sprite style character definition to assist with speed under XB only conditions. EC$ = In Magellan, characters which are simply blaked out are not exported as "0000000000000000" but rather they are skipped. So if you want to display a CALL MAGNIFY(3) Sprite, and any of the 4 characters are supposed to be blank, the Magellan data will not cater for this and they will remain pre-defined. I get around this problem by specifically defining a blank sprite as a chosen character. Then using a CALL CHARPAT command I can search for such characters and have them correctly defined as a blank character. If this function is to be used then set EC$ to a character of your choosing and if discovered it will be defined as blank. I personally tag my blank characters with this little guy "3C5ADBFF18244281". D = Disk drive number for output files (There will be two files, one contains two programs which can be copied/pasted, the second with extension "-S" is a scratchpad and also contains formats of data which may be useful). FN$ = File name * Please note I have not included any error checking. If any of the above values have not been correctly set then the program will crash or may give unexpected results. * Any character between 0-159 will be displayed to screen if found, however character under 32 and over 143 will not be hex defined. The characters go up to 159 to support RXB users, although this shouldn't be required as RXB users have file access plus some additional commands which largely obsolete this program. * It takes a long time to complete a screen scan. I haven't timed it but guess it is probably 15 minutes. Much better to run in CPU overdrive....