It would be nice if users had the possibility to add their own filetype / extension / loader method to our asset loader.

To be complete, we would then use that method ourselves.

Thinking of a generic interface, let's brainstorm.

type FileLoader interface {
    // Extensions returns the file extensions for which this FileLoader should be used, excluding the '.' in front of it
    Extensions() []string

    // Load is called with the url (location) of the file, and is called whenever the file must be loaded
    Load(url string) error

    // Unload is called with the url (location) of the file, and is called whenever the resources of the file should be freed from the memory
    Unload(url string) error
}

There'd also have to be a generic method of retrieving the actual resource? Or not? Kinda like our engo.Files.Image("url") returns an actual (loaded) image.

Thoughts? Improvements? Changes? Always welcome.

As Go is such a nice language to do multithreading in, and most games lack multithreading, it'd be nice if we supported it.

Currently, each frame, we are iterating over all Systems, and iterating over all Entitys "in" those Systems.

I'm not sure if we can safely multithread multiple Systems at once, but we could easily multithread the iteration over Entitys?

Current implementation

    for _, system := range w.Systems() {
        if headless && system.SkipOnHeadless() {
            continue // so skip it
        }

        system.Pre()
        for _, entity := range system.Entities() {
            if w.paused {
                ok := entity.GetComponent(&unp)
                if !ok {
                    continue // so skip it
                }
            }
            if entity.Exists {
                system.Update(entity, dt)
            }
        }
        system.Post()
    }

Proposed implementation

    for _, system := range w.Systems() {
        if headless && system.SkipOnHeadless() {
            continue // so skip it
        }

        entities := system.Entities()

        system.Pre()

        // It's not always faster to multithread; so in this case we're not going to
        if len(entities) < 2*runtime.NumCPU() {
            for _, ent := range entities {
                system.Update(ent, dt)
            }
            system.Post()
            continue // with other Systems
        }

        entityChannel := make(chan *Entity)
        wg := sync.WaitGroup{}

        // Launch workers
        for i := 0; i < runtime.NumCPU(); i++ {
            go func() {
                for ent := range entityChannel {
                    system.Update(ent, dt)
                    wg.Done()
                }
            }()
        }

        // Give them something to do
        for _, entity := range entities {
            if w.paused {
                ok := entity.GetComponent(&unp)
                if !ok {
                    continue // so skip it
                }
            }
            if entity.Exists {
                wg.Add(1)
                entityChannel <- entity
            }
        }

        // Wait until they're done, before continuing to other Systems
        wg.Wait()
        close(entityChannel)

        system.Post()
    }

I know it's a bit more code than the original implementation, but it sure is efficient.

Hi there,

this is a PR (based on other ones) that adds rotation support for Engi.

The rotation is implemented in the default shader. I'd like the changes I introduced in the shader interface.It may be possible to avoid this by passing the space width and height in the gl buffer.

This crashes as soon as I launch the example with the following traceback:

fatal error: unexpected signal during runtime execution
[signal 0xb code=0x1 addr=0x0 pc=0x7f90bf226ff0]

runtime stack:
runtime.throw(0x7bac40, 0x2a)
    /home/faide/tools/go/src/runtime/panic.go:527 +0x90
runtime.sigpanic()
    /home/faide/tools/go/src/runtime/sigpanic_unix.go:12 +0x5a

goroutine 1 [syscall, locked to thread]:
runtime.cgocall(0x60d8e0, 0xc8200c7ad0, 0x0)
    /home/faide/tools/go/src/runtime/cgocall.go:120 +0x11b fp=0xc8200c7a88 sp=0xc8200c7a58
github.com/go-gl/gl/v2.1/gl._Cfunc_glowDrawElements(0x7f90bef73760, 0x600000004, 0x1403, 0x0)
    github.com/go-gl/gl/v2.1/gl/_obj/_cgo_gotypes.go:12227 +0x35 fp=0xc8200c7ad0 sp=0xc8200c7a88
github.com/go-gl/gl/v2.1/gl.DrawElements(0x600000004, 0xc800001403, 0x0)
    /home/faide/go/src/github.com/go-gl/gl/v2.1/gl/package.go:19385 +0x45 fp=0xc8200c7af8 sp=0xc8200c7ad0
github.com/paked/webgl.(*Context).DrawElements(0xc8200f6000, 0x4, 0x6, 0x1403, 0x0)
    /home/faide/go/src/github.com/paked/webgl/webgl_gl2.go:775 +0x42 fp=0xc8200c7b18 sp=0xc8200c7af8
github.com/paked/engi.(*HUDShader).flush(0xc8200be000)
    /home/faide/go/src/github.com/paked/engi/shaders.go:289 +0x168 fp=0xc8200c7b58 sp=0xc8200c7b18
github.com/paked/engi.(*HUDShader).Post(0xc8200be000)
    /home/faide/go/src/github.com/paked/engi/shaders.go:294 +0x21 fp=0xc8200c7b68 sp=0xc8200c7b58
github.com/paked/engi.(*RenderSystem).Post(0xc82000e420)
    /home/faide/go/src/github.com/paked/engi/render.go:291 +0xce fp=0xc8200c7ca0 sp=0xc8200c7b68
github.com/paked/engi/ecs.(*World).Update(0xc820014720, 0x0)
    /home/faide/go/src/github.com/paked/engi/ecs/world.go:121 +0x2d5 fp=0xc8200c7d90 sp=0xc8200c7ca0
github.com/paked/engi.RunIteration()
    /home/faide/go/src/github.com/paked/engi/engi_glfw.go:194 +0x53 fp=0xc8200c7da8 sp=0xc8200c7d90
github.com/paked/engi.runLoop(0x7f90bc69f360, 0xc6fb60, 0x400)
    /home/faide/go/src/github.com/paked/engi/engi_glfw.go:226 +0xd9 fp=0xc8200c7e70 sp=0xc8200c7da8
github.com/paked/engi.Open(0x0, 0x71d4b0, 0x8, 0x0, 0x400, 0x280, 0x0, 0x0, 0x7f90bc69f360, 0xc6fb60)
    /home/faide/go/src/github.com/paked/engi/engi.go:68 +0xf4 fp=0xc8200c7ea0 sp=0xc8200c7e70
main.main()
    /home/faide/go/src/github.com/paked/engi/demos/hud/hud.go:108 +0xab fp=0xc8200c7f50 sp=0xc8200c7ea0
runtime.main()
    /home/faide/tools/go/src/runtime/proc.go:111 +0x2b0 fp=0xc8200c7fa0 sp=0xc8200c7f50
runtime.goexit()
    /home/faide/tools/go/src/runtime/asm_amd64.s:1721 +0x1 fp=0xc8200c7fa8 sp=0xc8200c7fa0

goroutine 17 [syscall, locked to thread]:
runtime.goexit()
    /home/faide/tools/go/src/runtime/asm_amd64.s:1721 +0x1

if I suppress the call to w.AddEntity(hudBg) it works so I suspect something in generateHUDBackground but I can't see what really differs from generateBackground which works fine.

In engi.go, two variables are globally defined:

var (
    responder   Responder
    Wo          Responder
)

They have exactly the same value, and are used for exactly the same. Which one are we keeping?

Side-node, if it's a Responder (and not a World), should we even call it Wo? It took me a while before I noticed why Wo didn't have the functions / variables available that World has.

Fixes #119

Breaking change

Things like

type MyCustomSystem struct {
    *ecs.System
}

have become

type MyCustomSystem struct {
    *ecs.BasicSystemWrapper
}

Things like

func (m *MyCustomSystem) New(*ecs.World) {
    m.System = ecs.NewSystem()
}

have become

func (m *MyCustomSystem) New(*ecs.World) {
    m.BasicSystemWrapper = ecs.NewBasicSystemWrapper(m)
}

Things like

func (*MyCustomSystem) Update(*ecs.Entity, float32) {}

have become

func (*MyCustomSystem) EUpdate(*ecs.Entity, float32) {}

New features

A valid System (which you can add to a World instance), is this:

type MyCustomSystem struct {}
func (*MyCustomSystem) Type() string { return "MyCustomSystem" }
func (*MyCustomSystem) Priority() int { return 1 }
func (*MyCustomSystem) AddEntity(*ecs.Entity) {}
func (*MyCustomSystem) RemoveEntity(*ecs.Entity) {}
func (*MyCustomSystem) New(*ecs.World) {}
func (*MyCustomSystem) Update(dt float32) {}

One can still use the 'old' behavior which does the looping-over-entities for you, this can be done like:

type MyCustomSys struct {
    *ecs.BasicSystemWrapper
}
func (*MyCustomSys) Type() string { return "MyCustomSys" }
func (*MyCustomSys) Pre() {}
func (*MyCustomSys) Post() {}
func (m *MyCustomSys) New(*ecs.World) {
    m.BasicSystemWrapper = ecs.NewBasicSystemWrapper(m)
}
func (*MyCustomSys) EUpdate(*ecs.Entity, float32) {}

How should clicks be handled according to the ECS?

In javascript/html, there's some kind of propagation: the foremost element is clicked, then passed along to any other element that may have been involved ; and each time the element has the ability to stop the propagation.

In ECS, I would assume there is some kind of System that monitors whether or not something gets clicked?

Any best-practices here? Anything I misunderstood? (I imagine the "buttons" in the "main menu" I'm creating, to be some kind of clickable)

Current status

• [ ] Rightclick-handling

As of this moment, each key is under the same general namespace. So if you want the w key, you would get engo.W.

My proposition: Namespace so we could get it with engo.Keys.W. This way we wouldn't "dirty" the general namespace and it would be easier with an IDE for example to understand what that engo.W means.

From gitter:

@paked 09:15 Thoughts on removing ECS from our branding? @paked 09:16 I have a theory some people are intimidated by the idea of "using ECS"

Thoughts everyone?

Basically I'd like to make us a "game engine", not an "ECS game engine" - even though we will still use ECS under the hood, and the users will still interact with it.

I'm new to go (learning by making a game with engo) so it may be a misunderstanding on my part.

$ sudo apt-get install libopenal-dev libglu1-mesa-dev freeglut3-dev mesa-common-dev xorg-dev libgl1-mesa-dev golang gccgo-go
$ go get -u engo.io/engo
# github.com/go-gl/mathgl/mgl32
../go/src/github.com/go-gl/mathgl/mgl32/mempool.go:12: undefined: sync.Pool
../go/src/github.com/go-gl/mathgl/mgl32/mempool.go:29: undefined: sync.Pool
../go/src/github.com/go-gl/mathgl/mgl32/mempool.go:41: undefined: sync.Pool
# github.com/luxengine/math
../go/src/github.com/luxengine/math/sqrt_amd64.s:6 6a: No such file or directory: textflag.h
# golang.org/x/mobile/internal/mobileinit
../go/src/golang.org/x/mobile/internal/mobileinit/ctx_android.go:8:17: fatal error: jni.h: No such file or directory
 #include <jni.h>
                 ^
compilation terminated.

I am running Linux Mint 17.2, if it helps.

I installed the dependencies with the command sudo apt-get install libopenal-dev libglu1-mesa-dev freeglut3-dev mesa-common-dev xorg-dev libgl1-mesa-dev

Then I used the command go get -u github.com/engoengine/engo to get the library.

I made a new file ~/test.go to try the Getting Started example, and I pasted the contents into the file.

When I ran go run test.go I got the following error message:

test.go:4:5: cannot find package "github.com/EngoEngine/ecs" in any of:
    /home/ryan/bin/go/src/github.com/EngoEngine/ecs (from $GOROOT)
    /home/ryan/go_workspace/src/github.com/EngoEngine/ecs (from $GOPATH)
test.go:5:9: cannot find package "github.com/EngoEngine/engo" in any of:
    /home/ryan/bin/go/src/github.com/EngoEngine/engo (from $GOROOT)
    /home/ryan/go_workspace/src/github.com/EngoEngine/engo (from $GOPATH)

I checked, and the path /home/ryan/go_workspace/src/github.com/engoengine/engo exists. Is there a case sensitivity issue or is there another problem? If it's case sensitive how would I fix it?

Thanks!

Hello, I was wondering if there was an equivalent to the ebiten example that draws on a transparent window giving the effect of drawing upon the desktop? The relevant relevant code they have is in their mascot example:

$ go run -tags=example github.com/hajimehoshi/ebiten/v2/examples/mascot@latest

I tried setting my canvas background color but this doesn't seem to be enough, because the background still shows up as black.

common.SetBackground(color.Transparent)

Is there a way to manage the window's settings/configuration to do the same thing? Is there a way to signal this to the glfw library underneath?

I build this map with Tiled and imported into the adventure demo and somehow it mixes up some of the assets. It looks fine in the editor. Do you have any advice, or could this be a bug?

In-Game render: Tiled Map Editor:

Those are the assets I tried out: https://opengameart.org/content/whispers-of-avalon-grassland-tileset

WSL's latest update includes monitor/window support. I'd like to test it out to and see if it's a viable alternative to MySys/Cygwin for building on windows yet.

When isometric tiles of different sizes are used, Tiled arranges them such that the tile lines up with the bottom-most point of the grid, and allows the tiles to overflow. Update the isometric demo to account for that.

I tried to build my project with the headless tag, but got the following error: github.com/!engo!engine/[email protected]/engo_empty.go:79:4: fallthrough statement out of place