Go binding for SFML

[Groogy]

rbSFML using SWIG ?

No

Sorry for late answer but no I don't, I have written the binding manually. Using SWIG would easy on the process but the library would become very un-ruby-like. Hard to explain but Ruby is thought of being used in a certain way and if I would just do a a straight port, it wouldn't fit in with how you would work normally in the language. Good example is how events are processed using rbSFML.

I also do it directly against the C++ version of SFML and do not go trough the C binding instead. The reason behind this is because I can give Ruby more stuff from the actual library like proper inheritance and custom drawable. Though if I would have gone with the C binding of SFML I could have written entire rbSFML in Ruby but it would be VERY slow because Ruby DL module would have to translate objects and values between Ruby and C all the time.

[gyscos]

I have one remark for now : the use of pointer or value in functions is not always coherent (or I miss the logic) : sf.NewViewFromRect takes a *sf.FloatRect, but View.SetViewport, as well as many other methods, take a sf.FloatRect...

EDIT : getris completed, time to try some real stuff...

[daemon]

Yes I guess you could consider this as a bug as passing nil would simply lead to a crash. In general: If you can pass a pointer then using nil is perfectly valid. Thank you for pointing this out though. Also keep in mind that there are other standing problems like the need of runtime.LockOsThread() and GC.

[gyscos]

Yeah, I noticed the LockOsThread in the examples, but didn't add it in my app, and it hasn't crashed yet.
Although I noticed after some time the texture used for the blocks just turned to blank - maybe the GC ?...

[daemon]

No, Sprite keeps an internal reference its texture to make sure that it doesn't get removed. Without LockOsThread your application won't run properly as OpenGL doesn't support calls comming from a thread other than the one it was created in (afaik). So maybe you could try if that solves your problem  .

[Laurent]

OpenGL doesn't support calls comming from a thread other than the one it was created in

You can call OpenGL functions in any thread, as long as you have an active context. A context cannot be active in more than one thread at a time.

[gyscos]

One bug found : you renamed Rect{f,i} to {Float,Int}Rect as in SFML, but struct_test.go still uses the old version.
Added an issue at bitbucket.

Also, I created a package for Archlinux to ease installation :
https://aur.archlinux.org/packages/go-sfml2/
Just tell me if if it's a problem.

I added a temporary fix for structs_test.go.
Also, you might want to think about licensing it. If you don't really care, BSD or ZLIB licenses are a good start.

[shoulder_rats]

Hi Guys,

Thanks for making the Go wrapper.

I'm getting this error when I try to build the gosfml2 wrapper in Windows:

C:\Go\src\pkg\gosfml2>go build
# gosfml2
circleShape.go:15:39: fatal error: SFML/Graphics/CircleShape.h: No such file or directory compilation terminated.

I found in CircleShape.go that it is searching here:
// #include "SFML/Graphics/CircleShape.h"

I've even tried hard coding straight to this, but that doesn't seem to work.
// #include "C:\sfml\include\SFML\Graphics\CircleShape.h"

I even tried setting the environment path to it:
GOPATH=C:\GO;C:\sfml\include;C:\sfml\lib
GOROOT=C:\Go

For what it's worth I compiled SFML RC version 134 statically beforehand with these commands:
cmake -G "MinGW Makefiles" -D CMAKE_BUILD_TYPE=Release -D BUILD_SHARED_LIBS=FALSE C:\sfml
mingw32-make
cmake -G "MinGW Makefiles" -D CMAKE_BUILD_TYPE=Debug -D BUILD_SHARED_LIBS=FALSE C:\sfml
mingw32-make

The compiling went ok.

Is there a way I can get Go or GCC to find the header files? Is there like some parameter I need to add to 'go build', an environment variable to see, or a config file?