next »

[Ordnas]

Code:

#include __FILE__

Brilliant

Only an evil genius could have conceived that! 

[ferreiradaselva]

I need opinions for the approach I will use to separate platform-specific/framework-specific code.

For example:

Code:

texture_opengl_es.c
texture_opengl.c
texture_direct.c

texture.h

Then, in the texture_opengl.c (and the others), I would have #ifdef/#endif wrapping the entire file, like this:

Code:

/* texture_opengl.c */

#include "config.h

#ifdef GRAPHIC_DEVICE_OPENGL

/* ALL FUNCTION DEFINITIONS WITH OPENGL SPECIFIC CODE GO HERE */

#endif

So in the Makefile (or VS), I would compile all the *.c, but only those with the macros defined in "config.h" would be compiled anyways.

Any feedback?

[JWki]

What's the problem with just including platform relevant files in the build?

[ferreiradaselva]

What's the problem with just including platform relevant files in the build?

I was thinking that that would make more trouble to setup on a IDE like VS, because I can't provide a VS project myself, and would require the user to select those relevant files. The way I'm thinking, it would require only to define a macro in the "config.h". Unless I'm missing something.

[JWki]

What's the problem with just including platform relevant files in the build?

I was thinking that that would make more trouble to setup on a IDE like VS, because I can't provide a VS project myself, and would require the user to select those relevant files. The way I'm thinking, it would require only to define a macro in the "config.h". Unless I'm missing something.

Nah it's reasonable.

EDIT: You might want to look into cross platform build systems tho. VS project setup is painful enough already, file selection wouldn't be the worst part of it, not by far.

[oahda]

this is the best thing i've ever seen

[Ordnas]

this is the best thing i've ever seen

Very interesting  . I do not know if I would try it, it is not worth the effort, I think you will sacrifice too many things, even if you are building a prototype.

[oahda]

Yeah, this is just code golf, not meant as a serious way to make games, but as a demonstration of how much can actually be done with modern CSS if you really want to, which is quite amazing (and amusing!).

[ProgramGamer]

Prepare to have your mind blown by this article.

https://twitter.com/dolphin_emu/status/891570452291649539

[bateleur]

Prepare to have your mind blown by this article.

https://twitter.com/dolphin_emu/status/891570452291649539

Sort of the reverse, actually, because I know too many perfectionist software geeks. Right from the start of the article I guessed what they were going to do and was thinking: No! Don't do that! Async is fine! That solution is completely overkill... but of course they did it.

[ProgramGamer]

But they said that async caused issues with not rendering objects. And they specifically demonstrated that metroid prime 3 in particular was in need of this solution.

Anyways, whether it was necessary or not is irrelevant now. But it's really cool what you can come up with when you're dedicated to get something running in an emulator.

[ferreiradaselva]

Async is fine on non-emulated software. If it's non-emulated and you wrote the software, you can make the main thread do other things while waiting for the second thread and grab the result when done, and even organize to not miss anything. You can't do that with an emulated software that you didn't even write.

I thought they were going to write a megashader, like in Godot. But, looks like a different solution (if I understand correct), and it's really nice.


... I will wait it to get into the stable and I'm going to play some games with it.

[oahda]

That Dolphin article was very interesting, thanks!

So apparently a 3D object format based on JSON has been created by the Khronos group, and the Godot engine is vouching for us all to try and make it an industry standard.

https://godotengine.org/article/we-should-all-use-gltf-20-export-3d-assets-game-engines

I'm liking what I see a lot, and hold their other work (OpenGL, GLSL, Vulkan) dear, so I'm definitely behind that statement. Absolutely going to try and use this format when I get back to this part of my engine code. I just implemented a JSON parser, so it would be fun to do this parsing myself too, but there's lots of readymade stuff for all sorts of languages here: https://github.com/KhronosGroup/glTF

[JWki]

I hear it has some issues but I haven't looked into what exactly those issues are - I think it was something about Maya/3DsMax animations not being exported properly due to some spline stuff not being correct, but in general glTF does look interesting.

[oahda]

Hopefully they're fixing it if they haven't already (unless the issue was with the exporters rather than the format). c:

[ferreiradaselva]

gltf looks really interesting. What I wish, though, is that Blender had an export that would only export a couple of properties of the object, like name, type and position. That would make Blender a better tool as editor of maps. When loading map with your own engine, you don't need the vertices of every object, just those properties I mentioned (and some extras, maybe). Your engine is responsible to load the object vertices/UV/material from the content library.

Now, other thing: GLFW and SDL have the functions glfwSwapBuffers and SDL_RenderPresent, which pushes the backbuffer to the frontbuffer (the doublebuffer operation). I always thought those were equivalent of glFlush, but they are not! It seems it's still useful to call glFlush, because your GPU will start doing the work and glFlush returns immediately, while on the client side, you can do other things in parallel!

[JWki]

gltf looks really interesting. What I wish, though, is that Blender had an export that would only export a couple of properties of the object, like name, type and position. That would make Blender a better tool as editor of maps. When loading map with your own engine, you don't need the vertices of every object, just those properties I mentioned (and some extras, maybe). Your engine is responsible to load the object vertices/UV/material from the content library.

Now, other thing: GLFW and SDL have the functions glfwSwapBuffers and SDL_RenderPresent, which pushes the backbuffer to the frontbuffer (the doublebuffer operation). I always thought those were equivalent of glFlush, but they are not! It seems it's still useful to call glFlush, because your GPU will start doing the work and glFlush returns immediately, while on the client side, you can do other things in parallel!

You can write a custom exporter for Blender if you want.
But the usual workflow is Blender -> FBX / whatever -> Custom Tool -> Runtime - glTF wants to be where FBX is atm which many people like as an idea because FBX isn't exactly a nice format.
Oh and yeah glFlush will force the driver to, well flush the command queue to the GPU.
glfwSwapBuffers / SDL_RenderPresent will call wglBuffer or whatever the linux equivalent is which will do the present operation on the swap chain internally used by the gl context which as you state will swap front- and backbuffer, or in a triple buffered setup present whatever the current render target was.
Not being able to manage swap chains is one of the annoying things in OpenGL btw - having that makes multi window trivial while in OpenGL it always felt somewhat hacky to do, at least without some help by SDL/GLFW.

[Crimsontide]

I've been hearing about this new GLTF but haven't read anything on it.  What are they trying to do, apart from just adding yet another 3d file format?  Are we talking just FBX in a wrapper or a fundamental difference in the way data is stored?  Is it scene-graph, model only, standardized animation?

[oahda]

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.

[JWki]

This felt relevant to me.
Anyways one should keep in mind that glTF is an exchange format and not meant to be used as a runtime format necessarily. Being able to reference external binary data blobs makes it nicer to use as the standard exchange format in your pipeline than something like FBX tho.