Bones-69

I understand sprite magnification. I just never ever thought about using CALL MAGNIFY(3) sprites to display something in this manner (periods added for sprite clarity); GA ........ ME ........ OV ........ ER TI ......... 99 ......... 4/ ......... A! 1............2 .............3 ..........4 (SPRITE) 128........132..........136...... 140 (ASCII code) What can I say? It's a clever idea as opposed to using 4 times the number of Magnify(1) sprites to display text if you are trying to sneak in another "colour set" - without a full A-Z character commitment.

I spent a few hours shuffling characters and have come up with a workable solution but I have to say, I would have never considered using magnified sprites to trick the TI into displaying additional horizontal "sprited" characters! In this instance it wasn't practical because my problem was actually running our of definable characters (so I chose to solve the problem by actually using sprites), but what a clever idea to fool the TI into doing something it won't normally do. This one is certainly going into my little box of tricks for future reference.

Thanks guys. While this is not really what I really wanted to hear, I appreciated the info. Looks like it is time to shuffle some characters and try and gain another 5 that I can recycle from the same colour set.

I remember that when 4 or 5 sprites were lined up they would start to become invisible on the original hardware. My emulator of choice is Win994a and I notice that in regards to sprite reproduction it is not faithful (it is better!), as sprites never go invisible in Win994a. I would like my game to be playable on original hardware and can not remember if the sprites went invisible when they were lined up horizontal or vertical. My plan was to display the game score as sprites rather than placed characters due to colour set contradictions. Can anyone confirm for me if the sprite issue happened on the horizontal or vertical plane? Also, if it turns out the sprite flicker was for horizontal sprites, can I confirm which how many sprites were able to be displayed without problems? Currently the maximum score in my game is 99999 so I am hoping that 5 sprites will display properly. Ultimately I am trying to avoid having to reserve extra characters for a second set of numbers.... Thanks!

I think TI Invaders is the best Invaders game released on any platform. THE BEST! I am also a little surprised nobody has mentioned Fathom or Return To Pirates Isle..... RTPI was spectacular for its time.

Sorry for my newbie attitude - but it really is that easy is it??

I have been using RXB in preference over XB now for some time. I thought XB programmers not familiar with RXB might be interested in some of the added functions that I have found very useful. I reckon this is the XB that TI should have made.... CALL DIR - List drive contents from command prompt CALL HPUT - Similar to DISPLAY AT but you can place text from column one (As opposed to DISPLAY AT where you loose columns 1,2,31 & 32) CALL HGET & VGET - Similar to CALL GCHAR only you can grab up to 255 screen characters into a single string. CALL LDIAG & RDIAG - Similar to HCHAR & VCHAR but will place repeated characters diagonally. CALL CLSALL - Will close all open files CALL GMOTION - Returns velocity of moving sprites CALL RMOTION - Reverses velocity of sprites * Auto repeat feature for HCHAR, CHAR, VCHAR, COLOR, GCHAR, COINC, DISTANCE & others. * Cool ALL functions added to COLOR, MOTION, CHAR, RMOTION & others. * Able to use character sets 15 & 16 (but has some limitations when using sprites at the same time) * Able to redefine and color specify characters 30 & 31 (COLOR set 0) I haven't attempted to include all the extra stuff (have probably only mentioned 20% of it), but hopefully this gives a little snap shot of what I have found very useful. Also, I have never used RXB on a genuine machine, only under Win994a so can't comment on real machine performance..... And to top it all off, all existing XB programs will still run using RXB. Anyway... I think it bloody rocks! I have attached the RXB document for anyone who hasn't seen it Rich Extended Basic Manual.pdf

Attached are the files which seem to be causing some issues. I have "lost" my Photoshop at the moment, but when it gets re-installed I will post some screen shots of what the screen looks like just before it crashes (with a bad value in 1460 error). File.zip

So I only just recently found this place and missed the SSGC contest.... When is the next one?

There seems to be a bit of a bug in the latest version. When the screen is exported (I have only tried it in XB), there is a problem re-drawing the screen. Initially the characters are out of whack then the process halts with an error. I tried the same map using version 6 to export the text file with no problems. Not sure (because I didn't spend as long on it as I probably should have), but I suspect the map size data in version 7 might be causing the issues.

Playing with this latest version it has occurred to me that I can use the map layout to design my game data location files (keep in mind my game has no graphics). By changing the grid size to my adventure game spec's, I can create my world and then write a program to interpret the Magellan output, which then writes the required game location data files. Doing this would be so much cleaner and more accurate than the way I am doing it at the moment and make it very easy to change things along the way if required. There are a few limitations to my idea (mainly because not enough unique ascii character exist to cover my game world), but I can use this principal to take care of a large chunk of my game data/locations - especially for the repetitive and "no go" locations. Again Codex, thanks for this awesome program. The ability to also take care of sprite creation within the same program (possibly in a future version) will really go some distance in making this a great all round program. I would also like to echo what Opry said, excellent that you have been so enthusiastic to request and include our suggestions - I think it goes a long way to build something of great value that will have a very long life span.

Thanks Codex. I really can't begin to tell you how much quicker and easier this program/update will make my life. The latest changes really rock so thanks once more for your efforts in developing this awesome program.

Am really digging the latest changes, that's some great work - Thanks for your efforts! Another odd request..... Would it be possible to have a setting where you could type characters directly onto the grid rather than having to select individual chars with the mouse? Perhaps type in a single character and then tab to the next position similar to excel? This would be very handy for screens with lots of text. For what I am using Magellan for at the moment, this single function would turn Magellan into my best friend for designing screens with graphics and large amounts of text.

Really not sure at this stage. Maybe when I get closer to a working version I might look at the idea a bit more.

While you are playing with this request, any chance to get the selected charcters ascii number displayed somewhere on the screen?

I took a break from building the game files to do something a little more creative (and much more fun), and started finalising some of the player screens. Have attached a screen sample for a feel of the games appearance. It doesn't include the sprites which will be added later. Using Magellan for this has been incredibly useful. I have found it a little slow with some of the more delicate work (but I acknowledge the way I am using it is probably a little odd), but being able to work out the text placement, characters and colours using Magellan has been incredibly helpful. Prior to discovering Magellan I have been using Excel for a similar purpose and while it is quicker you just can't get a true appreciation of how you hope the finished screens will look. I suspect Magellan will get a real work out while LGB slowly comes together!

My preference these days is Rich Extended Basic (RXB) over standard XB. Under RXB you can simply type CALL DIR("DSK1.") for a disk catalogue, it's very handy and convenient. I have wondered the same.... Open Load Device? I really don't know, just guessing...

Mate, that is the one! Thank you *so* much. I am looking at the hex now that grapefruit created.

I remember many years ago a 8 X 8 font used in some programs. It resembled a type of "modern computer" font similar to the images attached. Have looked everywhere and even tried making them myself from scratch with little success. Would anyone have this font amongst their collection and mind posting the hex code for character 0-9 and A-Z ?

Yes, this is correct. In earlier versions the files were called LOCROM and LOCRAM. Then when I tore them all apart and took a different approach I renamed them differently just so I wouldn't get confused amongst all my notes. I suppose calling them GRAM and GROM is quite misleading in regards to discussions.... might have to rename them again!

Whoops.. Forgot the attachment.

This is actually something I was also thinking. Once the game is complete it wouldn't be impossible to build an editor. In all honesty I don't think this is something that will ever happen, but it would not be all that difficult. Below is a small sample of a map which better illustrates how the locations (where a player can't go) are used in the program. Looking at the centre location in grey which is a spaceship wall, it can be seen how one location can be multi-sided and used as a blocker when the player is in different parts of the map, this is also good for me because I don't have to double up on the data during map creation. In certain parts of the game these types of locations can be renamed, or destroyed, or unlocked allowing the player to move into secret or new locations - all that is required is the 5 GROM files and 3 GRAM files for a particular location need to be replaced with different data, in fact - the GROM files themselves carry event tags that instruct the program which file numbers to replace the data with, so it becomes all very automated within a single IF/THEN statement within the program, rather than having special lines to cater for each individual event in each location (which would mean numerous additional commands and excessive processing of IF/THEN commands throughout the game).

I was invited to start a thread on a game that I have been working on now for about 2-3 years. I find that my interest in this project comes and goes as I seem to work on it for a few months then take a few months off…. This approach has not resulted in quick progress as it is difficult to pick-up where I left off upon each return. I also seem to return with “better ideas” after a break – maybe that part is good, but if I never get it finished all the good ideas in the world won’t count for anything. I was a little reluctant to start this thread because realistically my game is probably still at least 12 months from completion and several aspects of the idea are still very much in development. However, after finding the AtariAge TI forum I have been infected with new motivation after seeing just how active the TI community still is (which is so great to see). Basically, my game known as LGB (Little Green Bastard), will be a text adventure game written with the Win994a Simulator and Rich Extended Basic. For a long time I contemplated what version of BASIC I should write it in before finally deciding that RXB was the most suitable. Now after using RXB for some time I am left wondering how I could ever return to XB as some of the RXB features are fantastic and I think compliment the standard XB language very well. Like most adventure games, your task is to save the world (or the entire universe in this instance). You as the player are awaken from a deep space sleep aboard your spacecraft to the sound of your ships security siren. Suffering hibernation sickness you stumble around to discover that while you slept your spacecraft has been boarded by aliens (hence the title Little Green Bastard). Your spaceships computer shows that the hyperdrive fuel source (an incredibly rare material that has not been manufactured for over 1000 years), has been removed leaving your ship without light speed engines. This rare fuel source, in the wrong hands, can be used as a weapon against all life in the known universe. Video footage from your computers security log confirms the worst, you have been boarded by a hostile alien race that has a violent dictatorship history. Your mission is to track down and stop these alien bastards, retrieve what has been stolen from you and save the known universe. Your adventure takes place on your spacecraft, different planets plus a moon –however, most of your adventure is conducted on an artificial planet similar to Earth that was originally created for international space tourism. Corny huh?  A few things I wanted to achieve with this game. I didn’t want it to be one of those games where the main challenge was to use exactly the right word to achieve a task and due to this a large flexible vocabulary is built in (although only two word commands are accepted). Also, I didn’t want to create a game that ends in death because a player took a single wrong turn or fell over in the dark, in this game it is impossible to die. I also wanted to create an adventure game that could be finished with or without performing every aspect of the game. This game will keep score so when/if it is completed you have a target to beat the next time around. Final score is determined by secret locations found, achieving missions along the way, remaining health and energy plus the state of your finances at game completion. For a text adventure I think my project is pretty ambitious. The LGB world consists of 1225 locations made up of a grid 35 x 35. While this probably sounds a little absurd and overdone, the player can not (nor has to), visit this many locations. For example, a player might be walking down a hallway with a wall on either side. Their current position is classed as one location, as is each opposite wall. So in this particular example 2 game locations are never actually used. In time I will try and post some graphics to make this point a little clearer. I chose this method because it gave me a lot of flexibility in my game design, as well as being able to easily change the game map during creation and also during actual game play. Each of the game 1225 locations is described by 5 different files which each consist of a 10 digit variable. These location variables are located in a single disk file know as GROM (Game Rom) which is 220K in size with a total of 6125 records. As I make progress I am looking at using this same file to store other GROM data so this file will likely increase in size and records. Obviously with this amount of data, 32K was never going to cut it so there is a second file used known as GRAM (Game Ram). Gram is used to store the variables of each location that can be altered during game play. The GRAM disk file consists of 3675 records (3 records for each location) and each record is also a 10 digit variable, the file size for the GRAM file is 133K. The 3 records in the GRAM file are updated each time the player leaves the current location so nothing about individual locations is stored by the TI memory, every ounce of TI memory is used for the actual program with limited stack used for variable values. While there is only one GROM file for LGB, each unique LGB game slot will require its own GRAM file. The GRAM file is effectively a snapshot of the complete saved-game world at any given time while the GROM file sets the location physics and characteristics. For each 10 digit variable found in the GROM and GRAM files, anywhere from 4-11 variables are hiding in each 10 digit record (I managed to squeeze more variables out of the single number-string by giving them a positive or negative value, and also a decimal point in some instances). I chose to store them as a "string-number" rather than a string due to the reduction in file size between saving numbers and text. I found I could save a number such as -.123456789 in a FIXED 9 file yet to store the same characters as a string the file size was MUCH larger. Therefore, combined GROM and GRAM files represent around 60,000 different game variables. GRAM and GROM files will each occupy one open DSK file. A third open file will be used to access several files for all the game text, character definitions, screen draw data and the objects found in the game. Because of the nature in which the program data is stored the DSK#.LOAD program must always be first executed prior to starting each game. During the LOAD program the player selects the game slot (from previously played games or “blank games slots), LOAD also checks the integrity of the selected GRAM files to check it has been correctly closed during the last game play (this will only take a few seconds). The LOAD program also loads most of the graphics in advance to keep as much unnecessary code out of the main program. Originally I wanted my game to fit on a single emulated 1.44mb disk but it is looking like this will now not be possible. Upon completion I expect the game to use two disks, the second will hold the save game slots (the GRAM files) along with any other data required for saving program variables. So there you have it, a snap shot of my project. Speed of the program and the available memory have played a very large factor in the way I have designed my program and the DSK files used. I am aiming for “thinking time” between commands to be around 5 seconds but at this point can’t confirm this. Currently there is no program to speak of that I can post and even if there were it would be useless without the large GROM and GRAM files used during the game. I have developed around 20 routines for the game engine(and re-written these over and over and over to make them as small and as slick as possible), I have developed the structure of all the files plus have a game map that I am still making small changes on. I guestimate close on 500 hours have been invested over the last 2-3 years to get to the stage I am currently at. Excel has been used extensively during the game design so when the time comes the data will be exported to a word document and then imported as required. This is something I am looking forward to, once this is done the actual program should then come together quite quickly. Probably one of the reasons my motivation has come and gone is due to the lack of programming required at this stage, so far it has mostly been preparation of the enormous amount of data required for the game which compared to programming, I find quite tedious and a little frustrating. All I want to do at the moment is start throwing the game together (building the program), but until the data in the files is finalised there is not much else I can do at the moment.

I thought this might be a good place for tips on XB programming.... I have one! We probably all know that the use of sprites can slow XB down. I did some testing with the following programs; Example 1 100 CALL CLEAR:: CALL INIT :: ! FOR A=1 TO 28 :: CALL SPRITE(#A,65,2,100,100+A) :: NEXT A 110 INPUT A$:: FOR I=1 TO 100 :: PRINT I :: NEXT I :: INPUT A$ The execution time for this was around 9 seconds. I used this program as a method of "calibration" Example 2 100 CALL CLEAR:: CALL INIT :: FOR A=1 TO 28 :: CALL SPRITE(#A,65,2,100,100+A) :: NEXT A 110 INPUT A$ :: FOR I=1 TO 100 :: PRINT I :: NEXT I :: INPUT A$ The execution time for this was around 9 seconds. Putting 28 sprites on the screen but not specifying a velocity seems to come at zero cost. Example 3 100 CALL CLEAR:: CALL INIT :: FOR A=1 TO 28:: CALL SPRITE(#A,65,2,100,100,50,50) :: NEXT A 110 INPUT A$:: FOR I=1 TO 100:: PRINT I :: NEXT I :: INPUT A$ The execution time for this was around 13 seconds. Putting 28 sprites on the screen but specifying a velocity comes at the cost of speed and I got the same results when specifying a zero sprite velocity by replacing the sprite command with CALL SPRITE(#A,65,2,100,100,0,0) Example 4 100 CALL CLEAR:: CALL INIT :: FOR A=1 TO 28:: CALL SPRITE(#A,65,2,100,100,50,50) :: CALL MOTION(#A,0,0) :: NEXT A 110 INPUT A$ :: FOR I=1 TO 100:: PRINT I :: NEXT I :: INPUT A$ The execution time for this was also 13 seconds. It appears that once you put a sprite in motion and stop it, there is still a cost in execution time as the sprite checking continues even on those sprites that are now stationary - but originally had a velocity specified when they were created. Example 5 100 CALL CLEAR:: CALL INIT :: FOR A=1 TO 28:: CALL SPRITE(#A,65,2,100,100,50,50) :: NEXT A :: CALL LOAD(-31878,0) 110 INPUT A$ :: FOR I=1 TO 100:: PRINT I :: NEXT I :: INPUT A$ The execution speed for this was back down to 9 seconds. COOL! In example 5 the CALL LOAD command seems to not only stop sprite motion, but it reverts back to the same result as my example 2 where velocity was never specified. CALL MOTION (#?,0,0) does not do this and you still pay the price of execution speed even after stopping sprite movement. Fiddling with the program, I used CALL PEEK(-31878,B) to discover that the value of B is not the highest sprite displayed on the screen, but the highest sprite that has had a velocity originally specified regardless of if it was still in motion. Using CALL LOAD(-31878,20) for example stopped sprites 20-28 from moving and gave an improvement over execution speeds where sprite checking for those 8 sprites was turned off. CALL LOAD(-31878,10) stopped 18 sprites and resulted in again better execution time. I think using CALL LOAD(-31878,#) is a pretty cool way to stop and start several sprites at the same time, but also found it interesting that you can milk a little more speed from XB using this method to switch off sprite checking for the sprites you no longer wish to be in motion (but still want displayed on the screen). While it is not as flexible as the CALL MOTION command where you can stop an individual sprite (say #20 & #22- but still have #21 in motion), I can see uses for this tip in certain applications. In the instance of the 28 sprites that are completely reset using the CALL LOAD command, there seems to be an improvement of almost 50% in execution time which I though impressive. The above was tested using WIN99/4a and the RXB cartridge. I assume the results are the same for standard XB in original hardware with 32K memory but haven't and can't check....

Well don't I feel silly.... That's awesome. Thanks!