Godot 3.0.2 stable and modularity...

Tarmik

Hi !

I'm continuing working with godot, and adapting to my own needs. Now I've picked up official stable branch 3.0.2 and readapted to build without scons, using Visual studio only. (Currently only windows, plan to enable Android support back later on).

To anyone, who might be interested - godot project + patches to it: https://drive.google.com/open?id=1fg3MnahN1uZ6iSW_YFoy7YSXL9hpmqby

I've now also enabled libtheora & libvorbis compilation as well (previously they were disabled).

I'm not sure if I'll contribute this change to godot git, as this is parallel build system to scons, and to my best understading it will be not easy to change, and requires some agreements to be made on used build tools / files generation. (Currently there is a lot of .gen. files, which must be present in build area in order for my project to pick up compilation after that).

I have multiple questions, maybe I mark them each with number, answer to whichever you can.

1) "thirdparty\thekla_atlas\nvmesh\BaseMesh.cpp" / QuadTriMesh.cpp I had to add extra include: #include "../nvcore/Array.inl"

So I'm still bit puzzles which define, include directory or compilation flag I need to turn on, in order to avoid adding this include. Without it source code does not compile with following error:

1>BaseMesh.obj : error LNK2019: unresolved external symbol "class nv::Stream & cdecl nv::operator<<<struct nv::BaseMesh::Vertex>(class nv::Stream &,class nv::Array<struct nv::BaseMesh::Vertex> &)" (??$?6UVertex@BaseMesh@nv@@@nv@@YAAAVStream@0@AAV10@AAV?$Array@UVertex@BaseMesh@nv@@@0@@Z) referenced in function "class nv::Stream & cdecl nv::operator<<(class nv::Stream &,class nv::BaseMesh &)" (??6nv@@YAAAVStream@0@AAV10@AAVBaseMesh@0@@Z) 1>VertexWeld.obj : error LNK2019: unresolved external symbol "public: void thiscall nv::Array<struct nv::BaseMesh::Vertex>::resize(unsigned int)" (?resize@?$Array@UVertex@BaseMesh@nv@@@nv@@QAEXI@Z) referenced in function "public: unsigned int thiscall nv::Weld<struct nv::BaseMesh::Vertex,struct nv::Hash<struct nv::BaseMesh::Vertex>,struct nv::Equal<struct nv::BaseMesh::Vertex> >::operator()(class nv::Array<struct nv::BaseMesh::Vertex> &,class nv::Array<unsigned int> &)" (??R?$Weld@UVertex@BaseMesh@nv@@U?$Hash@UVertex@BaseMesh@nv@@@3@U?$Equal@UVertex@BaseMesh@nv@@@3@@nv@@QAEIAAV?$Array@UVertex@BaseMesh@nv@@@1@AAV?$Array@I@1@@Z) 1>bin\ReleaseDebug\godot_windows.exe : fatal error LNK1120: 2 unresolved externals

To my best understanding array.h is declaring template function, which is implemented in array.inl, but noone ever includes array.inl, causing missing function to be born. Does anyone has any idea why this works in current godot compile stage and does not work in my environment.

2) Link time of godot 3.0.2 dropped to something like 20 seconds per link, which is quite bad performance.

Just tried to compare with scons, and it has something like 24 seconds link time (one code line change).

I've harvested already some dynamic link library / shared object support - and to my understanding it's currently non-trivial / considered as non-mandatory:

https://github.com/godotengine/godot/issues/3936 https://godotengine.org/qa/16495/getting-c-to-compile-as-a-shared-object-dll

With partially supported system - as it's possible to make custom modules:

http://docs.godotengine.org/en/stable/development/cpp/custom_modules_in_cpp.html

Does makes any sense godot splitted into multiple custom modules ?

Previous version of godot which I have took from trunk was slightly faster, I suspect there are too many 3rd party libraries, also now bullet library.

Tarmik

Noticed one problem with syncproj and fixed it: https://sourceforge.net/p/syncproj/code/148/log/?path=

Bugfix: Adding files 'Memory.cpp' and 'dir/memory.cpp' resulted in same object file generated, and further conflicts because of this.

Tarmik

I would go with current godot (as whole .exe), if incremental linking would be fast enough at least on windows, but unfortunately godot 3.0.2 is slow on incremental linking, I'm not talking about Android, where clang linker is even slower.

Since I will need to do also modifications to godot (want to bring .avi / .flv , etc playback), and maybe will fully customize appearance of godot itself, I've decided to strip down godot and collect only what I need for my task currently - that's UI (+ later on also VideoPlayer & modules).

As as result I've collected somehow minimal version of godot, by excluding a lot of stuff, for example like 3d graphics, as well as physics handling. I've included all UI elements, and as a demo application I'm launching AcceptDialog just for test purposes.

I've copied main/main.cpp as main2.cpp, as that file required a lot of modifications, rest of code I've instrumented via GCORE define.

Example patch is over here: https://drive.google.com/open?id=1OFMo1AA9x5aOr-nWtycU0ZormxosOOAe (On top of compiled godot 3.0.2 stable).

Now incremental link works 3-4 seconds (Visual studio 2015, Win32, ReleaseDebug configuration).

I'll now continue with analyzing godot modules in depth, and especially VideoPlayer & .ogv playback how it's implemented.

Tarmik

With few adjustments works also on Android. (Updated patch)

One thing I've noticed that without call OS::get_singleton()->set_low_processor_usage_mode(GLOBAL_DEF("application/run/low_processor_mode", true));

godot seems to use 24% cpu on idle work mode. I've tried how this works with normal godot, and it also eats 5% cpu by default.

On Android however same line causes heavy blinking, so I had to disable it from Android. Need to check what this actually means for Android.

Tarmik

Now collected additionally 3 modules - libtheora, libogg and libvorbis, and made simple player instantiation code.

SceneTree *sml = Object::cast_to<SceneTree>(main_loop); VideoPlayer* vp = memnew(VideoPlayer); sml->get_root()->add_child(vp); main_loop->init(); Ref<VideoStreamTheora> vst = memnew(VideoStreamTheora); \#ifdef _WIN32 vst->set_file("C:\\Prototyping\\godot_games\\video.ogv"); \#else vst->set_file("/storage/self/primary/Installs/video.ogv"); \#endif vp->set_stream(vst); vp->play(); Rect2 r = vp->get_viewport_rect(); vp->set_size(r.size); vp->show();

Code currently looks like rather trivial.

Collected a a patch to godot 3.0.2 (https://drive.google.com/open?id=1ZpBbIFK9Ry8JFOtnsg8fDBaH9V-mxsD9 ) If anyone is interested.

On Android libtheora must be compiled with speed optimizations otherwise video lags on device. Godot is by default compiled with speed optimizations, but in my own project I've mostly disabled those. Need to return speed optimizations back for core/*.cpp and for libtheora.

It's also possible to enable arm specific optimizations for libtheora - look for example here: https://github.com/xiph/theora/tree/master/lib/arm

But I don't think it's so relevant.

I will try to cross connect now my own stripped godot with vlc code base.

Tarmik

One approach how to troubleshoot performance problems - is to measure performance on windows, using visual studio, and then after that you know there performance penalties are generally - then look in Android port on same code.

For windows performance problems turned to be in function oc_state_frag_recon_mmx, which is x86 assembly optimized. For Arm it's also possible to perform similar optimizations, but godot does not seems to have arm optimizations integrated. Something similar to https://github.com/xiph/theora/tree/master/lib/arm

I have simply enabled optimizations for code where generic version of that function is located - it was in thirdparty/libtheora/state.c

Optimizing only that file seemed to be insufficient, so I've enabled optimizations for whole libtheora library - after that Android lags fade away.

Tarmik

Btw - currently my own "godot.apk" weight is around 6 Mb, comparing to what godot base can do - I would say it's rather small size. UI + video playback + audio playback (specific codecs).

Xamarin UI apk size starts from 50 Mb. ("Hello world" message box)

Tarmik

No need to collect anymore my patches from link above, I've finally integrated godot 3.0.2 + applied patches on top of it into my own repository - if you want - you can glance it here:

https://sourceforge.net/p/vlc2/code/HEAD/tree/

Godot is under godot/ directory.

Main reason why to use SCons over syncProj project generation tool was multiprocessor build - I have now enabled multiprocessor building for both platforms - for Windows and for Android.

I will not compare SCons build time against Visual studio build time, as I'm building currently sub-set of godot - not everything.

This is first generation script, which collects bits and pieces of godot:

https://sourceforge.net/p/vlc2/code/HEAD/tree/iptv.cs

Tarmik

If you ever want to try out how .ogv playback is working, you will need Visual studio 2017, but besides this - main2.cpp contains hardcoded path to .ogv file.

For Android I have modified contents of AndroidManifest.xml to give application permissions to read from sd card.

To my best understanding permissions should be requested at run-time for newer platform SDK, but this is not implemented in godot, I suspect godot itself does not need those permissions. I'm wrong here ?!

Megalomaniak

@Tarmik said: I suspect godot itself does not need those permissions. I'm wrong here ?!

And what would a typical game write to disk during game play beyond player progress? ;) Or for that matter why would a game need to read someones contact list(other than to spy on them)? etc.

Tarmik

@Megalomaniak said:

@Tarmik said: I suspect godot itself does not need those permissions. I'm wrong here ?!

And what would a typical game write to disk during game play beyond player progress? ;) Or for that matter why would a game need to read someones contact list(other than to spy on them)? etc.

Depends on game, I can imagine wanting to assign my own photo to character in game. But I agree, normally this is not needed. :-)