I've been using EnTT for the past 6 months or so for real-time content-creation development, coupled with a graphics framework called Magnum, and am really enjoying it. It's very intuitive and the author is very friendly and responsive too which is a massive plus for to get going and bounce ideas around - https://gitter.im/skypjack/entt
I've used EnTT in both compiler and graphics projects over the past few years. Nice API, good documentation, and continuous updates from skypjack. If you're looking for a C++ ECS, give EnTT a try.
Completely agree. I still follow its development even though I don’t currently use it (I plan to get back to my toy game eventually though), its a great library, well designed, excellent performance and skypjack is friendly, super responsive and helpful. Big fan of EnTT.
Read the post and realised it might be a great idea. Perhaps each node in the AST is an entity and you can add/remove components to a node during compilation ? Need to really try it out to be sure this works.
Yes, this is the basic idea. Tokens from the lexer, AST nodes, basic blocks, control and data-flow graph nodes + edges can all be entities and/or components of entities, depending on how you wish to structure your data. Since a 32-bit entity ID provides a sufficiently large "address space", you get the added benefit of only needing to store 4-byte handles instead of 8-byte pointers.
EnTT has an eventing system as well. These can be triggered in various ways (entity created, entity deleted, component assigned/removed, etc). I've used eventing to control fine-grained compilation pipelines. For example a recent scheme compiler I wrote used events to simplify inlining (both define-macro/define-syntax and straight procedure inlining) and quote/quasi-quote/unquote/unquote-splicing translation.
If you spend a lot of time writing compilers, I find an ECS like EnTT can give you extra flexibility during the design/prototype phase. Try it out on a simple prototype and see if you like it.
My recent work involving EnTT is still under NDA, though at least one of the projects should have a public announcement sometime next year.
With that said, if there is interest, I'd enjoy building a clean room compiler for an existing language using EnTT and other techniques I've developed over the years. Thoughts? While I absolutely adore TinyCC, it might be worthwhile giving that space another go?
Well, I don't think I've enough skills on this and I'd follow the project eagerly to learn something new, so I'd go with what you feel confident and/or you like!
My thoughts are that such a project would be of interest for tons of people though, I'd willingly share it as much as possible. :)
It's a fantastic piece of c++. I've been using it for a year or so and it's still impressive and an immense time saver. The only thing I could think of as an improvement is the documentation. There is a lot of it but it's in many different places and not easy to find. There's an article series on his blog, there is some in the readme but most is in different pages on the GitHub wiki.
I was looking at EnTT's API when building a little toy ECS of my own in JavaScript. Since I'm working in JS, I haven't really tried to copy its internal architecture since it doesn't quite make sense for a higher-level GC'd runtime, but I think the public API was a really handy reference for the kinds of things a practical ECS needs to have. It's a really impressive and robust project, and the documentation is super thorough and worth a peek if you have any interest in game architecture.
(slightly off-topic, but I'm excited to have a venue to ramble a bit about this:) ECS is really cool, and I'm excited about using it more for my games. The "cheap" (de)serialization by moving all state into pure, data-only components is really fascinating - I've been playing around with building networked multiplayer games for a while now, and I'm currently experimenting with rollback netcode.
A key part of rollback is saving your state every frame so you can load it if you need to roll back, and ECS makes saving/loading easier to reason about, since you can "just" grab the components and their associated entity IDs and load if needed (EnTT, for the record, has an API for this[1], though they leave the actual (de)serialization up to you). Of course, JS's lack of a memcpy equivalent makes this much harder than what you could do in C++, which has lead me to experiment with immer[2] in my ECS, which uses structural sharing to avoid mutation, so you can get a "copy" of your state by just keeping a reference to it, as future updates will make new objects. This, of course, theoretically could make a ton of garbage (e.g. updating your position every frame would create a new Position object every frame), which is not great for high performance games. I'm not sure how bad this will be in practice - JS GC is relatively smart and fast these days, but I haven't tried doing much beyond little pong or platformer demos yet. I'd also imagine that, like, doing a deep clone of my state tree every frame (or doing the whole JSON.stringify/parse dance if I stick to primitive values) probably generates just as much garbage. Maybe if I could integrate immer with some kind of object pool it'd avoid these issues, but I have no idea how useful object pooling is in practice in JS...
I've been doing a lot of gamedev and performance tuning in JS, and I do a fair bit of object pooling, but I don't think I've ever found a case where I was able to measure any actual impact on performance from it. It seems like either modern JS engines (well, v8) are incredibly good at dealing with small short-lived objects, or maybe my specific use cases aren't heavy enough for pooling to be meaningful.
Yeah, I suspect this is one of those things where when you Google it, people are mostly like "why would you ever need pooling in JS," but then it turns out pooling is used under the hood in a lot of game frameworks.
I know Ecsy[1] is using it, which makes sense because that's targeted at apps building for WebVR which really cannot afford GC pauses, so I guess it must have some merit.
I guess I could try monkey-patching immer to have it pull from a pool when creating new objects? Theoretically if it just used nominal typing (re: classes) to pick objects out of the pool and overwrite all the fields on it, as I assume it normally would do with a brand-new object, this could work out okay. Could just do pooling on the top-level component objects and deal with GC on any nested objects to simplify things (especially because nested objects probably wouldn't have classes associated with them).
1) Isn't that tick rate not frame rate? Is there really a tangible benefit to rendering 140fps over 60? I always read that beyond 60 had huge diminishing returns and was hard to detect as a human.
2) Is it really necessary for anything beyond a competitive shooter with bullets flying around? Outside of the bullets, fighting games are as or more precise than the average shooter and 60fps continues to be the standard there and I don't think >60 tick rate would bring any big value to a fighting game. A 60fps game with no buffer can already yield situations that are close to or beyond human execution (see: Melee)
I'm not actually sure requestAnimationFrame() in a browser ever gets you >60 fps. At that point, honestly, you'd probably need an independent render thread (doing some degree of interpolation) and stick to a 60fps logic tick. Which you can theoretically do in JS using web workers, though I know message-passing incurs some serious overhead in that case.
Depends on the browser, but at least in Firefox and Chrome it should match actual refresh rate if the graphics stack plays properly. (i.e. I don't know if it does if GPU acceleration doesn't fully work)
requestAnimationFrame absolutely supports higher than 60 FPS. You can also do all rendering off the main thread with OffscreenCanvas, though you can certainly hit 144 Hz or higher without doing that.
And the new Edge? Of browsers from major vendors at least, I thought Edge was worth mentioning since it recently overtook Firefox in desktop market share.
Phaser 3 (and its predecessor Phaser 2) provide helper code for managing object pools[1]. I can imagine any non-toy project takes advantage of pooling for speed when it can.
You should do this in both GC'd and non-GC'd languages. Obviously C/C++/etc give you more options for arenas and the like. If you have a well bounded upper limit there's a while lot of good reasons to preallocate(locality of data, GC pressure, etc).
Some engines I used to work with would assert() on malloc/free if it happened outside certain safe regions of execution.
I made an ECS in JS and have been using it for some time. It's not particularly designed for the kind of rollback you're talking about, but you might find it useful as a comparison:
In mine I store each entity's state for a given component as an object (e.g. `{ mass:1, velocity:[0,0,0] }`, so the internal storage of the ECS for a given component is an array of such objects. To really optimize for the "cache and rollback" kind of behavior you're talking about I guess it would be ideal for the internal storage to be flat arrays of numbers, but at first blush it seems like that would make the implementation of the ECS itself kind of hairy.
Since you generally want to keep a set number of time steps the commonly used data structure for this is a ring buffer. No garbage and all you do is increment the index (with wraparound) every step.
Having read through the README, I'm not quite sure what makes this perform better than other systems.
I can see that it will perform excellent when iterating over a single type as all entries for this type are next to each other. However, for each meaningfull operation you are likely to combine at least two different types, which means data will have to be read from different locations, defeating the purpose. You could put more data in a single type (for the example from README, you would put velocity and position in a single type) but than you are back to hand-tuning your data types as you would in any other system.
It still looks like an interesting library, but if there are any inherent performance benefits I am failing to see, I would love to hear about them.
The design is such that you pay for what you need. To do what you're looking for, that is, a linear access on multiple components without jumps nor anything else, there exist groups. They are the fastest thing you can imagine because you iterate literally N arrays for N components in order with no jumps nor branches. They affect performance on creation/destruction though, in order to speed up quite a lot linear accesses.
Also, views are such that it doesn't worth it creating a group when one of the components involved in a query is assigned to few entities, since the view internally uses the shortest pool.
And so on, there are tons of details and use cases. The documentation (the wiki, not the README) contains all the details but it's pretty big and takes a while to go through all them.
The fact is that a real world software isn't made only of linear accesses, so the whole library is meant to allow optimizing the given access pattern when needed.
Feel free to ask if I triggered you and you want more details. ;)
Reach me out here, on gitter, discord, by mail, whatever...
Side note: The vel+pos example is a common one in ECS. It also often follow that you should put them in one type in the real world. However, nowadays thanks to SIMD instructions, it is probably faster to have them separate, as you don't have to unpack/align the various fields:
// p={(x0,y0),(x1,y1),...} and v={(vx0,vy0),(vx1,vy1),...}
for(int j=0;j<2*SIZE;j++)p[j]+=v[j];
I really enjoy the storage strategy for EnTT. Other ECS games I had known the architecture for were a lot more rigid in terms of space, and it's nice to see more flexibility in that aspect.
