Good job~ And the next version's Go will support developing games on android
There are zero plans from the Android team to support Go today.
31–40 of 46 posts
Good job~ And the next version's Go will support developing games on android
There are zero plans from the Android team to support Go today.
Earlier quoted context omitted.
Nobody said anything about obsessing. When you write code you need to care about your allocations, whether you have a GC or not. When you write code without a GC you need to be mindful of freeing memory. With a GC you do not. So the GC relieves part of the burden of memory management, and that part is often the hardest part (particularly in concurrent systems).
This is not neccessarily true, e. g. in Rust you have code without GC, but the compiler makes sure that everything is freed.
Garbage collector FAQ isn't necessarily reassuring, since it seems to say "go through the same hoops other GC gaming platforms push you through". Obligatory Rust gaming comment goes here.
- no generics? You don't really need it.
- no operator overload? You are doin' it wrong.
- GC pauses are annoying? Man up and reconsider what you do.
Earlier quoted context omitted.
This is not neccessarily true, e. g. in Rust you have code without GC, but the compiler makes sure that everything is freed.
If that is true, what's the trade-off? There are no silver-bullets so if their approach didn't involve some potential "deal-breakers" Go team (or the ecosystem) would probably have offered a Go clone of it. Would be curious what they're doing there in Rustland..
The web site looks cool, but it sets off a whole bunch of red flags for me. First of all it doesn't seem to be a game engine. Instead it's a 3d engine and some other libraries suitable for games packaged together. A game engine drives game logic, that's not what this does. Second, there's no demos of games at all, if I dive into their github account I find some super trivial 3d scene demo's, no games. Third, no asset…
Wikipedia at least, defines a game engine to be "a software framework designed for the creation and development of video games" and goes on to say "The core functionality typically provided by a game engine includes a rendering engine (“renderer”) for 2D or 3D graphics, a physics engine or collision detection (and collision response), sound, scripting, animation, artificial intelligence, networking, streaming, memory management, threading, localization support, and a scene graph.".
Azul3D has a rendering engine, and a soon-to-be-released 3D audio engine. Go provides networking, streaming, memory management, threading, and a few Go packages provide localization support. Azul3D also provides 2D physics (through Chipmunk 2D), with 3D physics (provided by Bullet) coming soon. Arguably scripting is not needed, Go has very "scripting-language" like syntax. But you could use the various Go bindings for scripting languages out there today (Lua, Python, etc). Azul3D doesn't have any support for animation yet -- but in the near future it will receive a Blender model loader with support for 3D animated models. AI and scene graph libraries will surely be developed over time. I agree that the engine isn't ready for serious 3D games yet, more work still needs to be done for that to happen as I've already stated. Perhaps right now it just looks like a graphics engine -- but in the future it will get better I promise.
Yes, there aren't any game demos yet. These things take time. Do note that Go's image package allows decoding png/jpeg/gif images (and probably others, as well). Loading 3D models is coming soon.
Concurrency could be incredibly useful in games -- I'm a bit shocked that you'd say otherwise. Imagine having a single goroutine perform decisive actions for an in-game NPC etc. With Go you can literally have thousands of goroutines running at the same time (like coroutines -- only better).
I enjoy the criticism nonetheless, it lets me know where I am and where I need to be. Thank you.
"No, and it likely never will. Azul3D is for programmers and doesn't provide GUI-editors." So, you write your levels using a text editor? That's not for programmers, that's for people who hate themselves.
There is a blender model loader coming soon, that will help with level creation. It will provide very in-depth integration with the Blender suite.
Earlier quoted context omitted.
It's a framework, not a game. This is a rabbithole many devs fall into--and I've been there myself.
But there must be examples. I doubt they are just developing a framework without having any example demo apps where they test and use the framework. And hopefully, there is also at least one serious game using this framework, otherwise it's doubt-able whether this framework is useful in practice.
https://github.com/azul3d/examples
But there aren't any screenshots. I know of at least two others (than myself) writing serious games with Azul3D, but none have released any screenshots or demos yet.
What's with the package versioning? http://azul3d.org/doc/versioning.html#development-versions v1 (latest version) import "azul3d.org/audio.v1" v0 (in development) import "azul3d.org/audio.v0" Is this normal for go packages?
That's one way of doing it. Another is to just use their github path and use vendoring tools like godep. I prefer vendoring since it doesn't rely on a 3rd party being online or existing in a year. Also it's simpler when you want to have repeatable builds, since the vendored code is usually in your repo. It's also convenient for CI/CD things, since your repo ships as a unique component. Also using versioned path like…
this caught my eye a few months ago when I decided to learn some opengl/gamedev. Started working with it but abandoned it when I realized that opengl 2 is decade old. Other then that it seemed a rather nice set of tools for my inexperienced eye
OpenGL 2.x as base feature level is still a decent choice if you want to be truly multi-platform (e.g. also cover mobile devices). You can still get modern GL features with OpenGL 2.x selectively by using extensions if present. The only things that newer GL versions offer over extensions is a guaranteed support for certain feature sets (similar to Direct3D versions).
Although the renderer is GL 2.X based -- it supports OpenGL 3+ features using extensions. It was written against OpenGL 2.X so that the lowest OpenGL 3 hardware could be targeted.
The web site looks cool, but it sets off a whole bunch of red flags for me. First of all it doesn't seem to be a game engine. Instead it's a 3d engine and some other libraries suitable for games packaged together. A game engine drives game logic, that's not what this does. Second, there's no demos of games at all, if I dive into their github account I find some super trivial 3d scene demo's, no games. Third, no asset…
Full disclosure: I am the creator of the project. Wikipedia at least, defines a game engine to be "a software framework designed for the creation and development of video games" and goes on to say "The core functionality typically provided by a game engine includes a rendering engine (“renderer”) for 2D or 3D graphics, a physics engine or collision detection (and collision response), sound, scripting, animation, arti…
I've been coding Go for some 2 years and I can tell you it does not magically provide your machine with thousands of extra cores so "at the SAME time" is precisely speaking exactly inaccurate. I love coroutines but they're still multi-plexed onto OS threads and they don't all run as massively parallel as you suggested.