vercidium.com
Game engine developer from Australia, I’m keen to share what I’ve learned about optimising games.
youtube.com/vercidium
101 posts
265 followers
48 following
Regular Contributor
Active Commenter
comment in response to
post
This looks incredible! I love skyboxes like this
comment in response to
post
All of this was rendering incredibly slowly, so I switched to an instanced rendering system.
This was also initially buggy, producing some strange images:
comment in response to
post
Shadows were finally working, and I also fixed specular lighting
comment in response to
post
I then enabled shadows. Initially my engine only supported Cascaded shadows, which is overkill for this.
I added a new 'Spotlight' shadow system, which only renders the scene to one depth texture.
I messed up some OpenGL calls which led to these strange glitches:
comment in response to
post
I then animated it appearing from the void below.
All these blocks were being rendered one at a time, which was very slow!
I changed to an instanced rendering system, which brought it up from 48 up to 560 FPS.
comment in response to
post
Started very basic with a smaller world
comment in response to
post
Destroying the lootboxes looks so satisfying! Added to my wishlist
comment in response to
post
Smaller clovers are darker to create the illusion of depth
comment in response to
post
Each clover is constructed of 20 vertices and sways in the wind.
comment in response to
post
It's not realistic but they also look great underwater.
I'll definitely need to add some underwater vegetation next
comment in response to
post
Wishlisted and signed up for the playtest. Keen to try it out and share my feedback!
comment in response to
post
Hot off the press! Watching now
comment in response to
post
Here's another before and after - I love these streaks of light
comment in response to
post
Performance is decent, the whole bloom process takes 0.4ms on a 3440x1440px screen with my RTX 3070.
Using a forward renderer (no more deferred rendering!) and the improved shadows from my last post, I’m at around 370 FPS on average
comment in response to
post
I love the soft glow effect it has on these metal textures:
comment in response to
post
Previously I used separate gColour and gBloom buffers and only wrote to gBloom if I wanted bloom applied to that part of the screen.
I changed it to use one HDR gColour buffer like in this article: learnopengl.com/Guest-Articl...
comment in response to
post
Thank you for the explanation! For a voxel map it would work great, as the shadows only need to update when the map changes.
Player + particles change every frame so I would update their shadows every frame.
Found this great writeup too: www.reddit.com/r/GraphicsPr...
comment in response to
post
Tell me more 👀 I’m ready for the next step!
comment in response to
post
The TextureUnitHelper just keeps track of a counter that resets when a shader is bound, to ensure two different textures / sampler types aren't using the same texture unit.
Bindless textures would also solve this, but I'd like to maintain support for older GPUs
comment in response to
post
The best change is that textures are now bound at the same time uniforms are set.
This uniform class is the only time that glActiveTexture is called, which means uniforms and textures will never be out of sync.
comment in response to
post
So I changed ShaderUniform to be an abstract class, with multiple ShaderUniform<Type> classes that inherit from it.
To define uniforms for a shader, I can now call AddUInt(...), AddFloat(...), etc:
comment in response to
post
I previously had a ShaderUniform class which was used to set a value on a uniform in a shader. It had functions like SetInt, SetVec3, SetMat4, etc.
However this meant I could call SetMat4 on an integer uniform, and it won't throw an error.
comment in response to
post
I'm also looking back at some old code and thinking "what was I thinking!?"
There's so much room for optimisation here. I'm keen to run some benchmarks post- and pre-refactor
comment in response to
post
Thank you for sharing, that is very concise! I like it, I’ll try it out
comment in response to
post
Oooh I see. I’ll check out HLSL, thank you!
comment in response to
post
My goal is to reduce the amount of manual ‘management’ work - e.g. ensuring uniforms/varyings have the same names across shaders and code - so that shaders don’t break so easily when working on them
comment in response to
post
I started learning Vulkan the other day and having to compile my shaders down to SPIRV is a hassle 😅 I’ll need to add a pre-build step that does it automatically for me
comment in response to
post
So far this refactor has removed 2000 lines of code, and means shaders are more enjoyable to work on!
comment in response to
post
Varying are also defined in one place now and are appended to both fragment and vertex shader strings (‘in’ is replaced with ‘out’ for the vertex shader).
comment in response to
post
So I’ve created a ShaderUniformHelper class that has AddFragment(…) and AddVertex(…) functions, which appends the uniforms to the top of the shader string.
Now all the uniforms for one shader are defined in one place.
comment in response to
post
Previously I was defining uniform names in 3 places (C# variable name, C# string parameter, and in the fragment/vertex shader)
With hundreds of shaders and over 1000 uniforms, this duplication adds up!
comment in response to
post
Let us know how it goes! Been looking for a chair with good lower back support for a while
comment in response to
post
@nivmiz.bsky.social some inspiration for your pixelated renderer :)
comment in response to
post
Absurd and High modes are hard to look at, my eyes feel like they're unfocused when they're not. I like both Moderate and Zero
comment in response to
post
Hahaha can relate. We all have days like that
comment in response to
post
Exorcist lizard 😆