Forums

Hi,

For 2 or 3 weeks now, I'm fighting with the hud of my GG game.
It's SpaceHawks ported to GG, to understand the difference between the SMS and the GG.

I won't talk about my (bad) surprise to discover they used a "window" on the SMS screen.
My concern is more about the fact that, doing this way, the 3 first rows aren't on screen and so, HScroll lock isn't working (VDP Reg 0 bit 6).

Since I use Hscroll to move the enemies group AND my HUD is on top of the screen....the HUD scrolls too :(

To handle that, I though I could use the trick to set the xscroll value within a line interrupt, like it was done before by sverx (http://www.smspower.org/forums/16281-DevkitSMSExamples#94090 and http://www.smspower.org/Homebrew/RasterParallax-SMS)

And here came the problems...
Doing that, the scroll is shaggy on each row and the VDP is sometimes corrupted.
I don't see why.
I first though the LineInterrupt occured while I was writing to VDP but it's not(?) possible with my workflow of my game.

loop
wait for vblank
do all VDP writes, sprites update flush included
do all game logic, unrelated to VDP
i = 0
set lineCounter(8)
enable lineinterrupt
endloop

lineInterrupt handler
if (i=0) scroll = 0
if (i=3) scroll = scrollValue, disable lineinterrupt
i++
endhandler

Am I missing something very important ?

The only thing I now could think of, after trying everything else is
when I enable lineinterrupt, the VDisplay has already started
so when I test if (i=0), it doesn't mean I'm on line 0... but on first line displayed after I ended my loop

It could explain why the screen is shaking :
if (i=3) scroll = scrollValue is never called at the same moment, based on the amount of time I spend updating the game logic (collide detection included, so time related to the number of sprites to test)

but in this case, how could I handle it ?!
Limit the code to fit on the vblank time interval seems to be really hard to master.
I though I handled it on SMS but should I understand it breaks on GG ?!

I'm totally out of idea, about to trash the project...and all of this because Sega used this stupid "centered SMS window"

Why don't you do

set lineCounter(24)
scroll = 0

and get rid of i?

Calindro wrote

Why don't you do

set lineCounter(24)
scroll = 0

and get rid of i?

It's what I tried first, unfortunatly
I came to this one to handle every scroll (the 0 one included) on lineInterrupt, to see if it was the reason it failed

Alright, then I can only ask about a rom file again. It would make it much easier for me to investigate what's going wrong.

really, I suggest you don't call lineIRQ every line, that would eat up too much of your CPU cycles.

see the other topic, which is what Calindro is also saying here. Also, it's the correct way as you want the screen to start unscrolled.

Using Emulicious' Profiler, I found that my game loop is almost 200 scanlines.
So obviously, Lineinterrupt occurs while I'm updating my game logic.
It explains why things could be broken any times and why waiting the end of game loop to activate LineInterrupt makes the screen shaking (since scroll is updated every 2 frames and reseted to 0 every frame)

It would ask me too much to make the game loop to be "line interrupt" compliant (!) so I'll jump to the software scroll option.
It'll less fluid but more in sync with the original CPC game, giving it an old feeling and be different from the SMS version.

thanks for all your help and hints, it helped me to go even deeper on the display process of the GG (and SMS).

KanedaFr wrote

I found that my game loop is almost 200 scanlines.

you've got 262 of them each frame so you should be fine

in other words, profile your functions and you'll find out where you're eating too much CPU

there are also a few tricks if you just need to save a few lines and you never need all the 64 sprites...

Maybe you dont have to check everything all frames. I am doing half one frame and halc other. Even some things are done one in four frames.

eruiz00 wrote

Maybe you dont have to check everything all frames. I am doing half one frame and halc other. Even some things are done one in four frames.

I split my heavier logic (collide!) on 4 frames without too much bugs...
So, yes, I already tried...

sverx wrote

KanedaFr wrote

I found that my game loop is almost 200 scanlines.

you've got 262 of them each frame so you should be fine

in other words, profile your functions and you'll find out where you're eating too much CPU

there are also a few tricks if you just need to save a few lines and you never need all the 64 sprites...

The point is , at 200 scanlines, a part of my gameloop is still running while a line interrupt occurs.
So it means I could set the hscroll while I'm testing 1 collide...and this seems to be UNSAFE : it brokes my Z80 registers (HL or BC, according where the lineinterrupt occurs)

Author	Message
KanedaFr Joined: 01 Jul 2016 Posts: 55	GG Hscroll lock nightmare Posted: Fri Mar 31, 2017 11:14 pm Last edited by KanedaFr on Fri Mar 31, 2017 11:48 pm; edited 1 time in total
KanedaFr Joined: 01 Jul 2016 Posts: 55	Hi, For 2 or 3 weeks now, I'm fighting with the hud of my GG game. It's SpaceHawks ported to GG, to understand the difference between the SMS and the GG. I won't talk about my (bad) surprise to discover they used a "window" on the SMS screen. My concern is more about the fact that, doing this way, the 3 first rows aren't on screen and so, HScroll lock isn't working (VDP Reg 0 bit 6). Since I use Hscroll to move the enemies group AND my HUD is on top of the screen....the HUD scrolls too :( To handle that, I though I could use the trick to set the xscroll value within a line interrupt, like it was done before by sverx (http://www.smspower.org/forums/16281-DevkitSMSExamples#94090 and http://www.smspower.org/Homebrew/RasterParallax-SMS) And here came the problems... Doing that, the scroll is shaggy on each row and the VDP is sometimes corrupted. I don't see why. I first though the LineInterrupt occured while I was writing to VDP but it's not(?) possible with my workflow of my game. loop wait for vblank do all VDP writes, sprites update flush included do all game logic, unrelated to VDP i = 0 set lineCounter(8) enable lineinterrupt endloop lineInterrupt handler if (i=0) scroll = 0 if (i=3) scroll = scrollValue, disable lineinterrupt i++ endhandler Am I missing something very important ? The only thing I now could think of, after trying everything else is when I enable lineinterrupt, the VDisplay has already started so when I test if (i=0), it doesn't mean I'm on line 0... but on first line displayed after I ended my loop It could explain why the screen is shaking : if (i=3) scroll = scrollValue is never called at the same moment, based on the amount of time I spend updating the game logic (collide detection included, so time related to the number of sprites to test) but in this case, how could I handle it ?! Limit the code to fit on the vblank time interval seems to be really hard to master. I though I handled it on SMS but should I understand it breaks on GG ?! I'm totally out of idea, about to trash the project...and all of this because Sega used this stupid "centered SMS window"

Calindro Joined: 14 Apr 2013 Posts: 624	Posted: Fri Mar 31, 2017 11:38 pm
Calindro Joined: 14 Apr 2013 Posts: 624	Why don't you do set lineCounter(24) scroll = 0 and get rid of i?

KanedaFr Joined: 01 Jul 2016 Posts: 55	Posted: Fri Mar 31, 2017 11:42 pm
KanedaFr Joined: 01 Jul 2016 Posts: 55	Calindro wrote Why don't you do set lineCounter(24) scroll = 0 and get rid of i? It's what I tried first, unfortunatly I came to this one to handle every scroll (the 0 one included) on lineInterrupt, to see if it was the reason it failed

Calindro Joined: 14 Apr 2013 Posts: 624	Posted: Fri Mar 31, 2017 11:45 pm
Calindro Joined: 14 Apr 2013 Posts: 624	Alright, then I can only ask about a rom file again. It would make it much easier for me to investigate what's going wrong.

sverx Joined: 05 Sep 2013 Posts: 3823 Location: Stockholm, Sweden	Posted: Sat Apr 01, 2017 4:58 pm
	really, I suggest you don't call lineIRQ every line, that would eat up too much of your CPU cycles. see the other topic, which is what Calindro is also saying here. Also, it's the correct way as you want the screen to start unscrolled.

KanedaFr Joined: 01 Jul 2016 Posts: 55	Posted: Thu Apr 06, 2017 11:42 am
KanedaFr Joined: 01 Jul 2016 Posts: 55	Using Emulicious' Profiler, I found that my game loop is almost 200 scanlines. So obviously, Lineinterrupt occurs while I'm updating my game logic. It explains why things could be broken any times and why waiting the end of game loop to activate LineInterrupt makes the screen shaking (since scroll is updated every 2 frames and reseted to 0 every frame) It would ask me too much to make the game loop to be "line interrupt" compliant (!) so I'll jump to the software scroll option. It'll less fluid but more in sync with the original CPC game, giving it an old feeling and be different from the SMS version. thanks for all your help and hints, it helped me to go even deeper on the display process of the GG (and SMS).

sverx Joined: 05 Sep 2013 Posts: 3823 Location: Stockholm, Sweden	Posted: Thu Apr 06, 2017 12:00 pm
	KanedaFr wrote I found that my game loop is almost 200 scanlines. you've got 262 of them each frame so you should be fine in other words, profile your functions and you'll find out where you're eating too much CPU there are also a few tricks if you just need to save a few lines and you never need all the 64 sprites...

eruiz00 Joined: 28 Jan 2017 Posts: 556 Location: Málaga, Spain	Posted: Thu Apr 06, 2017 4:35 pm
	Maybe you dont have to check everything all frames. I am doing half one frame and halc other. Even some things are done one in four frames.

KanedaFr Joined: 01 Jul 2016 Posts: 55	Posted: Thu Apr 06, 2017 10:50 pm
KanedaFr Joined: 01 Jul 2016 Posts: 55	eruiz00 wrote Maybe you dont have to check everything all frames. I am doing half one frame and halc other. Even some things are done one in four frames. I split my heavier logic (collide!) on 4 frames without too much bugs... So, yes, I already tried...

KanedaFr Joined: 01 Jul 2016 Posts: 55	Posted: Thu Apr 06, 2017 10:53 pm
KanedaFr Joined: 01 Jul 2016 Posts: 55	sverx wrote KanedaFr wrote I found that my game loop is almost 200 scanlines. you've got 262 of them each frame so you should be fine in other words, profile your functions and you'll find out where you're eating too much CPU there are also a few tricks if you just need to save a few lines and you never need all the 64 sprites... The point is , at 200 scanlines, a part of my gameloop is still running while a line interrupt occurs. So it means I could set the hscroll while I'm testing 1 collide...and this seems to be UNSAFE : it brokes my Z80 registers (HL or BC, according where the lineinterrupt occurs)

Forums

View topic - GG Hscroll lock nightmare