Bones-69

I tried once, a few years ago. I sourced myself some TI assembly books and started reading. None of it was intuitive compared to my current knowledge. I literally did not comprehend a single thing I was reading and nothing was falling into place. I guess I gave up within just a few days. I've been a TI guy in one form or another for over 40 years and would love to learn Assembler. But the honest truth is - I just don't think I am intelligent enough.

I re-wrote the files and changed the way the program ran so now it only requires the use of 2 dimensional arrays. The execution speed increased by about 5% and I salvaged back about 500 bytes in program space (so all up it was a win). I was still hoping for a more impressive speed increase but I guess this is what I have to work with. Realistically by the time everything else is going on - the characters will probably slow to maybe 75% of their current speed. I don't think I can get anything more from it. I haven't tried the string method yet that I discussed above.... 2000 ON AS(1)GOTO 2100,2010,2010 ! 2010 CORRECT LATER FOR OPTION 2&3 2010 PRINT "STOPPED 2010" :: STOP 2100 AE(1)=AE(1)+1 ::A1=AL(1):: ON MT1(MIR(A1),AE(1)) GOTO 2300,2150,2110 ! 1.STANDARD 2.INCREMENT LOC. 3 N/A 2110 PRINT "STOPPED 2110 @ DECREMENT REQUEST" :: STOP 2150 A1,AL(1)=AL(1)+1 :: IF A1<>91 THEN 2160 ELSE AS(1)=1::A1,AL(1)=1::AE(1)=7:: GOTO 2300 2160 AE(1)=2 2300 ! Continue 2700 CALL LOCATE(#1,MSY(A1)+MY1(MIR(A1),AE(1)),MSX(A1)+MX1(MIR(A1),AE(1)),#2,MSY(A2)+MY1(MIR(A2),AE(2)),MSX(A2)+MX1(MIR(A2),AE(2)))

I had this as a kid but don't ever remember buying it. Did it come with the TI system? Maybe a school buddy just put a copy on a TDK tape for me back in the day.....

This is interesting to know and I learned something similar in a recent thread. I'm confident I can reduce the two 3 dimensioned arrays down to 2 dimensions as the second/middle dimension can only have a value of 1 or 2. I'll have to rewrite the DSK files and branch the program earlier so I can manually specify these separate values- but I can already think of something that could yield a faster executing result (at the expense of more program lines - but not additional processing). There are basically two sets of 8 matrixes that can potentially plug into a screen position. These control the sprite offset and therefore determine the movement effect (bounce or float). The third position in the 3 dim arrays returns the sprite X/Y adjustment values. The ultimate goal is to reveal these values. I'm wondering how it might work if I created strings with all the X/Y offset values and just sequentially SEG$'d my way through them. This could get me down to a single dimension string array but I would have to VAL() the SEG result before it could be used. I don't know if SEGing and VALing would be faster or slower than simply using a 2 or 3 dimension array. I'd initialize the string values from disk but would still have to deal with the overhead of 32 strings each 72 or 76 characters in length. That sounds pretty expensive and I don't think I can afford this. Having said all this... there are a few VDP functions in XB256 that I have not yet taken the time to understand. Maybe some of these can be also utilized. I'll hit the books and sleep on it for a few days. Good news is I've now got some fancy spreadsheets that produce all the export data so manipulating things to test new ideas will be a breeze (as compared to creating them in the first place). I'm now hoping I to see a return in the time I invested in getting the spreadsheets to produce all my data statements.

Agree on the 3 dimensionsional arrays - I only recently started understanding the speed impact of using these (I always thought they were a free lunch!). I'm thinking I might be able to reduce some of the array processing by branching my program to handle specific values. It will add a lot more lines to the program so I'll fiddle and see how memory space is looking....

So my idea works but I was hoping it would execute a bit quicker. Maybe I just need to downgrade my expectation and reduce the number of enemies in play.... With only one or two is was quite quick. I'll try re-writing it a few times and do some time testing to see if I can improve on the execution speed. This is what I have working at the moment (just multipled by 4 times for each enemy). There is potentially some double handling that I might be able to clean up a little. 2000 ON AS(1) GOTO 2100,2010,2010 ! 2010 CORRECT LATER FOR OPTION 2&3 2010 PRINT "STOPPED 2010"::STOP 2100 AE(1)=AE(1)+1::ON MT(MIR(AL(1)),1,AE(1)) GOTO 2200, 2150, 2110 ! 1.STANDARD 2.INCREMENT LOC. 3 N/A 2110 PRINT "STOPPED 2110 @ DECREMENT REQUEST"::STOP 2150 AL(1)=AL(1)+1::IF AL(1)=91 THEN GOSUB 5000::GOTO 2300 2160 AE(1)=2 2200 A1=AL(1)::P1=MIR(AL(1))::P3=AE(1)::CALL LOCATE(#1,MSY(A1)+MYA(P1,1,P3),MSX(A1)+MXA(P1,1,P3))!::GOTO 2000

I absolutely agree, but in this instance I seem to need an enormous foundation just to test the basic concept. That's OK - I'm rusty and have forgotten a lot. Having to write all the disk files and work stuff out has been a good refresher. I'm probably now only a few more hours now from having something animated on the screen to see if my idea performs as hoped.

I've been doing some work on this game and started writing the DSK files which will initialize most of the program variables. I had a vision of how the Invaders would move through the game screen and I wanted them to have a bounce in their stride. While the invader is airborne it can't be destroyed - only when it touches the ground can the players bullet take it down. I expect this should increase the difficulty somewhat.... The game will have 91 locations that the Invaders can occupy (although two are not used), and each location has fixed predefined sprite coordinates. By plugging in one of 8 "matrixes" into each screen location I can adjust the position of the Invader in reference to the Fixed location position. In sync with the individual matrix values (and new Invader screen position), I can overlay values that relate to coinc detection (CALL COINC will not be used), and general events that occur during movement through the screen location (maybe a beep when the aliens touch the gound, etc). I'm really chewing into memory with all these references but I am hoping the flipside is something that will run quite quickly, and with very few lines of programming. ON GOTO will be used very extensively. I'm testing as I go and monitoring memory so hoping not to get caught out. Of course this is still just an idea in my head that is only now unfolding to paper. Not sure if it will work yet!

Might need some help there. I know the syntax for making music, but don't have the musical skills to put anything together that has ever sounded good...

I've been working on this XB shoot 'em game idea and feel I have the basic concept now sorted along with a reasonable idea of how the program might run. Now that I'm happy with my charset - I guess I can start.... The way I see it, in this game you are the bad guy. You land on a space platform that contains precious crystals and start taking them. The local invaders aren't too happy... Invaders are beamed down from the mothership and proceed to zig zag down to the bottom of the screen dropping bullets along the way. The Mothership also shoots at the player (player can't shoot it back). Any Invader that breaches the final zag results in Game Over (player being invaded). The invaders will bounce through the zig zag in a tidy little routine I've been working on that should compile well. During play, by pulling back on the joystick for a few moments the action will pause and the game shifts into Strategy Mode where you can give basic Joystick commands to two miner droids. Their function is to go out and harvest exposed crystalls. The droids will suffer enemy and friendly fire and their health must be managed by returning them for repairs as required. A miner destroyed in the field will lose its crystal and need to be restored (penalty time and disadvantage). Meanwhile those aliens are also mining the same crystals. Any game that finishes where the Invaders have gathered more crystals than the Player will result in an overall loss and points reduction. I've decided to put the game on a timer so it doesn't drag on or become one of those infinite situations, although I am expecting it to be quite challenging and hopefully run at a quickish pace. Player will only have one ship although it does have a shield which can take some hits. I may or may not release "Power Up's" and "Timer Bonuses". I've allowed for such things but I have grand plans and only TI memory so we'll just have to see how it all goes and how it plays. I'm aiming for an early 80's arcade feel. I also came up will a cool name. Foray. Defined by Google as "a sudden attack or incursion into enemy territory, especially to obtain something". This suits the game theme nicely, but I mostly like the 4A pun and wonder if the name has been done before.... 😁

Thanks for the invite - but that's way out of my league.

Cool info here. Lot of stuff I never knew. Senior_Falcon I did a little more testing and was astonished to see the true cost of using 3 dimensional arrays. The testing method you have suggested seems solid. I might throw a little time at this. It would be interesting to get some insight into a whole range of functions and methods both for XB and for the relative Compiled code. I'm keen to throw everything into a loop and see if there are any unusual surprises. I haven't used the Classic timer so will read up on that as well.

I've been developing an idea in Magellan that looks great and everything about my idea seems doable, but I will have a lot going on at once so I wrote a little program to act as a "speed check". Initially I expected to visually see a difference in the speed of the little ball moving across the screen but this was not to be. My method was to run each test for exactly two minutes in native XB. I used a stopwatch and stopped the program each time at 120 seconds and then recorded the value of COUNT (which had been incremented every cycle). A higher number means a faster result. Test #1. Count 3433 200 A=B(A):: COUNT=COUNT+1 210 CALL LOCATE(#1,100,A):: GOTO 200 Test #2. Count 3066 *Slowest 240 A=A+1 :: COUNT=COUNT+1 :: IF A=193 THEN A=1 250 CALL LOCATE(#1,100,A):: GOTO 240 Test #3. Count 3888 *Fastest 280 FOR A=1 TO 192 :: COUNT=COUNT+1 290 CALL LOCATE(#1,100,A):: NEXT A :: GOTO 280 Test #4. Count 3500 330 A=A+0.05 :: COUNT=COUNT+1 340 CALL LOCATE(#1,100,A):: GOTO 330 Test #4 came a bit later in the thought process. Test #4 is the same as Test #2 less the IF statement. I expected the FOR/NEXT method to be the quickest, which it was. However if Test #1 and Test #4 are fair to compare, then this result surprises me a lot. If my method here is sound, then A=A+1 executes quicker than A=B(A). I simply expected anything that involved maths to be a lot slower than simply fetching a known variable. Even now this doesn't feel right. Also wondering if these results would transfer to XB compiled code? Which is ultimately what I am trying to work out here.... Unfortunately this is not easily testable with compiled code using my simple methods. Another noteworthy is how expensive the IF statement actually was. In Test #2 it seems to have consumed approx 15% of the processing time just to compare A against a value of 193. Maybe none of this is a surprise.... But not knowing how things work under the bonnet I gotta tool around like this and hope to fluke a good result. [code] 100 DIM B(193):: FOR I=0 TO 192 :: B(I)=I+1 :: NEXT I :: B(193)=1 110 CALL CLEAR :: CALL CHAR(128,"3C7EFFFF7E3C"):: CALL SPRITE(#1,128,2,100,1) 120 PRINT "1. A=B(A) ERR CHECKING N/A" 130 PRINT "2. A=A+1 WITH ERR CHECKING" 140 PRINT "3. FOR/NEXT ERR CHECKING N/A" 150 PRINT "4. A=A+0.05 N0 ERR CHECKING" 160 ACCEPT AT(24,1)SIZE(1)VALIDATE("1234"):A$ :: IF LEN(A$)=0 THEN 160 ELSE CHOICE=VAL(A$) 170 CALL CLEAR :: PRINT "VIEW VARIABLE *COUNT* AT END": : : :: ON CHOICE GOTO 180,220,260,300 180 ! EXAMPLE 1 190 PRINT "1.":"A=B(A) ERR CHECKING N/A" 200 A=B(A):: COUNT=COUNT+1 210 CALL LOCATE(#1,100,A):: GOTO 200 220 ! EXAMPLE 2 230 PRINT "2.":"A=A+1 WITH ERR CHECKING" 240 A=A+1 :: COUNT=COUNT+1 :: IF A=193 THEN A=1 250 CALL LOCATE(#1,100,A):: GOTO 240 260 ! EXAMPLE 3 270 PRINT "3.":"FOR/NEXT ERR CHECKING N/A" 280 FOR A=1 TO 192 :: COUNT=COUNT+1 290 CALL LOCATE(#1,100,A):: NEXT A :: GOTO 280 300 ! EXAMPLE 4 310 PRINT "4.":"A=A+0.05 WITHOUT ERR CHECKING" 320 PRINT :"IGNORE MOVEMENT SPEED" :: A=1 330 A=A+0.05 :: COUNT=COUNT+1 340 CALL LOCATE(#1,100,A):: GOTO 330 [/code]

Here is an idea I experimented with for checking sprite coincidence - without using CALL COINC. Running in XB it is as slow as expected. The intent was to use it with the compiler. Use arrow keys to generate a coincidence with the red cross. There is no error checking so if you leave the screen it's Game Over. 100 CALL CLEAR :: CALL SCREEN(2):: FOR I=1 TO 12 :: CALL COLOR(I,15,2):: NEXT I :: CALL MAGNIFY(3):: DISPLAY AT(24,1):"COINC:" 110 S$="!-30!-31!-21!-12!-13!03!13!12!21!31!30!3-1!2-1!1-2!1-3!0-3!-1-3!-1-2!-2-1!-3-1!20!02!0-2!-20!10!00!-10!01!0-1"::Y=100 :: X=100 120 CALL CHAR(124,"0000000000010107070101000000000000000000008080E0E0808",128,"0000000000000001010000000000000000000000000000808") 130 CALL SPRITE(#2,124,7,80,X,#1,128,5,Y,X,#3,124,14,50,50,0,10,#4,124,14,50,50,0,-5,#5,124,14,50,50,0,5) 140 CALL KEY(0,A,B):: IF A<8 OR A>11 THEN 140 150 ON A-7 GOTO 160,170,180,190 160 X=X-1 :: GOTO 200 170 X=X+1 :: GOTO 200 180 Y=Y+1 :: GOTO 200 190 Y=Y-1 200 CALL LOCATE(#1,Y,X):: CALL POSITION(#2,A,B):: A=A-Y :: B=B-X :: A$="!"&STR$(A)&STR$(B):: C=POS(S$,A$,1):: IF C=0 THEN A$="NO" ELSE A$="YES" 210 DISPLAY AT(24,7):A$ :: GOTO 140