Gigatron Hackers

Thank you for the help

That cleaned up all the random weirdness in the graphics as well as the issue with the text positioning.

Now to get the sprites displaying again

I am getting this error which I don't understand why. Looks like it is complaining about jumping a page boundary ?

Yes that's exactly what it is, remove the ampersand to fix it, (the ampersand is an old ROM optimisation technique which you pretty much don't need at all for ROMvX0).

I found an interesting situation. My sprites were still breaking up so I stripped everything out of the program, got the sprites working then started adding all the code back a little at a time to find out what was breaking the sprites.

I found that if the sprite loading is in the main code flow it works but if I put the sprites into a procedure and call that from the main code flow they get scrambled.

This works:

Score1 = 0: Score2 = 0 ' Initialise the score.
GameStatus(11) = 0 ' Pause Game OFF

' CALL LoadImages ' Load all images for sprites

LOAD SPRITE, Images/Willy1.tga, 0
LOAD SPRITE, Images/Willy2.tga, 1
LOAD SPRITE, Images/Willy3.tga, 2
LOAD SPRITE, Images/Willy4.tga, 3
LOAD SPRITE, Images/Willy5.tga, 4
LOAD SPRITE, Images/Willy6.tga, 5
LOAD SPRITE, Images/CentralCavern/Guardian1.tga, 6
LOAD SPRITE, Images/CentralCavern/Guardian2.tga, 7
LOAD SPRITE, Images/CentralCavern/Guardian3.tga, 8

SPRITES INIT

SPRITE SHOW, 0, 255
SPRITE SHOW, 1, 255
SPRITE SHOW, 2, 255
SPRITE SHOW, 3, 255
SPRITE SHOW, 4, 255
SPRITE SHOW, 5, 255
SPRITE SHOW, 6, 255
SPRITE SHOW, 7, 255
SPRITE SHOW, 8, 255

But if I put the code above into a PROC called LoadImages and call it they don't

This just shows how rushed and lacking in documentation this ROM and version of gtBASIC are

ALL loads of any type must be done before code is run, as all loading in gtBASIC is really just static allocation of memory by the compiler. i.e. Nothing is actually loaded at runtime on the Gigatron, (this may seem obvious, but it can get confusing sometimes).

So this explains why you can't use any type of LOAD in a gosub or call, just think of a LOAD as the compiler creating an area of memory filled with pre-compiled data that is then sent to the Gigatron at a later stage through the .gt1 downloading mechanism.

If you look at all my examples, all the LOAD's are done first, either in the main source code, or through the MODULE statement.

OK, I will remember that. It is working in a procedure for LOAD BLIT but maybe this will break later.

I am not quite understand SPRITE SHOW, ID, ?
If I call it once with a value of 1 the sprite shows, then if I call it a second time the sprite disappears and on the 3rd call it reappears.
Can you describe what values should be in the second parameter and how it works ?

This is for code showing a character walking where the sprite changes as well as position

Finally can I flip a Sprite so that I save loading my characters facing different directions ?

Blits have to be loaded before code is run, all LOAD's have to appear before code, anything else is undefined behaviour. I wouldn't leave the load blits in a proc.

You may have found a bug in sprite show, but so far it has worked fine for me. SPRITE SHOW, ID, on/off where off=0, on=anything not 0

No flipping of sprites yet, that will require 3 more sets of sprite routines, (future addition, but no promises as to when).

I think there is a bug in the SPRITE SHOW command. It blanks out every 2nd show.

I am moving the sprites off screen for the moment to hide them when not in use. This is working for me ok when my characters are walking.

If you move them off-screen and you haven't FREE'd that area of memory and the compiler has placed code/data there, then you are corrupting that area of memory.

It will basically give you random undefined behaviour as your game gets bigger.