21 replies to this topic

[them4n!ac]

Everything's in there (explanation, example, experiment):
Download gm_overdraw.gm6

This test is made to present the overdraw problem in many 3d games. The blocks are drawn with an alpha value that is 0.5 to make the problem visible.

Overdraw means you're drawing the same pixels more often than necessary. If you're drawing non-transparent (alpha = 1) objects from back to front, you're wasting the processing time.

Controls
- M - Change the drawing order
- F1 - Show this window

Edited by them4n!ac, 27 November 2008 - 02:48 PM.

[FredFredrickson]

Could you explain a little bit about what the example is, and what you're showing us here, them4niac?

[IQbrew]

Everything's in there (explanation, example, experiment):
Download gm_overdraw.gm6

Yes...After all the dangerous/filthy files that have been posted here, we need a lot more, such as pictures...Or an explanation.

[them4n!ac]

the info is in the example, but ok..

IQbrew: that's not a bad file, it's a gm6 file. you can't execute that so it's not dangerous.

Edited by them4n!ac, 27 November 2008 - 02:49 PM.

[Zelda4evr]

upon loading i get an error stating that it is, in fact not a gm file

[icuurd12b42]

upon loading i get an error stating that it is, in fact not a gm file

Then try again because it is...

[Pie Person!]

Oh, I see! Very nice, altho you should comment this part:

if( camera.make_overdraw )
{
	depth = point_distance( x, y, camera.x, camera.y );
}
else
{
	depth = 10000 - point_distance( x, y, camera.x, camera.y );
}

So that it is easy to tell what one fixes overdraw.

Edited by Pie Person!, 03 December 2008 - 12:33 AM.

[Tepi]

Wow. Really good that you presented this...I had no idea.

So preventing depth problems for transparent objects can slow your game down quite much. Must keep that in mind.

I noticed that if you set d3d_hidden off in the start, there is no change in fps whether you're using the owerdraw of not. Does this mean that z-buffer has less work when the owerdraw is not used? Is this the reason why it's happening?

Thanks for this.

[them4n!ac]

Pie Person:
'M' key lets you look at both ways of drawing, that's for presentation, because many people tend to run the example before looking at the code. If they don't see anything interesting, they don't care about the code.

Tepi:
Z-buffer culls the invisible pixels. and alpha blending is expensive.
Overdraw means some pixels are drawn more times than necessary. The z-buffer helps to avoid that.

So preventing depth problems for transparent objects can slow your game down quite much. Must keep that in mind.

Maybe, maybe not.
You can draw all the transparent objects after the opaque ones. Sort the opaque objects from front to back and the transparent objects the other way. And avoid using alpha blending. (I think you can switch it off with texture_set_blending( false ); or something like that..)
If you're not using alpha blending, you won't get any transparent objects.

Edited by them4n!ac, 03 December 2008 - 04:21 PM.

[infinitygames]

Thats called the depth bug.... but point_distance(); so many times causes lagg. maybe ds_priority might work

[Pie Person!]

@them4n!ac
What? How does that have anything to do with what I said?

[Tahnok]

Interesting point. I never really considered that the depth could cause things to draw needlessly. I can't seem to get any extra FPS out of the method though. I think the distance checking for all the objects kills any possible speed increase in my game. For something with more of a fixed camera though this would be great.

[FredFredrickson]

Yeah, I got the same thing - it definitely looks different when I toggle the modes, but the FPS always jumps back to being the same.

[qwertyuiop23]

Does this improve only the graphical side?

[icuurd12b42]

You could possibly do the depth change in an alarm for non moving objects, like every quater second...

[Tahnok]

You could possibly do the depth change in an alarm for non moving objects, like every quater second...

I tried it every second, all offset from each other, and still couldn't get ahead of the curve.

[icuurd12b42]

You could possibly do the depth change in an alarm for non moving objects, like every quater second...

I tried it every second, all offset from each other, and still couldn't get ahead of the curve.

I don't know, since you are using the draw event to draw your object anyway, you should have this in the draw event so one less event to trigger (if you are using the step event).

Non moving objects then have not code in any other event but the draw. One less cpu drain.


You can also have an alarm every quarter second, even every second depending on how fast the player moves, to turn the visibility to false if it's beyond the fog.

visible = point_distance3d(x,y,z,cam.x,cam.y,cam.z) < cam.FogDistance+100)
alarm[0] = room_speed


in the draw
depth = point_distance3d(x,y,z,cam.x,cam.y,cam.z) < cam.FogDistance+100)
//draw code

The cost of the point distance should not be much compared to the cost of the 3d translations and actual draw

You may skip a beat once in a while but many comercial games do...

[them4n!ac]

You won't see a big difference on the newest graphics cards.
But this helps to speed up the game on Shader Model 2.0 graphics cards and older.

infinitygames: I want to see your dictionary. Everywhere I look it's not called like that.

Edited by them4n!ac, 05 December 2008 - 03:05 PM.

[Tahnok]

[...]
You can also have an alarm every quarter second, even every second depending on how fast the player moves, to turn the visibility to false if it's beyond the fog.
[...]

Manually switching visibility seems kind of redundant when the camera can be setup to automatically clip stuff beyond the fog (which I have it setup to do).

If what them4n!ac is saying is true though then that's why I'm not seeing any improvement. I have a brand new video card. It makes me wonder now if I should leave in my depth adjustment code in hopes that it helps someone, since it's not seemingly slowing things down for me.

[icuurd12b42]

[...]
You can also have an alarm every quarter second, even every second depending on how fast the player moves, to turn the visibility to false if it's beyond the fog.
[...]

Manually switching visibility seems kind of redundant when the camera can be setup to automatically clip stuff beyond the fog (which I have it setup to do).

It's not reduntant at all, dont forget that invisible instances will not have their draw code executed... Even if you rely on the 3d to not draw your object, GM will still waste time calling your draw event for nothing and interpret code for nothing...


I use the method and the fps is really up there... Giving me a large bandwidth for my actual game.