Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Flecs – A fast entity component system for C and C++

flecs.dev

Post reply on HN
Print view View original

11–20 of 90 posts

Re: Flecs – A fast entity component system for C and C++

#11

Post by charcircuit »

tbillington wrote: post #7
korijn wrote: post #2

Any idea what a game loop would look like for an ECS engine that only renders a new frame when some animation is running or when the user is manipulating the camera, but not otherwise? Let's not argue "why". Most obvious would be saving battery.

The bevy engine (ECS based) has an `UpdateMode` that specifies "Continuous" vs "Reactive" https://docs.rs/bevy/0.10.1/bevy/winit/enum.UpdateMode.html . Here's an example using it, it's well suited for "desktop applications", the shorthand to use it is `desktop_app()` https://github.com/bevyengine/bevy/blob/1c5c94715cb17cda5ae2... . https://github.com/bevyengine/bevy/

How often your app takes in events != How often your app outputs frames

The OP only mentioned that he wanted to stop outputting frames. Animations, physics, input, etc should still happen normally.

Re: Flecs – A fast entity component system for C and C++

#14

Post by Cthulhu_ »

korijn wrote: post #2

Any idea what a game loop would look like for an ECS engine that only renders a new frame when some animation is running or when the user is manipulating the camera, but not otherwise? Let's not argue "why". Most obvious would be saving battery.

I'd say this is something that can be done on a driver / GPU level; if the inputs to render the next frame are the same, it can just reuse the previous one.

That's probably oversimplifying it, I don't know anything about graphics programming.

Re: Flecs – A fast entity component system for C and C++

#15

Post by Cthulhu_ »

jiggawatts wrote: post #3
korijn wrote: post #2

Any idea what a game loop would look like for an ECS engine that only renders a new frame when some animation is running or when the user is manipulating the camera, but not otherwise? Let's not argue "why". Most obvious would be saving battery.

I wrote a game engine that did that, because it was for a very simple, largely static scene. You would implement it almost the same as a standard Windows GUI -- using an event handler loop that marks the screen as "dirty" and needing a refresh if it has changed. Where it would immediately break down is ongoing animations. If you stopped moving your mouse, then animations would stop. Of course, you can set up the even…

Some games (I'm thinking FFXIV) will run on a lower framerate (15fps) while minimized or, in that game's case, if the player is idle for an X amount of time, that's a pretty decent compromise.

But yeah, games don't need to render any frames while minimized. I do feel like this should be the operating system's responsibility as well, but then, a lot of games still have the graphics rendering and other parts of the game linked tightly together.

Re: Flecs – A fast entity component system for C and C++

#17

Post by crabmusket »

pavlov wrote: post #8
crabmusket wrote: post #5

Earlier quoted context omitted.

I've implemented exactly this at $WORK. We literally just set a global variable, "should render next frame", from input handlers and other important events. It's not pretty but it gets the job done. There are occasional bugs where someone forgets to set the render flag after some significant event. But the bug goes away as soon as the mouse is moved, so it's usually not a big deal. If we wanted we could also schedule…

> “the bug goes away as soon as the mouse is moved, so it's usually not a big deal” This reminds me of: https://thedailywtf.com/articles/Hidden-Tax-Moves "Wait, let me try," Bruce said, grabbing the mouse. "Whoa, what just happened?" a teammate exclaimed. "What did you do? A ton of traffic just came through!"

Incredible. It's like the opposite of JS logic, where you are encouraged to do as little as possible in event handlers.

Re: Flecs – A fast entity component system for C and C++

#18

Post by fileeditview »

pavlov wrote: post #8
crabmusket wrote: post #5

Earlier quoted context omitted.

I've implemented exactly this at $WORK. We literally just set a global variable, "should render next frame", from input handlers and other important events. It's not pretty but it gets the job done. There are occasional bugs where someone forgets to set the render flag after some significant event. But the bug goes away as soon as the mouse is moved, so it's usually not a big deal. If we wanted we could also schedule…

> “the bug goes away as soon as the mouse is moved, so it's usually not a big deal” This reminds me of: https://thedailywtf.com/articles/Hidden-Tax-Moves "Wait, let me try," Bruce said, grabbing the mouse. "Whoa, what just happened?" a teammate exclaimed. "What did you do? A ton of traffic just came through!"

> After several meetings, it was decided that it wasn't the best idea to put critical code in an app's MouseMove event.

Prove that the story is real ;)

Re: Flecs – A fast entity component system for C and C++

#20

Post by strictfp »

I'm working with an ECS at $dayjob. But I'm starting to question one aspect of them. Composition of functionality makes sense. And systems acting independently and only on objects with related components makes sense.

But dynamically updating the set of components for an entity in order to "send it" to some other system, and relying on the ECS as a query database to coordinate all this, seems like questionable practice to me. I'm seeing more and more of that in our systems.

I think ECSes are becoming too dynamic, and will start to eat perf, and hide relations. Like some message bus.

Anyone else with the same gut feeling?

Post reply on HN