Opry99er Posted October 29, 2015 Share Posted October 29, 2015 16530 DIF=ABS(PR-FCR)+ABS(PC-FCC) 16540 IF DIF>4 THEN 17000 PC and PR represent a static column and row position on the screen and FCC snd FCR represent a movable piece. Brownie points to who can tell me the shape of the legal playfield for the movable piece. (Coded this into my Jedi Gauntlet game last night and I pretty happy about it) Quote Link to comment Share on other sites More sharing options...
Asmusr Posted October 29, 2015 Share Posted October 29, 2015 A 'diamond'? /\ \/ Quote Link to comment Share on other sites More sharing options...
Opry99er Posted October 29, 2015 Author Share Posted October 29, 2015 Aye... I guess it was not that difficult... But it took me a day or two to figure out a universal function for all directions. ABS ended up being the key to the kingdom. 4 brownie points for the great Rasmus. Quote Link to comment Share on other sites More sharing options...
+adamantyr Posted October 29, 2015 Share Posted October 29, 2015 Very nice! I'm looking forward to playing this one. Quote Link to comment Share on other sites More sharing options...
Opry99er Posted October 29, 2015 Author Share Posted October 29, 2015 Should have something playable soon. Just have to design and code in the remaining level data, then finish tightening up my Force 'move objects' code and then it should be ready for testing. The force playfield code listed above was a big step... I am still playing with the allowable value, right now '4' is working nicely... I may go to 5. We shall see how the difficulty ramps up. 1 Quote Link to comment Share on other sites More sharing options...
sometimes99er Posted October 30, 2015 Share Posted October 30, 2015 Interesting. A very nice and simple implementation for this shape. Technically the algorithm is collision detection between two diamonds. The break value will detect a hit between two diamonds of certain sizes. ABSolutely perfect Forcefield ? Hint. Test approach from more than 8 corners of the world (southeast, northwest etc.). Quote Link to comment Share on other sites More sharing options...
Willsy Posted October 30, 2015 Share Posted October 30, 2015 16530 DIF=ABS(PR-FCR)+ABS(PC-FCC) 16540 IF DIF>4 THEN 17000 PC and PR represent a static column and row position on the screen and FCC snd FCR represent a movable piece. Brownie points to who can tell me the shape of the legal playfield for the movable piece. (Coded this into my Jedi Gauntlet game last night and I pretty happy about it) If you're not using DIF elsewhere, then just do: 16530 IF (ABS(PR-FCR)+ABS(PC-FCC))>4 THEN 17000 Quote Link to comment Share on other sites More sharing options...
Opry99er Posted October 30, 2015 Author Share Posted October 30, 2015 Interesting. A very nice and simple implementation for this shape. Technically the algorithm is collision detection between two diamonds. The break value will detect a hit between two diamonds of certain sizes. ABSolutely perfect Forcefield ? Hint. Test approach from more than 8 corners of the world (southeast, northwest etc.). Thanks for the reply. I have edge cases handled to where every screen position is accessible... For instance, on an "up" check, IF ROW<2 (blocking the border in row 1), then you cannot move the Force cursor, and similar code for each cardinal direction. You have to get pretty close to the corner to access a corner position, but that is part of the strategy. once you are locked on to an object, you cannot move Yoda until you drop the object, and you have a limited number of Force actions per level. Much of the strategy will be positioning Yoda in the correct place BEFORE initiating the Force so that you have the room to move the piece to the proper location in one Force move. 1 Quote Link to comment Share on other sites More sharing options...
+adamantyr Posted October 30, 2015 Share Posted October 30, 2015 If you're not using DIF elsewhere, then just do: 16530 IF (ABS(PR-FCR)+ABS(PC-FCC))>4 THEN 17000 In TI BASIC though, you may want to separate calculation from the actual comparison check. I noticed when writing Aperture that overloading IF statements with a lot of extra math slowed things WAY down. In fact, Owen, you should make sure you're only doing the diamond check when ABSOLUTELY needed. (To quote the thread title. ) Every calculation takes visible time to do. Quote Link to comment Share on other sites More sharing options...
Opry99er Posted October 30, 2015 Author Share Posted October 30, 2015 True. This calculation is only done when Force is activated and a move is attempted by the user. Currently it is very fast and responsive. Quote Link to comment Share on other sites More sharing options...
+adamantyr Posted October 30, 2015 Share Posted October 30, 2015 True. This calculation is only done when Force is activated and a move is attempted by the user. Currently it is very fast and responsive. Excellent! yeah, with Aperature I ended up breaking up normal movement and falling into completely separate routines so that I could limit the number of IF statements checking the graphic character you were moving into to only the ones necessary. I also found out that statements like this: IF (G=128)+(G=129)+(G=130) THEN 1000 Are actually WAY more time-consumptive than this: IF G=128 THEN 1000 IF G=129 THEN 1000 IF G=130 THEN 1000 I also would put the most common character encountered in gameplay first so it could exit the loop of checking characters as quick as possible. 1 Quote Link to comment Share on other sites More sharing options...
Opry99er Posted October 30, 2015 Author Share Posted October 30, 2015 Good thinking. 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.