+Karl G Posted August 3, 2017 Share Posted August 3, 2017 It seems that if pfheights is defined then vertical scrolling causes the score and the 6lives_statusbar minikernel to jump up and down. This happens even when all of the rows are set to 8, and it doesn't happen when pfheights is not defined. Is there any way to avoid this? The part of my game where I need scrolling doesn't require any nonstandard row heights - I know that I can't turn off this kernel option temporarily, though. :-) Here is a pared down example that shows the jumping for the score. vert.bas vert.bas.bin Quote Link to comment Share on other sites More sharing options...
RevEng Posted August 3, 2017 Share Posted August 3, 2017 It looks like batari figured that people wouldn't use scrolling with pfheights. I've given pfheights the same last line condition as non-pfheights kernels, and it seems to work. Stick this kernel in your build directory, and rebuild your basic game. std_kernel.asm This is completely untested with any other pfheights code, so it's entirely possible it will do weird things. Quote Link to comment Share on other sites More sharing options...
+Karl G Posted August 3, 2017 Author Share Posted August 3, 2017 Thanks! Yes, it looks like that fixed the problem for my example, but, yes, it also causes weirdness when I actually use pfheights on my game over screen (without any scrolling). gameover.bas.bin gameover.bas Quote Link to comment Share on other sites More sharing options...
RevEng Posted August 3, 2017 Share Posted August 3, 2017 If you set "playfieldpos = 1" right before the game over screen does it improve anything? If not, the value might depend on your pfheights - try a few different values too. Quote Link to comment Share on other sites More sharing options...
RevEng Posted August 3, 2017 Share Posted August 3, 2017 Actually, scratch that. I thought you meant the score was still bouncing. The standard kernel really isn't designed to correctly and smoothly scroll through variable PF heights. That would likely take a new kernel, with more sacrifices. Quote Link to comment Share on other sites More sharing options...
+Karl G Posted August 3, 2017 Author Share Posted August 3, 2017 Actually, scratch that. I thought you meant the score was still bouncing. The standard kernel really isn't designed to correctly and smoothly scroll through variable PF heights. That would likely take a new kernel, with more sacrifices. I figured that was the case - but I'm not trying to scroll on a screen with variable pfheights. My Game Over example here does not do any scrolling. I have one section of the game that does scrolling, but doesn't need custom pfheights (all are set to , and another part of the game (the Game Over screen) that needs variable pfheights, but does not need scrolling. I don't at any point need to scroll a variable height playfield. The first part is fixed, thanks to you, but right now the customized kernel doesn't deal well with a variable height playfield that isn't scrolling. I appreciate your help - I hope I am explaining myself better this time. Quote Link to comment Share on other sites More sharing options...
RevEng Posted August 3, 2017 Share Posted August 3, 2017 Ok. If you remove the pfscroll command from your game over screen loop, and add "playfieldpos=1" prior to the drawscreen, it should be stable. Quote Link to comment Share on other sites More sharing options...
+Karl G Posted August 3, 2017 Author Share Posted August 3, 2017 Ok. If you remove the pfscroll command from your game over screen loop, and add "playfieldpos=1" prior to the drawscreen, it should be stable. Oh - I missed that I hadn't taken out the pfscroll command in my simplified demo. Adding playfieldpos=1 fixed the display stability issue. The one remaining issue I see if that the first pfheight value for the top row now gets discarded, so my "game over" is at the top of the screen instead of more centered. Is this an unavoidable side effect of your kernel fix? gameover.bas Quote Link to comment Share on other sites More sharing options...
RevEng Posted August 3, 2017 Share Posted August 3, 2017 Yeah, I believe so. There are compile-time differences between a variable pfheights screen and other types of screens, and this is pretty much as close we can get to eating your cake and having it too. With a kernel rewrite it may be possible, but other things would probably get lost in the process. Quote Link to comment Share on other sites More sharing options...
+Karl G Posted August 3, 2017 Author Share Posted August 3, 2017 No worries - and thank you! If I wanted to truly be stubborn about it, I could always retool my game to use your multikernel framework, and have pfheights in some parts but not others. Probably for this project I'll just force myself to be less pedantic about the position of the game over text. 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.