-
Notifications
You must be signed in to change notification settings - Fork 45
Closed
Description
So, I was told by some people at the slack-chat, that we aren't using idiomatic Go. There may be collisions between the Type() string methods, and we're wasting performance by doing constant lookups.
They said: why don't you use reflect? Well, reflect is horrible so I don't want to use it.
But the idea is simple: get rid of the global []Entity, which stores every Entity. Instead, add the user-made entities to the appropriate systems,
Usage would be something like:
type MyEntity struct {
BasicEntity
SpaceComponent
RenderComponent
}
func main() {
// There'd be some kind of global list of systems, which contain every system, so we can loop over them
var systems []BasicSystem
// Each system we create, we add to that global list of systems
RS := &RenderSystem{}
systems = append(systems, RS)
// Then we can define initialize our own custom-made entity struct
e := &MyEntity{}
// Add the appropriate component-references to the RenderSystem - this way you know for sure which components the render-systems requires
RS.Add(&e.BasicEntity, &e.SpaceComponent, &e.RenderComponent)
// And now we loop
for _, sys := range systems {
sys.Update(0.25)
}
}Upsides;
- It's blazing-fast. The current
Componentfunction takes 91ns per lookup, theComponentFastabout 18ns, and this approach takes 0ns. For something that might happen thousands / millions of times a second, this is nice. - It's idiomatic Go, in the sense that it uses Go's type-safety. If it compiles, it'll most-likely run.
Downsides:
- You need a reference to each system you want to use. Where to keep those references? What if we changed
Scenes? They would have to start using other references. - It would break everything
This change is huge, but might also be worth it. I'd love a discussion on this, and maybe a fix for the downside? @paked, @everyone?
Metadata
Metadata
Assignees
Labels
No labels