next »

[qMopey]

Yes they are different.

The first one consists of a single stream of data. If you utilize all of this data, and loop over it linearly, you will have 100% efficient cache utilization (along with a cache miss or two when you first start iterating and pull the array into the cache).

The second one uses four data streams, meaning when you start looping on each array (assuming it is not already cached), you will hit four in total cache misses or so.

The purpose of the second option is to increase cache utilization. For each cache line (64 bytes) you pull into memory, what percentage of the cache line is actually used? This is your cache utilization. If an algorithm only needs to access transforms, and loops over the first option, you will have very poor cache utilization.

Cache utilization matters as when a cache line is pulled into cache, another is evicted. The less evictions you have, theoretically the better performance you have.

You can separate your data streams further, and do:

Code:

id* transform_ids;
id* renderdata_ids;
id* animator_ids;
id* physicsdata_ids;

Transform* transforms;
Renderdata* renderdata;
Animator* animators;
Physicsdata* physicsdata;

The whole point is to try and only pull into the cache what you need when you need it, and avoid pulling in extraneous stuff. Though, arguably, it's more important to just start putting things into arrays, and the whole "separating things into multiple streams" thing becomes less important. Basically: diminishing returns.

In practice all options are likely to be *fast enough* for all real games made on these forums, so it probably doesn't matter much.

[oahda]

Thank you both! Yeah, I was thinking since most of these will usually be processed together (rendering needs both the transform and the animator and the renderdata for example). But the second is still better?

(and just for some context since you said "likely fast enough", this is a full 3D game which I possibly want to run on mobile and definitely on consoles)

[qMopey]

“Better” becomes very fuzzy. There’s a juggling of priorities. More data streams puts more pressure onto registers. High register pressure can potentially result into stack spilling. This is just one example. It completely depends on the exact use case. We’re talking about splitting hairs here, so to speak; you should try different options out and measure performance stats to get a feel for this stuff.

[oahda]

Yeah. Maybe I'll try to implement both in a way that I can try each just by changing a define or something and then do profiling.

[JWki]

Thank you both! Yeah, I was thinking since most of these will usually be processed together (rendering needs both the transform and the animator and the renderdata for example). But the second is still better?

(and just for some context since you said "likely fast enough", this is a full 3D game which I possibly want to run on mobile and definitely on consoles)

Another tip: a thing that a lot of people struggle with is "both rendering and physics need a transform" and then they try to figure out how to share that data in the most efficient way because it doesn't even occur to them that they could just duplicate the data in both systems.

BTW if you really really seriously want to get on consoles you'll need to lose STL and also get comfy with the idea of ditching opengl for those builds. And if you want to target the last generation (Xbox 360, PS3), especially PS3 requires a whole different way of designing your data transformations due to it's unique architecture.

[Ordnas]

Thank you both! Yeah, I was thinking since most of these will usually be processed together (rendering needs both the transform and the animator and the renderdata for example). But the second is still better?

(and just for some context since you said "likely fast enough", this is a full 3D game which I possibly want to run on mobile and definitely on consoles)

Another tip: a thing that a lot of people struggle with is "both rendering and physics need a transform" and then they try to figure out how to share that data in the most efficient way because it doesn't even occur to them that they could just duplicate the data in both systems.

BTW if you really really seriously want to get on consoles you'll need to lose STL and also get comfy with the idea of ditching opengl for those builds. And if you want to target the last generation (Xbox 360, PS3), especially PS3 requires a whole different way of designing your data transformations due to it's unique architecture.

Or I think that now we have less constraints due to the fact that PS4 and XONE have a more PC-like architecture and we can start to forget the unique PS3 hardware.

[oahda]

TBH Switch is the only one I'm really interested in. Will be happy to make any changes necessary if that day comes. I know about PS3 and I'm not touching it.

[Ordnas]

TBH Switch is the only one I'm really interested in. Will be happy to make any changes necessary if that day comes. I know about PS3 and I'm not touching it.

Switch compiler is more "fussy" than Visual Studio about variable shadowing, order of variable in construction list and other errors that VS compiler by default would forgive.

[oahda]

Yeah, my setup requires me to keep making sure my code compiles on both LLVM and GCC anyway. c: Plus I enable somewhat picky warnings to catch things like that.

[JWki]

Yeah, my setup requires me to keep making sure my code compiles on both LLVM and GCC anyway. c: Plus I enable somewhat picky warnings to catch things like that.

Can recommend -Wall and -Werror.

[oahda]

Yeah, I would enable -Werror if I didn't have third-party code slapped into my codebase which won't compile if I do that. But I treat the warnings in my own code as such and make sure to eliminate them. Considered compiling the external code to a separate static library and linking against that instead but meh. This works. c:

[JWki]

Yeah, I would enable -Werror if I didn't have third-party code slapped into my codebase which won't compile if I do that. But I treat the warnings in my own code as such and make sure to eliminate them. Considered compiling the external code to a separate static library and linking against that instead but meh. This works. c:

Yeah what I do is either compile in a separate library or wrap with #pragmas when possible (i.e. header only libs which is most of my deps). "Compiles without warnings" has become one of my criteria when choosing libraries though.
But either way, I found that after a while I usually don't write code that would produce a warning in the first place, at least in MSVC, because you get used to fixing them a priori. It's a really good practice.

[oahda]

Yes, definitely. Most of the times I don't get warnings anyway because I know to avoid them. I keep checking just to be sure, of course.

[ferreiradaselva]

"Compiles without warnings" has become one of my criteria when choosing libraries though.

One reason I'm thinking about writing a lib for loading .ogg files. STB ogg loader is full of warnings, to the point I have no idea where to start to fix.

[ferreiradaselva]

I'm really digging this:





I want to write one fluid simulation eventually. I've found some example codes, already, it seems simple.

[ThemsAllTook]

I want to write one fluid simulation eventually. I've found some example codes, already, it seems simple.

Neat. This is something I'm going to be working on soon. If you have/find any other good resources, please share them!

[JWki]

I'm really digging this:





I want to write one fluid simulation eventually. I've found some example codes, already, it seems simple.

It is surprisingly few code but depending on what you wanna do it's not necessarily simple. Shallow water surface sim is pretty straightforward, full body simulation is a bit more complex (and expensive).

[ferreiradaselva]

I want to write one fluid simulation eventually. I've found some example codes, already, it seems simple.

Neat. This is something I'm going to be working on soon. If you have/find any other good resources, please share them!

This was the most simple example I found: https://www.mikeash.com/pyblog/fluid-simulation-for-dummies.html
Certainly has caveats.

It is surprisingly few code but depending on what you wanna do it's not necessarily simple. Shallow water surface sim is pretty straightforward, full body simulation is a bit more complex (and expensive).

I'm aware it's expensive. I will do just for fun.

More fun videos:









The last one is by Matthias Müller-Fischer. There are the name of his papers in the description of his videos.

[Ordnas]

I want to write one fluid simulation eventually. I've found some example codes, already, it seems simple.

Neat. This is something I'm going to be working on soon. If you have/find any other good resources, please share them!

This was the most simple example I found: https://www.mikeash.com/pyblog/fluid-simulation-for-dummies.html
Certainly has caveats.

It is surprisingly few code but depending on what you wanna do it's not necessarily simple. Shallow water surface sim is pretty straightforward, full body simulation is a bit more complex (and expensive).

I'm aware it's expensive. I will do just for fun.

More fun videos:









The last one is by Matthias Müller-Fischer. There are the name of his papers in the description of his videos.

Very interesting to watch, I am wondering when all that good we will see in an actual game.

Someone suggest this book: https://www.amazon.com/PHYSICAL-FLUID-DYNAMICS-D-Tritton/dp/9579437017, explains without going too much on the maths side and more on how things work.

[buto]

Yeah, I would enable -Werror if I didn't have third-party code slapped into my codebase which won't compile if I do that. But I treat the warnings in my own code as such and make sure to eliminate them. Considered compiling the external code to a separate static library and linking against that instead but meh. This works. c:

Since I'm typically also only interested in my own warnings, I sometimes declare includes from external libraries as "system includes" in my build system. In CMAKE one could e.g. do the following to hide any boost-internal warnings:

Code:

include_directories(SYSTEM ${Boost_INCLUDE_DIRS})

Maybe there's some more elegant way though...