Ti Extended Basic - sprite control

[gekido_ken]

Hi guys!

I'm developing a little version of brekout for a contest in basic 4k, but....damn sprite!

They have big control latency on CALL MOTION and CALL COINC.

 

My quest are these:

 

#1 is there a mode like CALL LOAD or similar to make better check collision?

 

#2 is there a mode for check sprite position on character name table, like CALL GCHAR?

 

THANKS.

[1980gamer]

Under development resources look for this:

MG Smart Programming Guide for Sprites ^PDF
Advanced tutorial on how to efficiently use sprites in Extended Basic.

 

This has all the conversions for background position to sprite position etc. In hchar mode or display at.

Very good info.

[sometimes99er]

# 1
Not that I know of.

Standard TI Extended Basic will require 32K Memory Expansion to work with CALL LOAD. So not just stock console with TI Extended Basic.

One could build an Assembler based routine and hook it on the Interrupt Service Routine. It could then control certain aspects of the game. Like reading input, moving the paddle, bounce the ball, remove bricks and update certain bytes with information for the Extended Basic program to process, like no. of bricks hit. Extended Basic would run at almost full speed with the routine in the background. I estimate such a routine to be less than 1K.

# 2
No mode, but you can calculate it. And then of course use CALL GCHAR to check if there’s a brick or wall there. I think that Breakout would usually calculate the future position of the ball before moving it.


One option is to compile your TI Extended Basic program. Requires the 32K Memory Expansion, and the support routines themselves can easily be more than 4K.

Another option is not to use sprite auto-motion. You would then move the sprites yourself using CALL LOCATE. Movement will probably not be very smooth, but you wouldn't miss collisions.

Another option is not to use sprites. Again movement will not be very smooth.

If you stick with TI Extended Basic and sprites (not compiled and no special support routines), you should have a very small game loop - to only catch collisions. When stuff do happen (other than just moving the ball and the paddle), you branch to the code to do whatever, like bouncing the ball. It should be possible.

 

[gekido_ken]

Is there some memory address to use with Call Peek for to know sprite position, without use call position?

[sometimes99er]

Is there some memory address to use with Call Peek for to know sprite position, without use call position?

 

CALL PEEK peeks the CPU memory. The position (with fraction) and speed vectors are stored in VDP memory. There's no command in TI Extended Basic for reading VDP memory. The Mini Memory Module do have CALL PEEKV for reading VDP memory (in addition to CALL PEEK).

 

Other than that, peeking the memory for the sprite position, is not going to be faster or more efficient than CALL POSITION. The latter serves you the x and y-coordinates separately and even for multiple sprites in one go.

 

 

[unhuman]

Seems like this would be a great candidate for a compiled game and you could manage all motion with call position instead of using motion. Then you could calculate all the things discussed ^^^

[RXB]

Hi guys!

I'm developing a little version of brekout for a contest in basic 4k, but....damn sprite!

They have big control latency on CALL MOTION and CALL COINC.

 

My quest are these:

 

#1 is there a mode like CALL LOAD or similar to make better check collision?

 

#2 is there a mode for check sprite position on character name table, like CALL GCHAR?

 

THANKS.

If you want check out RXB 2015 and you will see CALL MOTION and CALL COINC have added features.

 

Also RXB has CALL PEEKV(address,variable) and to help even further has CALL RMOTION that reverses the motion of a sprite.

 

Also I demo some of these in my videos on my channel;

 

https://www.youtube.com/user/CarbonicHolyPally

Edited May 20, 2019 by RXB