Earth Versus the Flying Saucers

[Retrospect]

Today I have started a test project to find out about any issues we may have with compiling XB.  My game is running in ordinary Extended Basic (not XB256) and has been compiled. 

I am aware my code is not finished, as it still needs checks to see how many saucers have been killed etc etc in order to set up 4 new ones, however, I have come across issues before I got to that stage.

 

Video attached shows game running under normal XB, then I turn on the CPU Overdrive to pick things up a little , and then I compile the game.  You can then see what happens.  The graphics glitch, and indeed the TI froze and crashed when I tried to break out of the game (not shown on video)

 

Here is my documented source .... EARTH VERSUS THE FLYING SAUCERS.txt
 <<<

The sound that you can hear is meant to be the noise of the flying saucers.

 

 

 

[SteveB]

The updates of the SAUCERS / flickering looks like there is something wrong with the VDP memory setup .. are you sure XB256 is not active somehow? 

[Retrospect]

7 minutes ago, SteveB said:

The updates of the SAUCERS / flickering looks like there is something wrong with the VDP memory setup .. are you sure XB256 is not active somehow? 

If it is active I don't know how.  I purposefully selected XB.  I can't even get the coinc's to happen, that's usually my fault but in this case I think something might be amiss.

I might try this program with JS99er and see what happens there

EDIT: Yeah it's my fault the coinc's dont happen, same thing happened in JS99er

[Retrospect]

Okay so now I've revised the collision detection routines and included a variable to tell us how many are dead, and now we get new saucers when all four are dead.

There is NO ghosting sprites or abnormal behavior YET .... this is running under normal XB and then compiled.

 

EARTH VS FLYING SAUCERS V2.txt <<< slightly less documented (less cluttered) code

 

 

 

[tmop69]

4 minutes ago, Retrospect said:

Okay so now I've revised the collision detection routines and included a variable to tell us how many are dead, and now we get new saucers when all four are dead.

There is NO ghosting sprites or abnormal behavior YET .... this is running under normal XB and then compiled.

 

EARTH VS FLYING SAUCERS V2.txt <<< slightly less documented (less cluttered) code

 

 

 

 

The problem with your previous code is in one of the comments at the end of the lines.   I've removed all the comment and it compiled without any problem (see attachment). You already experienced an issue in the past in a similar way. It's better to place the comments at the beginning of each line, just to avoid such kind of problems.

 

 

 

 

 

 

EARTH VERSUS THE FLYING SAUCERS - FIXED!.txt

[Retrospect]

29 minutes ago, tmop69 said:

I've removed all the comment and it compiled without any problem (see attachment).

thankyou TMOP    I already did this and it showed no problems, in fact further progress has been made, see attached video 
We now have scoring, saucers firing at player truck, and player truck death ... there are no "lives" yet.

This is proving so far that any problems I have had with Anubis are entirely my own fault and not some technical fault of either XB256 or the compiler.
 

 

 

 

[Retrospect]

We now have the saucers leaving the ground on fire for a short time after they've shot at it, and if your truck drives into it, truck "dies".  tested in normal XB and XB256 both compiled fine.  No issues at present with sprites. 

 

 

 

[senior_falcon]

8 hours ago, tmop69 said:

 

The problem with your previous code is in one of the comments at the end of the lines.   I've removed all the comment and it compiled without any problem (see attachment). You already experienced an issue in the past in a similar way. It's better to place the comments at the beginning of each line, just to avoid such kind of problems.

OK, so you have identified a bug in the compiler. The following XB code should compile the same:

4105 IF A2>10 THEN A2=1 ! BUT ONLY UP TO 10 THEN BACK TO 1
4106 IF A2>10 THEN A2=1

Here is the compiled code:

L4105
       DATA CGT,NV1,NC1,NT1
       DATA IF,NT1
       DATA ENDIF
L4106
       DATA CGT,NV1,NC1,NT1
       DATA IF,NT1
       DATA LET,NV1,NC2
       DATA ENDIF

 

Hopefully this can be fixed.

 

[Retrospect]

Always tinker and a thinker my fingers go like a dot matrix printer ..... 
 

 

 

[Retrospect]

Dang.  

 

 

 

[Retrospect]

Get to the Choppah.   

 

 

 

[senior_falcon]

I am 97.3% sure this is caused by the integer math in the compiler. I haven't seen the code, but you are probably dividing the sprite column by 8 to get the column needed for HCHAR. XB will round a value up or down as needed, but the compiler only rounds it down. Here is a test program that works fine in XB:

100 CALL CLEAR
110 CALL CHAR(100,"8080808080808080FFFFFFFFFFFFFFFF")
120 COL=8
130 COL=COL+1
140 CALL HCHAR(24,1,32,32)
150 CALL SPRITE(#1,100,2,177,COL)
160 CALL HCHAR(24,(COL+3)/8,101)
170 CALL KEY(0,K,S):: IF S<1 THEN 170
180 GOTO 130

 

Adding an INT to line 160 messes up the alignment
160 CALL HCHAR(24,INT((COL+3)/8),101)

Now it is misaligned, but at least it runs the same whether in XB or compiled.

 

But you can change line 160 to deal with the misalignment.

160 CALL HCHAR(24,INT((COL+7)/8),101)

And all is well.

 

Edited February 25, 2023 by senior_falcon

[Retrospect]

Ahhh I see .... thankyou @senior_falcon, I shall make some amendments to this code later on ... for what it's worth I ended up with this code for the player missile vs buildings ..
CALL POSITION(#4,Z1,Z2)::CALL GCHAR(INT(Z1/7)+1,INT(Z2/8)+2,H2)
And that didn't fair TOO badly ... but the example you gave me will no doubt improve things ... especially for the Player Ship vs Buildings part of my code which allows the player to travel 4 characters through a building before it even realizes the player should have died.

 

I did have one thought though, the book "smart programmers guide" by millers graphics, seems to deal with sprites of magnification factor 1 ... not 3, like I'm using.  So that might be fudging my brain too.  

Here's the code, but you'll have to excuse the mess, because I haven't had chance to tidy it up yet and the player explosion routine is an abomination.

SAUCY SAUCERS.txt

[+TheBF]

1 hour ago, senior_falcon said:

I am 97.3% sure this is caused by the integer math in the compiler. I haven't seen the code, but you are probably dividing the sprite column by 8 to get the column needed for HCHAR. XB will round a value up or down as needed, but the compiler only rounds it down. Here is a test program that works fine in XB:

100 CALL CLEAR
110 CALL CHAR(100,"8080808080808080FFFFFFFFFFFFFFFF")
120 COL=8
130 COL=COL+1
140 CALL HCHAR(24,1,32,32)
150 CALL SPRITE(#1,100,2,177,COL)
160 CALL HCHAR(24,(COL+3)/8,101)
170 CALL KEY(0,K,S):: IF S<1 THEN 170
180 GOTO 130

 

Adding an INT to line 160 messes up the alignment
160 CALL HCHAR(24,INT((COL+3)/8),101)

Now it is misaligned, but at least it runs the same whether in XB or compiled.

 

But you can change line 160 to deal with the misalignment.

160 CALL HCHAR(24,INT((COL+7)/8),101)

And all is well.

 

 

This got me wondering about my own system so I translated this program.

Working only in integers, cuz that's all I have, I don't need to add 7 to the COL to make it work correctly.

So is this is a kind of "proof" that the rounding down function of the compiler makes the difference. 

??

 

Spoiler

INCLUDE DSK1.GRAFIX
INCLUDE DSK1.DIRSPRIT

DECIMAL
VARIABLE COL

: RUN
   CLEAR
   S" 8080808080808080FFFFFFFFFFFFFFFF" 100 CALLCHAR
   0 COL !
   BEGIN
     0 23 32 32 HCHAR
     COL @ 8 / 23  101  1 HCHAR
     100  2  COL @ 176  1 SPRITE
     BEGIN KEY? UNTIL
     COL 1+!
     ?TERMINAL
   UNTIL
   DELALL
;

 

 

[senior_falcon]

11 hours ago, Retrospect said:

... for what it's worth I ended up with this code for the player missile vs buildings ..
CALL POSITION(#4,Z1,Z2)::CALL GCHAR(INT(Z1/7)+1,INT(Z2/8)+2,H2)
And that didn't fair TOO badly ... but the example you gave me will no doubt improve things ... especially for the Player Ship vs Buildings part of my code which allows the player to travel 4 characters through a building before it even realizes the player should have died.

I had assumed that the alignment problem only occurred when compiled, but was OK when running in XB. But what you posted also has an alignment problem when running in XB. Remember that the sprite position is at the upper left corner, but the actual sprite pattern could be anywhere on the 8x8 or 16x16 grid, depending on how you have defined it.

 

You have: CALL GCHAR(INT(Z1/7)+1,INT(Z2/8)+2,H2)

The 7 needs to be an 8 because the character tiles are 8x8 pixels.

Then you probably need to add a number to Z1 and Z2 to get the character rows and columns(24x32) properly synced with the sprite rows and columns(192x256)

INT(Z2/8)+2  could be INT((Z2+16)/8) and then you don't need to add the 2. You would probably have to adjust the 16 up or down a few pixels. The exact number could be determined by trial and error. Or you could use a short program like the one I posted, but with your sprite patterns, and with that you could quickly work out the values.

 

By the way, I really like the way the saucers "uncloak" when they come into view.

 

Edited February 26, 2023 by senior_falcon

[Retrospect]

1 hour ago, senior_falcon said:

By the way, I really like the way the saucers "uncloak" when they come into view.

Thanks , yeah I had to think about how the saucers would arrive ... after a conversation with a friend the other day where he discussed possibilities of "portals" (he's a bit out there) I decided that one would appear as though through one of those ... about the trial and error , I had gone through a bit of trial and error with the positions beforehand and eventually came up with those numbers.  I'll put your suggestions into the code and we'll see what we can see.     Got a few projects juggling at the moment, as always