+- Frictional Games Forum (read-only) (https://www.frictionalgames.com/forum)
+-- Forum: Open Source Collaboration (https://www.frictionalgames.com/forum/forum-27.html)
+--- Forum: HPL1 Engine (https://www.frictionalgames.com/forum/forum-28.html)
+--- Thread: Let's make this working on Android (/thread-56750.html)
Let's make this working on Android - onager - 03-29-2020
Good evening everybody!
I am planning to do a big rework of HPL1 and Penumbra: Overture code.
As my final goad I would like to get Penumbra: Overture running on Android; this requires a lot of work and I'm not sure if it's even possible at this point.
I see this this way: code from Github should be compilable with Android Studio/NDK, but game will run only if game assets from bought game are put in correct place during build so they are copied during build in resulting APK file, similarly as it is done currently for other platforms.
I managed to compile game on older Xubuntu 12.04 (Virtualbox VM), I have the following problems:
1. In fullscreen mode mouse is kinda hypersensitive, mostly stuck at edge screen, not playable
2. In windowed mode mouse behaves better in menu so you can actually start the game, it is not always aligned properly, like it doesn't account for the fact that window may not be at top left corner.
In actual game it is also crazy.
3. If shader setting is anything above "Very low", everything becomes blue
4. When I inspect things in the beginning scene, image does strange things, like super zoomed in.
5. Both Angelscript and game has to be compiled with AS_MAX_PORTABILITY, otherwise it crashes. I believe this means lower performance, but I don't care about performance at this point.
Note that most of these problems also reproduce on latest Steam version.
It was compiled by newer gcc than originally used, it can be seen from this:
objdump -s --section .comment penumbra.bin
Output mentions gcc 4.4.7, 4.0.2 and 4.1.1.
I've chosen to start with Linux version because it uses CMake (build system that also can be used for building native code for Android) and is in general closer to Android than others.
Here is the list of risky items for the purpose of making this game runnable on modern Linux and then on Android:
* Sound, OpenAL - should not be a problem, can be paired with OpenAL Soft which supports Android (I've seen a couple of warnings about using deprecated API, should not be a problem, also not sure about ALUT)
* FLTK - can be easily removed
* SDL1 - kinda supports Android, but option to port to SDL2 can be considered. API changes are significant though.
* Graphics, GLee - I would like to fix current issues with OpenGL first. Android supports OpenGL ES only, so no GLee (this library can't even be downloaded from official site anymore), and, more importantly, no Cg (it is a moderately risky item because Cg shaders for the game were not open sourced, but we can call Cg compiler at build time to prepare GLSL versions of those shaders, no idea if it would work though).
Interesting thing is Mesa (library responsible for OpenGL on Ubuntu) also supports OpenGL ES and EGL, so we may use that for testing.
* Angelscript - moderately risky item because of crashes that I experienced before, but portable mode gives hope. Port to use newer version is available in this fork (https://github.com/ArchyInf/HPL1Engine)
* Newton - IMO the most risky item. I contacted Julio Jerez, developer of this library, apparently source of the original version was lost. Port to use Newton 2 is also available, but the oldest versions of Newton are around revision 800 (year 2013) which is still significantly newer.
At this moment I would like to finish configuration of my Ubuntu 18.04 VM and try to build game there (easier to use because it's newer), after that fix the mouse. This will give some freedom to play with physics and actually play the game.
As you probably guess, amount of work to accomplish porting to Android is enormous, so any kind of help and contribution is very welcome. As you can see, there are many items here that can be done in parallel.
I'm open to your suggestions, opinions and any other help.
Will try to keep you informed.
RE: Let's make this working on Android - Mudbill - 03-30-2020
Interesting stuff! Been dabbling with compiling this thing myself but appeared tricky.
BTW are you sure the mouse issues were not because it's in a VM? I know this is very common.
Also I might have an older Newton version around here somewhere...
Ah yes, here's version 1.53. I believe this is the version that Penumbra uses since the headers match.
https://cdn.discordapp.com/attachments/682219158443655190/682578484966588440/newtonLinux-1.53.tar.gz
RE: Let's make this working on Android - onager - 03-30-2020
(03-30-2020, 01:13 AM)Mudbill Wrote: Interesting stuff! Been dabbling with compiling this thing myself but appeared tricky.
BTW are you sure the mouse issues were not because it's in a VM? I know this is very common.
Also I might have an older Newton version around here somewhere...
Ah yes, here's version 1.53. I believe this is the version that Penumbra uses since the headers match.
https://cdn.discordapp.com/attachments/682219158443655190/682578484966588440/newtonLinux-1.53.tar.gz
Thank you Mudbill for a copy of old Newton! I investigated a little bit, I believe archive doesn't contain many source files, so I can't recompile the source with new compiler, but it should help.
It's possible that mouse issues are related to VM. I will think about a possibility to try it on hardware. Also MouseSDL.h (in HPL1Engine/include/impl) has these spicy TODOs (Fix so it works and handles screen size) and code like
Code:
// Do a transform with the screen-size to the the float coordinates.
cVector2f vPos = mvMouseRelPos;
//Ok this is?
mvMouseRelPos = cVector2f(0,0);
return vPos;So it looks like original developers knew about these problems.
RE: Let's make this working on Android - onager - 04-04-2020
Quick note about the mouse issues: game works fine if fullscreen mode in game AND mouse integration in VM is disabled. I experimented with it a little bit, apparently cursor in main menu is not even handled by SDL, it is managed by the game (e.g. created in Overture code, cMainMenu::cMainMenu)
Code:
mpGfxMouse = mpDrawer->CreateGfxObject("player_crosshair_pointer.bmp","diffalpha2d");I tried to check how other games work in the same VM, Warzone 2100 crashed right at the start, 0 A.D. crashed the whole VM
RE: Let's make this working on Android - onager - 04-05-2020
Yesterday I learned that you can't build HPL1 on Ubuntu 18.04 because GLee is not compatible with new OpenGL headers. When trying to compile in this environment, errors will appear:
Code:
/home/krystian/OvertureSource-2/HPL1Engine/sources/graphics/Material_Fallback01_BaseLight.cpp: In destructor ‘virtual hpl::cGLState_ATISpot::~cGLState_ATISpot()’:
/home/krystian/OvertureSource-2/HPL1Engine/sources/graphics/Material_Fallback01_BaseLight.cpp:250:15: error: ‘glDeleteFragmentShaderATI’ was not declared in this scope
if (mlBind) glDeleteFragmentShaderATI(mlBind);
^~~~~~~~~~~~~~~~~~~~~~~~~
/home/krystian/OvertureSource-2/HPL1Engine/sources/graphics/Material_Fallback01_BaseLight.cpp: In member function ‘virtual void hpl::cGLState_ATISpot::Bind()’:
/home/krystian/OvertureSource-2/HPL1Engine/sources/graphics/Material_Fallback01_BaseLight.cpp:256:3: error: ‘glBindFragmentShaderATI’ was not declared in this scope
glBindFragmentShaderATI(mlBind);In short, it is not easy to fix, and since I will need to get rid of this library, I'm going back to older Ubuntu.
Technical reason of incompatibility: GLee uses hardcodes names of header guard macros for glext.h
Code:
#define __glext_h_ /* prevent glext.h from being included */RE: Let's make this working on Android - Mudbill - 04-07-2020
I guess that's why I had issues compiling it on my Mint box :')
F
RE: Let's make this working on Android - erolmatei - 05-23-2020
Hello again.
For the shaders, the HPL1 repo contains some drop-in replacements that work perfectly. Oddly enough, only the highest shaders work well and the others not-so-much, at least on my Intel GPU on Linux.
For the rest, I am experiencing issues with AngelScript not properly binding some core functions, like SetJointControllerPropertyFloat (which is used to open the trapdoor inside the mine). Did that happen to you as well?
Also, did the old GCC ignore blatant violations in AngelScript code (in particular a "return 0" in a function returning a asUPtr struct) to you?