kikipdph Posted March 25 Share Posted March 25 Although the game has not yet been tested, people who have obtained it have started sharing it, so I am publicly releasing it The Final D The player's goal is to protect the core of the spaceship from the attacks of the alien race. Download link https://www.prijedor-x.com/finald.html 7 2 Quote Link to comment Share on other sites More sharing options...
kikipdph Posted March 26 Author Share Posted March 26 Updated: The game did not pass the test on the Harmony cartridge. on Stella is OK Quote Link to comment Share on other sites More sharing options...
Thomas Jentzsch Posted March 26 Share Posted March 26 1 hour ago, kikipdph said: Updated: The game did not pass the test on the Harmony cartridge. on Stella is OK What's wrong on real hardware? Using Stella, I spot some inconsistent scanline counts, does it roll? Quote Link to comment Share on other sites More sharing options...
kikipdph Posted March 26 Author Share Posted March 26 (edited) 55 minutes ago, Thomas Jentzsch said: What's wrong on real hardware? Using Stella, I spot some inconsistent scanline counts, does it roll? When I hit an enemy on the Harmony cartridge, the screen glitches (screen flicker). It's okay on my Stella. I don't personally have an Atari 2600, so I can't test it regularly. The background doesn't move (roll), and the top line flickers as a force field effect. Edited March 26 by kikipdph Quote Link to comment Share on other sites More sharing options...
Thomas Jentzsch Posted March 26 Share Posted March 26 Stella sensitivity to imperfect frames is not 100% accurate. Also each TV behaves differently. If you enable the info overlay, you can see it flickering from time to time. If you then skip back in the debugger, you can see that some frames are longer than 262 scanlines. And you can increase the jitter sensitivity in developer mode from 8 to 9 or 10. This will catch more frame bugs, even slight ones. Quote Link to comment Share on other sites More sharing options...
kikipdph Posted March 26 Author Share Posted March 26 (edited) 3 hours ago, Thomas Jentzsch said: Stella sensitivity to imperfect frames is not 100% accurate. Also each TV behaves differently. If you enable the info overlay, you can see it flickering from time to time. If you then skip back in the debugger, you can see that some frames are longer than 262 scanlines. And you can increase the jitter sensitivity in developer mode from 8 to 9 or 10. This will catch more frame bugs, even slight ones. I knew where the problem was, now we know what's causing it, but I haven't found the BUG. I tried to solve it with one more drawscreen, but Atari doesn't allow it, or rather, it does allow it but it slows down the game a lot, but it solves the 262 lines problem. However, that method cannot be used because it slows down the game. Even though it solves the problem, it's not a viable solution. I'm new to Batari Basic, and I didn't know that the Stella had separate functions Edited March 26 by kikipdph Quote Link to comment Share on other sites More sharing options...
Thomas Jentzsch Posted March 26 Share Posted March 26 Sounds like you have to optimize your code. Do you know which code is most time consuming? Or maybe there is code which must not be executed each frame? Quote Link to comment Share on other sites More sharing options...
kikipdph Posted March 26 Author Share Posted March 26 (edited) 49 minutes ago, Thomas Jentzsch said: Sounds like you have to optimize your code. Do you know which code is most time consuming? Or maybe there is code which must not be executed each frame? The most important problem occurs when missile0 and sprite make contact, that is when this if missile0y + 3 > player5y && missile0y < player5y + 7 && missile0y < 180 then m = 1 if m = 1 && missile0x + 8 > player5x && player5x + 8 > missile0x then missile0y = 190: player4y = player5y : player4x = player5x : o = 1 : gosub __polica_9 : player5y = 210 m = 0 It's similar to when the Enemy hits the Player and doesn't create a problem. sub polica 9 is scoring The variable "o" is for the animation and sound of the enemy's death. "Player4" replaces "sprite5" and serves with "o" as the animation of the enemy's death. The variable "m" is used to detect which sprite is dying. Edited March 26 by kikipdph Quote Link to comment Share on other sites More sharing options...
Thomas Jentzsch Posted March 26 Share Posted March 26 What happens when you remove the scoring call? Quote Link to comment Share on other sites More sharing options...
kikipdph Posted March 26 Author Share Posted March 26 4 minutes ago, Thomas Jentzsch said: What happens when you remove the scoring call? That's the problem and that's the only thing I didn't pay attention to. I will test it some more and then we will see if it's resolved. Now, I just need to figure out how to implement the score. Quote Link to comment Share on other sites More sharing options...
Thomas Jentzsch Posted March 26 Share Posted March 26 You could set a marker and increase the score when you have time. Quote Link to comment Share on other sites More sharing options...
kikipdph Posted March 26 Author Share Posted March 26 3 hours ago, Thomas Jentzsch said: You could set a marker and increase the score when you have time. The problem still persists, Score just slightly eased it. Something is wrong with the code, and I can't figure out what. I'm also a bit overwhelmed with life. if missile0y + 3 > player5y && missile0y < player5y + 7 && missile0y < 180 then m = 1 The part of the code that I previously wrote, when I isolate it, everything is okay. The variable N is not the problem, but rather in this part. if missile0y + 3 > player5y && missile0y < player5y + 7 && missile0y < 180 Quote Link to comment Share on other sites More sharing options...
Thomas Jentzsch Posted March 26 Share Posted March 26 I do not do bBasic, so I cannot help with details. You should ask in the bB forum. Quote Link to comment Share on other sites More sharing options...
kikipdph Posted March 26 Author Share Posted March 26 15 minutes ago, Thomas Jentzsch said: I do not do bBasic, so I cannot help with details. You should ask in the bB forum. And it's actually better because I found an error, although it's not really an error in the code, but rather something that is meaningless and difficult to explain. Quote Link to comment Share on other sites More sharing options...
Phobos867 Posted March 27 Share Posted March 27 (edited) Cool game! I love the graphics and the way how the enemy moves on the later stages. The only thing that botters me is how slow the first stage is. I know it supposed to be easy but you have to wait a lot without little to do. Maybe the enemies could shoot the player? Anyway really cool overall. I love the background details and the enemy design. Edited March 28 by Phobos867 Quote Link to comment Share on other sites More sharing options...
Mr SQL Posted March 28 Share Posted March 28 On 3/26/2023 at 11:05 AM, kikipdph said: if missile0y + 3 > player5y && missile0y < player5y + 7 && missile0y < 180 then m = 1 if m = 1 && missile0x + 8 > player5x && player5x + 8 > missile0x then missile0y = 190: player4y = player5y : player4x = player5x : o = 1 : gosub __polica_9 : player5y = 210 m = 0 One way may be to balance branches by adding labels to jump around doing both long conditional checks on m each frame, based on m: if m=1 goto branch2:rem load balance branch1 if missile0y + 3 > player5y && missile0y < player5y + 7 && missile0y < 180 then m = 1:goto donebranches:rem load balance branch2 if m = 1 && missile0x + 8 > player5x && player5x + 8 > missile0x then missile0y = 190: player4y = player5y : player4x = player5x : o = 1 : gosub __polica_9 : player5y = 210 m = 0 donebranches This way only one of those long conditional checks will be done each frame and should not impact the other. Not sure if you wanted to use and instead of logical && 1 Quote Link to comment Share on other sites More sharing options...
kikipdph Posted March 28 Author Share Posted March 28 On 3/27/2023 at 9:36 AM, Phobos867 said: Cool game! I love the graphics and the way how the enemy moves on the later stages. The only thing that botters me is how slow the first stage is. I know it supposed to be easy but you have to wait a lot without little to do. Maybe the enemies could shoot the player? Anyway really cool overall. I love the background details and the enemy design. This is my second video game, and when I realized that I had surpassed the limitations of Atari, and that the repairs required more time, I lost the will to fix this one and make other games. But I agree with what you wrote. Quote Link to comment Share on other sites More sharing options...
Phobos867 Posted March 30 Share Posted March 30 (edited) On 3/28/2023 at 2:37 PM, kikipdph said: This is my second video game, and when I realized that I had surpassed the limitations of Atari, and that the repairs required more time, I lost the will to fix this one and make other games. But I agree with what you wrote. It's just a nitpick though. The game is pretty fun and I'm getting used to it! Edited March 30 by Phobos867 Quote Link to comment Share on other sites More sharing options...
kikipdph Posted March 31 Author Share Posted March 31 (edited) 5 hours ago, Phobos867 said: It's just a nitpick though. The game is pretty fun and I'm getting used to it! The game has been pulled due to revisions, it will be released in a few days. I will write to you when I publish it. "Now the first phase has been shortened." Edited March 31 by kikipdph 2 Quote Link to comment Share on other sites More sharing options...
kikipdph Posted April 1 Author Share Posted April 1 On 3/30/2023 at 10:16 PM, Phobos867 said: It's just a nitpick though. The game is pretty fun and I'm getting used to it! I fixed the game, and now it's working fine without any overscan issues. I took the opportunity to listen to your advice and shortened the first phase.https://www.prijedor-x.com/finald.html 1 Quote Link to comment Share on other sites More sharing options...
kikipdph Posted April 1 Author Share Posted April 1 The game 'The Final D' has been repaired after being obtained from the internet and is now available again. I apologize for any inconvenience caused, and it has since been tested on the Atari 2600 console, which I do not personally ownhttps://www.prijedor-x.com/finald.html 2 Quote Link to comment Share on other sites More sharing options...
Phobos867 Posted April 2 Share Posted April 2 The timing is much nicer now, good job! 1 Quote Link to comment Share on other sites More sharing options...
Phobos867 Posted April 14 Share Posted April 14 2 Quote Link to comment Share on other sites More sharing options...
kikipdph Posted April 16 Author Share Posted April 16 On 4/14/2023 at 7:38 PM, Phobos867 said: I wonder if anyone has managed to reach the end of the game. I've come close twice myself, even though I created it and know what's at the end, I'm still excitedly struggling to reach the end. 1 Quote Link to comment Share on other sites More sharing options...
+ZeroPage Homebrew Posted April 27 Share Posted April 27 ZeroPage Homebrew is playing The Final D on tomorrow's ZPH stream LIVE on Twitch, hope you can join us! Fri Apr 28, 2023 | LIVE @ 6PM PT | 9PM ET | 2AM GMT+1Day WATCH LIVE: https://www.twitch.tv/zeropagehomebrew/WATCH LATER: https://youtube.com/zeropagehomebrew/ Games: The Final D (2023 WIP | 2600) by Mirsad Sarajlic @kikipdph Grocery Game (2023 WIP | 2600) by Grocer Games / Kevin Kelley @KevKelley Lupin 3 (2023 WIP | 2600) by Alberto @jab The Legend of Zelda (2023 WIP | 2600) by mzxrules @mzxrules (WATCH AT 1080P60 FOR BEST QUALITY) UPDATE! The time has changed to 6PM PT and has been updated in the post as unfortunately Darcy is feeling under the weather and can't make it for an early show. See you tonight! Quote Link to comment Share on other sites More sharing options...
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.