Jump to content
IGNORED

Why won't this work? (Solved!)


Retrospect

Recommended Posts

COSMIC DEFENSE.txt < needs XB256 to run.  Intention is to compile.

 

This program I'm working on, works in normal XB with the XB256 extension running.  The player base moves left to right, and fires, whilst the aliens are moving.  

There's a mothership that moves left to right above some blocks.  

 

When compiled, it doesn't work.  It screws up.  I've not got any idea why.  If anyone has any ideas?

 

 

Link to comment
Share on other sites

15 minutes ago, SteveB said:

Currently I can't even compile it for some reason...

 

Update ... I had ISABELLA8 active ... with JEWEL it compiles and does not work as you say ...

 

yeah, it's a mystery.  I'm not sure where in the code, the compiler doesn't like something.  Pretty certain I did all this similar for my invaders game which worked without a problem.  I've checked this program with JS99er and that does the same so this one's on me somehow

Link to comment
Share on other sites

Just now, Retrospect said:

yeah, it's a mystery.  I'm not sure where in the code, the compiler doesn't like something.  Pretty certain I did all this similar for my invaders game which worked without a problem.  I've checked this program with JS99er and that does the same so this one's on me somehow

I thought a little code-mangling might help and imported it in TiCodEd to SXB and then exported back to XB ... with the very same result as in your video.

 

I had a similar problem in the past and some random PRINT commands shifted things enough to make it run. I thought the code ping-pong would change the code enough to make it run.

 

 

Link to comment
Share on other sites

11 minutes ago, SteveB said:

change the code enough to make it run.

thanks for the effort.  I'm starting to wonder if this is a "me" issue or a compiler issue.  It can't be a compiler issue though because it's run similar stuff to this before, without a problem.  nine times out of ten it's something i've done.

Link to comment
Share on other sites

@Retrospect The problem is clearly in the routine for managing movement/shooting. If you comment the GOSUB used for test, except the one for joystick you can experience the issue in compiled code. Maybe you are grabbing some garbage from an array that can have different values from XB and assembler. I guess it's in the fire management portion. If you just replace line 20511 with:

 20511 CALL MOTION(#4,0,JY)

you can see in compiled code that you can move the ship, but there is the strange behaviour with the missile (without having to use the fire button). So I'll start looking at that portion of the code. I suggest to rewrite it from scrath: you are checking twice the fire button and there some jumps up and down in the code that surely can help nasty bugs. ? 

  • Like 2
  • Thanks 1
Link to comment
Share on other sites

Just now, 1980gamer said:

I am trying to remember, but I think I had some issues with long variable names.

You have some longer vars than I use these days.  Maybe copy to a test file and refactor it.  Count to CNT, Mother?  MTR  etc.

 

i usually do that when i'm making a final release.  it's solved anyhow! :)

  • Like 2
Link to comment
Share on other sites

Solved!  Thank you Tmop for mentioning something about leaving comments on certain lines!  This was the issue.  

PS: reason i'm not using auto-motion is that the player base has to shoot those blocks under the mothership and I want it to be 100 percent accurate so, alas, 8 pixels at a time scrolling of the player base it is.  

 

  • Like 6
Link to comment
Share on other sites

1 minute ago, 1980gamer said:

Great.

I use short vars and sometime have to make them shorter to save space! The fun of limited memory!

yeah it can have quite an impact on the overhead.  If my game isn't impacted by speed nor has the need for the memory I am guilty of leaving them in there, I'm a lazy bitch at times.  But this program is going to be tidied up before it's "official" .... and bug-tested to holy hell before it even sees the light of day.  :)

Link to comment
Share on other sites

<Advertising>

 

With TiCodEd you may user // for comments and they get removed on the generation of pure Extended Basic, so do not waste your TI memory. REM and ! will be transfered. And you may use long variable names up to 32 char and assign short names for the export, also avoiding above trouble and save TI memory.

 

</Advertising>

 

  • Like 1
Link to comment
Share on other sites

Looks like a great start.

I was going to try something similar using the pixel scroll functions.  I did a quick demo a few years ago, but I have 4 different games "in progress" already!  LOL

 

With that I can eliminate the 4 sprite per row limit.  Also the 28 total sprites is limiting in a game like this.

 

  • Like 1
Link to comment
Share on other sites

5 minutes ago, SteveB said:

<Advertising>

 

With TiCodEd you may user // for comments and they get removed on the generation of pure Extended Basic, so do not waste your TI memory. REM and ! will be transfered. And you may use long variable names up to 32 char and assign short names for the export, also avoiding above trouble and save TI memory.

 

</Advertising>

 

Thats a great option which I might take up.  Just so you know, though, I do remove comments from my games once the memory gets tight and also just before it goes "official".  But yes I would like to look into TI CodeEd

Link to comment
Share on other sites

4 minutes ago, senior_falcon said:

Too cryptic for me. Which lines caused the problem?

Far as I know any line with a Return but I did delete a lot of comments at once, so I'll make a test program later , filled with comments, including the Return , and i'll determine the issue from that.

 

Note: I don't normally even leave comments at the ends of statement lines, but i did this time as i wanted it to be readable for me when i get back to it after a day or so.  I've had issues with cognitive impairment after having Covid.  But that's another story!

Edited by Retrospect
Link to comment
Share on other sites

Program that moves a ball sprite whilst changing it's colour

 

Possibility is that comments after statements are causing problems in compiled code.  This is evident in so far as these two tests.

Tests to continue to get ball to move.  

 

Findings so far: Whatever the issue is, it's not exclusive to the RETURN command + a comment at end 

 

 test 1 compiler.txt <<< ball doesn't move OR change colour.

test 2 compiler.txt <<< ball changes colour but does not move

 

 

Edited by Retrospect
Link to comment
Share on other sites

test3 compiler.txt << program now works

 

 

It has been determined that if there is a line like this;

C=C+1 :: IF C>16 THEN C=3

We cannot then leave a comment at the end of this line.

 

Note: I am probably the only one who did not know this.

@senior_falcon

Edited by Retrospect
  • Like 1
Link to comment
Share on other sites

2 hours ago, Retrospect said:

test3 compiler.txt << program now works

 

 

It has been determined that if there is a line like this;

C=C+1 :: IF C>16 THEN C=3

We cannot then leave a comment at the end of this line.

 

Note: I am probably the only one who did not know this.

@senior_falcon

Well, I'm another one. I will see if there is a fix for that. If there isn't then I will make a note of it in

the docs.

Edited by senior_falcon
  • Like 1
  • Thanks 2
Link to comment
Share on other sites

18 minutes ago, senior_falcon said:

Well, I'm another one. I will see if there is a fix for that. If there isn't then I will make a note of it in

the docs.

Thanks Harry.  I think Tmop had a good idea what was going on with the commenting too.  Normally I wouldn't comment on code like that, but I had to be able to follow it, and then it wouldn't work  and so I kept it all in to make sure everyone else could read the code.  In doing so, I made the bug happen.  There's a word for that behaviour I'm sure!  :)

Link to comment
Share on other sites

3 hours ago, 1980gamer said:

With that I can eliminate the 4 sprite per row limit.  Also the 28 total sprites is limiting in a game like this.

I've made at least one game recently that uses Character graphics for the main aliens due to that limitation.  I needed 40 aliens so F-18A sorcery wasn't even going to cut it for me.  I had to use characters.  I did have sprites for the alien's missiles and for the player missiles, that way, it saves a bit of execution time just using CALL LOCATE with an updated X coordinate for the missile rather than having to blank out the previous position of a character etc etc ... I made an array of the screen x(24) and y(32) so that the sprites could be used against characters with CALL GCHAR.  It gives off the effect of good hit detection but really it's not it's just functioning as it should.

Another trick I did, to save execution time and ensure the player base wasn't halted, was each of the 40 aliens was only updated one at a time, so, gosub to joystick  , increment alien counter, gosub to alien movement, twinkle a star, gosub to missiles/hit detection then back to joystick for example.  Rather than trying to move 40 aliens in one go lol  

Edited by Retrospect
  • Like 3
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...