next »

[oahda]

It's a classic. c;

And yep.

[g0r1ll4]

Hello, sorry if I'm offtopic but do anyone know how this game made his 3d with gamemaker ?
https://forums.tigsource.com/index.php?topic=26526.0

Thanks.

[oahda]

I haven't used GM since 6.0 and stopped around the time 6.1 came out, but even then it was possible to do some 3D and there was a tutorial for a Doom-style first-person labyrinth in the docs. I can only imagine 3D support has improved a lot in the decade or more that has passed since then, with Studio and all.

[Crimsontide]

The link I posted explains everything quite well. Some highlights are:

• Uses JSON so that datatypes don't have to be decoded manually.
• Can link to external binary files that can pretty much be sent straight to the GPU.
• Standardised units such as metres, and that y is up, so that everyone is on the same page, from one modelling software to another, to an engine.

Appreciate the info.  IMHO we don't need another interchange format, we already have way too many of those.  If this was a binary/GPU orientated format then that would be pretty cool.  Oh well, I have my own formats

[cynicalsandel]

Hello, sorry if I'm offtopic but do anyone know how this game made his 3d with gamemaker ?
https://forums.tigsource.com/index.php?topic=26526.0

Thanks.

I don't know if it's the exact technique that game used, but

http://www.like100bears.com/writing/2d-3d-in-gamemaker-studio

[oahda]

Thoughts on -ffast-math?

[JWki]

Thoughts on -ffast-math?

Doesn't it remove the guarantee that floating point numbers are stored according to IEEE standards?

[Schrompf]

Thoughts on -ffast-math?

Default in my builds. Didn't remember any issues with it so far.

[ferreiradaselva]

Yeah, I don't have any problem with it either.

Operations' results might be different between builds using -ffast-math and builds not using -ffast-math due round-off.

Regarding the round-off:
If you are going to release a game that uses procedural generation based on a randomness seed, for example, stick with the option you released the first version (whether it was with --ffast-math or without -ffast-math), otherwise the different game releases would generate different levels when they are using the same randomness seed.

I don't see any other case that you should worry about.

[InfiniteStateMachine]

One thing to remember is that modern processors optimize around the float precise modifier. In fact in some cases it's actually faster to use precise float over fast float.


EDIT : My bad, this seems to be some GCC flag. I'm not sure if that's the same thing.

[Ordnas]

One thing to remember is that modern processors optimize around the float precise modifier. In fact in some cases it's actually faster to use precise float over fast float.


EDIT : My bad, this seems to be some GCC flag. I'm not sure if that's the same thing.

I do not think is the same thing. Anyway in Visual Studio the precise is set to /fp:precise by default (instead of /fp:fast, corresponding to -ffast-math): https://blogs.msdn.microsoft.com/vcblog/2015/10/19/do-you-prefer-fast-or-precise/

I know that several games used fast math without problems, maybe you need to experiment expecially if you are using some third physics library (Havok, Physx...). I am also interested in Rapid Packed Math.

[Schrompf]

On the topic of procedural generation: you might be doomed anyways. There's also a CPU flag concerning Floating Point Math which changes the behaviour in corner cases, and it's global. A few programs (such as some printer drivers) are famous for changing this flag in mid-flight, so your procedural content generation might fail without notice.

Floating point math is not reliable. This will get only more pronounced once you port your stuff to another OS and compile with a different compiler, applying different optimisations or different order of execution, yielding different rounding behaviour. Might appear to work in most of the cases, but might also fail in rare circumstances when the differences happen to hit a comparision which takes your whole content generation down a different path.

I'm too lazy/busy to dig for the sources, but I pondered that exact question a few months ago and ended up relying all my content generation on fixpoint math.

[InfiniteStateMachine]

One thing to remember is that modern processors optimize around the float precise modifier. In fact in some cases it's actually faster to use precise float over fast float.


EDIT : My bad, this seems to be some GCC flag. I'm not sure if that's the same thing.

I do not think is the same thing. Anyway in Visual Studio the precise is set to /fp:precise by default (instead of /fp:fast, corresponding to -ffast-math): https://blogs.msdn.microsoft.com/vcblog/2015/10/19/do-you-prefer-fast-or-precise/

I know that several games used fast math without problems, maybe you need to experiment expecially if you are using some third physics library (Havok, Physx...). I am also interested in Rapid Packed Math.

yeah /fp:precise is what I'm thinking of, it can often be faster than fp:fast (at least on some consoles)

[ferreiradaselva]

I'm here brainstorming while coding to find what i can improve about my renderer. I want to decouple everything into shader, buffer (VAO and VBO).

Even though I give the option to create many shaders as possible in my engine, I want to hopefully make some sort of default uber shader. That would be nice.

[qMopey]

In tinygl I separated all those concepts. There's the concept of vertices, vertex attributes, shaders, uniforms, draw calls, frame buffer. I didn't care about VAO and instead manually manipulated glVertexAttrib funcs. Maybe it will give you an idea.

Initialization:

Code:

// setup tinygl
tgContext* ctx_tg = tgMakeCtx(32, GL_COLOR_BUFFER_BIT|GL_DEPTH_BUFFER_BIT, GL_DEPTH_TEST);
tgMakeFramebuffer(&fb, &post_fx, screen_w, screen_h);

//glEnable(GL_CULL_FACE);
//glEnable(GL_DEPTH_TEST);
//glCullFace(GL_BACK);
//glFrontFace(GL_CCW);

tgVertexData vd;
tgMakeVertexData(&vd, 1024 * 1024, GL_TRIANGLES, sizeof(Vertex), GL_DYNAMIC_DRAW);
tgAddAttribute(&vd, "in_pos", 2, TG_FLOAT, TG_OFFSET_OF(Vertex, pos));
tgAddAttribute(&vd, "in_col", 3, TG_FLOAT, TG_OFFSET_OF(Vertex, col));

tgRenderable r;
tgMakeRenderable(&r, &vd);
char* vs = (char*)ReadFileToMemory("simple.vs", 0);
char* ps = (char*)ReadFileToMemory("simple.ps", 0);
TG_ASSERT(vs);
TG_ASSERT(ps);
tgLoadShader(&simple, vs, ps);
free(vs);
free(ps);

lookAt(cam, v3(0, 0, 5), v3(0, 0, 0), v3(0, 1, 0));
UpdateMVP();

tgSetShader(&r, &simple);
tgSendMatrix(&simple, "u_mvp", mvp);
tgLineMVP(ctx_tg, mvp);

Making a draw call:

Code:

tgDrawCall call;
call.r = &renderable;
call.texture_count = 0;
call.verts = &verts[0];
call.vert_count = verts.size();
tgPushDrawCall(ctx_tg, call);

Doing the actually rendering calls:

Code:

tgFlush(ctx_tg, SwapBuffers, 0);

[ferreiradaselva]

Yeah, that's very much how I'm rewriting my code!

One thing that I was just stuck at, and looks like you have a nice approach to solve, is the need to call `glVertexAttribPointer()` every time a draw is made, since in this design VBOs and shaders aren't fixed to a pipeline (you can use the same VBO with different shaders). Anyway, your approach by storing the vertex data with `tgAddAttribute` solves that and is nice!

[qMopey]

Yeah, in tinygl you can use the same tgVertexData with different shaders. The idea is that a VertexData and a Shader can be combined to make a Renderable. Different shaders can be matched with different VertexData as long as the user makes sure the attributes matchup

[ferreiradaselva]

I'm almost there. I will get a new renderer in the middle of my previous implementation and how you implemented in tinygl.

Now, something that I'm curious about the opinion of you all: VAOs.

I found a forum thread where some people share the same opinion as me: they are demonic useless creatures that breaks design.

Even the argument of "they make the code cleaner" isn't good, because you could just make your own function that binds the VBOs you want, and EVEN BETTER, you could make it fit nicely with your manager/renderer.

What is worse is that these evil beings are obligatory on OpenGL >=3.something (I forgot specifically which version). But, there's a suggestion in the thread I linked above: create a single VAO in the beginning of the program, and never ever switch it. Just work like if VAOs weren't a thing and edit your VBOs at will.

Have anyone done that?

[JWki]

I'm almost there. I will get a new renderer in the middle of my previous implementation and how you implemented in tinygl.

Now, something that I'm curious about the opinion of you all: VAOs.

I found a forum thread where some people share the same opinion as me: they are demonic useless creatures that breaks design.

Even the argument of "they make the code cleaner" isn't good, because you could just make your own function that binds the VBOs you want, and EVEN BETTER, you could make it fit nicely with your manager/renderer.

What is worse is that these evil beings are obligatory on OpenGL >=3.something (I forgot specifically which version). But, there's a suggestion in the thread I linked above: create a single VAO in the beginning of the program, and never ever switch it. Just work like if VAOs weren't a thing and edit your VBOs at will.

Have anyone done that?

I've done that before I knew about what VAOs were.
However, I actually found them to be quite useful once they introduced separate attribute definitions because now they're somewhat similiar to input layouts in D3D or Vulkan, which I consider a good thing to have?

[qMopey]

In tinygl I create a single VAO because it is required, and I never do anything with it. https://github.com/RandyGaul/tinyheaders/blob/master/tinygl.h#L291-L293

VAO is just a bag of state settings. You can use it, or not. It doesn't really matter. In the end I would assume the usage of a VAO would have the opportunity for driver optimization simply because it can cut down on the number of needed GL calls to perform a draw call. However, in practice I would bet this "potential room for driver optimization" would be negligible, near zero, or possibly even slower than manually setting up your state and tearing it down.

In the end the usage of VAOs may simplify the end-result of your code and possibly clean up some bits. To be specific, the usage of a VAO can clean up this function: https://github.com/RandyGaul/tinyheaders/blob/master/tinygl.h#L918-L984

But when we say "clean up" it is very subjective! Personally I think hiding all of these attribute states behind a VAO is a poor use of abstraction. VAOs are an abstraction of state. This abstraction does hide the details in the above link, but personally I think these details are important to lay out in the open. It gives a clearer picture of exactly how GL is used in tinygl.

In the end it will come down to a preference/judgement call. There isn't really a right answer here.

If you have the time I would highly suggest a VAO implementation, and an implementation with a dummy VAO. It would be highly educational for you to come back and post a comparison of each implementation so we can all learn from the example