Beginner help with IntyBasic

[dalves]

Thanks mmarrero, I will check that out.

 

Here's my current version of Pressure Cooker. It is playable, but I still have some bugs to work out  along with the speed of the game. The link below is for the Atari 2600 manual for anyone not familiar with the game. Use the top button to throw back any wrong veggies, or to drop a completed burger into the wrapping slot.

 

https://atariage.com/manual_html_page.php?SoftwareLabelID=375

PRESCOOK5.rom

[dalves]

I have been trying to figure out what I am doing wrong on my own, and it seems when I think I figured it out, I don't.

 

I've been having random problems in games with collision detection. The problem is the collision detection seems to double the value of what I want it to do. whether If shooting a target should give you 10 points, it gives you 20. If being hit by a target should take away a life, it takes away two. Below is an example from a game I'm currently working on. This is within the main game loop. The line with "COL3 AND HIT_SPRITE1" calculates the FRTCNT and #SCORE values correctly. However the "IF COL6 AND HIT_SPRITE1" line doubles up the lost of HLTH value each time.

 

    SPRITE 0, BSKX+HIT+VISIBLE+ZOOMX2, 80+ZOOMY2, SPR00 + SPR_TAN
    SPRITE 1, BSKX+HIT+VISIBLE+ZOOMX2, 80+ZOOMY2, SPR01 + SPR_BROWN
    IF FRTY>79 THEN TOGGLESPRITEHIT(1)
        
    WAIT
    
    IF COL4 AND HIT_SPRITE3 THEN #FRTCLR=SPR_BROWN:BDFRT=1
    IF COL5 AND HIT_SPRITE3 THEN #FRTCLR=SPR_BROWN:BDFRT=1
    IF COL3 AND HIT_SPRITE6 THEN GOSUB WORMRESET
    IF COL3 AND HIT_SPRITE1 AND BDFRT=0 THEN FRTCNT=FRTCNT+1:#SCORE=#SCORE+10:GOSUB FRUITRESET:GOSUB UPDATE
    IF COL6 AND HIT_SPRITE1 THEN FRTCNT=0:HLTH=HLTH-1:GOSUB WORMRESET:GOSUB UPDATE

 

 

Edited December 28, 2020 by dalves

[Zendocon]

I try to avoid using hardware collision detection when possible.  The Intellivision Executive ROM was designed to do everything in a cycle of 3-6 video frames, reducing the size of cartridges at a time when ROM was a lot more expensive.  Therefore the collision detection flags are designed to be accurate by the third frame after collision actually happens.  Try to write your own routines to bypass using hardware collision detection if possible for your own sanity.

 

In my upcoming game DILLIGAS, I have one object bounce off the others.  My code looks something like this:

IF COL0 AND (FRAME AND 1) THEN
  zappervelx = 0 - zappervelx  ' bounce horizontally
ELSEIF COL0 THEN
  zappervely = 0 - zappervely  ' bounce vertically
END IF

Based on the idiosyncracies of hardware collision detection, how the "zapper" (sprite 0) bounces ends up being random.  Sometimes it bounces on one axis, sometimes the other, and sometimes on both axes.  ("FRAME AND 1" means every other video frame).

[+nanochess]

6 hours ago, dalves said:

I have been trying to figure out what I am doing wrong on my own, and it seems when I think I figured it out, I don't.

 

I've been having random problems in games with collision detection. The problem is the collision detection seems to double the value of what I want it to do. whether If shooting a target should give you 10 points, it gives you 20. If being hit by a target should take away a life, it takes away two. Below is an example from a game I'm currently working on. This is within the main game loop. The line with "COL3 AND HIT_SPRITE1" calculates the FRTCNT and #SCORE values correctly. However the "IF COL6 AND HIT_SPRITE1" line doubles up the lost of HLTH value each time.

 

    SPRITE 0, BSKX+HIT+VISIBLE+ZOOMX2, 80+ZOOMY2, SPR00 + SPR_TAN
    SPRITE 1, BSKX+HIT+VISIBLE+ZOOMX2, 80+ZOOMY2, SPR01 + SPR_BROWN
    IF FRTY>79 THEN TOGGLESPRITEHIT(1)
        
    WAIT
    
    IF COL4 AND HIT_SPRITE3 THEN #FRTCLR=SPR_BROWN:BDFRT=1
    IF COL5 AND HIT_SPRITE3 THEN #FRTCLR=SPR_BROWN:BDFRT=1
    IF COL3 AND HIT_SPRITE6 THEN GOSUB WORMRESET
    IF COL3 AND HIT_SPRITE1 AND BDFRT=0 THEN FRTCNT=FRTCNT+1:#SCORE=#SCORE+10:GOSUB FRUITRESET:GOSUB UPDATE
    IF COL6 AND HIT_SPRITE1 THEN FRTCNT=0:HLTH=HLTH-1:GOSUB WORMRESET:GOSUB UPDATE

 

 

The problem here is the following:

 

* Frame 1 - Your sprites are drawn.

* Frame 2 - The collision is detected, you order to remove the sprites.

* Frame 3 - The collision is detected because in this frame were updated the sprites.

* Frame 4 - The collision ceases.

 

The solution is easy, if you have a variable to signal a sprite alive (I tend to set the Y coordinate to zero to indicate a dead sprite), then add it to the condition check.

 

IF COL6 AND HIT_SPRITE1 THEN

    IF sprite_alive = 1 THEN

        ' Do collision process

        sprite_alive = 0

   END IF

END IF

 

[dalves]

Thanks for the help. Before knowing this I spent a lot of time moving the code around. Sometimes I would get lucky and it would work. Other times I'd still have trouble. These methods will help a ton. Thanks again.

[+Steve Jones]

Hi, I was just trying out your game but I can't seem to reject/throw back unwanted ingredients.

It says use the top button but that doesn't seen to be working.

It does work to drop the burgers down the chute on the other screen.

I'm using an Intellivision flashback controller and jzintv on my MacBook.

I never played the Atari version but watched a couple of videos and this seems to have the potential to be a good port of it.

(I'm not a programmer but I like to check out this forum and try out the new stuff you guys are working on)

 

Cheers, Steve

[masseo1]

"Beginner help with intybasic"?

Is there a 64-bit compiled linux version of intybasic?

I just picked up a chrome book and downloaded Intybasic 1.4.2. The binary fails to run because it is a 32bit binary and this Chromebook running linux on top, does not have 32bit support. I'll jump on my main laptop and give compiling a try, but figured I'd check here first.

 

Thanks.

 

 

 

 

[masseo1]

On 3/13/2021 at 5:16 PM, masseo1 said:

 

Is there a 64-bit compiled linux version of intybasic?

 

I got it compiled and it works fine. (now I have to get jzintv compiled correctly, in the small linux environment Im testing within Chrome OS)

Edited March 15, 2021 by masseo1
typo

[+DZ-Jay]

1 hour ago, masseo1 said:

 

I got it compiled and it works fine. (now I have to get jzintv compiled correctly, in the small linux environment Im testing within Chrome OS)

There is a jzIntv 64-bit binary already.  Does that not work in Chrome OS?

 

        -dZ.

[masseo1]

On 3/15/2021 at 7:57 PM, DZ-Jay said:

There is a jzIntv 64-bit binary already.  Does that not work in Chrome OS?

 

        -dZ.

Ah, I just totally missed that zip file.

I see the 64bit version .

 

thanks.

[+bhall408]

On 3/15/2021 at 5:00 PM, masseo1 said:

I got it compiled and it works fine. (now I have to get jzintv compiled correctly, in the small linux environment Im testing within Chrome OS)

Argon is 64 bit and will run on the Chromebook side of things... I've not used linux on a Chromebook, but presuming you can still use the Chromebook side of things at the same time as Linux side (ie, easily switch back and forth), you can have your linux makefile copy the resulting binary over to Download/Argon and then run it in Argon.

 

[dalves]

It's been a while since I've been here. I've decided to try to update some of my older game ideas and make them into something that offers a lot more playability. I've been doing a lot with sprites and on screen locations to make things happen. I'm aware there is a way to use BACKTAB locations as substitutes for more sprite. I was wondering if anyone knows a good existing .bas file that uses this method that I could research? I think if I could see how this is written, it would help a lot in implementing this into my own games.

[carlsson]

14 minutes ago, dalves said:

I'm aware there is a way to use BACKTAB locations as substitutes for more sprite. I was wondering if anyone knows a good existing .bas file that uses this method that I could research? I think if I could see how this is written, it would help a lot in implementing this into my own games.

Perhaps this post will help you a little, though by no means is it the ultimate implementation. Most importantly this method is great for sprites aligned to an even row or column and only needs to move smoothly horizontally or vertically. If you need to move in both directions, things get far more complex.

[Mik's Arcade]

On 12/28/2020 at 12:04 PM, nanochess said:

The problem here is the following:

 

* Frame 1 - Your sprites are drawn.

* Frame 2 - The collision is detected, you order to remove the sprites.

* Frame 3 - The collision is detected because in this frame were updated the sprites.

* Frame 4 - The collision ceases.

 

The solution is easy, if you have a variable to signal a sprite alive (I tend to set the Y coordinate to zero to indicate a dead sprite), then add it to the condition check.

 

IF COL6 AND HIT_SPRITE1 THEN

    IF sprite_alive = 1 THEN

        ' Do collision process

        sprite_alive = 0

   END IF

END IF

 

I'm glad this topic was resurrected; I still have this problem in my Sasuke game and I plan on fixing it.

 

With the solution above, where and when would "sprite_alive" get set to 1?

 

Or should the code actually be:

 

 

IF COL6 AND HIT_SPRITE1 THEN
   IF sprite_alive = 1 THEN
      ' Do collision process
      sprite_alive = 0
   ELSE
      sprite_alive = 1
   END IF
END IF

 

[+nanochess]

52 minutes ago, Mik's Arcade said:

I'm glad this topic was resurrected; I still have this problem in my Sasuke game and I plan on fixing it.

 

With the solution above, where and when would "sprite_alive" get set to 1?

 

Or should the code actually be:

 

 

IF COL6 AND HIT_SPRITE1 THEN
   IF sprite_alive = 1 THEN
      ' Do collision process
      sprite_alive = 0
   ELSE
      sprite_alive = 1
   END IF
END IF

 

Remove the ELSE part and you should be good.

[Mik's Arcade]

35 minutes ago, nanochess said:

Remove the ELSE part and you should be good.

that is where I am confused.

 

How does sprite_alive ever get set to 1 then?

 

thanks

[+nanochess]

17 hours ago, Mik's Arcade said:

that is where I am confused.

 

How does sprite_alive ever get set to 1 then?

 

thanks

In the code point where you set it to enter the gameplay. The part of code where you setup the x and y properties for a new spawn.

[Mik's Arcade]

1 hour ago, nanochess said:

In the code point where you set it to enter the gameplay. The part of code where you setup the x and y properties for a new spawn.

ok, perfect.  I have sections of my code for variable setups and will include this new variable here and test it out.

 

I also have that unique concept of the sprite being an enemy with more than 1 hit point, so I don't want to reset the sprite, just reduce the count one time per collision.  I'll probably need additional code for this though since the sprite will actually still be alive.  Then again, I could kill the sprite and just display it again.

 

And every now and then, the sound effect for the enemies that only have hit point plays twice, and this is why.

 

I've read about the double count on collision before, and talked about it with DZ-Jay before, but the way you outlined it above frame by frame finally helped the reason sink in.

 

thanks!

Edited December 21, 2021 by Mik's Arcade

[+nanochess]

39 minutes ago, Mik's Arcade said:

ok, perfect.  I have sections of my code for variable setups and will include this new variable here and test it out.

 

I also have that unique concept of the sprite being an enemy with more than 1 hit point, so I don't want to reset the sprite, just reduce the count one time per collision.  I'll probably need additional code for this though since the sprite will actually still be alive.  Then again, I could kill the sprite and just display it again.

 

And every now and then, the sound effect for the enemies that only have hit point plays twice, and this is why.

 

I've read about the double count on collision before, and talked about it with DZ-Jay before, but the way you outlined it above frame by frame finally helped the reason sink in.

 

thanks!

You're welcome.

 

The logic changes for a multi-hit enemy, basically you create a "shield" variable where you protect the enemy for a certain time.

 

For a multi-hit enemy, you change the code to something like this:

 

   IF enemy_shield THEN enemy_shield = enemy_shield - 1

    IF COL0 AND $0002 THEN   ' Sprite 0 vs 1

        IF enemy_alive <> 0 AND enemy_shield = 0 THEN    ' Enemy hit, and without shield

            enemy_shield = 5     ' Shield for 5 frames

            enemy_hits = enemy_hits + 1

            IF enemy_hits = 2 THEN

                enemy_alive = 0

                ' ... your sound effect for enemy explosion ...

                ' ... explosion code and such ...

            ELSE

                ' ... your sound effect for enemy hit ....

            END IF

        END IF

   END IF

[Mik's Arcade]

6 minutes ago, nanochess said:

You're welcome.

 

The logic changes for a multi-hit enemy, basically you create a "shield" variable where you protect the enemy for a certain time.

 

For a multi-hit enemy, you change the code to something like this:

 

 

   IF enemy_shield THEN enemy_shield = enemy_shield - 1

    IF COL0 AND $0002 THEN   ' Sprite 0 vs 1

        IF enemy_alive <> 0 AND enemy_shield = 0 THEN    ' Enemy hit, and without shield

            enemy_shield = 5     ' Shield for 5 frames

            enemy_hits = enemy_hits + 1

            IF enemy_hits = 2 THEN

                enemy_alive = 0

                ' ... your sound effect for enemy explosion ...

                ' ... explosion code and such ...

            ELSE

                ' ... your sound effect for enemy hit ....

            END IF

        END IF

   END IF

 

Yes!  This is what I was thinking, and I'm pretty sure a game in one of your books discussed the shield concept.

 

I'll to plug this code in and test even though I've moved on to my next game.  Soon I'll have two completed games in the books!