Very cool project! I'll try to remember it the next time I'm looking for a specific image. I noticed that repeated appearances of the search term are ranked higher, which isn't necessarily productive. Also, some kind of duplicate detection would be nice. Searching for "SpongeBob" yields many copies of the same images that mentions "SpongeBob" several times.
I don't think there is a fundamental difference. ECS is the application of relational databases in a dynamic real-time context with relatively modest amounts of data, but lots of sequential processing. Sparse sets work well in this context, but they are ultimately an implementation detail. There are other ECS implementations that don't make use of it but can still deal with large throughput.
> ECS is the application of relational databases in a dynamic real-time context with relatively modest amounts of data, but lots of sequential processing.
This is probably the best explanation that I can imagine -- that they're not fundamentally different, just that ECS tends to make a sufficiently different set of design choices that it warrants some of it's own terminology.
I can't help but wonder what a more generalized take on ECS might look like, if it were to continue drawing from relational databases. For example, support for multiple indices to assist with different query patterns. Or triggers to abstract away cascading updates. Or perhaps materialized views to keep query patterns simple.
I've never had the opportunity to use an ECS system, especially in a performance sensitive context, so I don't have a good sense of where any pain points are in practice versus what my imagination can conjure up.
I also wonder what it might look like to use SQL to generate an optimal C++ representation while keeping the data definition high level.
Just idle musings - maybe one day I'll take the time to experiment.
Triggers might be counter productive. Games usually have a fundamental concept of a game loop. Changes can be processed in the loop and side effects can be processed in the following iteration. Triggers would cause this processing to be unpredictable (or at least harder to predict). ECS provides a clean way to define the order in which systems are processed each loop. Triggers might disrupt this ordering.
Maybe that's still desired, maybe not. I just thought it would be interesting to mention.
That's a great insight. I wonder if it'd be practical to defer them until after the causal operation was complete
say translating all positions, then calling all of the triggers for the positions component.
that'd keep everything in tight single purpose loops and preserve cache lines.
fair enough that it'd probably make execution order harder to predict, but also in theory it would be in the realm of possibility to generate a plan and print out the order that things would happen in.
(I'm not positing that this is actually worth doing or that the pros out weigh the cons -- just toying with the idea)
A lot of game engines have the concept of messaging that tends to happen synchronously or with a delayed dispatch step which sounds very similar to triggers. The latter comes with a verification cost because the message might not be valid anymore.
The thing with the actual gameplay layer is your often processing mainly heterogeneous elements rather than homogeneous so all the worry and focus on cache is largely academic for most kinds of game.
Completely agree on the different design choices. Curious if the analogy of how different gui packages work might have some parallels. FLTK uses a "retained mode" paradigm where IMGUI uses immediate mode. More idle musings..
>I'm guessing you pay significantly more for food at these local places than you would at a big box grocery store.
I think you have a very wrong picture of what the GP is talking about, since this is not really the case at all. We're not talking about NY-style bodegas here. In Germany for example, cut-throat discount stores like Aldi that constantly try to lower the price floor for groceries are ubiquitous and can definitely be found in dense neighborhoods. Come to think of it, a while ago I read that they started building apartment buildings with a store integrated in the ground floor because that concept works well for them.
Yeah, I have hilariously expensive convenience shop at ground floor of my apartment block. As bonus quality of products is low.
Twice the distance, 20m away there is another overpriced convenience shop but with a better quality.
I shop in supermarket about 250m away on ground floor of another apartment block that has quite good prices, good enough that it is not worth time and other costs to shop further away for many products.
George RR Martin still writes his books with the DOS program WordStar. Given the pace he releases books at, this might more be out of preference than desire to focus though...
I still occasionally use Freedos and a wordstar compatible editor I wrote in 1991, I dont even go to the DOS prompt I just boot strait in to it. The biggest problem is still getting my work off this machine to a networked one so I can back it up or publish it, used to use a floppy when those were an item but now using a serial file transfer program.. all pretty clunky.
I'm pretty sure you can have an ad-hoc setup with a serial to network adapter. It might require more custom software on both ends, but if you control both ends anyway, it might give you a smoother experience anyway.
The source refers to retail electricity prices and thus doesn't apply here. The German electricity price is subject to lots of different taxes and fees; energy generation makes up less than a quarter of it [1]. These taxes do not need to exist and even the "EEG" which subsidizes renewables could be paid via the general budget. Like, for example, power plants could be paid for by the state. The comparison of household prices therefore makes little sense, as it implies the governments are in a race to offer the lowest rates to its population.
So according to your logic, taxes used to subsidize electricity production should not be included when calculating the cost of electricity, which can only give rise to a meaningless cost. Germany imposes such high taxes because they have such massive subsidies for producers. That is why electricity costs so much more in Germany — because it costs so much more to produce. But being fungible, the cost of wholesale electricity on the transnational exchanges will of course tend to the law of one price. It is the taxes that bring this in line with reality as to the fully loaded cost of generation, which in Germany is much higher.
>Germany imposes such high taxes because they have such massive subsidies for producers.
Even without the EEG, the electricity price would be among the highest in all of Europe. Also, given how much public money coal for example receives in Germany, I think it is a very reasonable argument that the EEG subsidy should not really be considered a fixed part of the electricity price that could not be moved elsewhere.
I'm not sure why you're trying to say here. Pretty much every German and most definitely every merchant has a bank account. Personally I've never had an account that wasn't free either, although some banks are changing this in light of the low/negative interest rates.
The front page sample does not explicitly use the Point type in the declaration of p. Typo or does the compiler actually match table variable definitions to available type definitions?
Even the (by far) most dense borough of Berlin is only at 14,373/km²[1], though. That's considerably lower than almost all of the Parisian boroughs[2]. Even the whole city's average is 20,000/km². From the point of view of most American cities with some obvious exceptions, the difference is probably indeed not that noticeable though.
