next »

[InfiniteStateMachine]

Still using Premake (but also CMake for Android) underlyingly, but created a simpler format for projects using my particular toolkit/framework so that I don't have to deal with them directly (or separately). It's basically this:

1. Each target platform has a separate module (a folder with stuff) with a file that contains the build settings specific to that platform, in my custom JSON format.

2. Each project has platform-agnostic settings for all of its targets (include files, flags, defines, links and so on). No knowledge of SDL or such either; that's up to the module (specifying my framework as a library to link invokes a special case that sets up whatever dependencies it has for the platform in question).

3. When it's time to make a target, my tool reads both of these and generates the correct build files (Premake or CMake; the module specifies) with the accumulated settings.

The target platforms' modules all have their own separate scripts to make, build and run that do whatever extra work is necessary in addition to just invoking Premake/CMake and so on—the build tool itself has no idea how to do this, but just calls whatever scripts the module contains, so that I can easily add build support for new target platforms by slapping another module folder in there. c:

Wow interesting. Was the main motivation for this because Android has a hard requirement for cmake project files?

care to share a sample of your project definition format?

[oahda]

I did look into writing a new Android module with Premake but concluded that it would be much faster to just write some code to generate CMake files and keep my old CMake setup (which was very difficult to set up to begin with). But the modularity opens up for really easily replacing it with a Premake module in the future if I ever get around to it.

But even if everything were Premake, I'd still do all of this so that I can avoid dealing with platform-specific stuff and so on in individual project files and have them be quick to set up and running. c:

Excluding the setup for remote build and what platforms to build for which are also in the same file, the targets (well, one) look like this for my test project:

Code:

	"targets": 
	{
		"main": 
		{
			"type": "app",
			"root": "src",
			"includes": ["**.cpp"],
			"links": ["karhu"]
		}
	}

And the project for my framework's library itself:

Code:

	"targets":
	{
		"external":
		{
			"type": "slib",
			"root": "src",
			"includes": ["test.cpp"]
		},
		"main":
		{
			"type": "slib",
			"root": "src",
			"includedirs": ["", "karhu/lib"],
			"includes": ["**.cpp"],
			"excludes": ["karhu/tool/**.cpp", "test.cpp"],
			"links": ["external"]
		}
	}

The 'external' target is just a little test I set up as I was implementing support for multiple targets, but I am planning on moving all borrowed code (small libraries that I've just added to my codebase instead of linking) in there so that I can apply stricter flags (-Werror and such) to the code I've written myself, which was not possible when everything was a single target, as the borrowed code hasn't been written with such considerations.

There's another file with general project information (name and so on) and the 'main' target reads its final name from there, so that the name doesn't have to be updated in multiple places if the name of the project ever changes.

[InfiniteStateMachine]

Very clean. Nice work

[JWki]

Editor coming along!
Got rudimentary asset importing going - you can import textures, meshes and create materials from textures, then you can assign meshes to entities and for each submesh assign a material to be used when rendering.
Getting this to work was both hell and enjoyable because there was no infrastructure for this at all but at the same time I could do most of it while having the application running (well, except for when I crashed it or had to alter the main application interface) which made fine tuning the interface and everything WAY less painful than with a recompile-restart workflow.

[oahda]

Cool! Are you doing anything special to generate the thumbnails, or would they be stretched if they weren't square already? Or cropped?

Yesterday I got to work on the actual main framework of the "application engine" (not necessarily the same as the game engine as I'll also use it for an editor and so on), finally. Got up and running with a modular architecture for backends with various mix-and-match subsystems based on a previous experiment I did with that. Today I mostly spent cleaning it up.

Most subsystems are configurable at compile time (so that build modules can replace them as necessary for the target platform) but the graphics and audio subsystems are also swappable at runtime to make it possible to switch from OpenGL to Vulkan in a settings menu for example. Of course I haven't gotten far enough that I would have to deal with the headaches of reloading textures and so on if I do that.

The word 'module' is starting to get really confusing by now. There are the build modules that I talked about the other day (folders), there are going to be the dynamic modules (code to be hot reloaded at runtime) and then there's the modularity of what I mentioned now, which is not the same as the hotload modularity (because it's lower level than that).

[JWki]

Cool! Are you doing anything special to generate the thumbnails, or would they be stretched if they weren't square already? Or cropped?

Yesterday I got to work on the actual main framework of the "application engine" (not necessarily the same as the game engine as I'll also use it for an editor and so on), finally. Got up and running with a modular architecture for backends with various mix-and-match subsystems based on a previous experiment I did with that. Today I mostly spent cleaning it up.

Most subsystems are configurable at compile time (so that build modules can replace them as necessary for the target platform) but the graphics and audio subsystems are also swappable at runtime to make it possible to switch from OpenGL to Vulkan in a settings menu for example. Of course I haven't gotten far enough that I would have to deal with the headaches of reloading textures and so on if I do that.

The word 'module' is starting to get really confusing by now. There are the build modules that I talked about the other day (folders), there are going to be the dynamic modules (code to be hot reloaded at runtime) and then there's the modularity of what I mentioned now, which is not the same as the hotload modularity (because it's lower level than that).

Thumbnails are just ImGui::Image calls so I think they would be stretched/squeezed.
My module system isn't mature yet but the idea is the same as behind the machinery system I posted a while back. It's all based on dynamic loading of DLLs however also works with static linking in theory. My editor is just another module that's being loaded by the runtime and uses the APIs exposed via the dynamic registry directly.

[JWki]

Yay for spam.
Here's a video that I don't know how to embed.

https://puu.sh/xBMVC/71744f15ed.mp4


EDIT: Here's also a screenshot to motivate you to click that video.

[oahda]

Fun following all your stuff on Twitter too. c:

[JWki]

Fun following all your stuff on Twitter too. c:

Yeah I've not been active there at all for some time thought I'd pull up a timeline of this now to get to where I am at currently to maybe attract the attention of some people that would be handy to know for jobs. Hoping I don't get too spammy.

Esp. because you could have seen most of it here already.

[oahda]

C++ reflection, baby:



becomes



The GUI structure makes no sense because LightSourceType is an enum and Light seems to be an Actor or whatevs but the enum values are dynamically retreived at runtime.
I've just done the most hacky implementation of this but now I have a feel for how it can work and can start doing a real reflection API.
libclang is a wonderful tool.

So I just dug up this old post of yours. I'm just wondering how the REFLECT thing works, now that I've tried out libclang myself: since the AST generation will fail on any C++ errors as usual, what exactly does the macro do? Or are you preprocessing it somehow? Or is it a clang annotate attribute or something?

EDIT:
Found out I can actually use attributes like this (but I have to use __attribute__((annotate())) because clang will ignore or filter out anything else, so macros it is).



EDIT 2:
Here's a pretty cool thread on C++ reflection using annotate() to implement C#-style attributes! https://www.reddit.com/r/gamedev/comments/3lh0ba/using_clang_to_generate_c_reflection_data/

[JWki]

Yeah that's how I did it essentially. REFLECT is defined to resolve to nothing except for when running through the reflection tool.

[powly]

Finally acted upon an idea I had earlier this year and it turned out to be not terribly difficult to get working -- at least on some level. So, you know how annoying it is that you can't printf from a shader to debug it? Well, now you can.

[oahda]

Howww? Are you outputting the characters to a texture that you read back on the CPU?

[powly]

A generic buffer (SSBO) instead of a texture but essentially exactly that also allows for atomic accesses so multiple threads can write and each printf() results in a consecutive array of characters (though obviously the order is otherwise quite arbitrary)

[ProgramGamer]

Genius.

[gimymblert]

Wow!

[oahda]

How are the print functions implemented anyway? Didn't know GLSL had support for strings at all, let alone variadic function parameters.

[JWki]

Ooooooooohhh nice someone on a team I was on mentioned playing with the idea of this once but I don't think they ever actually tried it out - that seems realllllllly useful!

[Ordnas]

Nice! Probably you already know it, but there is GLSL-Debugger http://glsl-debugger.github.io/

[powly]

btw you can try it out https://github.com/msqrt/shader-printf
main drawback: requires at least gl4.3 so probs no go on macs or webgl

the example project is vs but you only need one header that provides a modified glShaderSource and the host side code for parsing the resulting buffer (and handling the setup/binding of that buffer), the idea being that it should be relatively easy to plug in to any existing codebase.

How are the print functions implemented anyway? Didn't know GLSL had support for strings at all, let alone variadic function parameters.

Smoke and mirrors, it's just a preprocessing step for the shader source code -- GLSL indeed has no support for strings or even chars. And to have actual function calls at all you'd have to manage the stack yourself.

The key here is that the amount of arguments doesn't change at runtime and each argument is a 32bit value (or a few in case of vecX), hence if we do the format parsing on the CPU each printf results in a constant amount of output. So I just inspect the printf call before handing it to the GLSL compiler and generate replacement code that reserves enough space in the output buffer for all the characters in the string and all of the arguments of the call and writes, one by one, the results into the buffer.

It's not terribly fast but you can't print from too many threads and expect to be able to comprehend the output anyway. And there isn't much use for this other than debugging. I guess.

Nice! Probably you already know it, but there is GLSL-Debugger http://glsl-debugger.github.io/

The project is vaguely familiar but didn't really recall it and don't think it was this advanced when I last checked, have to try it out! VS has something similar built in for HLSL and it's indeed very cool. This kind of approach gives potentially a lot more info but it's somewhat more intrusive to the workflow. That's why I felt the need for the printf functionality, it falls on the debugging spectrum somewhere between outputting debug colors and step by step debugging.