write 2D graphic engine in GO? things like Skia,Cario

[Fino Meng]

is it possible to write 2D graphic engine in GO?  things like Skia,Cario

GO want to replace C++, Skia is written in C++, 

but Skia is compile to .so  file.

I think for graphic libs, C is not very continent.  C++ is too heavy,

GO is designed between C and C++, 

but if we cannot use GO to write low level 2D/3D graphic libs, and GUI widgets,

then GO cannot replace C++, isn't it?

fino/

[Philipp Schumann]

Check out "gocos2d".

[minux]

1. Go doesn't mean to replace C++ (no other language has succeeded in trying to do that:

as C++ still exists in mainstream).

2. Gccgo can generate .so file, and i think whether we have shared library support or not

is not relevant to the question of whether one can write 2D graphics engine in Go.

3. Why you think Go can't be used to write low level 2D/3D graphics libraries or GUI widgets?

It seems you only give one reason (lack of shared library support).

[Archos]

A language with garbage collector is not going to replace to C++. In change, Rust has been disegned to replace C++ and the main motivation on its design was to build a browser engine based in Rust.

In the Rust community there are already several games developers, so you should question in its mailing list.
http://www.rust-lang.org/

Here you have a MP2 decoder which was designed as a demo of the soft real-time capabilities and safety features of Rust:

https://github.com/pcwalton/fempeg

[bryanturley]

On Monday, February 4, 2013 2:39:58 PM UTC-6, Archos wrote:

A language with garbage collector is not going to replace to C++. In change, Rust has been disegned to replace C++ and the main motivation on its design was to build a browser engine based in Rust.

What exactly about a garbage collector is bad for 2d graphics?

Or if we take it from another direction, this http://minecraft.com EXTREMELY popular/successful game runs on top of a garbage collected language (java).
So how does garbage collection prevent this?

In the Rust community there are already several games developers, so you should question in its mailing list.
http://www.rust-lang.org/

Here you have a MP2 decoder which was designed as a demo of the soft real-time capabilities and safety features of Rust:

https://github.com/pcwalton/fempeg

Whats with all the go haters hanging around here?

[bryanturley]

On Monday, February 4, 2013 7:17:47 AM UTC-6, Fino Meng wrote:

is it possible to write 2D graphic engine in GO?  things like Skia,Cario

GO want to replace C++, Skia is written in C++, 

but Skia is compile to .so  file.

I think for graphic libs, C is not very continent.  C++ is too heavy,

Not sure what you mean by continent but the worlds leading graphics library (opengl) is written in C not C++.
I have never used skia but reading about briefly suggests that it can use opengl as a back end.

[Archos]

El lunes, 4 de febrero de 2013 20:54:24 UTC, bryanturley escribió:

On Monday, February 4, 2013 2:39:58 PM UTC-6, Archos wrote:

A language with garbage collector is not going to replace to C++. In change, Rust has been disegned to replace C++ and the main motivation on its design was to build a browser engine based in Rust.

What exactly about a garbage collector is bad for 2d graphics?

Or if we take it from another direction, this http://minecraft.com EXTREMELY popular/successful game runs on top of a garbage collected language (java).

Sure, you can build in Go whatever simple game designed in Java.
But the author is also questioning about low level 2D/3D graphic libs and C++ so my answer is telated to all that.

So how does garbage collection prevent this?

In the Rust community there are already several games developers, so you should question in its mailing list.
http://www.rust-lang.org/

Here you have a MP2 decoder which was designed as a demo of the soft real-time capabilities and safety features of Rust:

https://github.com/pcwalton/fempeg

Whats with all the go haters hanging around here?

To be objective is fundamental to know choose the appropriate technology in each case.

The next one is one of my accounts with open source wich has only Go code and with more than 15 free Go projects. Am I a Go hater or somebody that knows to choose the technology according to the project?
https://github.com/kless

[bryanturley]

You just seem to point people towards rust a lot.
In this case for no reason, since nothing about go stops it from being useful in this use scenario.
Nothing against rust but it already has a mailing list somewhere else.

[Archos]

El lunes, 4 de febrero de 2013 21:17:45 UTC, bryanturley escribió:

On Monday, February 4, 2013 3:08:12 PM UTC-6, Archos wrote:

El lunes, 4 de febrero de 2013 20:54:24 UTC, bryanturley escribió:

Whats with all the go haters hanging around here?

To be objective is fundamental to know choose the appropriate technology in each case.

The next one is one of my accounts with open source wich has only Go code and with more than 15 free Go projects. Am I a Go hater or somebody that knows to choose the technology according to the project?
https://github.com/kless

You just seem to point people towards rust a lot.

I just to explain about be objective.

In this case for no reason, since nothing about go stops it from being useful in this use scenario.

In this case there is reason when OP believes that Go can be used to replace to C++ and since the question is related to game developing, then I can advise about a language suited for such task
 

Nothing against rust but it already has a mailing list somewhere else.

 That is the reason because I said to the OP tthat goes to questioning on its ML.

[bryanturley]

On Monday, February 4, 2013 3:24:40 PM UTC-6, Archos wrote:

El lunes, 4 de febrero de 2013 21:17:45 UTC, bryanturley escribió:

In this case for no reason, since nothing about go stops it from being useful in this use scenario.

In this case there is reason when OP believes that Go can be used to replace to C++ and since the question is related to game developing, then I can advise about a language suited for such task
 

I see go as perfectly viable for 2d/3d libraries and game development right now, and as the compiler/runtime continues to mature it will only get better.
Could you explain why go isn't suited for game developing, with substance?

[Nigel Tao]

On Tue, Feb 5, 2013 at 12:17 AM, Fino Meng <xme...@gmail.com> wrote:
> is it possible to write 2D graphic engine in GO? things like Skia,Cario

Freetype-Go comes with a vector rasterizer. It does cubic Béziers,
similar to Skia or Cairo.

$ go get code.google.com/p/freetype-go/raster
$ go run code.google.com/p/freetype-go/example/raster/main.go
Wrote out.png OK.

[Fino Meng]

sorry I want to mean  convenient,  mainly for GUI/Windows/Widgets, 

just want to have  inside struct method,  then we can use things like  " XXXbuttion.leftclick()"

in C , this is done by function pointers,  which is not that direct u have to find where is the really function in place.

but I didn't see inherit and polymorphic is really needed by GUI/Windows/Widgets design.

[bryanturley]

On Monday, February 4, 2013 7:10:38 PM UTC-6, Fino Meng wrote:

sorry I want to mean  convenient,  mainly for GUI/Windows/Widgets, 

just want to have  inside struct method,  then we can use things like  " XXXbuttion.leftclick()"

in C , this is done by function pointers,  which is not that direct u have to find where is the really function in place.

but I didn't see inherit and polymorphic is really needed by GUI/Windows/Widgets design.

You could use interfaces for the polymorphism and you don't absolutely need inheritance for guis.
 

[Dougx]

There are a few mostly abandoned efforts like:

https://github.com/Urmel/Go2D

https://github.com/runningwild/glop

https://github.com/vova616/GarageEngine

The last of these looks like it's still moderately alive and maybe usable:

http://www.youtube.com/watch?v=iMMbf6SRb9Q

The issue is that most of these rely heavily on C or C++ backends and go bindings, which in itself is fine, but they're usually not portable (or only as portable as the base library).

I know there was some talk on the SDL mailing list a while ago about an SDL binding for go, but I've only seen these ones that are based on SDL 1.2, which you don't want to use:

https://github.com/banthar/Go-SDL

https://github.com/0xe2-0x9a-0x9b/Go-SDL

As for 'purely in go' --> No.

There's not even a proper cross platform GL binding, never mind GLES. If you want to write a game in GO, 

https://github.com/banthar/Go-SDL + https://github.com/banthar/gl Is probably as good as it gets.

...and it's not very cross platform, just as a warning.

"Why should you not use go to write games?"

No reason. ...but if you're just writing a go wrapper around a tonne of C and C++ code, why bother? Just write the whole thing in C++ instead. I'm extremely dubious that keeping two code bases (including go as one) will be more productive that one non-go code base. Perhaps. Depends how much of your logic has to dip down into the C layer. I suspect a lot.

Without a graphics library as part of the core package, I just don't think it's worth it.

~

Doug.

On Tuesday, February 5, 2013 8:34:36 AM UTC+8, dyso...@gmail.com wrote:

I am also interested in game development in Go.
We are already doing games in Lua and Python... so why not? Although the mark-and-sweep garbage collector might be a problem.

I know there are a couple of SDL and Allegro bindings... but is there anything specifically designed for Go ? Any idiomatic frameworks?

[bryanturley]

On Monday, February 4, 2013 8:57:47 PM UTC-6, Dougx wrote:

No reason. ...but if you're just writing a go wrapper around a tonne of C and C++ code, why bother? Just write the whole thing in C++ instead. I'm extremely dubious that keeping two code bases (including go as one) will be more productive that one non-go code base. Perhaps. Depends how much of your logic has to dip down into the C layer. I suspect a lot.

So far from what I can tell you will only need a little cgo for windowing, opengl, audio and input.

 

Without a graphics library as part of the core package, I just don't think it's worth it.

What viable hardware supported graphics libraries exist in reality?
OpenGL - c
Direct3D - c++ (maybe c as well?)
Everything else I can think of is a software renderer or just layers on top of those two.

By your logic you couldn't write a game in anything but c/c++
Yet many people successfully write games in many other languages today.

Games are being sold that run in emulators on all the major home consoles, that has to be the worst possible performance scenario yet they are also successful.
Yes they are generally older, but people are still enjoying them despite their diminished performance.

Most of the code in games is the actual game.
Drawing/audio/input aren't the entire picture.

[Dougx]

Sure.

Virtually every game that is not written in a c based language exists because the "language" layer has a smart wrapper around the core that provides an easy to use API.

Panda3D is python wrapped around c++

Moai, Love, Corona are lua wrappers around c++

Unity is a js/c#/boo wrapper around a c++ core

etc. etc.

If a wrapper like this *already existed* for go, then sure, it'd be a great platform to use.

...but it doesn't. That means you have to *write one* if you want to write a game in go.

I just don't think its a really compelling use case for go at the moment.

~

Doug.

[bryanturley]

On Monday, February 4, 2013 10:10:20 PM UTC-6, Dougx wrote:

Sure.

Virtually every game that is not written in a c based language exists because the "language" layer has a smart wrapper around the core that provides an easy to use API.

Panda3D is python wrapped around c++

Moai, Love, Corona are lua wrappers around c++

Unity is a js/c#/boo wrapper around a c++ core

etc. etc.

If a wrapper like this *already existed* for go, then sure, it'd be a great platform to use.

...but it doesn't. That means you have to *write one* if you want to write a game in go.

I just don't think its a really compelling use case for go at the moment.

~

Doug.

So if your lazy go is not a good language to write games in is what your really saying.
I can see that point of view.

[chris dollin]

On 5 February 2013 05:45, bryanturley <bryan...@gmail.com> wrote:

> So if your lazy go is not a good language to write games in is what your
> really saying.

Not constructive, reads like a personal attack. Please
don't do that.

Chris

--
Chris "allusive" Dollin

[Gerard]

sorry I want to mean  convenient,  mainly for GUI/Windows/Widgets, 

For the GUI part, you can take a look at https://github.com/mattn/go-gtk. It's a quite impressive GTK+ wrapper.

 

 

[Ethan Burns]

Hi Fino,

I maintain a plotting library for Go called Plotinum (code.google.com/p/plotinum); it includes a fairly small vector graphics package named vg.  Vg is really just an interface that sits on top of svgo for SVGs, draw2d for PNG and other raster images, gopdf for PDFs, and a custom encapsulated Postscript generator.  For a GUI toolkit, you probably want OpenGL support.  Currently, vg does not support OpenGL, but an OpenGL back-end could probably be added fairly easily.

Best,

Ethan

[ajstarks]

Here is a high-level 2D library built on OpenVG for the Raspberry Pi:

http://github.com/ajstarks/openvg

http://godoc.org/github.com/ajstarks/openvg

http://www.flickr.com/photos/ajstarks/sets/72157630913689774/

http://mindchunk.blogspot.com/2012/09/openvg-on-raspberry-pi.html

On Monday, February 4, 2013 8:17:47 AM UTC-5, Fino Meng wrote:

[Glenn Brown]

> https://github.com/banthar/Go-SDL + https://github.com/banthar/gl Is probably as good as it gets.
>
> ...and it's not very cross platform, just as a warning.

I've had great luck with https://github.com/banthar/gl , but Go-SDL is broken on many architectures, including MacOSX. The problem is that SDL provides its own main() function in the library on many architectures, which is *ridiculous* interface design. In theory, Go-SDL might be able to work around this, although it shouldn't have to. Consequently, Go-SDL works only on Linux, AFAIK.

--Glenn

[Job van der Zwan]

On Tuesday, 5 February 2013 14:14:34 UTC+1, ajstarks wrote:

Here is a high-level 2D library built on OpenVG for the Raspberry Pi:

http://github.com/ajstarks/openvg

http://godoc.org/github.com/ajstarks/openvg

http://www.flickr.com/photos/ajstarks/sets/72157630913689774/

http://mindchunk.blogspot.com/2012/09/openvg-on-raspberry-pi.html

 

Cool, did you announce that last year? Must have missed it...

BTW, and a bit offtopic: what are your thoughts on this development in hardware accelerated vector graphics?

https://developer.nvidia.com/gpu-accelerated-path-rendering

I think it's pretty exciting -  it's kinda weird that hardware support for 2D graphics seems to lag behind support for 3D graphics.

[bryanturley]

3D hardware can be used for 2D, it is just not as hyped as 3D.
People just normally do the 2D stuff on the main cpu to make it more portable, and in the past to not tie up video device resources.

[Erwin]

I've had great luck with https://github.com/banthar/gl , but Go-SDL is broken on many architectures, including MacOSX.  The problem is that SDL provides its own main() function in the library on many architectures, which is *ridiculous* interface design.  In theory, Go-SDL might be able to work around this, although it shouldn't have to.  Consequently, Go-SDL works only on Linux, AFAIK.

Go-SDL works fine on OS X as well, and so it does on Windows, i believe.

 

[Job van der Zwan]

On Tuesday, 5 February 2013 19:32:27 UTC+1, bryanturley wrote:

3D hardware can be used for 2D, it is just not as hyped as 3D.
People just normally do the 2D stuff on the main cpu to make it more portable, and in the past to not tie up video device resources.

If I understood the presentation by NVidia correctly, the current solutions - including hardware acceleration - have a lot of room for improvement, both in terms of performance and in graphical fidelity (an example being conflating coverage - bad seams). From the FAQ[1]:

If you play with the nvpr_svg example in the NVprDEMOs.zip, you’ll find that  NV_path_rendering is typically many times (in a few cases even 100x faster) than other well-known path renderers.  This includes even includes Direct2D. 

[1] http://developer.download.nvidia.com/assets/gamedev/files/NV_path_rendering_FAQ.pdf (second-to-last page)

[bryanturley]

These graphics devices used to have a lot of fixed functionality back in the 90s early 2000s, if you strayed from this fixed functionality you had to use the main cpu instead.
Now they are mostly just a whole bunch of almost general purpose FPUs and memory controllers, with a few exceptions (2d/3d texturing hardware is the only thing  that comes to mind).
They didn't have to change the hardware to implement it, they probably just wrote a few shaders and execute them through the api behind the scenes.
Something they couldn't have done say <= ~2004* on mainstream hardware.

* I can't remember when opengl shaders hit the almost general purpose level.

[Job van der Zwan]

On Tuesday, 5 February 2013 21:44:46 UTC+1, bryanturley wrote:

These graphics devices used to have a lot of fixed functionality back in the 90s early 2000s, if you strayed from this fixed functionality you had to use the main cpu instead.

Now they are mostly just a whole bunch of almost general purpose FPUs and memory controllers, with a few exceptions (2d/3d texturing hardware is the only thing  that comes to mind).
They didn't have to change the hardware to implement it, they probably just wrote a few shaders and execute them through the api behind the scenes.
Something they couldn't have done say <= ~2004* on mainstream hardware.

* I can't remember when opengl shaders hit the almost general purpose level.

 

Well, it's not 'just a few shaders', they've implemented all standards for path rendering in a new OpenGL extension now retro-actively supported on any CUDA-capable NVIDIA hardware. The point about programmability of GPUs still stands of course.

Point is: if this is something that now works for NVIDIA cards from all the way back to 2006, it's kind of disappointing that it took this long to be implemented, don't you think? Especially since most computers spend more of the time rendering 2D graphics than 3D. 

But this is getting awfully off-topic.

[Sean Russell]

On Tuesday, February 5, 2013 7:40:52 AM UTC-5, Ethan Burns wrote:

I maintain a plotting library for Go called Plotinum (code.google.com/p/plotinum); it includes a fairly small vector graphics package named vg.  Vg is really just an interface that sits on top of svgo for SVGs, draw2d for PNG and other raster images, gopdf for PDFs, and a custom encapsulated Postscript generator.  For a GUI toolkit, you probably want OpenGL support.  Currently, vg does not support OpenGL, but an OpenGL back-end could probably be added fairly easily.

And thanks for that, by the way.  Plotinum is one of my go-to libraries.

--- SER 

[Fino Meng]

thanks for kind reply,

I hope I can find time to study the  code in this month:)

Fino/

[Fino Meng]

thanks, I will try it later,

but I want to know more if GO is suitable for write level graphic lib,  lib below GTK+, just above Linux driver (direct FB....)

it's job mostly done by C/C++ today.

the purpose to find new language to replace C++ is, C++ is difficult to learn, and I need productive language than C,

the lib may not run on normal linux, but very custom and modified kernel,  for  embedded system.

Fino/

[Fino Meng]

thanks for kind reply,

I want to find language more productive than C ,  easy to understand than C++, 

compiled, can do level graphic lib and make embedded system only contains C and this language,

maybe Object-C likes very fit :)

Fino/