Azul3D - A 3D game engine written in Go!

A 3D game engine written in Go!

Visit azul3d.org for more information.

Update Oct 23, 2021

I spent nearly four (awesome) years building Azul3D. I didn't produce any demos or anything that looked cool, but I learned an immense amount. You can read about my journey here: https://devlog.hexops.com/2021/increasing-my-contribution-to-zig-to-200-a-month

Utlimately, it appeared on Hacker News which at the time I found a bit demoralizing. Development slowed down for various reasons, and I joined a startup (Sourcegraph) for other reasons. I've learned so much about programming, myself, what I want to do in life, business, and so much more since.

Originally, I intended to resume development of Azul3D - but as time went on this seemed less likely. At the same time, I began experimenting with lower level languages such as Rust, a custom language, and Zig - ultimately finding Zig to be an awesome experience and a very natural transition from Go.

If you're a Go developer interested in gamedev, I really think that you will feel at home with Zig and suggest you give it a try.

It's now time for me to put some serious commitment behind something I'm passionate about, game development. I'm doing that in Zig, you can find out more here:

https://devlog.hexops.com/2021/mach-engine-the-future-of-graphics-with-zig

Owner
Azul3D
A 3D game engine written in Go!
Azul3D
Comments
  • Better Package Versioning

    Better Package Versioning

    From @slimsag on September 16, 2014 12:7

    One of the things that really bothers me about Go is it's lack of official package versioning. Today, Azul3D uses a versioning scheme like gopkg.in does -- except on the azul3d.org domain.

    Pros of versioned import paths (in my opinion):

    • Reproducible builds are easier -- but not guaranteed ("The new text renderer has the same API but renders text at half the resolution and now it looks all ugly!" or "I ran into some hidden corner case.").
    • It looks like a correct approach to newcomers.

    Cons of versioned import paths (in my opinion):

    • A lot of cases require bumping the version number (i.e. "I just changed one tiny thing -- and now we must release a new version of the package with just one tiny change") and it looks silly.
    • If new features are added to a package, say foo.v1, if the API is the same it keeps the same version number (v1) -- so, yes, you have to update your v1 package multiple times to get new features which looks silly.
    • Changing import paths is not easy -- but tools do exist to do it for you.

    Other solutions are:

    • Go-Package-Store -- Web GUI that shows available updates to all your packages.
    • godep -- tool to save and restore dependencies from a JSON file for truly reproducible builds.

    I want to better understand how the rest of the Go community feels about this, so I've created a survey we can all fill out to get a better understanding of the most liked solutions tot his.

    Take the survey

    View the results

    Copied from original issue: azul3d/oldissues#25

  • [CLOSED] Missing Encoding support.

    [CLOSED] Missing Encoding support.

    Issue by slimsag Friday Aug 08, 2014 at 20:43 GMT Originally opened as https://github.com/azul3d/audiowav/issues/1


    We should add the ability to encode a wav file.

  • Better Package Versioning

    Better Package Versioning

    From @slimsag on September 16, 2014 12:7

    One of the things that really bothers me about Go is it's lack of official package versioning. Today, Azul3D uses a versioning scheme like gopkg.in does -- except on the azul3d.org domain.

    Pros of versioned import paths (in my opinion):

    • Reproducible builds are easier -- but not guaranteed ("The new text renderer has the same API but renders text at half the resolution and now it looks all ugly!" or "I ran into some hidden corner case.").
    • It looks like a correct approach to newcomers.

    Cons of versioned import paths (in my opinion):

    • A lot of cases require bumping the version number (i.e. "I just changed one tiny thing -- and now we must release a new version of the package with just one tiny change") and it looks silly.
    • If new features are added to a package, say foo.v1, if the API is the same it keeps the same version number (v1) -- so, yes, you have to update your v1 package multiple times to get new features which looks silly.
    • Changing import paths is not easy -- but tools do exist to do it for you.

    Other solutions are:

    • Go-Package-Store -- Web GUI that shows available updates to all your packages.
    • godep -- tool to save and restore dependencies from a JSON file for truly reproducible builds.

    I want to better understand how the rest of the Go community feels about this, so I've created a survey we can all fill out to get a better understanding of the most liked solutions tot his.

    Take the survey

    View the results

    Copied from original issue: azul3d/oldissues#25

  • Use GLFW instead of Chippy

    Use GLFW instead of Chippy

    From @slimsag on August 22, 2014 20:59

    This issue affects #5 since it would provide OS X support.

    Positive Things About GLFW:

    • OS X support
    • Less bugs (not maintained by us).
    • More features being added all the time.
    • Joystick support.

    Negative Things About GLFW:

    • No transparent windows.
    • No automatic rebuild of windows when changing OpenGL framebuffer configurations (pixel formats).
    • github.com/go-gl/glfw3 bindings can only be used from the main thread (can't set window title from seperate goroutine easily, etc).
    • Dynamically linked (place the right file in the right place, build on Windows properly, yuck -- hard for newcomers who just want simple install/build).
    • Callback-based events are ran sequentially from the main thread (a very linear design pattern) versus using channels (not available in C obviously) for events.
    • github.com/go-gl/glfw3 bindings don't use azul3d.org/keyboard.v1 and azul3d.org/mouse.v1, obviously, but where does this put us with cross-platform input (i.e. Android)?

    Ideas:

    • github.com/go-gl/glfw3 needs to keep the GLFW API (including callback event handling, etc).
    • A separate branch of github.com/go-gl/glfw3 with GLFW sources checked-in could provide no dynamic linking, just simple go get (Note the downside: all CMAKE build options are chosen for you).
    • New Package -- either azul3d.org/..... chippy.v2 or glfw.v1 or gfx/system.v1 or gfx/os.v1 or gfx.window.v2 ? Needs careful thought.
    • New Package: just wraps github.com/go-gl/glfw3 and makes it thread-safe -- set window titles, position, etc from different goroutines.
    • New Package: Automagical rebuilding of the GLFW window when e.g. you set window hints, change pixel formats, etc..
    • New Package: Send events over channels instead of using callback functions.
    • New Package: Use keyboard.v1 and mouse.v1 packages (or somehow handle cross-device issues, e.g. Android getting mixed in), some other interface for the window/display itself?

    I'm not settled on doing anything yet. These are just thoughts I've been testing about with and I'm interested in hearing other's thoughts on this.

    @shurcooL may be interested in this?

    Copied from original issue: azul3d/oldissues#18

  • godoc.org not working

    godoc.org not working

    From @slimsag on September 20, 2014 20:32

    I've been meaning to ask @nf if azul3d.org could be removed from the godoc.org / gddo blacklist.

    Originally I posted this in #25, but I am moving it here:

    In March/April Azul3D was completely inside a single Google Code repository, and there was a bug with the server at azul3d.org. It would serve a go-import meta tag for azul3d.org/v0/foobar like this:

    <meta name="go-import" content="azul3d.org/v0/foobar git http://azul3d.org/v0/foobar">
    

    go get would clone http://azul3d.org/v0/foobar into $GOPATH/src/azul3d.org/v0/foobar, but the git repo http://azul3d.org/v0/foobar was actually our entire git repository (also containing a foobar package directory)! gddo would then recursively scan further into that directory. Eventually the machine(s) running gddo ran out of storage space and godoc.org went down for a short period of time.

    There is no fix for gddo in this case because azul3d.org was literally reporting that it was a massive multi-gigabyte repository and there isn't any way that gddo can detect such recursion (because it happened solely at azul3d.org). The only solution for gddo is just to blacklist any massive repository like that.

    FWIW the issue with azul3d.org was fixed back on April 2 and I did inform @nf of it via email, but I guess he never got around to it -- in his defense, I told him not to worry about it in the same email because Azul3D was very immature at the time.

    Copied from original issue: azul3d/oldissues#26

  • Text package

    Text package

    From @1l0 on October 7, 2014 10:46

    A noob question. To show just a rune by keyboard typing, this works fine, gist/rune.go but when I attempt to show runes as text within an object dynamically, this fails, gist/dtext.go this doesn't show appropriate texture for each rune. Perhaps I should prepare specific shader for the mesh and texture array?

    Copied from original issue: azul3d/oldissues#31

  • Tracking all issues

    Tracking all issues

    From @slimsag on September 25, 2014 21:32

    @azul3d

    Since we have so many separate repositories it's a bit hard for people to track all of the issues across them. I've had more than one person mention this to me. A few people have watched each repository, but I imagine it's a bit tedious to do so.

    Does anyone have suggestions?

    Copied from original issue: azul3d/oldissues#28

  • VSync broken in Windows

    VSync broken in Windows

    From @guregu on August 17, 2015 12:55

    Apparently GLFW silently ignored VSync for certain configurations of Windows until recently, and it's now fixed. Could you please upgrade the included version of GLFW? Using the current master branch solved my problems.

    engi for example, has a game loop that depends on glfw's vsync.

    Copied from original issue: azul3d/native-glfw#3

  • Mesh not being updated when data changes in v2-dev

    Mesh not being updated when data changes in v2-dev

    Issue by oal Saturday Jan 03, 2015 at 20:21 GMT Originally opened as https://github.com/azul3d/gfx/issues/88


    When I get an existing mesh like this, and try to change vertices and other attributes, the changes never show up on screen. I can set vertices and make changes before I start rendering anything, but as soon as the render loop starts, no changes are picked up. So it appears that the changed arrays aren't uploaded to the GPU.

        mesh := t.Meshes[0] // has .Dynamic = true
    
        mesh.Vertices = verts
        mesh.VerticesChanged = true
    
        mesh.TexCoords = []gfx.TexCoordSet{
            {
                Slice:   texCoords,
                Changed: true,
            },
        }
    

    Let me know if you need more information.

  • Can't view source through godoc.org

    Can't view source through godoc.org

    From @slimsag on October 8, 2014 20:56

    1. Visit this page.
    2. Notice that you can't click on a package source file.

    In order to fix this:

    • [x] golang/gddo#68 must be fixed first.
    • [x] semver v2 should generate the proper meta tags.

    Copied from original issue: azul3d/oldissues#32

  • Direct users to gotools.org instead of GitHub for viewing source.

    Direct users to gotools.org instead of GitHub for viewing source.

    From @slimsag on January 18, 2015 1:22

    When clicking on a data type, function, etc on an Azul3D package at godoc.org -- we have the ability to send the user to a place for viewing the source code of that symbol.

    Today, we send users to GItHub's source view. gotools.org is much nice and more appropriate as it offers great symbol lookup searching abilities.

    • gotools.org supports symbol names in the URL pattern.
    • godoc.org does not support symbol names in go-source meta tags.

    We currently have no way to connect the two together (without just dumping the user at the top of the gotools.org/azul3d.org/semver.v1 page and having them find the relevant source themselves).

    Copied from original issue: azul3d/oldissues#36

  • Project status

    Project status

    I spent nearly four (awesome) years building Azul3D. I didn't produce any demos or anything that looked cool, but I learned an immense amount. You can read about my journey here: https://devlog.hexops.com/2021/increasing-my-contribution-to-zig-to-200-a-month

    Utlimately, it appeared on Hacker News which at the time I found a bit demoralizing. Development slowed down for various reasons, and I joined a startup (Sourcegraph) for other reasons. I've learned so much about programming, myself, what I want to do in life, business, and so much more since.

    Originally, I intended to resume development of Azul3D - but as time went on this seemed less likely. At the same time, I began experimenting with lower level languages such as Rust, a custom language, and Zig - ultimately finding Zig to be an awesome experience and a very natural transition from Go.

    If you're a Go developer interested in gamedev, I really think that you will feel at home with Zig and suggest you give it a try.

    It's now time for me to put some serious commitment behind something I'm passionate about, game development. I'm doing that in Zig, you can find out more here:

    https://devlog.hexops.com/2021/mach-engine-the-future-of-graphics-with-zig

  • Cannot use dep as vendoring tool

    Cannot use dep as vendoring tool

    $ dep init init failed: unable to solve the dependency graph: Solving failure: No versions of azul3d.org/engine met constraints: master: "azul3d.org/engine/gfx/window" imports "azul3d.org/engine/gfx/gles2", which contains malformed code: no package exists at "azul3d.org/engine/gfx/gles2"

  • Requesting Fullscreen when calling window.Run() fails.

    Requesting Fullscreen when calling window.Run() fails.

    I'm running Ubuntu 17.04 and using the open source radeon driver. Requesting fullscreen when calling window.Run() results in an almost fullscreen, black area. Here's a more verbose code snippet:

    ` func gfxLoop(w window.Window, d gfx.Device) { // Initialization ... // Graphics loop for { ... } }

    func main() { props := window.NewProps() props.SetFullScreen(true) window.Run(gfxLoop, props) } `

    Perhaps fullscreen should be requested after the MainLoop is running? I'm about to try making the window request during the initialization portion of my gfxLoop function. I didn't see anything in the documentation about not being able to make such a request.

    Is there a reason not to try the request when calling window.Run()? If not, I'll just chalk it up to my display driver, or an Ubuntu quirk.

    UPDATE: Making the request from within the gfxLoop function works correctly.

  • engine/gfx/window/glfwgles2.go imports non existent package.

    engine/gfx/window/glfwgles2.go imports non existent package.

    engine/gfx/window/glfwgles2.go imports azul3d.org/engine/gfx/gles2, which doesn't appear to exist anymore, or even ever in this particular repository. As a consequence, this seems to break tools like go's dep and glide. Perhaps I'm missing something.

FlappyCalf - a game powered by Go+ spx game engine
FlappyCalf - a game powered by Go+ spx game engine

FlappyCalf - a game powered by Go+ spx game engine How to run Download Go+ and build it. See https://github.com/goplus/gop#how-to-build. Download this

Nov 6, 2022
FlappyCalf - a game powered by Go+ spx game engine
FlappyCalf - a game powered by Go+ spx game engine

FlappyCalf - a game powered by Go+ spx game engine How to run Download Go+ and build it. See https://github.com/goplus/gop#how-to-build. Download this

Nov 6, 2022
MazePlay - a game powered by Go+ spx game engine
MazePlay - a game powered by Go+ spx game engine

MazePlay - a game powered by Go+ spx game engine How to run Download Go+ and build it. See https://github.com/goplus/gop#how-to-build. Download this g

Dec 16, 2021
Engo is an open-source 2D game engine written in Go.

Engo A cross-platform game engine written in Go following an interpretation of the Entity Component System paradigm. Engo is currently compilable for

Dec 26, 2022
A simple game that I created with Ebiten game library as a way to teach myself Go. Enjoy!
A simple game that I created with Ebiten game library as a way to teach myself Go. Enjoy!

galactic-asteroid-belt Overview A simple game that I created with Ebiten game library as a way to teach myself Go. Enjoy! Run To run, you will need Go

Dec 2, 2021
RundQuiz-Game - This is a Go exercise that implements and builds a quiz game from a list of math questions in a CSV file.

Go RundQuiz Game Exercise details This exercise is broken into two parts to help simplify the process of explaining it as well as to make it easier to

Jan 5, 2022
Simple 2D game to teach myself various things about game development and ECS, etc

2d-grass-game I really don't know what to name this game. Its a big grass field, and its in 2d so....2D Grass game This is a simple 2D game to teach m

Jan 17, 2022
Go 3D Game Engine
Go 3D Game Engine

G3N - Go 3D Game Engine G3N (pronounced "gen") is an OpenGL 3D Game Engine written in Go. It can be used to write cross-platform Go applications that

Jan 9, 2023
Scalable Distributed Game Server Engine with Hot Swapping in Golang
Scalable Distributed Game Server Engine with Hot Swapping in Golang

GoWorld Scalable Distributed Game Server Engine with Hot Reload in Golang Features Architecture Introduction Get GoWorld Manage GoWorld Servers Demos

Dec 25, 2022
A pure Go game engine
A pure Go game engine

Oak A pure Go game engine Table of Contents Installation Motivation Features Support Quick Start Implementation and Examples Finished Games Installati

Jan 8, 2023
Terminal-based game engine for Go, built on top of Termbox
Terminal-based game engine for Go, built on top of Termbox

Termloop Termloop is a pure Go game engine for the terminal, built on top of the excellent Termbox. It provides a simple render loop for building game

Dec 29, 2022
A 2D ARPG game engine.
A 2D ARPG game engine.

Abyss Engine is an ARPG game engine in the same vein of the 2000's games, and supports playing games similar to Diablo 2. The engine is written in golang and is cross platform. This engine does not ship with game specific files, and will require a game's assets in order to run.

Dec 24, 2022
A small fantasy game engine in WASM using GoLang
A small fantasy game engine in WASM using GoLang

The GoLang Fantasy Engine (GoLF Engine) is a retro game engine. It draws inspiration from fantasy console projects like pico-8, tic-80, and pyxle. Like those projects it is designed to be a retro-feeling game creation/playing tool. Unlike those projects GoLF is more minimal in scope and only provides an API and a small set of tools to help you create your games. Tools like an image editor and code editor are not built in. Despite this minimalism creating games in GoLF is still easy and should still maintain the retro game feel.

Jul 16, 2022
golang powered game engine
golang powered game engine

Gobatch Go powered engine that offers features from low level opengl abstraction to UI framework. I created this to separate lot of logic from game am

Nov 13, 2022
spx - A 2D Game Engine for learning Go+
spx - A 2D Game Engine for learning Go+

spx - A 2D Game Engine for learning Go+ Tutorials How to run spx tutorials? Download Go+ and build it. See https://github.com/goplus/gop#how-to-build.

Dec 1, 2022
Go Game Engine using SDL for fun

nMage nMage is a (hopefully!) high performance 3D Game Engine written in Go being developed live, with recordings posted on YouTube. This project is b

Nov 30, 2022
HelloSpx - Hello world of Go+ spx game engine
HelloSpx - Hello world of Go+ spx game engine

HelloSpx - Hello world of Go+ spx game engine How to run Download Go+ and build it. See https://github.com/goplus/gop#how-to-build. Download this game

Nov 27, 2021
HelloWorldForSpx - Hello world of Go+ spx game engine
 HelloWorldForSpx - Hello world of Go+ spx game engine

HelloWorldForSpx - Hello world of Go+ spx game engineHelloWorldForSpx - Hello world of Go+ spx game engine

Nov 22, 2021
The classic game Pong, written in Go
The classic game Pong, written in Go

Pong Pong made in Golang Code is rough and needs to be cleaned up Warning: Many features such as collision detection have been hacked in and should be

Oct 20, 2022