next »

[gimymblert]

Doing simple raycasting for now.

If performance is a problem, you can do the overgrowth way, spread it over multiple frame

[oahda]

Yeah. I guess it's an exponential thing. The more occlusive geometry I put into the level, the more potential ray tests there are. Maybe the physics engine is clever about figuring out what's nearby tho, I dunno how it works underlyingly. But I can't really cheap out on it, because it would be super annoying if the player can clearly identify the subject but the game decides that it's not visible because the geometry used to test the rays against is too simplified or something.

[Ordnas]

Yeah. I guess it's an exponential thing. The more occlusive geometry I put into the level, the more potential ray tests there are. Maybe the physics engine is clever about figuring out what's nearby tho, I dunno how it works underlyingly. But I can't really cheap out on it, because it would be super annoying if the player can clearly identify the subject but the game decides that it's not visible because the geometry used to test the rays against is too simplified or something.

Because you are interested to detect walls, so static objects, what about using a 2D grid representation of the scene plane XZ, and mark each grid cell that contains the wall, and do the 2d-line intersect between a line and a box/circle? It is heuristic and has some error, but you could tweak it to have an acceptable level of precision.

If the raycast is still preferable, maybe a QuadTree could be used to lower significantly the geometry tests.

[qMopey]

When I was trying to get a hit detection of triangle to rectangular player right and couldn't do it for day and suddenly I go my problem fixed.

Congrats! That kind of code is hard to write

[oahda]

Yeah. I guess it's an exponential thing. The more occlusive geometry I put into the level, the more potential ray tests there are. Maybe the physics engine is clever about figuring out what's nearby tho, I dunno how it works underlyingly. But I can't really cheap out on it, because it would be super annoying if the player can clearly identify the subject but the game decides that it's not visible because the geometry used to test the rays against is too simplified or something.

Because you are interested to detect walls, so static objects, what about using a 2D grid representation of the scene plane XZ, and mark each grid cell that contains the wall, and do the 2d-line intersect between a line and a box/circle? It is heuristic and has some error, but you could tweak it to have an acceptable level of precision.

If the raycast is still preferable, maybe a QuadTree could be used to lower significantly the geometry tests.

Well, the game is going to be bumpy, organic and moving, so there could be anything absolutely anywhere from any angle at any time to obscure what the camera sees. So there isn't really going to be a scene plane like in this prototype in the actual game. /:

But I really only implemented the raycasting so that I can get on to testing what I actually want to be testing with the prototype, which is to present the photos taken to NPC's to get information about who/what/where is in the photo and so on, and it's good enough for that. In the final game, I'll probably do it mostly on the GPU anyway, whether that be through occlusion queries or checking depth buffers or whatever. c:

[JWki]

Yeah. I guess it's an exponential thing. The more occlusive geometry I put into the level, the more potential ray tests there are. Maybe the physics engine is clever about figuring out what's nearby tho, I dunno how it works underlyingly. But I can't really cheap out on it, because it would be super annoying if the player can clearly identify the subject but the game decides that it's not visible because the geometry used to test the rays against is too simplified or something.

Because you are interested to detect walls, so static objects, what about using a 2D grid representation of the scene plane XZ, and mark each grid cell that contains the wall, and do the 2d-line intersect between a line and a box/circle? It is heuristic and has some error, but you could tweak it to have an acceptable level of precision.

If the raycast is still preferable, maybe a QuadTree could be used to lower significantly the geometry tests.

Well, the game is going to be bumpy, organic and moving, so there could be anything absolutely anywhere from any angle at any time to obscure what the camera sees. So there isn't really going to be a scene plane like in this prototype in the actual game. /:

But I really only implemented the raycasting so that I can get on to testing what I actually want to be testing with the prototype, which is to present the photos taken to NPC's to get information about who/what/where is in the photo and so on, and it's good enough for that. In the final game, I'll probably do it mostly on the GPU anyway, whether that be through occlusion queries or checking depth buffers or whatever. c:

Compute shaders!

Nah seriously though what is your minimum spec requirement?

EDIT: Just finished up some UI shenanigans - now support multiselection for entities, so you can ctrl+click to pick what you want to select, or just shift+click to select whole ranges of entities at once.
The property editor doesn't really do anything useful with a multiselection other than give you the choice which entity to edit.
What's especially nice about this is that I didn't have to restart the app while coding it, other than when it was crashing the whole thing obviously, thanks to hot reloading.

[oahda]

You're progressing fast! Is that ImGuizmo? How are you managing the object ID's?

Compute shaders!

Nah seriously though what is your minimum spec requirement?

Basically "should work on the devices I have lying around to test on". And like I said before, I would like to try to write everything basically like GLES3 so that I don't have to do a lot of mobile-specific work. I may have gotten the wrong impression, but I'm fairly sure compute shaders are too new for that?

[JWki]

You're progressing fast! Is that ImGuizmo? How are you managing the object ID's?

Compute shaders!

Nah seriously though what is your minimum spec requirement?

Basically "should work on the devices I have lying around to test on". And like I said before, I would like to try to write everything basically like GLES3 so that I don't have to do a lot of mobile-specific work. I may have gotten the wrong impression, but I'm fairly sure compute shaders are too new for that?

GLES3.1 I believe is the first version to add Compute support.
Anyhow you're going to have to have A LOT of target hardware specific code in the end anyways so might as well exploit what you have on each platform to get the optimal result.
Write once, ship everywhere is a myth except maybe when using an engine that *already does* all the hardware specific stuff for you. As in, game code can be written once maybe but engine tech is pretty much something you can forget about.

As to your questions, the reason I'm progressing so fast is that I'm writing features first then after having some ground covered pulling stuff out and building an abstraction, instead of the other way around. While there's already some modularity in there (like the entity system, the graphics library, maths code, socket layer etc), the majority of the code is a massive linear block.

And yes, it's ImGuizmo but it's most certainly going to be replaced by a different solution because there's quite some things I don't like about it, it was just the quickest to implement.

Object ID's are managed in a fairly simple fashion - for each world that you create, there's a pool of handles. Handles are split into two parts, the lower 16 bit are used as an index into an array that stores common data for each entity - atm that's a transformation matrix and a display name pretty much - the upper 16 bit store a generation to be able to detect stale accesses. Removing and entity returns the index to the pool, with an increased generation counter.
Manipulation of entity data happens solely through the handle, what data is stored for each entity and how it is laid out in memory isn't exposed to the user of the entity system. This is something I maintain for all kinds of conceptual objects, including low level graphics resources like textures and buffers, and it's going to be used for entity components, assets and everything else too.


EDIT: Some more productivity, added Copy for entities, tbf a trivial operation until components come into play, as well as implemented the correct behavior for the translation gizmo when having multiple entities selected. Now I actually have to implement quaternions because averaging rotations is a fucking pain.

[JWki]

CAN SOMEONE ELSE PLEASE POST THINGS TOO THANKS




It's slow as fuck because I'm not precomputing the specular part of my image based lighting but it looks so fucking pretty

[oahda]

Sorry, difficult to keep up with this pace. c; Very nice! I wonder if I'll ever really touch this stuff because I'm interested in stylistic graphics rather than photorealism. But it's very interesting technically!

[JWki]

Sorry, difficult to keep up with this pace. c; Very nice! I wonder if I'll ever really touch this stuff because I'm interested in stylistic graphics rather than photorealism. But it's very interesting technically!

You can use this in some form to produce stylized graphics, there's a nice video out there showing what Gearbox are doing with UE4. Borderlands 3 will be very pretty if it comes out sometime.

EDIT: Really sorry but I'm having way too much fun with this:

[ferreiradaselva]

That is looking incredible.

[gimymblert]

Learning PBS do have some adventage, the most important concept IMHO is energy conserving, ie that you can't emit more light that received, which has the practical of having object reflect light consistently in various light setting and that help immensely setting scene without having to constantly tweak light value, ie speed and artistic gain.

[JWki]

So I've now successfully pulled out all rendering code that was pretty much hardcoded low level code previously into a first draft of a renderer interface working with materials (currently hardcoded to a single shading model with fixed inputs) and mesh components which allowed me to finally put everything editor-y into the editor module making the complete editor code hotloadable and also allowing me to have as many different meshes, textures and materials as I want in a scene so once I get the editor code to actually pick files to import from the hard drive and export them into my own formats done I can actually build small scenes.

Now as that's not done yet so there's not really anything new to see, here's a pretty screenshot that doesn't show anything new but hey it's pretty.

[oahda]

Nice!

My new modular build system finally works and builds to every platform again (there are still many things that could be refined and tweaked but I don't have to do that right away) and so I too can finally move on to modular and hotloaded code—the rebuild part is going to be very easy to pull off thanks to the new build system. c:

EDIT: Nice, SDL has a dlopen() counterpart so that I don't have to port the functionality myself.

[InfiniteStateMachine]

Are you no longer using premake in favor of your own solution?



The last few weeks I've been trying out various CI systems. Jenkings, TeamCity, BuildBot etc..

TBH they are all pretty good.

[oahda]

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:

[JWki]

Yeah when I have a bit more structure in my code I'll look into build systems again. I quite liked my python based one that I had - maybe the next iteration will be c based, I don't know yet.

[Garthy]

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:

Congratulations. That's an excellent accomplishment. Personally I would be very proud to have reached this point.

For my own projects (of any decent complexity) I don't have a lot of faith in the various build systems and tools out there. Everything seems to handle 95% of the job really nicely, and 5% really badly. So I tend to layer something on top that manages the process and turns something sensible into the form required for the underlying build system. It's also nice to be able to work around tool limitations at the top level rather than trying to find ways to fool the underlying tools to do what you want.

It is reassuring to see someone else taking a similar approach to this process and be proud of the results.

[oahda]

Congratulations. That's an excellent accomplishment. Personally I would be very proud to have reached this point.

It is reassuring to see someone else taking a similar approach to this process and be proud of the results.

It's also nice to be able to work around tool limitations at the top level rather than trying to find ways to fool the underlying tools to do what you want.

Oh, yes. Premake is great when it comes to specifying what files to include (and exclude, which is equally important!) using wildcards (* for anything, ** for recursive anything) but CMake is a real convoluted mess when it comes to this; I ended up using the same syntax as Premake and then just reïmplemented the recursion myself in the C++ tool that generates the build files instead of trying to generate a CMake file that does the same thing as a Premake file. And specifying absolutely everything is just impossible, which is why I have to write the little make/build/run scripts in addition, especially if I want it all on the command line.