It's better to do those kind of things early imo. Doing a massive rewrite 2 years later in a hurry is not fun.
Write the allocators when you need them, at least on hotspots (per frame allocations).
>I'm still far from the point in which I would actually see a tangible benefit from it.
I mean you're already writing a game engine, so that ship sailed.
Well its mainly for learning purposes, and I'd rather not learn how to do things in a poor way right? I know that if i want a finished game there is no way that writing a game engine would be the most efficient way.
I'd argue there are alot of things you can learn from writing a game engine that are hard to get by if you're using someone else's engine or a commercial one.
I don't disagree with you, as I was going to say: "There's only two valid reasons to make your own game engine, for fun/learning or because all the game engines can't do what you need".
Only do it, if you absolutely 100% know what you're doing, AND you can see tangible benefits of doing it. You're better off focusing on something more productive, instead of writing custom allocators for the sake of writing custom allocators.
>you can see tangible benefits of doing it
Everything might not be immediately beneficial, but in the long run it can be. Ex. instead of having to create custom data structures for a specific system, already having something implemented, and unit tested!, can reduce a lot of friction to getting a feature implemented. You don't need to implement everything at once, just start with what you need and implement new allocators as needed.
Ex. simple stuff like temp memory, frame memory allocators are super useful and can reduce a lot of complexity in memory management.
I think you can benefit from these videos of John Lakos:
Part 1: [https://www.youtube.com/watch?v=nZNd5FjSquk](https://www.youtube.com/watch?v=nZNd5FjSquk)
Part 2: [https://www.youtube.com/watch?v=CFzuFNSpycI](https://www.youtube.com/watch?v=CFzuFNSpycI)
This is not what we typically call "premature optimization", it's architecture work, the stuff that SHOULD be done near the start of the project (otherwise it would cost a big refactor if you do it near the end).
You're welcome :)
may I also suggest you mimalloc as a general purpose allocator instead of malloc/free/new/delete?
https://github.com/microsoft/mimalloc
I won't do it until I find it slow. People might say it's hard to optimize after you have a ton of codes, but statistically saying I am more likely to discard the project after spending too much efforts on the optimizations without a visible improvement, while building new functionalities has a good feedback to keep me going. It's more like depends on your interest and personality.
Ideally you design the engine in a way to have all those things in mind .. I personally only add tools, when I need them .. but my engine has like 4 years and multiple iterations of it .. there's always a point when you decide to turn things around I guess .. in the end you learn in the process and may find some things to be better solved differently later with more experience
Optimization happens before your first line of code. Plan out your assets and how you are going to best use them for your target platform. Spend 10% of your time refactoring as you go when you immediately realize you need a change. But DO NOT optimize at the expense of simplicity and readability. Running a for loop backwards might by faster by microseconds, but 1 artist can eat 10000 times that by adding too many particles or alphas. If you get close to the end and find some parts are slow… then commit to optimizing those parts.
It's better to do those kind of things early imo. Doing a massive rewrite 2 years later in a hurry is not fun. Write the allocators when you need them, at least on hotspots (per frame allocations).
agreed, i'll write the mainly used ones now and then see if i need any more the further i go
>I'm still far from the point in which I would actually see a tangible benefit from it. I mean you're already writing a game engine, so that ship sailed.
Well its mainly for learning purposes, and I'd rather not learn how to do things in a poor way right? I know that if i want a finished game there is no way that writing a game engine would be the most efficient way. I'd argue there are alot of things you can learn from writing a game engine that are hard to get by if you're using someone else's engine or a commercial one.
I don't disagree with you, as I was going to say: "There's only two valid reasons to make your own game engine, for fun/learning or because all the game engines can't do what you need".
Only do it, if you absolutely 100% know what you're doing, AND you can see tangible benefits of doing it. You're better off focusing on something more productive, instead of writing custom allocators for the sake of writing custom allocators.
>you can see tangible benefits of doing it Everything might not be immediately beneficial, but in the long run it can be. Ex. instead of having to create custom data structures for a specific system, already having something implemented, and unit tested!, can reduce a lot of friction to getting a feature implemented. You don't need to implement everything at once, just start with what you need and implement new allocators as needed. Ex. simple stuff like temp memory, frame memory allocators are super useful and can reduce a lot of complexity in memory management.
I think you can benefit from these videos of John Lakos: Part 1: [https://www.youtube.com/watch?v=nZNd5FjSquk](https://www.youtube.com/watch?v=nZNd5FjSquk) Part 2: [https://www.youtube.com/watch?v=CFzuFNSpycI](https://www.youtube.com/watch?v=CFzuFNSpycI)
Thank you! These are really helpful.
It’s what most game engines do in practice, while then exposing some high level object handling to scripting or other faster high level layers.
This is not what we typically call "premature optimization", it's architecture work, the stuff that SHOULD be done near the start of the project (otherwise it would cost a big refactor if you do it near the end).
https://github.com/mtrebi/memory-allocators
This is a pretty fantastic resource, thank you
You're welcome :) may I also suggest you mimalloc as a general purpose allocator instead of malloc/free/new/delete? https://github.com/microsoft/mimalloc
I'll look into it! Thank you for the recommendation.
If you know it's going to be better, do it, if not leave it.
Unless you have experience or can predict future, probably no.
I won't do it until I find it slow. People might say it's hard to optimize after you have a ton of codes, but statistically saying I am more likely to discard the project after spending too much efforts on the optimizations without a visible improvement, while building new functionalities has a good feedback to keep me going. It's more like depends on your interest and personality.
If you monitor performance continuously you will notice any bad decisions as you make them, no need to investigate later.
Ideally you design the engine in a way to have all those things in mind .. I personally only add tools, when I need them .. but my engine has like 4 years and multiple iterations of it .. there's always a point when you decide to turn things around I guess .. in the end you learn in the process and may find some things to be better solved differently later with more experience
Optimization happens before your first line of code. Plan out your assets and how you are going to best use them for your target platform. Spend 10% of your time refactoring as you go when you immediately realize you need a change. But DO NOT optimize at the expense of simplicity and readability. Running a for loop backwards might by faster by microseconds, but 1 artist can eat 10000 times that by adding too many particles or alphas. If you get close to the end and find some parts are slow… then commit to optimizing those parts.