Adam's Lair Forum

Not like one of those Unreal changelogs, but still lots of progress this month!



Excited for v3.0, among other things Also, thanks to loeller for his PRs! You owe him a bugfix or two.

_________________
Blog | GitHub | Twitter (@Adams_Lair)

I must admit this is impressive!

I would REALLY like to see the creator make a full game with Duality, to show off what it can really do. You know, like the Unity people have that demo game. I know there's a couple examples on Nuget, but not really a game to "show off".

Congratulations, Adam.

_________________
Hello there! Nice to meet you!
I have github. Apologies in advance for bad coding practices.

Thanks!


So would I! Pretty sure it will happen at some point. Not yet sure when though.

_________________
Blog | GitHub | Twitter (@Adams_Lair)

Attended a game jam yesterday, managed to get a small game mechanics prototype up and running:



Available on GitHub (binary download included), but requires a gamepad to be played.

_________________
Blog | GitHub | Twitter (@Adams_Lair)

Optional fixed-viewport rendering:


This feature was basically "for free" after I did some cleanup in the render setup. Super useful though, can't wait for v3.0 to progress

_________________
Blog | GitHub | Twitter (@Adams_Lair)

Merged the feature branch for render setup stuff back to the v3.0 milestone branch and completed the issue that I linked before.

Auto-Resize of fullscreen render targets for postprocessing effects:



Auto-Resize of fixed-resolution rendered images for games focues on pixel art. Render at any resolution and scale up the result while maintaining aspect ratio:

_________________
Blog | GitHub | Twitter (@Adams_Lair)

Forgot to show that before, just so you can have a look at what's behind doing a rendering setup: This is how it looks for the fixed-resolution rendering example as shown in the previous post:



There is a RenderSetup resource that does a world space and a screen space pass, both rendering to the MainTargetTex texture that has a fixed resolution of 320x300. A third rendering step in the PixelArtSetup will then draw that texture to the screen while resizing it to fit the available space and its own aspect ratio.

Another sample from the new RenderSetup sample package: A bloom filter.



A bloom filter usually involves a lot of rendering steps that gradually downsize the rendertarget and merge the results later on for performance reasons, making it a somewhat "big" operation, so it was a good test case for finding the boundaries of the current rendering setup customization.

Involved in the setup are 9 RenderTargets (plus 9 Textures), 4 FragmentShader, ShaderProgram and DrawTechnique resources, leading to a total of 30 user-visible resources when using only out-of-the-box setups and manually setting up all the steps.



Conclusion: It's possible to create a bloom filter just by using the editor, but it's really not a very usable thing to do and definitely not fun. It worked in the end, so I kept the bloom sample in the package, but immediately set out to find a better way for the more complex cases.

The current solution to this problem was to provide an API that can be used to process rendering operations programmatically, so you can use coding to deal with the more complex cases, as opposed to juggling with editor UI. This is the custom setup for the bloom filter. It automatically sets up all the RenderTarget resources it needs internally without exposing them and applies bloom in a single rendering step, rather than 13 individual and manually set up steps.



Way easier to handle that way, and also more flexible, should that flexibility be required. There's definitely room for improvement, but for now I think I'll leave it like that. It's already a huge improvement in what is easily (and overall) possible compared to v2.x, and after all, you only create a rendering setup once - after that, it's just drag-drop, even between projects.

_________________
Blog | GitHub | Twitter (@Adams_Lair)

This is super cool, and useful too! Thank you for the writeup!

Just released an update to RigidBody polygon shapes! They no longer have to be convex and there no longer is a limit to the number of vertices. Internally, a polygon decomposition algorithm will transform any simple (no crossing edges) polygon into a set of convex polygons for internal usage.

Defining a non-convex polygon. Note the decomposition lines appearing as soon as it turns from convex into non-convex:


The RigidBody editor now uses thicker lines to render shape outlines and joints. They are also now using a constant screen-space size, so they always remain visually readable regardless of your zoom level:


Physics with "non-convex" / auto-decomposed polygons:


This was heavily inspired by YMR's ComplexBody plugin, but it's not meant as a replacement. Even though some improvements are still scheduled, only a select subset of features you can see there will make it into the core.

_________________
Blog | GitHub | Twitter (@Adams_Lair)

Teamed up with YMR to build a vertex editing tool for the RigidBody Editor:



It's out there in the latest package release. Go get it

_________________
Blog | GitHub | Twitter (@Adams_Lair)