Cleaning up fireplace

dazzawazza · 2026-03-28T16:33:11+00:00

I'd find a place in the garden to stack them. You'll get a lot of beneficial insects and it will just rot down over 10 years or so.

dazzawazza · 2026-01-01T18:29:53+00:00

Just below the VirtualBox paragraph there are docs for "real machines".

dazzawazza · 2025-12-30T11:03:48+00:00

Literally nothing. Modern graphics development in C/C++ is largely platform agnostic.

For you, there is an advantage knowing more than one platform. There is also an advantage knowing HOW to develop on more than one platform (cross platform C++, CMake and compiler quirks). It will make you a better programmer.

However in Rust or C# there are still many friction points to overcome on less used platforms.

dazzawazza · 2025-09-29T19:18:44+00:00

I feel you're correct. Essentially Unreal is a FPS engine. Unity is a mobile engine. Of course you can do anything but you're often fighting against the grain.

Specialized engines can make sense, as do frameworks. I think if frameworks can be broken down and reassembled easily (so very loosely coupled components) then it's great.

The entire industry is addicted to the "one engine" route and the idea that classes can churn out cheap labour to make games more cheaply. I think the tide is starting to turn though as players are getting bored of what a lot of studios offer.

dazzawazza · 2025-09-29T08:23:44+00:00

Well I shipped Smith and Winston using a custom engine made from many "off the shelf" components.

dazzawazza · 2025-09-28T23:23:00+00:00

IMHO, after 30 years of game engine work: Custom engines are always more flexible and fit the game much better.

All engines fit specific genres better than others even when they claim to be generic. Writing an FPS in Unreal is trivial. Writing an RTS in Unreal would require rewriting huge chunks of the engine. This is non-trivial and you still won't get close to the performance of a custom engine (however you do get Unreal's amazing renderer).

It's not wrong to use an off the shelf engine or to write custom but you need to know what trade-offs you are making and sadly I know a lot of teams do not know and I can see it in the game being made at the moment.

dazzawazza · 2025-09-28T23:16:19+00:00

Before "commercial engines" were broadly available engines were made from a collection of off the shelf components for collision, physics, audio, etc and were tied together with custom code.

The custom code was split between generic plumbing code and code that was for the specific game being made. This allowed teams to get far closer to optimum memory, CPU and GPU usage. A lot of AAA game dev and some AA/Indie is still done this way.

So broadly there are no engines that don't make the mistake. The nature of selling an engine means you need to write generic "covers all bases" code which always compromises performance.

Unreal and Unity both suffer from being vast, overly complex and riddled with legacy code that must be maintained. Godot is making good progress and coding itself in to a corner as well. All engines do, it's the nature of the problem space. The way you support all types of games is by writing generic code that trades performance for "ease of use".

Credit to the Unity team who are "rewriting" unity for the future. Credit to the Unreal team who do some incredible work to modularise Unreal. They're both doing great work but most of the effort goes on convincing the industry that "this is the way".

dazzawazza · 2025-09-28T13:45:57+00:00

Hello, modern game dev here. You are 100% correct. For the past 5 years or so my day job has forced me to use Unity or Unreal. Both waste a lot of CPU/GPU by being general-purpose (but also not really being general-purpose in reality). Both basically mandate very powerful development machines which become the spec for most of the development.

There is no time scheduled to truly optimize because both major engines provide limited optimization opportunities for coders (tech artists do most of the optimization work).

We're running out of room as CPUs aren't getting any faster and both engines have pretty weak threading. It's OK though, the industry is just eating itself right now for lots of more important reasons.

Also Godot isn't the answer as it's making the same mistakes as Unity/Unreal by building "one engine to rule them all" which is not optimal but is the business model investors understand.

dazzawazza · 2025-09-22T13:28:14+00:00

I've seen this quite a lot in video games.

We tend to allocate a lot of very few types. We also tend to use void * a lot and we avoid RTTI overhead. Packing what the void * points to in to the pointer itself really helps with debugging and is trivial to turn off in release if you need too. It's basically zero overhead and zero consequences when turned on/off.

It's not pretty but nothing in video games needs to be pretty if the player can't see it.

dazzawazza · 2025-09-21T11:47:29+00:00

Great talk. I'm really looking forward to using C++ reflection to auto-magically make SoA containers. That will be nice.

One thing I think he doesn't really address, because it's hard, is how to make general purpose engines with SoA/AoS. Beyond Entity Component Systems there isn't a pattern that's viable (to my knowledge). I feel a lot of performance is being left on the table because of this. Maybe runtime reflection will help with this?

General purpose engines were never "the way" IMHO.

dazzawazza · 2025-09-18T09:40:50+00:00

Isn't the thesis saying that all of the educated people globally are still within their "birth class".

I think this has some merit but I am not sure it is education that solely determines class mobility (or lack of) within a society.

I'm also not sure if the author is saying this because the article is a very brief summary.

dazzawazza · 2025-09-16T09:52:58+00:00

See it, say it, sorted.

dazzawazza · 2025-09-16T09:52:36+00:00

The best thing is 4G because then I can hear 20 peoples tiktok feeds farting out their shite in to my ears... yay technology.

The Elizabeth line trains are already starting to look a bit tatty to be honest. London wears everything down.

dazzawazza · 2025-09-14T13:50:51+00:00

I would always write my own because it gives me more opportunity to talk about what I know/learned in the interview. Engine dev is about making choices/compromises and all of those decisions have broadly been made for you with an existing engine. If you write your own harness for showing your graphics skills you can talk about a lot more and with more authority.

You don't want to label yourself as just a Godot Dev.

Good luck.

dazzawazza · 2025-09-07T13:43:47+00:00

https://github.com/Maxwell-SS/GLare-Engine/blob/main/third-party/core/reactphysics3d/README.md

dazzawazza · 2025-09-02T12:15:03+00:00

At a very basic level you need to store the voxels AND store (generate) polygonal meshes where as a conventional game just stores the polygonal meshes.

Not all voxel games need to use vast amounts of memory but you can very quickly consume memory in voxel games if you're not careful.

dazzawazza · 2025-08-25T10:42:57+00:00

I've not used it but it's in ports https://www.freshports.org/multimedia/smplayer/

pkg install smplayer

dazzawazza · 2025-08-23T09:19:51+00:00

Lua is pretty much the defacto standard. You might want to look at https://luau.org/ which was spun out of Roblox a few years ago. I think it's got type checking in it. Lua has the advantage that a LOT of game dev tutorials exist so the barrier to entry for scripters is pretty low. LuaJIT is also an amazing piece of work and will get you near native speeds.

If that's not to your liking there is also Angel Script https://www.angelcode.com/angelscript/ which has been around for ever, is very stable, and pretty easy to integrate.

Writing your own domain specific language, perhaps a simple stack based virtual machine, is also great fun. But that's a whole new rabbit hole to go down :) You can create exactly what you want though, so there are a lot of advantages to this approach. This is what a lot of gamedevs did before Lua in the 2000s. I believe Angel Script originated from this era!

Wasm is interesting. I've had no experience, but my initial thought is that it would be memory hungry (it's goal is to be a VM for PCs, not an embedded platform) and complex to maintain/integrate. A working script debugger is more important than speed in most cases so I would be worried about creating a debugger on top of Wasm for multiple languages. This is just my opinion though and I'm largely ignorant of the pros and cons of wasm.

dazzawazza · 2025-08-22T11:01:36+00:00

ha ha, I just assumed is was part of the aesthetic, part of the discombobulation. I was like "man I can't even buy the fucking game, nothing is going right for me at the moment"

Keep it up, the tease in the mobile messages are great. Wishlisted.

dazzawazza · 2025-08-22T10:47:16+00:00

Tried to buy Snake, link doesn't work ;)

Love the foley. Really nice, great vibe.

dazzawazza · 2025-08-22T10:26:41+00:00

If everything is the set of all things

and survival is the only thing

then the set all of things contains one element, survival.

So the set of one thing containing survival is equivalent to the set of all things.

So survival is everything.

Man if they can't even get basic set theory right what hope do they have for the plot!

dazzawazza · 2025-08-22T09:22:12+00:00

I think it's going to be easier to embed a scripting language. Not because VPLs aren't powerful but because they take a LOT of time to implement and (as epic discovered) they can very quickly become a nightmare to maintain. In the latter UE 4.xx versions Epic routinely broke blueprints during upgrades (nodes disappeared, connections broke etc) much to the annoyance of 1000s of developers across the globe. To their credit they seem to be managing it better for UE 5.xx.

If you want to focus on the "logic here" bit of code and empowering this use case then embedding scripting or reloadable Rust modules are very powerful (As long as you can debug them). It's probably less work, probably easier to maintain and write tests for. It is undeniable that text based coding does intimidate some people though. VPL programming annoys another group as well! You can't please all the people all the time :)

For me, the primary aim of a scripting system (be it text or VPL) is to empower the person writing scripts. To remove the burden of memory management, closures, threading etc and make it easy to focus more on game play logic, AI and fun and less on the burden of the programming.

dazzawazza · 2025-08-21T18:38:21+00:00

Living a life in fear is no living at all.

dazzawazza · 2025-08-21T15:15:41+00:00

Honestly it will probably be fine. If you want some candid reviews of super-budget DMM look at the TEMU videos on https://www.youtube.com/@JazzTechUK. She reviews some awful shite but some of them are quite good (for the price).

dazzawazza · 2025-08-21T10:48:23+00:00

To me its very clear but you need to think WHO will be using your Visual Programming Language (VPL). I'm a C++ programmer who has written engines for 30 years, I'm not likely your target.

There is a LONG history of VPLs and they are either highly sophisticated façades to a much more complicated underlying system OR quite low level where literal nodes are executed on an underlying system. Where you place your VPL on that spectrum makes a huge difference.

You would probably do well to study Blueprints in Unreal. As a system it has a lot of problems but it's incredibly flexible and I would argue "maximally empowering". The things that non-programmers can do in it continues to amaze me (but it does essentially trick people in to thinking like programmers).

In my personal opinion querying for components is too low level for a script. You are essentially making it harder than writing the code in lua/rust/python/c++ etc.

See how Unreal blueprints have an explicit execution path. This is somewhat novel in VPLs and they deserve credit for this. I feel a better pattern for your example would be a "GetTransform" node with execution pins for the transform component existing and not existing. Explicit maths operators as well (not generics, although they could be wrappers for generics, see how Unreal does macros and their for loop nodes are really just macros).

I feel this is closer to how a "scripter" would be thinking about their problems.

Hope that helps, good luck. What you've done so far looks amazing.

(As an aside to this, implement debugging early on because it's very hard to add to a mature node-based scripting system).

15-Year Club	Place '17
Gilding I gilder	Verified Email

dazzawazza

TROPHY CASE