Godot game engine goes Open Source


That has already be posted and there isn't any new information. We'll see whether it's true once we have the sources and can judge for ourselves.
 
Tried compiling this for pandora using just SCons reconfiguring, but it seems the x11 platform code is built on opengl, while eg. android platform code uses gles+egl. Would require some merging of the two platform-specific code blobs to get one that works for us. Used a couple of days on this, got up to linking the final executable before the issues popped up. I get the feeling this would not be too difficult to port for someone who knows their way around EGL and OpenGL ES better than me. Most of the code is very much portable and the non-portable bits are nicely isolated.
 
Tried compiling this for pandora using just SCons reconfiguring, but it seems the x11 platform code is built on opengl, while eg. android platform code uses gles+egl. Would require some merging of the two platform-specific code blobs to get one that works for us. Used a couple of days on this, got up to linking the final executable before the issues popped up. I get the feeling this would not be too difficult to port for someone who knows their way around EGL and OpenGL ES better than me. Most of the code is very much portable and the non-portable bits are nicely isolated.
Yes, from a quick look at the github, that what I though. Needs some work to create a new platform mixing x11-linux and egl-gles. That may require some work (and Scons is ... hum ... not my favorite make tools). So some work should be required yes.

I'm working on C# right now, I may try godot after that, if it's not done by then.
 
Yeah, SCons gave me quite a hard time there. Especially the bug in it that treats any CCFLAGS given as a command line variable (SCons doesn't respect env variables at all) as a single flag. Got around this with a hack in the main SConstruct file to smuggle the env variables to SCons variables :p
 
I have built a working executable. (used some code I found here to make it work with egl and x11)

Right now it only uses GLES1 (somehow it can't create framebuffers with GLES2 ...) and the debug version seems not to be very fast (on Rebirth Pandora without overclocking), but at least it looks like all the example projects work without crashes. The performance of the release build seems to be ok.

Also the mouse-coordinates have an offset and in 3D-examples the backface-culling seems to be doing the opposite of what it should be doing.

I'll attach the binaries in case someone would like to give it a try. godot4pandora.zip

You can find some examples here: http://www.godotengine.org/wp/?page_id=51
 

Attachments

  • godot4pandora.zip
    35 MB · Views: 431
Awesome! I've been looking into an engine to learn after I get some experience working with opengl and sdl. I will need to look into this if it performs well on the OP.
 
I will commit my changes to a fork on github as soon as I get back to my PC.

But there is still a lot  to clean up. For example when building I  still have to add a lot of parameters to the commandline to use the cross-compiler correctly and for the final linking step I have to copy the command that scons tries to use and add some libs by hand.

As soon as I find the time I will add a pandora target to the scripts (if it is not too complicated compared to simply doing stuff by hand).

Edit: https://github.com/x1212/godot (forgot that I changed the user on my linux and had not set up the git-variables regarding email ... :( )

to build use: PATH=toolchainroot scons LINKFLAGS=-Ltoolchainroot/usr/lib CCFLAGS=-march=armv7-a\ -mcpu=cortex-a8\ -mtune=cortex-a8\ -mfpu=neon\ -Itoolchainroot/usr/include\ -Itoolchainroot/usr/include/freetype2 CFLAGS=-march=armv7-a\ -mcpu=cortex-a8\ -mtune=cortex-a8\ -mfpu=neon\ -Itoolchainroot/usr/include\ -Itoolchainroot/usr/include/freetype2 opengl=no target=release

if you use the -j option to speed things up it might fail the first time if scons detected a mingw. Then just delete all *.o and *.a that have something to do with the windows-build and build again with -j1 (then it will continue with that last linking-step).
 
Last edited by a moderator:
Finally got the GLES2 part to 'work' ... just had to link egl in before gles_cm.

All the other time I wasted on this was because I had to restart my pandora ...

Now it looks like the shaders bundled with it need some work, basically 2D stuff is now black rectangles (this includes text), and some 3D stuff that worked before is now broken as well ... but at least some of the 3D that didn't work before works now.

Also I will have to restart my github fork because I broke the history while trying to get my commits to be displayed with my user-name ...

Maybe I will package this into a pnd as soon as I get it to work properly. (for 2D and 3D without shaders, the GLES1-version should be fine already)

godot-gles2.zip
 

Attachments

  • godot-gles2.zip
    7.6 MB · Views: 349
Last edited by a moderator:
Finally got the GLES2 part to 'work' ... just had to link egl in before gles_cm.

All the other time I wasted on this was because I had to restart my pandora ...

Now it looks like the shaders bundled with it need some work, basically 2D stuff is now black rectangles (this includes text), and some 3D stuff that worked before is now broken as well ... but at least some of the 3D that didn't work before works now.

Also I will have to restart my github fork because I broke the history while trying to get my commits to be displayed with my user-name ...

Maybe I will package this into a pnd as soon as I get it to work properly. (for 2D and 3D without shaders, the GLES1-version should be fine already)

attachicon.gif
godot-gles2.zip
Hum; I haven't looked at the sources, but if you are linking both GLES_CM and GLESv2 (with -lEGL -lGLES_CM -lGLESv2), I think it wont work, because both librairie have symbols in common. You should choose to build either GLES 1.1 or GLES 2.0 (unless the engine do the linking at runtime with some dlopen...).

And yes, the "restart" after the EGL lib gets corrupted (BAD_ALLOC) is anoying!
 
Last edited by a moderator:
Well the command that scons uses to link it has -lEGL, -lGLESv2 and -lGLES_CM.

I'm not sure what it should be doing (I think I will have to read the g++ and ld docs again ...), but from my understanding it uses whatever it finds first ...

Also: does someone have some experience regarding debugging shaders? I only have some very basic knowledge about them, that I didn't use for nearly half a year ... and no experience with shaders on the Pandora.

I'm pretty sure that those problems with gles2 (geometry distorted, text/sprites/tiles black, ...) are caused by something in the shaders.

I would still like to get the gles2 to work correctly (even if the performance isn't as good as gles1) because some of the geometry using shaders is simply not rendered by the gles1 (or in some cases not correctly).

@admins/mods: maybe this should be moved to the development- or software- section?
 
Well the command that scons uses to link it has -lEGL, -lGLESv2 and -lGLES_CM.

I'm not sure what it should be doing (I think I will have to read the g++ and ld docs again ...), but from my understanding it uses whatever it finds first ...

Also: does someone have some experience regarding debugging shaders? I only have some very basic knowledge about them, that I didn't use for nearly half a year ... and no experience with shaders on the Pandora.

I'm pretty sure that those problems with gles2 (geometry distorted, text/sprites/tiles black, ...) are caused by something in the shaders.

I would still like to get the gles2 to work correctly (even if the performance isn't as good as gles1) because some of the geometry using shaders is simply not rendered by the gles1 (or in some cases not correctly).

@admins/mods: maybe this should be moved to the development- or software- section?
Linking with both GLES_CM and GLESv2, yes, it will take whatever comes first. So for some function the GLES_CM one, and for other GLESv2... So it won't work. Create a profile for GLES_CM and link only with EGL and GLES_CM, and another with EGL and GLESv2. Your shaders will works better without GLES_CM interfearing.
 
is it possible to add to the export target (on the normal win and linux version) pandora (a linux version compiled for arm with opengl es)? would be very handsome to build on the workstation and than compile for the pandora =)
 
Should be possible, but haven't looked too much into that yet. (looks like I would have to add a second exporter on the x11 platform but I'm not sure how to let godot know about this exporter yet)

However you should already be able to use the Linux-Export (with the Exec+Pack Setting) and simply replace the Exec when you put it on the Pandora.

I'm not sure what the 'Single Exec' would do if you simply replace the binaries in your templates directory ... maybe I'll try this as soon as I have the time.
 
worked on this again ...

https://www.youtube.com/embed/4lRTekkOToE?feature=oembed
I didn't really figure out what causes stuff to go wrong yet, but I think I'm getting closer.

Those problems with GLES2 (distorted geometry) only appear if I add a source of light to a scene, if I leave them dark everything is fine (shape ok, but it's black in front of a background).

With GLES1 that's no problem but there are a lot of effects that won't work without GLES2.

Another problem with the GLES2-build is that some textures won't be applied (most things in 2D like text stay black but most of the icons work ...).

If someone has a clue about what could possibly cause this, it would really help (or if there were some testers that help to find out what works and what not).
 
Back
Top