KevKelley Posted January 9, 2020 Share Posted January 9, 2020 I am trying to figure some things out with having a virtual sprite scroll from one side of the screen to the other side. When it reaches the end, intend on the Sprite to then move to a different y-coordinate and then travel in the opposite direction. The problem I seem to be having is that when the Sprite reaches the end of the screen, part of it may appear on the other side before making the jump. I had tried NUSIZx{7} command to have the Sprite move off screen and not show up, but that did not seem to work to well. I will have to post the code in a little bit (I don't have it at the moment - I'm on my phone). I had looked through RT's website to no avail and was wondering if I am overlooking something simple or if anyone has any tricks they have used in the past in regards to the desired effect. It makes me wonder about my code in the past because I had the sprites generally loop so I may not have noticed any funny stuff. Quote Link to comment Share on other sites More sharing options...
+Gemintronic Posted January 9, 2020 Share Posted January 9, 2020 It depends on which kernel you're using but all of them I've seen have this behavior. The only solution I've come up with is to manually figure out which x position each sprite needs to stop at before looping. Typically using some code to display the x position as a decimal number in the score. Quote Link to comment Share on other sites More sharing options...
+Karl G Posted January 9, 2020 Share Posted January 9, 2020 Check out the virtual Sprite masking section on RT's batari basic page. https://www.randomterrain.com/atari-2600-memories-batari-basic-commands.html#dpc_sprite_masking Quote Link to comment Share on other sites More sharing options...
KevKelley Posted January 9, 2020 Author Share Posted January 9, 2020 I had read that section. My thoughts are that when moving from right to left, the issue is more pronounced because currently when the x-coordinate hits 0 is when the y-coordinate changes, where as in the other direction the x-coordinate keeps adding up and it goes off the screen. I wasn't really thinking about this at the time but I guess if I redo the check at 0 it may work better. Quote Link to comment Share on other sites More sharing options...
KevKelley Posted January 17, 2020 Author Share Posted January 17, 2020 (edited) So I kind of figured out a solution. After going through RT's page, I read about PF0. I was using DPC+. To be honest, I never really understood about PF0 prior. I knew the playfield stopped at a certain point but that was all. If I use PF0 = %11110000 it makes the thicker border and hides the sprites as they reach the end of the playfield so that they do not linger on the screen any longer than desired. The only trade off I find is the appearance of a smaller screen. While in my game the player did not originally cross the coordinates into this area, I liked the appearance of the screen without the border and the border did not really offer much than hiding a Sprite every once and a while as it moved off screen. Now if I choose to use PF0 the new problem I have found is that the colors are extremely weird and do not match up with the middle of the screen. That I have yet to learn about. Otherwise I will just alter how the sprites move so they don't seem glitchy. Edited January 17, 2020 by KevKelley Spelling error. 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.