### Author Topic: Problem with shooter code  (Read 7723 times)

0 Members and 2 Guests are viewing this topic.

#### LemonDrop

• LV2 Member (Next: 40)
• Posts: 26
• Rating: +4/-0
##### Problem with shooter code
« on: August 01, 2013, 01:51:47 pm »
So pretty much I was looking at the axe example of a space invaders clone thing and was trying to just get movement and bullets working by using the system they had, just to try to learn the language better. Oddly though even though the code is very close to the example mine crashes after like 3 seconds. Before then it works fine but then a bullet sprite appears in the bottom left corner for some reason. Heres the code that isnt working:

Code: [Select]
.TEST[002442DBE7BD2400->Pic1[0000183C3C240000->Pic2DiagnosticOffClrDrawDrawInv 44->X54->Y0->B->E->TRepeat getKey(15)sub(DDispGraphsub(DIf getKey(2) and (X!=1X-1->XEndIf getKey(3) and (X!=87X+1->XEndIf getKey(4) and (Y!=1Y-1->YEndIf getKey(1) and (Y!=55Y+1->YEndIf getKey(54) and (T=0B+1->B*3+L1->I0->{I-2}X->{I-1}Y->{I}15->TEndT=0+T-1->TFor(I,0,BI*3+L1->J{J-2}-1+{J}->{J}If {J}=57 or ({J}=0B*3+L1->KCopy(J,K,3)^^rB-1->BEndEndEndClrDrawClrHomeReturnLbl DPt-Change(X,Y,Pic1For(I,0,BPt-Change({I*3+L1-1},{I*3+L1},Pic2End
And what happens when I try to do stuff:

Dunno if this is the right place to ask this but any help would be nice

#### Runer112

• Project Author
• LV11 Super Veteran (Next: 3000)
• Posts: 2289
• Rating: +639/-31
##### Re: Problem with shooter code
« Reply #1 on: August 01, 2013, 02:51:52 pm »
Yes, this is the right place to ask. I didn't actively debug the code, but I suspect the problem has to do with the bullet logic. My suspicion is that, as the result of a few code issues, the number of bullets is getting decreased when it's already zero, wrapping around from 0 to 65535 and then causing a great big mess. Here are the three culprits that appear to me:

• For(I,0,B : This loop will parse one more "bullet" than you want: the "0th" bullet. The fix for this is simply to increase the lower bound of the loop to 1.
• Copy(J,K,3)ʳ : Copy() copies data from the first pointer argument to the second, but you want to copy from K to J, so they need to be switched around.
• When a bullet is removed during the bullet processing loop by copying a bullet from the end of the list over it, the copied bullet still needs to be processed, but the loop counter will increase for next iteration and skip it. The usual way to fix this is to decrease the loop counter by one when a bullet is removed/overwritten to negate the next iteration's increase.

Here's your bullet processing code with the above fixes applied:
Code: [Select]
For(I,1,BI*3+L1->J{J-2}-1+{J}->{J}If {J}=57 or ({J}=0B*3+L1->KCopy(K,J,3)^^rB-1->BI-1->IEndEnd
I quickly tested plugging that into your code, and it seemed to work great. I've also attached the working source program; not that it's really needed, because the changes made were quite minimal and should be easy to apply directly to your copy of the source.

Good luck expanding this code out, I'd love to see a full-fledged game result from it! If you have any other questions with your project in the future, you can always post them back in this thread and they should hopefully be answered swiftly as well.

#### Hayleia

• Programming Absol
• Coder Of Tomorrow
• LV12 Extreme Poster (Next: 5000)
• Posts: 3367
• Rating: +393/-7
##### Re: Problem with shooter code
« Reply #2 on: August 01, 2013, 03:27:35 pm »
Also note that Axe is not Basic. The main difference being that Axe is compiled while Basic is not. This means that "forgetting" parentheses in Basic saves space in the executable and in the source (since they are the same), but in Axe, that doesn't save anything for the executable. And saving space in the source only is not useful except if you have a 83+ non-SE. Otherwise, I'd advise you to close your parentheses to avoid mistakes such as writing A+(C=1→A which you understand as A+(C=1)→A but which the parser understands as A+(C=1→A).
I own: 83+ ; 84+SE ; 76.fr ; CX CAS ; Prizm ; 84+CSE
Sorry if I answer with something that seems unrelated, English is not my primary language and I might not have understood well. Sorry if I make English mistakes too.

#### LemonDrop

• LV2 Member (Next: 40)
• Posts: 26
• Rating: +4/-0
##### Re: Problem with shooter code
« Reply #3 on: August 01, 2013, 04:23:19 pm »
Also note that Axe is not Basic. The main difference being that Axe is compiled while Basic is not. This means that "forgetting" parentheses in Basic saves space in the executable and in the source (since they are the same), but in Axe, that doesn't save anything for the executable. And saving space in the source only is not useful except if you have a 83+ non-SE. Otherwise, I'd advise you to close your parentheses to avoid mistakes such as writing A+(C=1→A which you understand as A+(C=1)→A but which the parser understands as A+(C=1→A).
Ah yes. I've been coding with ti-basic for a while and its sorta confusing because my brain is still thinking on how I'd do a program in ti-basic when here things like speed dont matter as much.

#### ben_g

• Hey cool I can set a custom title now :)
• LV9 Veteran (Next: 1337)
• Posts: 1002
• Rating: +125/-4
• Asm noob
##### Re: Problem with shooter code
« Reply #4 on: August 01, 2013, 05:49:39 pm »
Also note that Axe is not Basic. The main difference being that Axe is compiled while Basic is not. This means that "forgetting" parentheses in Basic saves space in the executable and in the source (since they are the same), but in Axe, that doesn't save anything for the executable. And saving space in the source only is not useful except if you have a 83+ non-SE. Otherwise, I'd advise you to close your parentheses to avoid mistakes such as writing A+(C=1→A which you understand as A+(C=1)→A but which the parser understands as A+(C=1→A).
Ah yes. I've been coding with ti-basic for a while and its sorta confusing because my brain is still thinking on how I'd do a program in ti-basic when here things like speed dont matter as much.
Even when you code in axe, it's bets to try limit the size of the executable as much as possible and making it as fast and optimized as possible. Axe is a great and powerfull language, but the calc's hardware is very limited. When you have to handle a lot of objects at once, that work really pays off.
My projects
- The Lost Survivors (Unreal Engine) ACTIVE [GameCommandoSquad main project]
- Oxo, with single-calc multiplayer and AI (axe) RELEASED (screenshot) (topic)
- An android version of oxo (java)  ACTIVE
- A 3D collision detection library (axe) RELEASED! (topic)(screenshot)(more recent screenshot)(screenshot of it being used in a tilemapper)
Spoiler For inactive:
- A first person shooter with a polygon-based 3d engine. (z80, will probably be recoded in axe using GLib) ON HOLD (screenshot)
- A java MORPG. (pc) DEEP COMA(read more)(screenshot)
- a minecraft game in axe DEAD (source code available)
- a 3D racing game (axe) ON HOLD (outdated screenshot of asm version)

This signature was last updated on 20/04/2015 and may be outdated

#### LemonDrop

• LV2 Member (Next: 40)
• Posts: 26
• Rating: +4/-0
##### Re: Problem with shooter code
« Reply #5 on: August 02, 2013, 01:11:24 am »
Yea I came across another thing I wanted to ask about here, With some code like:

0->{I-2}->{I-3} The {I-3} dosent work for some reason when something like 0->A->B would. Is there any way to do that with the value of a pointer thing?

#### Streetwalrus

• LV12 Extreme Poster (Next: 5000)
• Posts: 3821
• Rating: +80/-8
##### Re: Problem with shooter code
« Reply #6 on: August 02, 2013, 02:23:53 am »
Yea I came across another thing I wanted to ask about here, With some code like:

0->{I-2}->{I-3} The {I-3} dosent work for some reason when something like 0->A->B would. Is there any way to do that with the value of a pointer thing?
Nope, it's impossible because foo->{bar} will return bar. The select command may help you though :
Code: [Select]
Select(foo,->{bar1})Select(,->{bar2})Select(,->{bar3})This is another example of HL abuse using the stack (am I right Runer ?) to help keep the correct value. It's definitely smaller than
Code: [Select]
foo->{bar1}foo->{bar2}foo->{bar3}But it's slower.
« Last Edit: August 02, 2013, 02:24:10 am by Streetwalker »

#### Hayleia

• Programming Absol
• Coder Of Tomorrow
• LV12 Extreme Poster (Next: 5000)
• Posts: 3367
• Rating: +393/-7
##### Re: Problem with shooter code
« Reply #7 on: August 02, 2013, 02:43:20 am »
Also note that Axe is not Basic. The main difference being that Axe is compiled while Basic is not. This means that "forgetting" parentheses in Basic saves space in the executable and in the source (since they are the same), but in Axe, that doesn't save anything for the executable. And saving space in the source only is not useful except if you have a 83+ non-SE. Otherwise, I'd advise you to close your parentheses to avoid mistakes such as writing A+(C=1→A which you understand as A+(C=1)→A but which the parser understands as A+(C=1→A).
Ah yes. I've been coding with ti-basic for a while and its sorta confusing because my brain is still thinking on how I'd do a program in ti-basic when here things like speed dont matter as much.
Even when you code in axe, it's bets to try limit the size of the executable as much as possible and making it as fast and optimized as possible. Axe is a great and powerfull language, but the calc's hardware is very limited. When you have to handle a lot of objects at once, that work really pays off.
Yeah, it is a good thing to optimize the executable for speed and size, but there is no point optimizing the source (except if you have a 83+ non-SE and have very little space).
I own: 83+ ; 84+SE ; 76.fr ; CX CAS ; Prizm ; 84+CSE
Sorry if I answer with something that seems unrelated, English is not my primary language and I might not have understood well. Sorry if I make English mistakes too.

#### LemonDrop

• LV2 Member (Next: 40)
• Posts: 26
• Rating: +4/-0
##### Re: Problem with shooter code
« Reply #8 on: August 03, 2013, 05:20:58 pm »
Sorry for asking a lot of questions here but I think its better than making new threads. So I was wondering about a few things:
1. Are axe programs in the Full 15mhz mode by default
2. Is using things like rotC, flipH and flipV instead of making sprites for different angles better (speed/space wise)
3. I heard that separating if statements (If A:If B) is faster than combining them (If A and B), is this true? Which one uses less space also
and finally
4. Whats the risk of using L3 for data, or is it safer to just use a pseudo list (L2+250 being the start of it) if you know the data in L2 wont extend that far
edit:
Oh yea does sound with the freq command play synchronously (meaning if its told to play for 1 second will it wait 1 second to go to the next command or does it play as stuff is happening)

(also this is what I have so far for my game thing, ignore the completely terrible explosion sprites and stuff)
« Last Edit: August 03, 2013, 05:29:36 pm by LemonDrop »

#### Runer112

• Project Author
• LV11 Super Veteran (Next: 3000)
• Posts: 2289
• Rating: +639/-31
##### Re: Problem with shooter code
« Reply #9 on: August 03, 2013, 06:58:36 pm »
Sorry for asking a lot of questions here but I think its better than making new threads. So I was wondering about a few things:
1. Are axe programs in the Full 15mhz mode by default
2. Is using things like rotC, flipH and flipV instead of making sprites for different angles better (speed/space wise)
3. I heard that separating if statements (If A:If B) is faster than combining them (If A and B), is this true? Which one uses less space also
and finally
4. Whats the risk of using L3 for data, or is it safer to just use a pseudo list (L2+250 being the start of it) if you know the data in L2 wont extend that far
edit:
Oh yea does sound with the freq command play synchronously (meaning if its told to play for 1 second will it wait 1 second to go to the next command or does it play as stuff is happening)

(also this is what I have so far for my game thing, ignore the completely terrible explosion sprites and stuff)

1. Nope, all assembly programs should start at 6MHz.

2. Using the sprite rotate/flip commands will always be slower than not using them. flipV() takes 339 cycles, flipH() takes 1908 cycles, and rotC() and rotCC() take 2661 cycles. All four rotate/flip subroutines take up 73 bytes of space in total, so if you only have a few sprites that have rotated versions and the extra data isn't much larger than that, it would probably be smaller (and faster) to just include the rotated sprites as data. With more sprites, it begins to become more of a trade-off between size and speed. But if you want the speed of not using flip/rotate commands when sprites are drawn without the size of including extra copies of lots of sprites, you can still get the best of both worlds. Just include one copy of each sprite and then producing the flipped/rotated copies at startup time and save them in a static RAM area like L?-L? or a temporary OS variable.

3. In that direct comparison, separating the if statements does not save space. In fact, it costs 2 bytes. However, it does have two advantages. The first is that by breaking multiple conditions up into multiple if statements, if any condition is not true, none of the following conditions are even reached, thus saving time. The second advantage, and probably the more common reason why this is done, is that it works when one or more of the conditions doesn't actually depend on a boolean being zero or one, but on an integer being zero or nonzero. The and operator is an 8-bit bitwise AND, which works just like a logical AND for boolean values. But it doesn't work like a logical AND for integer values. (In case bitwise AND needs a bit of explanation, here's the wikipedia entry for it)

4. The Commands.html file included in Axe releases explains fairly well how large and how "safe" the L?-L? areas are. If you don't use any grayscale drawing commands or StorePic/RecallPic, L? should be safe to use.

5. The Freq() command in Axe is fairly primitive, so program execution doesn't continue while the tone plays. Having notes that play in the background requires fairly complicated interrupts and timing logic, so it hasn't been enough of a priority to find its way into Axe. However, I'm keeping an eye on Iambian's interrupt-based audio solution, which seems quite good. It might eventually be available as an Axiom (an external library for Axe programs).

#### LemonDrop

• LV2 Member (Next: 40)
• Posts: 26
• Rating: +4/-0
##### Re: Problem with shooter code
« Reply #10 on: August 04, 2013, 12:17:18 am »
Soo apparently I have another problem I cant fix (stared at this code for a good 15 minutes and couldn't figure it out lol). Pretty much everything in this works fine except the explosions from the dead test enemy dont display. This was after I decided to handle them in a array structure like I have been doing with the bullets and enemies. I cant tell if its a drawing issue with the sprites or a logic issue where the explosions are processed but maybe one of you can help. Helpful infos: C (number of explosions) gets 1 added to it when a enemies health hits 0 (!If {J-4}), and a new explosion entry is added at the current enemy position {J-1},{J}. The third value for explosions is the sprite offset which gets multiplied by 8 later.
-code removed because copyprotection-
« Last Edit: August 04, 2013, 12:44:39 am by LemonDrop »

#### Runer112

• Project Author
• LV11 Super Veteran (Next: 3000)
• Posts: 2289
• Rating: +639/-31
##### Re: Problem with shooter code
« Reply #11 on: August 04, 2013, 12:34:23 am »
On line 92, should If J>6 be If {J-2}>6 instead?

#### LemonDrop

• LV2 Member (Next: 40)
• Posts: 26
• Rating: +4/-0
##### Re: Problem with shooter code
« Reply #12 on: August 04, 2013, 12:40:27 am »
On line 92, should If J>6 be If {J-2}>6 instead?
Wow I'm pretty stupid not to have seen that lol. Oh well that happens when you code for a long time without a break lol.

#### Runer112

• Project Author
• LV11 Super Veteran (Next: 3000)
• Posts: 2289
• Rating: +639/-31
##### Re: Problem with shooter code
« Reply #13 on: August 04, 2013, 12:47:41 am »
Getting a second set of eyes can greatly increase debugging ability. Sometimes you're just completely blind to a certain error for no apparent reason.

#### DJ Omnimaga

• Former TI programmer
• CoT Emeritus
• LV15 Omnimagician (Next: --)
• Posts: 55838
• Rating: +3151/-232
• CodeWalrus founder & retired Omnimaga founder
##### Re: Problem with shooter code
« Reply #14 on: August 04, 2013, 01:19:36 am »

-code removed because copyprotection-
(By the way, if you post code then somebody steals it, releasing it on ticalc.org or re-using it without your permission there, I'M fairly certain that his file will not last for long, because many people here knows Axe very well and even if the guy releases a closed-source game using stolen code, he'll get caught very fast. Basically you would just have to complain here then someone will immediately try old pieces of your code then notice immediately. In other words, you shouldn't worry about keeping source code here, although it's your choice to remove it after getting help)
« Last Edit: August 04, 2013, 01:20:01 am by DJ Omnimaga »
In case you are wondering where I went, I left Omni back in 2015 to form CodeWalrus due to various reasons explained back then, but I stopped calc dev in 2016 and am now mostly active on the CW Discord server at https://discord.gg/cuZcfcF