Blitzmax rendering overview

2 Executables for the same game made in Blitxmax and benched with fraps:

DirectX with single grabpixmap to defeat lag
2006-04-02 00:30:21 - mainDX.exe
Avg: 49.567

OpenGL
2006-04-02 00:36:20 - mainOGL.exe
Avg: 125.933

Why is opengl so many times faster than DX? I have an ati card which even favours dx. The same story was reported on all my testers hardware: dx is much slower and in part this must be the 0,0,1,1 tiny grabpixmap.

With my slow pc, the 400mhz p2, I am seeing it go from being playable to entirely unplayable. I am posting in general in the hope of reaching a wider number of people who may have something to say about this. Please discuss...

I believe that OGL is much faster than DX... perhaps because there is a bit less abstraction going on. (I am probably completely wrong, though, since I know nothing).

It has been pointed out many times that BMax does OGL MUCH faster than DX, so it may be a bit more than just differenes between the two, and perhaps something going wrong on BMax's end. We'll probably have to wait for Mark for that one.

I would recommend using OGL over DX, though, since it can (sometimes) allow for much better compatibility.

Sorry but DX is better served under windows.

I think it has a lot to do with the drivers that you have installed. There is no speed gain using one API (OpenGL/DX) over the other. It comes down to the optimized drivers from your graphics vendor. Try installing/testing different drivers and see the results for yourself.

We did a huge test on this a while back. OGL is just plain
faster than DX when using Blitz. By alot, too.

It would be helpful to see the figures without the mouse lag fix, even though I know it's required for any legit release. My thoughts on the subject are that the DX module could be just as fast or faster than OpenGL if BRL would take the time to further develop it before going on to the GUI and 3D module. DX support originally came out of no where, which leads me to believe it was a rushed effort. If BMax is to be a serious game development language (on Windows, at least), I think the mouse lag issue and general DX slowness needs to be addressed.

I find it interesting that you cling to your misconceptions, having yourself uncovered evidence to positively falsify this outrageous claim.

DX is marginally better for crappy cards like Matrox and Intel. Manufacturers that produce high-end OpenGL cards (like Wildcat, FireGL and Quadro) will have optimised OpenGL drivers for their cards.

agreed

The bottom line is, if you're shipping a puzzle game or something else that is not geared towards FPS gamers with the latest hardware, it would be suicide to default to OpenGL. If you care to garner potential customers, that is.

Well since you've ignored the two most popular ranges of consumer-level cards entirely, I'd have to say that many, many more of my customers are using Intel than are using Wildcat, FireGL and Quadro put together.

I was agreeing with eikon... not that wacky flameduck btw. :)

You're entitled to believe whatever you want. Since BRL have been working intimately with the DirectX API for at least 5 years, I would propose that your belief is somewhat flawed.

Nobody said anything about defaulting to OpenGL. Rob was claiming that DirectX was better on Windows, despite having earlier posted numbers to the contrary.

How do you mean?

You have more customers with Intel chipsets than GeForce? That's odd. I was under the impression that nVidia had a 60% market share or something.

But far be it for me to argue against numbers you've made up.

Blitz Research has at least five years of experience with the DirectX API, therefore any wrapper they write for it is clearly not rushed.


I didn't say anything about defaulting to OpenGL. Rob's test was final and from it we can conclude that in every instance DirectX is inferior to OpenGL on the PC. The discrepancy in Rob's numbers is nothing to do with a rushed DirectX implementation (see above), and it certainly is not due to a work around for a problem with the implementation (see above).


Excellent. You fell into my trivia and technicalities trap, which means I can then say...


I think nVidia has a 60% market share or something, therefore your numbers are obviously made up.

<kanati quickly glances back and forth between posts>

I think flameduck and Michael Rietzizienntaatarkas are the same person.

Exactly.

My point was, that if you agree the default should be Direct3D, this means most users will be using that, regardless of how much better OpenGL is.

I don't want to argue DX vs. OpenGL in general, because OGL is the clear winner. But to say that Direct3D is one third of the speed naturally, and not due to any fault of BRL's, doesn't seem plausible to me.

I was under the impression that Max2D is designed for the way OpenGL works internally and DX does not quite handle the same method so well, meaning a rewrite of Max2D would be in order, if anyone actually cared. DX is good as the default renderer because it provides stability on a wider range of systems... pro gamers are free to switch to OGL for the speed if they want. Providing you provided the capability...

I don't understand why Mark or Simon won't give a definitive answer or commitment to the problem.

Guys?

[edit]: I have been scouring the dxdev archives for "mouse lag" and "render ahead" and found an astonishing amount of good information from epic, nvidia, and other top developers on defeating dx7 mouse lag. The problem cannot occur on dx8 and above due to the rules for Present() which forbid this kind of activity.

Apparently it's mainly sync issue between gpu or cpu and the card. You can get up to half a second of lag - thats huge, and what I and my testers were experiencing. You can lock the backbuffer, or set a setting in DX which prevents this, however most of the discussions go over my head.

Apparently though, there are many solutions which do not require cutting your framerate to 1/3rd!

Sorry to disappoint you but just because I reply at 4am, doesn't mean I make things up.

I quote from a Februrary 2006 article "Overall, Intel claimed 32 percent of the desktop graphics market, the firm found. ATI held steady at 24 percent, and Nvidia picked up one point to come in at 23 percent."

And that's just in the desktop market. If you include laptops, Intel are up around 40% with the others trailing way behind.

NOTE: Edited to quote only FlameDuck's comments.

From the discussion over in the BlitMax Programming category, the difference in frame rate seems to caused only by the mouse lag fix. People there were experiencing seroius slow downs (1/2 frame rates), just because of the grab pixmap thing. Without it frame rates would be similair, but then your game would be messed up.

Even though I prefer OpenGL, I would love to see a fix for this that does not slow down the frame rate so dramatically (or at all).

Ragnar

http://discuss.microsoft.com/SCRIPTS/WA-MSD.EXE?A0=DIRECTXDEV
Plenty here on it - look up mouse lag.

Possible solution:


Could this be a very fast way to cure buffering ahead?

IMPORTANT: SOLUTION

Please test this solution. Going by the advice I found on dxdev, I draw an image each frame AFTER my flip. It is a 2x2 texture.

I then lock and unlock *just the texture*. It seems to have solved the problem. Please test...

        Flip 0

	DrawImage antiLag,0,0
	LockImage(antiLag)
	UnlockImage(antiLag)

do you have a framework to run the test in?

Nope. If this issue affects you, then you'll know immediately.

Does anyone at least test his stuff with BM 1.18 or just assume things?
While DX was slower till that point, we were not able to get any real difference between D3D7Max2D, BufferedD3D7Max2D (which is more suited for crap cards) and OpenGL within test apps that draws quite some stuff (from text, over images etc).
I first was under the impression that Buffered is faster, but this, at least on "real 3D cards" (which are min. requirements for BM anyway!), is not true.

And that grabpixmap destroys the performance is somehow quite logical. It must lock the backbuffer which blocks any rendering till it is unlocked again.
If you really want to defeat it, ask Indiepath for the render to texture and do your own flip chain. Then you will be without problems and speed burner "want to be workarounds"

My new solution does not destroy performance. I just want people to test it, not complain.

I am doing my utmost best to give BRL and blitzmax my support and I got off my backside to do so... if that is not good enough, it is the best I can do.

I hope it will serve as inspiration for BRL at least to check out my findings.

Just in case anyone missed it: please give feedback if this works for you...

OpenGL has always been faster under every cross API game I've seen ... why is this such a surprise?

Results on new solution

DirectX
DrawImage, Lock/Unlock - 1,000 FPS
GrabImage - 1,200 FPS
No Fix - 2,000 FPS

OpenGL
No Fix - 2,200 FPS

oh dear, not a good result. I'm beggining to think my next game should be in OpenGL only, sod it. Or only if OpenGL is not present then use DirectX and don't bother with a mouse lag fix. Or have some lame "fix mouse lag" in the options but warn that it severely impairs performance.

But wait, how does this affect games that are designed to run around 60FPS? I'll be using the fixed logic loop at 200FPSish and then spitting out a frame, and if the card has got Vsync on, the next frame won't come round until whatever the monitors refresh rate is (60-100Hz ish). If they have Vsync off, the game will run at a Max of 200HZ, but obviously rendering when it feels like, up to 200Hz. So will this whole lag thing still be an issue?

a lot of pro 3D cards are moving towards D3D now due to better viewport shader support and better speeds with higher polycounts.

Yes. Anything that has a lot of fillrate going on and very few polys. Ie... Blitzmax... unfortunately!

It is in the best interests of the manufacturers to make future cards friendly (and perhaps biased) toward DirectX. With XNA in mind, it puts them in the running during the next bidding war for future microsoft consoles.

Evak, you must be talking about "pro" gaming cards. Hardly any of the highend 3D and CAD software support D3D (except maybe for running game engines in the viewport). Maya, XSI etc. are all OpenGL only, and cross platform to boot.

This thread is about one specific thing: the renders being buffered up causing lag in games so please keep it on topic :)

Thank you.

Or you could just do a quick benchmark to figure out which is fastest, and use that.

Can you post (or host) some complete code for me to give you a test result?

Yes, One Eyed Jack, it works for me (Radeon 9600 Pro, DirectX 9.0c). The modified BlitzMax MouseX example below shows the lag - when I move my cursor around the screen, the white circle noticably lags while chasing it. By turning on your "magic," the circle remains glued to the cursor like it should. Nice workaround!

'Set to true to get rid of mouse lag in DirectX:
Const OneEyedJackMagic = False

Graphics 640,480
antiLag:TImage = CreateImage(2,2)

While Not KeyHit(KEY_ESCAPE)
	Cls
	DrawOval MouseX()-10,MouseY()-10,20,20
	Flip 0

	If OneEyedJackMagic Then
		DrawImage antiLag,0,0
		LockImage(antiLag)
		UnlockImage(antiLag)
	EndIf
	
Wend

Thanks WendellM :)

Your example never does cause lag on this super-fast pc though, so here's another example that could for others:


PLEASE NOTE: this issue is a known issue and will rear it's head mostly in low poly / high fillrate situations - that is why it often escapes detection by BRL and so forth :)

Making a whole game, you come across this issue...




Here's another example for everyone:

'low poly and high fill rate causes the issue, solvable by flushing the driver's
'buffered frames using grab pixmap or locking a buffer with a large speed penalty.
'opengl is unaffected.

'change how many loops you do till you see the lag and not general slowdown
'this will vary from pc to pc

'SetGraphicsDriver GLMax2DDriver()
Graphics 800,600,0,0

AutoMidHandle True
image:TImage = LoadImage("arrow.png") 'any 32x32 image

While Not KeyHit(KEY_ESCAPE)
	Cls
	mx = MouseX()
	my = MouseY()	
	
	SetScale 8,8
	For i = 0 To 2000
		DrawImage image,mx,my
	Next
	Flip 0
	
	'insert workarounds here
	
Wend
End

unfortunately the example I posted above actually breaks my little workaround!

The key with the workaround is the setscale command - it simulates a nice bit of large overdraw which causes the phenomenon to rear it's head.

Only inserting:


grabpixmap(0,0,2,2)


Just like that (garbage collector will take care of it) in place after flip 0, will the problem truely be solved, but at a great performance hit! I guess the above example is VERY effective at demonstrating the lag :)

BRL: balls in your court dudes - please fix this bug - you now have a good example to work with.

Not to "hijack" this thread, but wouldn't it be a bit more effective in the appropriate bug-reporting forum?

Done.

here is something odd....
when I test Wendel's example and set it to False I don't get the lag. When I set it to True I do. I'm running a nvidia 6800 with 78.11 drivers. I need to run the 78.11 because newer drivers don't work with most dual proc boards (762MP chipset)

In one of the earlier threads on this issue, it was suspected that the problem might be connected to ATI drivers. So it could be that the DX drivers for your nVidia card and those for my ATI one have different behaviors. If so, perhaps yours work fine without the "magic" and are harmed when it's used, while mine need it for decent performance. Weirdness for sure!

Maybe for now we could offer this workaround to users/players (in menus/options, or whatever) as a "recommended ON for ATI, recommended OFF for nVidia, but see which works better for you" deal when we write our BlitzMax apps/games? Not ideal, but better than nothing if no built-in BlitzMax fix appears or is possible (since the problem seems(?) to lie in DirectX/drivers rather than BMax)....

This is a solution posted on the DirectX archives, its a busy loop to stop dx from rendering ahead.

while(
DDERR_WASSTILLDRAWING==FrontBuffer->GetBltStatus(DDGBS_ISBLTDONE)
> );

I dont know if sleeping would be better... but I think this is guaranteed to fix it. The problem is when Flip doesn't halt, the GPU is rendering a backlog of frames while the CPU is blazing ahead. This will force it to halt without locking anything. If Mark or Simon (or anyone else) could port this to BlitzMax (I tried but I dont know which is the frontbuffer in the d3d7 structure) I can give it to some people who were having mouselag problems with my game. A fix would be awesome for this, my game loses like 1/3 of its speed to locking and unlocking.

Of course, this will cause a speed hit compared to no fix - you're chewing up cycles to artificially increase the CPU time spent in the renderer - but it should be the minimum hit possible to do this. Locking may soak up additional time.

Well, it cures the lag here. I haven't compared the speed hit though.

You'll need to change Pub.Mod\DirectX.Mod\dd.bmx (line 1659) to: Method GetBltStatus(flags)

'low poly and high fill rate causes the issue, solvable by flushing the driver's
'buffered frames using grab pixmap or locking a buffer with a large speed penalty.
'opengl is unaffected.

'change how many loops you do till you see the lag and not general slowdown
'this will vary from pc to pc

'SetGraphicsDriver GLMax2DDriver()
Graphics 800,600,0,0

AutoMidHandle True
image:TImage = LoadImage("lagimg.png") 'any 32x32 image

Local fix = 0

While Not KeyHit(KEY_ESCAPE)
  Cls
  
  If KeyHit(KEY_SPACE) Then fix = 1 - fix
  
  mx = MouseX()
  my = MouseY() 
  
  SetScale 8,8
  For i = 0 To 1000
    DrawImage image,mx,my
  Next
  
  SetScale 1, 1
  DrawText "Fix = " + fix, 12, 12
  
  Flip 0
  
  If fix
    If TD3D7Max2DDriver(_max2dDriver)
      While DDERR_WASSTILLDRAWING = PrimaryDevice.PrimarySurface.GetBltStatus(DDGBS_ISBLTDONE) ; Wend
    EndIf
  EndIf
Wend
End

I can confirm the new fix indeed is both faster than grabpixmap and works as intended.

You will need to bench from within your app and not rely on something like fraps which gives an incorrect result when grabpixmap is used.

sounds positive, I'll lurk until more confiurmation comes in as I not used to modifying the modules.

We're using Ogre instead. :)

*sigh* more framework to do later.

Hi Cygnus, please don't derail this topic. Thanks.

This is not necessarily a BMax issues as in BlitzPlus OpenGL blew away the DirectDraw performance.

The problem is, we were used to the 2D performance in Blitz BASIC and Blitz Plus which used DirectDraw. BlitzMax emulates 2D via 3D methods in Direct3D.

WinG was 2D, when it became DirectDraw it was 2D. It was some time before Direct3D came along and it was even longer before Direct3D was capable of emulating 2D.

However, from its first release, OpenGL has always been able to emulate 2D and has done so quite well.

In true 3D games, I think DX is better than OpenGL, but when it comes to emulating 2D, OpenGL beats DX hands down, especially when you are using really old versions of DX like DX7. DX 8 & DX 9 are much better at emulating 2D IMHO.

The fix works for me too. Great!

Now, lets get BLR to implement this as a function in B3D too!!!

I am hoping Simon and Mark's interest is piqued enough to consider this a line of investigation. It may be better served as a command - sort of a flushgraphics ()

I'm bumping this for a couple of reasons:

a) I have changed Pub.Mod\DirectX.Mod\dd.bmx as shown above but the rebuild modules options are dimmed out in 1.18 so I can't run the example because it says "too many parameters" on compile. Any help is appreciated :-)
b) When One Eyed Jack said "the new fix indeed is both faster than grabpixmap" did he mean the DrawImage fix or the While DDERR_WASSTILLDRAWING fix?

Thanks. I really hope this can be properly fixed but meanwhile I need to add in a temp fix to my code and I want to get the right one :-)

a) See this thread for further details (read it even if you've already installed MinGW).

b) He meant the While/Wend one.

ian (nearly typed hamish ;-)) a) great thanks, lame it's not standard. b) OK cool, I'll try it out. Anyone have any stats on how fast the new new fix is?

hmm, OK I'm gonna have to be dense about this, sorry. How do I make/edit environment variables in XP? Last time I did that sorta thing was in Win98 and I edited Autoexec.bat ...

Ok. Right click My computer -> properties -> advanced tab. Environment variables are there. Look for path. Add a semi colon on the end of the path string, then the path the bin dir as instructed.

lovely thanks, works a treat!

I can confirm that all input is affected by the lag such as keyboard input. It's not just mouse-based which had me confused, because, as most of you already know, the problem is to do with the rendering pipeline buffering previous frames when too much is going on instead of just trying to show the latest frame DOH!

Yeah...It's just much more conspicuous with the mouse because of the fast/large movements.

ok i havent read all the comments in here, but there is
something id like to point out - bmax rendering as far as i
know is geared towards opengl immediate mode rendering,
which is fine..its nice n clean. DX sadly doesnt support
immediate mode rendering, so its probably going through
the whole lockbuffer..unlockbuffer tedium..perhaps the dx
version buffers the draw commands + upadtes the buffer
on flip()..i dont know...but anyway - most cards should
support basic outa the box opengl 1.2 or whatever it is..
I cant think too many people are using cards older than
geforce2..

anyhoO...back to wurk!

You missed your pills today deffie.

I can confirm that the newlest and latest fix the While/Wend one drops my games maximum FPS from 1900FPS to 1500FPS, which is a bit of a bummer. That's 20% knocked off! Off course it probably makes no real speed difference to games not using Flip 0 and mine will be using Flip -1 in the end.

Since When? BMAX DX is Immediate mode.

From the DX7 SDK Docs :

Direct3D has two modes: Immediate Mode and Retained Mode. Retained Mode is a high-level 3-D API for programmers who require rapid development or who want the help of the Retained Mode built-in support for hierarchies and animation.

Direct3D Immediate Mode is a low-level 3-D API that is ideal for developers who need to port games and other high-performance multimedia applications to the Windows operating system. Immediate Mode is a device-independent way for applications to communicate with accelerator hardware at a low level. Direct3D Retained Mode is built on top of Immediate Mode.