terrible graphical tearing on my laptop

Blitz3D Forums/Blitz3D Programming/terrible graphical tearing on my laptop

Vorderman(Posted 2011) [#1]
I'm just trying out some of my programs on my laptop, which is a Dell with Win7 64bit and an ATI mobility radeon 4250, and I'm getting some really terrible tearing issues on even very simple programs.

I've tried all combinations of Vwait / flip etc.., with no obvious change in the results.

I've also tried forcing vsync on / off in the catalyst control centre, but again it looks exactly the same.

I'm using Mark's render tweening code from code archives from when Blitz was released, and it's always given very smooth results on all the PCs i've tried it on. On this laptop however I've got this massive tearing problem.

Anyone got any ideas how to solve it?


Vorderman(Posted 2011) [#2]
Aha, sorted it I think, and it was my code at fault.

I was updating the camera position just before the renderworld, rather than within the locked-rate logic. With the update moved into the logic loop it now seems solid at either 30 or 60 fps, with no tearing that I can see.

Also managed to get my stunt race game running at a sensible framerate on my laptop - with 8 cars it's getting mostly the normal 50fps with the occasional drop when it gets busy.

Turns out that just a single Text command (ironically the one that was displaying the framerate!) was pretty much quartering the framerate. I've swapped over so now the AppTitle displays the framerate in the window border and it's a lot better.


Rroff(Posted 2011) [#3]
Yeah text command is a framerate hog. What I do is render any text into an image buffer during the locked-rate logic part of the code (mine executes at 30Hz) and render that image to the screen every frame instead of the text command every frame = 40x speed up (with what I'm doing).

Tho when I get around to it I'm either gonna use fasttext or write my own replacement text commands.

Last edited 2011


Slomas(Posted 2011) [#4]
I also find it handy to display the millisecs() that the main loop is using-

This helps you see how each change in the code, or part of the game play is loading the CPU - and gives you some heads-up before you suddenly run out of frame rate and are forced to sacrifice something

As with the text command- it's often something trivial/dispensible hogging the CPU