RebelSDL screen update "problems"?

[Tuxedo]

Hello,

I noticed ome things that I cant know why happens using RebelSDL relative to the code attached:

Code: Select all

x = 0

@REQUIRE "rebelsdl", {Link = True, EnableVSync = False};, ForceFullRefresh = True};, UseDesktopFullScreen = True}

@DISPLAY 1, {Width = 640, Height = 480, Color = $444444};, Mode = "FullScreen"}

BOAR_HIT		= LoadBrush(Nil, "TestDATA/BOAR_HIT_3X2.png", {LoadAlpha = True, Hardware = True})
BOAR_RUN		= LoadBrush(Nil, "TestDATA/BOAR_RUN_3X2.png", {LoadAlpha = True, Hardware = True})
BOAR_WALK		= LoadBrush(Nil, "TestDATA/BOAR_WALK_3X2.png", {LoadAlpha = True, Hardware = True})

Function p_draw()

Cls()
;SelectBrush(1)
DisplayBrush(BOAR_HIT, 20, 70)
DisplayBrush(BOAR_RUN, x, 120)
DisplayBrush(BOAR_WALK, 20, 170)
;EndSelect()

EndFunction

Function p_add()

x = x + 1

EndFunction

Function p_Scroll()

p_add()
p_draw()

;DisplayBrush(1, 0 ,0)

Flip()

EscapeQuit(True)

EndFunction

BeginDoubleBuffer(True)

CreateBrush(1, 640, 480, #RED, {Hardware = True})
;DisplayBrush(1, 0 ,0)


Scroll	= SetInterval(Nil, p_Scroll, 1000/60) ; imposto la velocità di refresh

Repeat
	WaitEvent
Forever

1 - I've a 165Hz monitor but changing the "SetInterval(Nil, p_Scroll, 1000/x)" x value above 60 dont seems to do any difference...setting lower values slow down object velocity, but increasing above 60 dont seems to do anything...also setting up the EnableVSync TAG To "False"...my mistake or some RebelSDL limitation?

2 - Why if I use "UseDesktopFullScreen = True" TAG the moving object left the trails on the screen like if the old brush displayed wasnt cleared? I must add the Cls() command to have a right behaviour(changing also background color).

3 - Have same "trail" problem If I add then "ForceFullRefresh = True" TAG, in that case the screen wasnt cleared automatically before new Flip()?

4 - As you can see in the code I tryed to write to a brush instead than the display than write the objects directly to the screen...but that dont seems to work...or better... if I write the brush with the command "DisplayBrush(1, 0 ,0)", after endselectI got only the "empty" brush that overwrite everything else...but if I write to the brush without display it on the screen seems to work(If I do "CreateBrush(1, 640, 180, #RED, {Hardware = True})", I see only a piece of the blitted objects on the screen like I created as mask for the visible opbjects on screen...), to me that was a a weird behaviour...probaly I do some mistake realted to hardware brushes since doing the thing on software works, but cant recognize it in the manual...


Here the code and assets to try it...

https://app.box.com/s/lzo2gsow489n8nc6z12ba6u0c3fmu3vk

[airsoftsoftwair]

1 - I've a 165Hz monitor but changing the "SetInterval(Nil, p_Scroll, 1000/x)" x value above 60 dont seems to do any difference...setting lower values slow down object velocity, but increasing above 60 dont seems to do anything...also setting up the EnableVSync TAG To "False"...my mistake or some RebelSDL limitation?

Maybe 60fps is the maximum speed your system can handle? Try removing the SetInterval() completely and draw in a brute force loop without any throttle and measure the time. This should give you an idea of how many FPS are technically possible on the system.

2 - Why if I use "UseDesktopFullScreen = True" TAG the moving object left the trails on the screen like if the old brush displayed wasnt cleared? I must add the Cls() command to have a right behaviour(changing also background color).

If you don't redraw the whole screen for every frame you also need to make sure both front and back buffers are in sync.

3 - Have same "trail" problem If I add then "ForceFullRefresh = True" TAG, in that case the screen wasnt cleared automatically before new Flip()?

No, you're operating at a very low level with RebelSDL so you must make sure both buffers are in sync unless you use "ForceFullRefresh". Then RebelSDL will do it.

4 - As you can see in the code I tryed to write to a brush instead than the display than write the objects directly to the screen...but that dont seems to work...or better... if I write the brush with the command "DisplayBrush(1, 0 ,0)", after endselectI got only the "empty" brush that overwrite everything else...but if I write to the brush without display it on the screen seems to work(If I do "CreateBrush(1, 640, 180, #RED, {Hardware = True})", I see only a piece of the blitted objects on the screen like I created as mask for the visible opbjects on screen...), to me that was a a weird behaviour...probaly I do some mistake realted to hardware brushes since doing the thing on software works, but cant recognize it in the manual...

GPU-programming is tricky. Concerning programming mistakes it's not as forgiving as when using the software renderer

[Tuxedo]

1 - I tryed to do that:

Code: Select all

Repeat
	p_Scroll()
Forever

and the boar flyes off screen in a while....almost cant see it...about 4200 fps in fullscreen with EnableVSync = "FALSE" and 165 if "TRUE", so no performance problems...
To me seems that there was some problem honestly...or I do some mistake with screen sync

I also modified the script that way and seems confirmed the values in nVidia overlay:

Code: Select all

x = 0
y = 0

@REQUIRE "rebelsdl", {Link = True, EnableVSync = False};, ForceFullRefresh = True};, UseDesktopFullScreen = True}

@DISPLAY 1, {Width = 640, Height = 480, Mode = "FullScreen",  Color = $444444};, Mode = "FullScreen"}

/********************************************** DEBUG ********************************************************/
@OPTIONS {EnableDebug = True} ; ATTIVO L'OUTPUT DI DEBUG PER CONTROLLARE EVENTUALI ERRORI!!!!!!!!!
/********************************************** DEBUG *********************************************************/

BOAR_HIT		= LoadBrush(Nil, "TestDATA/BOAR_HIT_3X2.png", {LoadAlpha = True, Hardware = True})
BOAR_RUN		= LoadBrush(Nil, "TestDATA/BOAR_RUN_3X2.png", {LoadAlpha = True, Hardware = True})
BOAR_WALK		= LoadBrush(Nil, "TestDATA/BOAR_WALK_3X2.png", {LoadAlpha = True, Hardware = True})

Function p_draw()

Cls()
;SelectBrush(1)
DisplayBrush(BOAR_HIT, 20, 70)
DisplayBrush(BOAR_RUN, x, 120)
DisplayBrush(BOAR_WALK, 20, 170)
;EndSelect()

EndFunction

Function p_add()

x = x + 1
If x > 640 Then X = 0
EndFunction

Function p_Scroll()

p_add()
p_draw()

If GetTimer(1) > 1000
	DebugPrint("Frames/sec=    ", y)
	ResetTimer(1)
	y = 0
EndIf

;DisplayBrush(1, 0 ,0)

Flip()

EscapeQuit(True)

EndFunction

BeginDoubleBuffer(True)

CreateBrush(1, 640, 480, #RED, {Hardware = True})
;DisplayBrush(1, 0 ,0)
StartTimer(1)

;Scroll	= SetInterval(Nil, p_Scroll, 1000/60) ; imposto la velocità di refresh

Repeat
y = y + 1
p_Scroll()

;	WaitEvent
Forever

If you don't redraw the whole screen for every frame you also need to make sure both front and back buffers are in sync.

2 - sorry...how I can check that?

4 - Regarding the problem Trying to write to a big hardware brush with the hardware brushes to make a sort of "precalculated scene" any suggestion? or I've to do it in software and than create the big hardware brush like the "BeastScroll.hws" example?

[airsoftsoftwair]

2 - sorry...how I can check that?

You need to keep in mind that you're really dealing with two different buffers, e.g. if you draw like this:

Code: Select all

BeginDoubleBuffer(True)
SetFillStyle(#FILLCOLOR)
Box(0, 0, 640, 480, #RED)
Flip
Box(0, 0, 640, 480, #BLUE)
Flip
; all drawing done here will go to the buffer that contains the RED rectangle!
Flip
; all drawing done here will go to the buffer that contains the BLUE rectangle!
Flip
; now red again
Flip
; now blue again
...

RebelSDL will give you a real double buffer with two distinct buffers (front and back buffer). When using non-hardware double buffers with Hollywood the behaviour is different.

4 - Regarding the problem Trying to write to a big hardware brush with the hardware brushes to make a sort of "precalculated scene" any suggestion? or I've to do it in software and than create the big hardware brush like the "BeastScroll.hws" example?

Using very big hardware brushes is a bad idea for tile-based scenes. You should draw tiles instead.

[Tuxedo]

Ok,
I now understand how DoubleBuffer works correctly, thank yo!

BTW...how I can set a desired fps limit without get stuttering? I use ReblSDL.
The WaitEvent/WaitTimer method described in "15.3 Script Timing" paragraph on Hollywood manual gives me only bad scrolling...I get smooth scroll only if I use no timing and update the screen at my monitor refresh time(165Hz),
But how cat set a specified refresh rate with smooth scroll?

Thank you!

[airsoftsoftwair]

BTW...how I can set a desired fps limit without get stuttering? I use ReblSDL.

I'd set "EnableVSync" to TRUE when requiring RebelSDL and then just draw in a loop without using SetInterval() or anything, but just like this:

Code: Select all

@REQUIRE "rebelsdl", {EnableVSync = True}

Repeat
   p_DrawNextFrame()
   Flip
Forever

By setting "EnableVSync" to TRUE it is guaranteed that your drawing will never be faster than the vertical refresh.

[Tuxedo]

Sorry probably was me that dont understand but...if my script cant run much than 70 fps on a specific system and the related system have a 144Hz monitor using "EnableVSync = TRUE" the script wont run at bad speed? on the same sytem with 60Hz monitor instead it runs ok, but also...If I want run my script at 60fps to have same speed on every system that can run it to have perfect sync in every system how I can do it?
If a system can run my script at 400 hz, but I use a 60, 144 and 240 Hz monitor I dont have different effective speeds on the 3 different monitors if I dont sync the script at a desired refresh rate?
If I have a 3 pixel scrolling on 60 Hz wasnt 60 x 3, on 144 wasnt 144 x 3 and on 240 wasnt 240 x 3 every sec?

I miss something?

[Tuxedo]

To (try to) be more clear...
I in other post write stuttering, but the "stuttering" was only due to the "timing" standard methods...trhat seems to lock the script execution and RebelSDL cant do what it do simply if run "alone"...

BTW I check the

If I have a 3 pixel scrolling on 60 Hz wasnt 60 x 3, on 144 wasnt 144 x 3 and on 240 wasnt 240 x 3 every sec?

trying my script with my 165Hz monitor and on my 60Hz TV...and effectively the scroll was about 3 x faster on my monitor than on my TV...so was a big problem if I cant use a standard timing method on every system...

Cant be possible to add a "refresh speed" tag/option on RebelSDL plugin to have a standard refresh speed that handle directly RebelSDL?

[airsoftsoftwair]

if I have a 3 pixel scrolling on 60 Hz wasnt 60 x 3, on 144 wasnt 144 x 3 and on 240 wasnt 240 x 3 every sec?

Then your script needs to measure the time using GetTimer() and only move if the desired screen update time has elapsed.

Cant be possible to add a "refresh speed" tag/option on RebelSDL plugin to have a standard refresh speed that handle directly RebelSDL?

That's probably not the way SDL is meant to be used. You need to throttle the drawing in your script. Have you seen the SDL2 tutorials from Parallel Realities? I think studying them could be helpful for your case. I think there was also somebody who was porting them to RebelSDL, see here: https://forums.hollywood-mal.com/viewtopic.php?t=3667