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
Component function takes 91ns per lookup, the ComponentFast about 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?
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() stringmethods, and we're wasting performance by doing constant lookups.They said: why don't you use
reflect? Well,reflectis horrible so I don't want to use it.But the idea is simple: get rid of the global
[]Entity, which stores everyEntity. Instead, add the user-made entities to the appropriate systems,Usage would be something like:
Upsides;
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.Downsides:
Scenes? They would have to start using other references.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?