Bones-69

As another idea (something I have been experimenting with) - You could put an invisible sprite in motion and use its Position to trigger events. The good thing about this is you can go about your business and as long as you check the position occasionally the "timer" will keep ticking along without any ongoing maintenance.... This example will fire approximately every 30 seconds, give or take... 100 CALL CLEAR 110 CALL SPRITE(#1,32,1,8,1,0,1) 120 CALL POSITION(#1,A,B):: DISPLAY AT(10,1):"SECONDS";INT(B/3. 130 IF B<117 THEN 120 :: CALL SOUND(100,200,0):: GOTO 110

.

I had the same issue which was resolved by not leaving Classic99 in Throttle mode. I *think* I later read a comment that confirmed why this was the case.

Thanks for the find Asmusr. This looked to have great potential. Interesting thread as well....

I don't ever remember the game Hero but it looks fun. Seems there were versions for Atari, ZX Spectrum, Apple II, C64, Coleco, MSX and others - But I can find nothing for the TI. Can anybody advise otherwise? Looks very doable for our machines! https://atariage.com/2600/archives/HEROMaps/index.html

Anyone open to a discussion or interested in the concept of a sprite library for the TI? Any ideas on how such a thing might best work or be implemented? My thoughts are it would be great to have a central resource for sprite designs, sprite animations, multi-coloured sprites etc. Somewhere to perhaps upload designs and hex codes for sharing and general inspiration.

Cheers.

Harry - Have any thoughts on a possible future release that might support Relative files?

XB compiled would be fun and perhaps get more involved in experimenting with the compiler....

Youtube comments section; You will never find a more wretched hive of scum and villainy. We must be cautious. Personally, I think this looks great.

Well that was pretty damn cool. Gotta pull my finger out and get it finished now!

How cool!

A few things come to mind... I am out and about so only going from memory at the moment, but think I am on the right track. If you use something like the following this is likely causing the spaces; DISPLAY AT(1,1):"SCORE";A Whereas the following should give you a better display; A$="SCORE "&STR$(A)::DISPLAY AT(1,1)SIZE(LEN(A$)):A$ I think using the same A$="SCORE "&STR$(A) should allow you to use the XB256 feature. Again, only going from memory. Game looks great by the way!

Small update but I expect it will be the last one for a few weeks.... -The bottom gunner now fires a laser. This adds a whole new level of difficulty. -Made some changes to the "caterpillar march". When split, the forward facing part always becomes a head character. -Changed some timing. Still tinkering a little here. -Clawed back 2K in programming space by changing the way some processes were handled. There is still some further potential to save maybe another K if things get tight, but this will require I re-write the data file which will be a horrible job. I won't do this unless I absolutely have to. Pretty happy with the way it is coming out. One thing I notice straight up is that it is quite difficult game. I remember writing other stuff and it always seemed like the computer was easy to beat, like losing was always hard. Getting out on this one is not going to be hard....

Tursi, - Tried cold reset using the File-> options but this did not correct. The few times I experienced the issue I could only resolve by restarting Classic99. - I was in overdrive on all occasions (I think the only time I ever turn it off is when running a compiled program). I was fooling around with Classic and the compiler all weekend without any repeated issues. If it happens again I will try and capture more useful information.

No - Haven't done much of anything other than report it. When it happens I close off Classic99, restart it and the problem goes away. Has spontaneously occurred a few times but I haven't noticed any pattern....

Possible bug in the new version?? Has happened to me a few times now. Nothing that "rebooting" (restarting Classic99), doesn't seem to fix. Thought it an odd one worth sharing....

Same here. All good, no issues. :thumbsup

Another update for Gridslugger; -Rewrote the "caterpillar march" soooo very many times and don't think I can squeeze any more speed out of it. -Got the player controls working roughly the way I want. Still some room for improvement here. -Player shooting is working. -Added player bullet "bounce-back" when an empty shield is hit. Further down the track these shields will occupy bonuses that can be activated by shooting and then collecting. When empty they provide something else for the player to dodge. -Explosions are working. -HCHAR and sprite collisions are coincing perfectly. -Scores are updating. -Still no sounds. Have read about the XB256 sound lists but haven't started fooling around with this yet to appreciate exactly what is possible. I think sounds will really bring it to life. Down to 4K stack and 4K available program space so not too nervous at this stage (guess I am 70% done). Having so much fun with XB256 & the Compiler! Don't think I could ever go back now....

Can't chain compiled programs, Got it!

I am totally digging this concept even for a typical arcade style game. Comes to mind that one could write a dedicated program where all variables are initialised, characters defined, perhaps with a fancy graphical loading page.... Then without penalty to the available programming space in order to get to this point, the main program could then be seamlessly launched. I know my current project which reads all variables off disk still uses up 1600 bytes of programming space just for the initialisation routines. In my example it would be great to claw back some of this precious space.

I love this idea. Screen 1 could be used for text and Screen 2 could have all the pretty graphics, or maps, or some other graphical interface with all the flexibility/convenience of the extra XB256 character sets. Added to my "future project list"!

I haven't done anything yet that required a need to slow down a compiled program, but in my thoughts on the subject I had speculated that it could be feasible to put a transparent sprite into motion - say horizontally on a part of the game screen not used. Then by regularly fetching the X value using CALL POSITION you could use the returned value to trigger program events. I had thought that by speeding up or slowing down the motion of the sprite, and therefore the speed it arrives at certain screen positions (or value ranges), might be a practical way to adjust timing within a game. Higher levels in games could be sped up by increasing the speed of the sprite, and therefore the frequency of values returned. Would almost be a case of just setting it in motion and forgetting about it. No need for individual delays, or timers, or loops & no need to reset counters... Just wait until you return a value within some set limit and then execute some function/s as desired. Not tested, just an idea/concept.

Will this equate to faster execution times when compiled, or is it more about trying to better emulate something more faithful to the standard XB syntax? I have now gotten used to writing the way the compiler demands!

Made some decisions and cut some bells and whistles. Also re-wrote several of the little routines. I have chewed up more stack and more program space, but I think the significant boost in speed was worth the sacrifice. I am still making little tweaks here and there trying to reclaim some more programming space - but I think things are heading in a better direction. At the very least I am now feeling more encouraged to continue.