Port Requests


@ptitSeb : thanks for having a look at it :)

If I'm not mistaken, Minetest uses the Perlin noise algorithm to generate maps. As this algorithm is pretty heavy, do you think NEON optimizations would help ?

EDIT: I'll do some tests with "perf top" to see where the game spends the most time.

Cheers, Magic Sam
 
@ptitSeb: Ah, OK, I understand.

Regarding Lua, "libluajit-5.1.so.2" uses a lot of resources at times, is it related ?
12.75% libGLES_CM.so.1.10.2359475 [.] 0x35bf4
5.06% libc-2.9.so [.] memcpy
4.86% libc-2.9.so [.] 0x67730
3.16% minetest [.] CNodeDefManager::get(MapNode const&) const
2.31% minetest [.] _ZL17updateFastFaceRowP12MeshMakeDataN3irr4core8vector3dIsEES4_NS3_IfEES4_S5_RSt6vectorI8FastFaceSaIS7_EE.isra.389
2.20% minetest [.] irr::video::COpenGLDriver::getColorBuffer(void const*, unsigned int, irr::video::E_VERTEX_TYPE)
1.90% minetest [.] MapgenV6::flowMud(short&, short&)
1.85% minetest [.] getTileInfo(MeshMakeData*, irr::core::vector3d<short> const&, irr::core::vector3d<short> const&, bool&, irr::core::vector3d<short>&, irr::core::vector3d<short>&, unsig
1.80% libc-2.9.so [.] memcmp
1.67% libm-2.9.so [.] 0x16830
1.63% libluajit-5.1.so.2 [.] 0xac84
1.63% [unknown] [.] 0xffff0fe4
1.55% minetest [.] Map::spreadLight(LightBank, std::set<irr::core::vector3d<short>, std::less<irr::core::vector3d<short> >, std::allocator<irr::core::vector3d<short> > >&, std::map<irr::
1.53% libGL.so.1 [.] glshim_glDrawElements
1.43% libc-2.9.so [.] memset
1.39% perf [.] 0x3785c
1.35% [kernel] [k] __do_softirq
1.32% minetest [.] MapNode::getLight(LightBank, INodeDefManager*) const
1.31% minetest [.] noise2d_perlin(float, float, int, int, float, bool)
1.05% libc-2.9.so [.] malloc
1.02% libc-2.9.so [.] free
1.01% [kernel] [k] __schedule
0.99% minetest [.] 0xfb440
0.96% libc-2.9.so [.] dl_iterate_phdr
0.93% libgcc_s.so.1 [.] 0x195a8
0.79% minetest [.] std::pair<std::_Rb_tree_iterator<irr::core::vector3d<short> >, bool> std::_Rb_tree<irr::core::vector3d<short>, irr::core::vector3d<short>, std::_Identity<irr::core::ve
0.73% minetest [.] MapBlockMesh::MapBlockMesh(MeshMakeData*, irr::core::vector3d<short>)
0.67% libz.so.1 [.] longest_match
0.64% minetest [.] ClientMap::renderMap(irr::video::IVideoDriver*, int)
0.64% libstdc++.so.6 [.] std::_Rb_tree_increment(std::_Rb_tree_node_base const*)
0.60% minetest [.] _ZN3Map29getSectorNoGenerateNoExNoLockEN3irr4core8vector2dIsEE.part.281
0.58% libz.so.1 [.] deflate_slow
0.57% minetest [.] std::_Rb_tree<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::
0.53% libm-2.9.so [.] cosl
0.53% libstdc++.so.6 [.] std::_Rb_tree_insert_and_rebalance(bool, std::_Rb_tree_node_base*, std::_Rb_tree_node_base*, std::_Rb_tree_node_base&)
0.52% minetest [.] biLinearInterpolation(float, float, float, float, float, float)

Openal used to eat a lot of resources too (mix_NEON ~10% ?), until I turned the sound off in the options ;)

Cheers, Magic Sam
 
Most of the engine is in lua, so yeah, luajit has some work to do!
openal taking some time? I don't remember having that on my side.
Anyway, it seems it's mostly doing graphics stuff, with that large 10%+ inside the GLES driver...
 
Last edited:
I was browsing projects on github today. Just thought I'd share some in case someone was interested in porting them:

Voxel Quest: Interesting project that was recently made open source.
Zetawar: Turn based strategy game.
Captain Holetooth: Platform game made using Godot.
Rotorcross: Multi-rotor racing sim.
heXon: Twin stick shooter made with Urho3D. Urho3D was mentioned previously, but I don't think we've seen any ports use it yet. LucKey Productions seems to make a lot of open source, commercial games using this engine.
 
Last edited:
I guess it depend on the backend for the CPU Emulator. If it's pure interpretor yes, if it's a jit, someone will probably have to write it.
 
Hi all :)

Some port ideas:

Inexor (Cube 2 fork, better suited for the Pyra I guess)

Project Unknown (based on Quake 1 FTEQW)

@ptitSeb : speaking of Cube, how is the Pandora port going ?

Cheers, Magic Sam
Cube: it read the DEPTH buffer (wich is not possible on GLES) and I haven't spent much time (none in fact) trying to find a workaround.

Project Unknow doesn't seems to be release.

I'm not a big fan of multiplayer arena fps. I very much prefer single player FPS.
Still, I have ported quite a few Arena Multiplayer FPS already to the Pandora, and I'm not sure what thoses will bring more (puting aside the "collecting" part).
 
Hi,

Hatari has a new 2.0 release https://hatari.tuxfamily.org - http://download.tuxfamily.org/hatari/2.0.0/

Latest version in the repo is more than four years old (1.6) and there are tons of improvements and additions, - I managed to get 1.8 working in Slackware, but it would be nice to have 2.0 available as a pnd.
If a version with GUI is too much work a non-gui version would be nice as well. Any takers? @ptitSeb maybe? Pretty sure @skeezix will not be offended ;)

For compiling and running Hatari, you must have installed the following libraries and their development versions:

Following libraries are optional, but for your full Hatari pleasure, we recommend to install them:

  • The PNG image library, needed for compressing screenshots and AVI video recording - http://www.libpng.org/
  • The portaudio library, needed for Falcon microphone - http://www.portaudio.com/
  • The GNU Readline library, needed for Hatari debugger command line editing
  • The Xlib library, to support Hatari Python UI window embedding on systems with the X window system (Linux and other unixes)
 
Hi,

Hatari has a new 2.0 release https://hatari.tuxfamily.org - http://download.tuxfamily.org/hatari/2.0.0/

Latest version in the repo is more than four years old (1.6) and there are tons of improvements and additions, - I managed to get 1.8 working in Slackware, but it would be nice to have 2.0 available as a pnd.
If a version with GUI is too much work a non-gui version would be nice as well. Any takers? @ptitSeb maybe? Pretty sure @skeezix will not be offended ;)

For compiling and running Hatari, you must have installed the following libraries and their development versions:

Following libraries are optional, but for your full Hatari pleasure, we recommend to install them:

  • The PNG image library, needed for compressing screenshots and AVI video recording - http://www.libpng.org/
  • The portaudio library, needed for Falcon microphone - http://www.portaudio.com/
  • The GNU Readline library, needed for Hatari debugger command line editing
  • The Xlib library, to support Hatari Python UI window embedding on systems with the X window system (Linux and other unixes)
I have already too many things compiling (and not working), but I'll give this a try one day yes.
 
I have already too many things compiling (and not working), but I'll give this a try one day yes.

sure, no rush.

I might even try to compile it myself this weekend with code::blocks.
SDL should already be part of code::blocks and installing zlib from source doesn't seem to be that complicated.

Probably don't need Readline and isn't xlib just X11? If so that should be included in code::blocks as well..
 
sure, no rush.

I might even try to compile it myself this weekend with code::blocks.
SDL should already be part of code::blocks and installing zlib from source doesn't seem to be that complicated.

Probably don't need Readline and isn't xlib just X11? If so that should be included in code::blocks as well..
All libs should be in codeblocks. Even portaudio is there (I think it's v18, not 19, but I'm not sure).
 
Back
Top