+atari2600land Posted June 7, 2015 Author Share Posted June 7, 2015 The one with bacon in it? Quote Link to comment Share on other sites More sharing options...
pimpmaul69 Posted June 7, 2015 Share Posted June 7, 2015 The one with bacon in it?no version before that. I didn't realize you posted a bacon version already. Quote Link to comment Share on other sites More sharing options...
mthompson Posted June 7, 2015 Share Posted June 7, 2015 I'm likin' the change to bacon & syrup and giving me a utensil to eat the waffles. I'm wondering if, at some later point in the game, Commander Kellogg will be able to earn the right to get closer to the machine and try to hit a "kill" switch and defeat it, thus keeping the world from being overrun by waffles. 1 Quote Link to comment Share on other sites More sharing options...
pimpmaul69 Posted June 7, 2015 Share Posted June 7, 2015 (edited) I found a problem. This happened several times. If your guy is standing all the way to the bottom, the jams that come at waistish level are missing the bottom half of the jar. Did you increase the difficulty? It seems harder. Which is ok with me if you did. If not i must have forgotten how to play. Edited June 7, 2015 by pimpmaul69 Quote Link to comment Share on other sites More sharing options...
pimpmaul69 Posted June 7, 2015 Share Posted June 7, 2015 (edited) Found a fork/waffle. Still trying to get a pic of defective jam but there arent any waffles before the defective jam to kill myself to take a pic Edited June 7, 2015 by pimpmaul69 Quote Link to comment Share on other sites More sharing options...
pimpmaul69 Posted June 7, 2015 Share Posted June 7, 2015 (edited) Finally got a pic of it! I dont believe the bottom of the lowest waffle goes lower than that cuttoff point of the jam Edited June 7, 2015 by pimpmaul69 Quote Link to comment Share on other sites More sharing options...
+Tarzilla Posted June 7, 2015 Share Posted June 7, 2015 Finally got a pic of it! image.jpg Looks like a priority problem due to how Color Stack mode was used when generating the machine screen (as seen earlier in the thread when a bunch of "4"s showed up. In the Show_Machine procedure there are a bunch of Print statements to ensure that there is nothing in the foreground except the blue machine, there needs to be one more at 200, might as well put one at 220. Quote Link to comment Share on other sites More sharing options...
+DZ-Jay Posted June 7, 2015 Share Posted June 7, 2015 (edited) Found a fork/waffle. Still trying to get a pic of defective jam but there arent any waffles before the defective jam to kill myself to take a pic image.jpg I've seen this a few times. When generating a new object, you should test that the new one does not overlap any existing one. This particular combination makes the fork useless, and the biggest problem is that you will have to wait a long time for the next chance to get a new fork. This adds to the player's frustration. -dZ. Edited June 7, 2015 by DZ-Jay Quote Link to comment Share on other sites More sharing options...
+DZ-Jay Posted June 7, 2015 Share Posted June 7, 2015 Looks like a priority problem due to how Color Stack mode was used when generating the machine screen (as seen earlier in the thread when a bunch of "4"s showed up. In the Show_Machine procedure there are a bunch of Print statements to ensure that there is nothing in the foreground except the blue machine, there needs to be one more at 200, might as well put one at 220. The right solution is to use the Color Stack better. The quick-and-dirty solution would be to ensure that all MOBs have their "priority" bit set. That way, it guarantees that they show "on top" of any background, even if they are "invisible pixels." -dZ. Quote Link to comment Share on other sites More sharing options...
pimpmaul69 Posted June 7, 2015 Share Posted June 7, 2015 (edited) One other suggestion is i would flip the bacon horizontally (mirror image) so it doesnt look like a flag. Edited June 7, 2015 by pimpmaul69 Quote Link to comment Share on other sites More sharing options...
+atari2600land Posted June 7, 2015 Author Share Posted June 7, 2015 About the overlapping characters. I made it so the worst case scenario is that if the power up touches a waffle, it passes right through it and ends up on the other side. I am wondering if collision detection still works with blank MOBs. Probably not, so this was my solution. Do you have a better one? Also, I changed the bacon sprite and I changed the fork sprite to make it seem larger. Quote Link to comment Share on other sites More sharing options...
+Tarzilla Posted June 7, 2015 Share Posted June 7, 2015 Or just make the one line of code that randomly sets the power up y value smarter and have it avoid the the existing y values for the other objects if the x value is greater than a certain amount. 1 Quote Link to comment Share on other sites More sharing options...
+DZ-Jay Posted June 7, 2015 Share Posted June 7, 2015 (edited) I am wondering if collision detection still works with blank MOBs. Probably not, so this was my solution. Collisions are registered if two MOBs overlap, whether they their visibility bit is set or not, and whether they are within the screen boundaries or not. The way I would do this is as follows: When creating a new object, select a random "Y" position Convert the "Y" position into a sprite bounding box (PosY = top of sprite; PosY + 8 = bottom of sprite). Compare the "Y" position of the last one or two created objects against this range. If it falls within the range, discard and try again from the first step Otherwise, initialize the object and end. Ideally, you would compare the full bounding box of the new object against all other existing objects. Edited June 7, 2015 by DZ-Jay Quote Link to comment Share on other sites More sharing options...
GroovyBee Posted June 7, 2015 Share Posted June 7, 2015 Collisions are registered if two MOBs overlap, whether they their visibility bit is set or not, and whether they are within the screen boundaries or not. Not quite. They both need their INTR bit set in each MOB's x register to interact with each other. Quote Link to comment Share on other sites More sharing options...
+Tarzilla Posted June 7, 2015 Share Posted June 7, 2015 Collisions are registered if two MOBs overlap, whether they their visibility bit is set or not, and whether they are within the screen boundaries or not. The way I would do this is as follows: When creating a new object, select a random "Y" position Convert the "Y" position into a sprite bounding box (PosY = top of sprite; PosY + 8 = bottom of sprite). Compare the "Y" position of the last one or two created objects against this range. If it falls within the range, discard and try again from the first step Otherwise, initialize the object and end. Ideally, you would compare the full bounding box of the new object against all other existing objects. That's what I said above :-) The only thing is I would only test the y bounding box if the x value of the other objects is within a certain distance of the spawn point. No point testing if object is halfway across the screen. I think what we are both trying to say is...don't use collisions to determine if the power up will overlap with another object at spawn time when simple math will work quicker. Quote Link to comment Share on other sites More sharing options...
+Tarzilla Posted June 7, 2015 Share Posted June 7, 2015 About the overlapping characters. I made it so the worst case scenario is that if the power up touches a waffle, it passes right through it and ends up on the other side. I am wondering if collision detection still works with blank MOBs. Probably not, so this was my solution. Do you have a better one? Also, I changed the bacon sprite and I changed the fork sprite to make it seem larger. You also need to fix the jam half disappearing behind the background as was suggested above with the additional print statements in the show_machine procedure. Quote Link to comment Share on other sites More sharing options...
+DZ-Jay Posted June 7, 2015 Share Posted June 7, 2015 Not quite. They both need their INTR bit set in each MOB's x register to interact with each other. Ah, well, sorry for taking that as an obvious requirement. I meant that the visibility of objects does not have an impact on their collision detection, only their position and the "Interaction Bit." 1 Quote Link to comment Share on other sites More sharing options...
+DZ-Jay Posted June 7, 2015 Share Posted June 7, 2015 That's what I said above :-) The only thing is I would only test the y bounding box if the x value of the other objects is within a certain distance of the spawn point. No point testing if object is halfway across the screen. I think what we are both trying to say is...don't use collisions to determine if the power up will overlap with another object at spawn time when simple math will work quicker. Exactly: don't rely on the hardware collision detection for this. It's a "logical" collision: you detect it before you create the object. -dZ. Quote Link to comment Share on other sites More sharing options...
GroovyBee Posted June 7, 2015 Share Posted June 7, 2015 Ah, well, sorry for taking that as an obvious requirement. I meant that the visibility of objects does not have an impact on their collision detection, only their position and the "Interaction Bit." Its an IntyBASIC project and not everybody knows the STIC as well as we do . Quote Link to comment Share on other sites More sharing options...
catsfolly Posted June 7, 2015 Share Posted June 7, 2015 Ah, well, sorry for taking that as an obvious requirement. I meant that the visibility of objects does not have an impact on their collision detection, only their position and the "Interaction Bit." But I think the program makes the waffles initially "invisible" not by setting the visibility bit, but by assigning them to a blank picture. These "Blank Mobs" will not collide with anything, I think... Quote Link to comment Share on other sites More sharing options...
+atari2600land Posted June 7, 2015 Author Share Posted June 7, 2015 I tried and failed. I guess I'm just too dumb to do this. Can someone else do this for me? sgwp.bas Quote Link to comment Share on other sites More sharing options...
+Tarzilla Posted June 8, 2015 Share Posted June 8, 2015 Added simple Powerup Y coordinate spawn avoidance of existing waffles If waffle is on the same row as new powerup, but is more than 20 pixels from the left of the screen and more than 50 pixels from spawn point don't bother checking. Wont spawn on the same row of an existing waffle, gets a new Y if so. waffle1x <120 and waffle1x>20 can be fiddled with for each waffle to get a feel for how close a waffle can spawn if on the same row. sgwp_FixOverlapping_Powerups.bas This is probably not the most effiecient way but it probably is the simplest to understand Quote Link to comment Share on other sites More sharing options...
+atari2600land Posted June 8, 2015 Author Share Posted June 8, 2015 I saw a piece of bacon over a waffle I think. Quote Link to comment Share on other sites More sharing options...
+DZ-Jay Posted June 8, 2015 Share Posted June 8, 2015 But I think the program makes the waffles initially "invisible" not by setting the visibility bit, but by assigning them to a blank picture. These "Blank Mobs" will not collide with anything, I think... That is true, if there are no pixels on the MOB, then there is nothing for it to collide with. Its an IntyBASIC project and not everybody knows the STIC as well as we do . True again. Quote Link to comment Share on other sites More sharing options...
+Tarzilla Posted June 8, 2015 Share Posted June 8, 2015 I saw a piece of bacon over a waffle I think. Possibly. I went back and looked and I was assuming you were using waffle1y like you were with waffle1x, instead of hard coding the SPRITE y parameter. This version fixes that by adding Waffle1y etc variables and setting them to your hard coded values. I also changed the random function that generates the PowerY so it is actually generates random number between (1 and 66) +12, instead of always in the same 4 spots. You might want to consider randomizing the waffle1y etc values. I also added a technique to add some randomness to the RAND function by calling RAND each title screen loop to give more randomness. sgwp.bas Quote Link to comment Share on other sites More sharing options...
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
Recommended Posts
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.