Jump to content

Photo

pfheights and vertical scrolling


9 replies to this topic

#1 kdgarris OFFLINE  

kdgarris

    Chopper Commander

  • 129 posts

Posted Thu Aug 3, 2017 12:30 PM

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.

 

Attached File  vert.bas   1.08KB   13 downloads

 

Attached File  vert.bas.bin   4KB   13 downloads



#2 RevEng OFFLINE  

RevEng

    River Patroller

  • 4,638 posts
  • Bitnik
  • Location:Canada

Posted Thu Aug 3, 2017 1:03 PM

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.

Attached File  std_kernel.asm   17.66KB   10 downloads

This is completely untested with any other pfheights code, so it's entirely possible it will do weird things.

#3 kdgarris OFFLINE  

kdgarris

    Chopper Commander

  • Topic Starter
  • 129 posts

Posted Thu Aug 3, 2017 1:57 PM

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).

 

Attached File  gameover.bas.bin   4KB   9 downloads

 

Attached File  gameover.bas   1005bytes   11 downloads

 

gameover.bas_2.png



#4 RevEng OFFLINE  

RevEng

    River Patroller

  • 4,638 posts
  • Bitnik
  • Location:Canada

Posted Thu Aug 3, 2017 2:43 PM

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.

#5 RevEng OFFLINE  

RevEng

    River Patroller

  • 4,638 posts
  • Bitnik
  • Location:Canada

Posted Thu Aug 3, 2017 2:48 PM

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.

#6 kdgarris OFFLINE  

kdgarris

    Chopper Commander

  • Topic Starter
  • 129 posts

Posted Thu Aug 3, 2017 2:55 PM

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 8), 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.



#7 RevEng OFFLINE  

RevEng

    River Patroller

  • 4,638 posts
  • Bitnik
  • Location:Canada

Posted Thu Aug 3, 2017 3:02 PM

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.

#8 kdgarris OFFLINE  

kdgarris

    Chopper Commander

  • Topic Starter
  • 129 posts

Posted Thu Aug 3, 2017 3:13 PM

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?

 

Attached File  gameover.bas   1006bytes   9 downloads



#9 RevEng OFFLINE  

RevEng

    River Patroller

  • 4,638 posts
  • Bitnik
  • Location:Canada

Posted Thu Aug 3, 2017 3:26 PM

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.

#10 kdgarris OFFLINE  

kdgarris

    Chopper Commander

  • Topic Starter
  • 129 posts

Posted Thu Aug 3, 2017 4:01 PM

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. :)




0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users