Jump to content
Have You Played Atari Today?
2600|5200|7800|Lynx|Jaguar|Forums|Store

Bones-69

Members
 View Profile  See their activity

  • Posts

    253

  • Joined

  • Last visited

 Content Type 

Posts posted by Bones-69

    This should be a simple question

    in TI-99/4A Development

    Posted · Edited by 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

    Classic99 Updates

    in TI-99/4A Computers

    Posted

    Hi Tursi.

     

    I may have come across a bug .... in latest Classic99, when the TI goes into the blank screen after a while, it's locking up the emulator. It's done it twice on me now. Don't know if anyone else has seen it do this?

    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.

    Sprite library

    in TI-99/4A Development

    Posted

    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.

     

     

    • Like 3

    Night Stalker - (XB256 compiled) FINAL VERSION

    in TI-99/4A Development

    Posted

    As an aside, does anyone know how to keep the DISPLAY AT from adding a blank character to the left and the right of the value? IS DISPLAY AT USING the only way? Because that function doesn't compile. And unfortunately XB256's CALL LINK("DISPLAY") only uses character strings not values.

     

    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! :)

    • Like 2

    Gridslugger - Game in progress (compiled XB)

    in TI-99/4A Development

    Posted

    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....

     

    • Like 10

    XB Game Developers Package

    in TI-99/4A Development

    Posted

    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.

    Gridslugger - Game in progress (compiled XB)

    in TI-99/4A Development

    Posted

    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....

     

    • Like 10

    XB Game Developers Package

    in TI-99/4A Development

    Posted

    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.

    XB Game Developers Package

    in TI-99/4A Development

    Posted

    Running in XB rather than compiled has some advantages for large games where speed is not an issue. For example, you could have a large adventure game that uses.....

     

    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"!

    XB Game Developers Package

    in TI-99/4A Development

    Posted · Edited by Bones-69

    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.

    • Like 3

    XB Game Developers Package

    in TI-99/4A Development

    Posted

    Here's some news you're gonna like. I have been updating the compiler so it can use the more complicated XB style IF/THEN/ELSE statements. It all appears to work, but I want to take a few more days to be sure nothing is amiss.

    The only difference is that there are some minor restrictions on nesting IF/THEN/ELSE statements. A single IF, THEN, ELSE is OK in a line, but you cannot have: 100 IF A=1 THEN IF B=2 THEN C=3 ELSE D=4 ELSE E=5

     

    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! :)

    Gridslugger - Game in progress (compiled XB)

    in TI-99/4A Development

    Posted

    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.

     

    • Like 12
AtariAge
Forums
Store
General
Follow AtariAge

Copyright ©1998-2023 AtariAge

×
×
  • Create New...