Thinking about the roadmap 2021 autumn and future

[hajimehoshi]

EDIT: Here is the 2023 version: #2721

These are the big items I want to implement. I have not prioritize these yet.

GUI

IME Inputting

#286 #1029

Input

Handling inputting as event handlers

#926, #1704, #1778

Now Ebiten cannot detect finer inputs than TPS. What about redesigning the Game interface like this?

type Game interface {
    HandleInput(input Input) // Input is a new interface
    Update() error
    Draw(screen *ebiten.Image)
    Layout(width, height int) (int, int)
}

Graphics library

DirectX on Windows

#1007 (EDIT 2022-03-30: Done)

Vulkan on Android

#389

WebGPU on browsers

#719

Rewriting GLFW in Go

#1764 (EDIT 2022-05-20: Done)

Rich vector graphics API

Line

#1843

Anti-alias

#1845 #2385

Streaming game

#353, #1278

[TheMightyGit]

I'd love Vulkan for Linux and Windows to be on the roadmap (but this can be after Android). Especially as the Raspberry Pi 4/400 now has Vulkan support (the current GL impl on Pi is known slow, hence all the work on Vulkan for it). My ebiten stuff can struggle on RPi, especially full-screen even without much going on.

[hajimehoshi]

BTW, on Raspberry Pi, can dispman work instead of GLFW?

[TheMightyGit]

Event based input faster than TPS would be great. In the fantasy console I'm making it would make my input handling code much cleaner and hopefully remove the sluggish feeling when typing fast.

[tinne26]

Maybe you find #2053 relevant.

[bglogic]

Looks like SDL2 might save you some time

• No need to maintain workarounds for cases that SDL2 already cover (e.g. Controller vibrations (c-backend, js) #1452, mobile: Support gamepads on iOS #1105, Is there a general API to get gamepad identifers?: Gamepad GUID is not general #1048, etc.)
• You get OpenGL/Direct3D/Metal/Vulkan
• No need to rewrite GLFW in Go

[bglogic]

I know and it's awesome how you did go->wasm->go2cpp :)

I meant as the tooling matures over time and it might be possible to compile natively rather than using a custom wasm interpreter then you can use SDL for the console rather than maintaining your own console sdk bindings. The wasm approach is great because it provides a good solution for now but on the long run it's slower and single threaded.

[hajimehoshi]

I meant as the tooling matures over time and it might be possible to compile natively rather than using a custom wasm interpreter then you can use SDL for the console rather than maintaining your own console sdk bindings. The wasm approach is great because it provides a good solution for now but on the long run it's slower and single threaded.

Native compiling for Nintendo Switch was already succeeded (w/o SDL), and games actually worked.

https://zenn.dev/hajimehoshi/articles/72f027db464280

I'm now translating this article into English. Stay tuned!

[bglogic]

That's great news!

[hajimehoshi]

https://ebiten.org/blog/native_compiling_for_nintendo_switch.html Here you are

[bglogic]

Thank you! Very educational and a great read 👍

[hajimehoshi]

I'll brush the list up later for 2023 Autumn, but the current situation is as the following:

• IME Inputting: I'm working on this. For v2.6, I plan to support Windows, macOS, and browsers.
• Handling inputting as event handlers: I'm not working this yet, but I would like to work on this for v2.6 or later.
• DirectX on Windows: Done
• Vulkan on Android: Not yet
• WebGPU on browsers: Not yet
• Rewriting GLFW in Go: Done for Windows. Not yet for macOS and Linux.
• Rich vector graphics API: Done
• Streaming game: Cancelled