82 replies to this topic

[Desert Dog]

Thanks for that!

Yeah, so it sounds like it's pretty much business as usual then.. that was always the smart way to do 3d in GM... use models, make as few draw calls as possible, etc.

The only real difference as it seems to me is that know it seems we have the power here to draw high poly models lightning fast... in fact, if I'm reading you correctly, it's faster than low poly models because of gpu/cpu mix-mash. (which sounds bizarre!!)

Edited by Desert Dog, 05 May 2011 - 09:53 AM.

[Manuel777]

in fact, if I'm reading you correctly, it's faster than low poly models because of gpu/cpu mix-mash. (which sounds bizarre!!)

It might at first, but its understandable given nowadays graphic cards have a LOT of power.. youre literally wasting it.


So, how are we gonna handle compatibility issues now? are the surfaces alerts going to pop up?

Edited by manuel777, 05 May 2011 - 10:09 AM.

[Maarten Baert]

If you need a different size, then make a "unit" cube (1x1x1 in size), then use matrix scaling to make it the correct size. (same for spheres etc.)

That doesn't work if you use lighting, scaling messes up the normals.

Is there a render state like D3D9's D3DRS_NORMALIZENORMALS in DirectX 8? It would be really useful if we had a function to enable and disable it. I know it's slower (on low-end video cards at least), but it's still better than weird lighting.

[amd42]

That doesn't work if you use lighting, scaling messes up the normals.

Is there a render state like D3D9's D3DRS_NORMALIZENORMALS in DirectX 8? It would be really useful if we had a function to enable and disable it. I know it's slower (on low-end video cards at least), but it's still better than weird lighting.

Looks like Mike Dailly's already one step ahead of you: glog comment

[Nocturne]

Okay I am a 3D noob... BUT if a quad is a square or two triangles, isn´t that how GM deals with sprites? Two triangles textured from the sprite? And if so, then does my graphics card hate me for using sprites and making 2D games? More to the point, does all this speed boost for 3D have any rollover to the 2D world that I live in? Will I get a speed boost too on my games?

[Manuel777]

Okay I am a 3D noob... BUT if a quad is a square or two triangles, isn´t that how GM deals with sprites? Two triangles textured from the sprite? And if so, then does my graphics card hate me for using sprites and making 2D games? More to the point, does all this speed boost for 3D have any rollover to the 2D world that I live in? Will I get a speed boost too on my games?

Nope, 3D and 2D are two very dirrefent things, you dont draw your sprites as textured poligons (thats what you have to do in 3D engines like Unity), in GM all 2D is really 2D, images stacked with different depths and effects, positioned over two axis, X nad Y, nothing more. Now when you go to 3D the things are hell of different, since you need a new axis ( Z ) all screen-position calculations are based on objects position in the world, the camera position, angles, etc. Plus you have to make sure objects dont mess up with other objects depth, you have to add shadows for every vertex in the models, normals.. etc etc etc..

Edited by manuel777, 05 May 2011 - 03:01 PM.

[Medusar]

Okay I am a 3D noob... BUT if a quad is a square or two triangles, isn´t that how GM deals with sprites? Two triangles textured from the sprite? And if so, then does my graphics card hate me for using sprites and making 2D games? More to the point, does all this speed boost for 3D have any rollover to the 2D world that I live in? Will I get a speed boost too on my games?

Nope, 3D and 2D are two very dirrefent things, you dont draw your sprites as textured poligons (thats what you have to do in 3D engines like Unity), in GM all 2D is really 2D, images stacked with different depths and effects, positioned over two axis, X nad Y, nothing more. Now when you go to 3D the things are hell of different, since you need a new axis ( Z ) all screen-position calculations are based on objects position in the world, the camera position, angles, etc. Plus you have to make sure objects dont mess up with other objects depth, you have to add shadows for every vertex in the models, normals.. etc etc etc..

No, actually GM creates a D3D device regardless of 3D mode being on or not. That's why you can use the d3d_transform functions in 2D games. Enabling 3D mode just sets a couple of settings differently.

As for your question, Nocturne, I asked Mike that (don't recall where, must've been the other topic) and he said that the Delphi runner still draws sprites as individual quads. The C++ runner however puts sprites on a single texture page, so all drawing commands can be buffered by the runner and sent to the GPU all in one go.

[Nocturne]

As for your question, Nocturne, I asked Mike that (don't recall where, must've been the other topic) and he said that the Delphi runner still draws sprites as individual quads. The C++ runner however puts sprites on a single texture page, so all drawing commands can be buffered by the runner and sent to the GPU all in one go.

Thanks... so at the moment this advance will make no difference to me? At least not until the C++ runner is ready... Oh well. I am a patient man and can wait for GM9!

[Manuel777]

@Medusar: Really??
Never knew that, i alway thought GM used a standard 2D drawing method..

[Dark Matter]

What are QUADS?

rectangles, squares, 2 triangles etc...

And that's different from drawing two triangles? How? How do you even do it, because I'm pretty sure you don't mean drawing two triangles is bad practice ?

[FredFredrickson]

You can do this currently to some extent, but you can't draw models with multiple textures in one larger model, so it's only useful for many objects that share the same texture, and often, those objects are not always going to be placed close enough together to take advantage of being grouped into a single model.

That's not true - the purpose of being able to combine multiple models into one and be able to add translations and transformations on the fly to the added models is to provide an alternate mechanism of an animated model - a vehicle or a character, for example. And having a single texture for those is mostly exactly what you'd want.

Edit: I already said that.

I think that we're both talking about different things here. I was looking at it from the point of a static model. IE - you divide up all the areas of your level into chunks that you draw / don't draw at certain places, and you use a function like this to draw large, texturally diverse areas at once. Static stuff only, not set up as some kind of animation hierarchy.

Of course, I'd love to see some kind of native 3D animation support / help added to Game Maker - even something basic. Not being able to easily animate groups of models in 3D is one of the main reasons why I haven't really done much with it in a while. It's incredibly discouraging to look at coding a (probably slow) animation engine for even simple games, when other game engines out there have that stuff built-in, ready to load up animations directly from your 3D software. (Before Mike sees this and thinks I'm trying to start a riot here!) I know Game Maker isn't headed towards this level of 3D support, and I don't expect it to... but some kind of options, even support for loading basic model file formats, would be nice.

[YellowAfterlife]

Nope, 3D and 2D are two very dirrefent things, you dont draw your sprites as textured poligons (thats what you have to do in 3D engines like Unity), in GM all 2D is really 2D, images stacked with different depths and effects, positioned over two axis, X nad Y, nothing more. Now when you go to 3D the things are hell of different, since you need a new axis ( Z ) all screen-position calculations are based on objects position in the world, the camera position, angles, etc. Plus you have to make sure objects dont mess up with other objects depth, you have to add shadows for every vertex in the models, normals.. etc etc etc..

Note: GameMaker's 2D layer seems to be rendered by standart 'textured polygon' methods as well - you can apply d3d transformations (and even ones that are not avaible for 2d matrixes, like rotating x, y, z axis at once) to it. Also, from practice, I can say that room backgrounds are being rendered by two for() loops instead of textured polygon (using 4x4 background image causes more lag than using 128x128 image with that same patern tiled).

[scream681]

General rules.

Draw as much as you can in a single draw call. This means put as much into a GM model as you can.

If you draw <1000 polys (more on larger systems), the CPU will get in the way, and the GPU will get bored and have an affair with your HardDisk and thereby slowing your game down even more.

The more you can draw, the more time your CPU will have to execute other game code. The CPU and GPU work in parallel with large models.

Skin your models - even buildings and terrain. This allows large sections of a world to be rendered in one go, rather than a brick at a time.

Never, ever, draw QUADS if you can possibly avoid it. Your graphics card WILL hate you.


Anything else.....?

I agree with all the above, and I really tried my best to optimize Darkverse in these areas, I even tried using DLLs to perform calculations and then draw the models. But the main issue of the 3D system seems to be the drawing speed itself. Its just incredibly slow.

I did some tests when optimizing the game and posted the results here: http://gmc.yoyogames...5

While I do perform a lot of draw calls probably more than 500 each step. The overall polycount is still extremely low for today standards (max 10000 tris). I tried performing tests on other engines with exactly same models and same amount of drawing calls resulting in 50-100 times faster rendering.

After long discussions and testing with a lot of people experienced with GM 3d and GM internal structure (including icuurd12b42 and Zach Reedy). I came to a conclusion that the draw calls themselves are slow, and no further GML optimization could be done.

I hope this proves helpful improving GM 3D. If you need any code examples or further information, contact me.

Nick.

[Desert Dog]

As for your question, Nocturne, I asked Mike that (don't recall where, must've been the other topic) and he said that the Delphi runner still draws sprites as individual quads. The C++ runner however puts sprites on a single texture page, so all drawing commands can be buffered by the runner and sent to the GPU all in one go.

Quick, question concerning this. When making games, I don't go over 1024x1024, because games with large textures/images typically will get me players who can't run the game... they get an 'unexpected error' when loading is finished. Indeed, my computer struggles with large textures, too!!

What it sounds like here is we're going to end up with a pretty darn big increase in speed, but will older computers not be able to run it, because you've combined it all into 1 texture?


(note: 1024 is a base level I've personally set for myself as one all computers should be able to run, I believe the problem sizes are 2000+ sized textures)

[Nocturne]

As for your question, Nocturne, I asked Mike that (don't recall where, must've been the other topic) and he said that the Delphi runner still draws sprites as individual quads. The C++ runner however puts sprites on a single texture page, so all drawing commands can be buffered by the runner and sent to the GPU all in one go.

Quick, question concerning this. When making games, I don't go over 1024x1024, because games with large textures/images typically will get me players who can't run the game... they get an 'unexpected error' when loading is finished. Indeed, my computer struggles with large textures, too!!

What it sounds like here is we're going to end up with a pretty darn big increase in speed, but will older computers not be able to run it, because you've combined it all into 1 texture?


(note: 1024 is a base level I've personally set for myself as one all computers should be able to run, I believe the problem sizes are 2000+ sized textures)

Yes I wonder this too as I have experienced the same problem and even put the same size limit on my graphics (1024x1024 max)...

[nottud]

I have a wish relating to transformations - is it possible to add a command to save and load transformations of an object? So you say rotate a ball so much and then on the next draw you want to rotate the ball that amount plus a bit extra. This you could do by saving and transformation and then laoding it next step and adding another transformation. I know there is a stack but I can only save 1 transformation by that at a time really as it is a global stack. Is it possible to save a transformation to say like a variable or an index and laod them again for later use? Thanks.

[Phantom107]

So yes. We render everything in triangles. It's faster. Drawing Quads is terrible. Sometimes you can't help it, and thats fine. But you should never render everything as single or double triangles, and thats exactly what GameMaker does. So yes Dark Matter; Drawing 2 triangles at a time is always bad, but sometimes you can't help it.

In GameMaker this is true, but for big 3D engines? No sir.

You see, quads aren't slow. It depends entirely on how it is programmed. Infact almost all effects, including particles, are based on quads. Modern games have thousands of particles going about, all quads!

The trick is this. Groups of particles are merged into a very small amount of primitives, as that will make them render very fast, just like any other model. Then they use realtime vertex manipulation on models to make the particles fly individually. If you can provide GM with functions to manipulate vertex data on the fly, quads won't be any problem whatsoever. Although then the bottleneck would be GML... but well, better than nothing. And there are more uses for it, like realtime deformation.

[scream681]

scream681: This should now be solved. You still don't want to render too many models, but you will certainly be able to up the polygon count well past what you currently do. This was the goal in the first place.

I was never really bothered by the polycount. The game looks fine with the current meshes it uses. My main issue is the draw calls speed, will those be faster? Rendering more polys helps when you got static levels, but when you have lots of things moving on the screen, you can't avoid numerous draw calls.