136
WME Lite / Re: Any Linux developers out there?
« on: June 15, 2013, 12:41:27 PM »
I have uploaded a new build with viewport transformation removed. It works for me using the demo project. Can you give it a try?
- April 25, 2024, 02:57:09 AM
- Welcome, Guest
News:
Forum rules - please read before posting, it can save you a lot of time.
Show Posts
This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
137
WME Lite / Re: Any Linux developers out there?
« on: June 15, 2013, 11:16:09 AM »
I'm trying to understand what's happening. Strange thing is that when the transformation from screen to game coordinates is computed, this formula is used
but when that transformation is to be reverted, the formula looks like this
so my best guess is that the 2nd formula is missing the multiplication of the border with the ratio... But I'm really just guessing, I don't even have an idea why the viewport parameters are in. When the left top coordinates (0, 0) are translated, I would also have expected a negative X value. But due to the viewport correction, the X result is not -(240/1.41)=-170 but rather +69. Mnemonic, can you help me here?
Code: [Select]
point->x = point->x / m_RatioX - m_BorderLeft / m_RatioX + viewportRect.x;
point->y = point->y / m_RatioY - m_BorderTop / m_RatioY + viewportRect.y;
but when that transformation is to be reverted, the formula looks like this
Code: [Select]
point->x = MathUtil::RoundUp(point->x * m_RatioX) + m_BorderLeft - viewportRect.x;
point->y = MathUtil::RoundUp(point->y * m_RatioY) + m_BorderTop - viewportRect.y;
so my best guess is that the 2nd formula is missing the multiplication of the border with the ratio... But I'm really just guessing, I don't even have an idea why the viewport parameters are in. When the left top coordinates (0, 0) are translated, I would also have expected a negative X value. But due to the viewport correction, the X result is not -(240/1.41)=-170 but rather +69. Mnemonic, can you help me here?
138
WME Lite / Re: Any Linux developers out there?
« on: June 13, 2013, 08:09:59 PM »
Ooops, sorry. I uploaded a build with debugging enabled now.
139
WME Lite / Re: Any Linux developers out there?
« on: June 12, 2013, 08:01:00 PM »
Hi 2.0,
I have uploaded a new build that writes the original (i.e. from screen) coordinates and their transformation to game coordinates into the log, roughly once per second. Can you please check what happens when you touch the 4 corners on the touch screen and the 4 corners of where your game is drawn? It would be interesting to see how these coordinates are transformed.
I have uploaded a new build that writes the original (i.e. from screen) coordinates and their transformation to game coordinates into the log, roughly once per second. Can you please check what happens when you touch the 4 corners on the touch screen and the 4 corners of where your game is drawn? It would be interesting to see how these coordinates are transformed.
140
WME Lite / Re: Any Linux developers out there?
« on: June 12, 2013, 03:39:08 PM »
Hi Mnemonic,
I saw in the code that there's an offset from the renderer applied to the mouse position
But the values for m_Renderer->m_DrawOffsetX and m_Renderer->m_DrawOffsetY are never assigned after they are initialized to 0. Shouldn't they be set to the m_BorderLeft and m_BorderTop values computed in CBRenderSDL::InitRenderer?
I saw in the code that there's an offset from the renderer applied to the mouse position
Code: [Select]
void CBGame::GetMousePos(POINT* Pos)
{
CBPlatform::GetCursorPos(Pos);
Pos->x -= m_Renderer->m_DrawOffsetX;
Pos->y -= m_Renderer->m_DrawOffsetY;
But the values for m_Renderer->m_DrawOffsetX and m_Renderer->m_DrawOffsetY are never assigned after they are initialized to 0. Shouldn't they be set to the m_BorderLeft and m_BorderTop values computed in CBRenderSDL::InitRenderer?
141
WME Lite / Re: Any Linux developers out there?
« on: June 11, 2013, 03:32:48 PM »
Hi Mnemonic,
the blog post describes a nice way to solve a part of the problem. But in the end, it only makes assets work, and doesn't take care of having direct file access, or to deal with OBB files. I think we need to distinguish between the several methods.
Querying an asset directory for files is possible with the functionality provided, but whole iteration over a directory tree isn't - i.e. you need to know your directory in advance. I think that's ok because the asset subdirectories already follow a certain naming convention.
Checking an OBB mount is more flexible, because that one will be visible in the file system once mounted.
Writing files is a different story (I forgot about that one because there's not so much alternatives as for reading). There's a (user) private directory for every app which is r/w and can be used for savegames, settings... That one is easily accessible by wmelite, the Java part of the app can supply the correct path. Writing to the assets or the OBB is not possible. Furthermore, you cannot package files into an app which "automagically" occur in that app-and-user-private directory.
The log file is a different story, because the app-and-user-private directory cannot easily be read/written by somebody else, due to security of private data. On a non-rooted device, even the debug bridge won't allow access. Thus, the log file would have to go somewhere else, typically the "external storage" directory (Environment.getExternalStorageDirectory()). The same is true for the "local" settings.xml which cannot be written to the app-and-user-private directory from outside either.
So I think we need to solve the issue for reading/writing files for debugging (wme.log, settings.xml, maybe others?) which should go into a new "category" of directory.
A more difficult issue is to support, out of the possible options, at least these 3 possibilities to read files:
I can make the decision between 1. and 2. a compile time option. But I actually like how wmelite games for Android could be packaged without having to touch/recompile the native part of the app at all - so I'm still in favour of having a choice at runtime. Ok, the URI scheme might be over-engineered, but I like the idea behind it. Maybe we could encapsulate all file access in CBFile, where you already have defined virtual functions for file access? I guess they're just not implemented by any subclass yet? That could be a starting point.
the blog post describes a nice way to solve a part of the problem. But in the end, it only makes assets work, and doesn't take care of having direct file access, or to deal with OBB files. I think we need to distinguish between the several methods.
Querying an asset directory for files is possible with the functionality provided, but whole iteration over a directory tree isn't - i.e. you need to know your directory in advance. I think that's ok because the asset subdirectories already follow a certain naming convention.
Checking an OBB mount is more flexible, because that one will be visible in the file system once mounted.
Writing files is a different story (I forgot about that one because there's not so much alternatives as for reading). There's a (user) private directory for every app which is r/w and can be used for savegames, settings... That one is easily accessible by wmelite, the Java part of the app can supply the correct path. Writing to the assets or the OBB is not possible. Furthermore, you cannot package files into an app which "automagically" occur in that app-and-user-private directory.
The log file is a different story, because the app-and-user-private directory cannot easily be read/written by somebody else, due to security of private data. On a non-rooted device, even the debug bridge won't allow access. Thus, the log file would have to go somewhere else, typically the "external storage" directory (Environment.getExternalStorageDirectory()). The same is true for the "local" settings.xml which cannot be written to the app-and-user-private directory from outside either.
So I think we need to solve the issue for reading/writing files for debugging (wme.log, settings.xml, maybe others?) which should go into a new "category" of directory.
A more difficult issue is to support, out of the possible options, at least these 3 possibilities to read files:
- Reading game packages from assets (packaged files, maybe compressed) using a similar method as described in the blog post.
- Reading game packages from expansion files (not packaged, not compressed), assuming all expansion files (there are max. 2) are just renamed .dcp files.
- Reading settings, savegames, and other user-specific data from the app-user-private directory
I can make the decision between 1. and 2. a compile time option. But I actually like how wmelite games for Android could be packaged without having to touch/recompile the native part of the app at all - so I'm still in favour of having a choice at runtime. Ok, the URI scheme might be over-engineered, but I like the idea behind it. Maybe we could encapsulate all file access in CBFile, where you already have defined virtual functions for file access? I guess they're just not implemented by any subclass yet? That could be a starting point.
142
WME Lite / Re: Any Linux developers out there?
« on: June 11, 2013, 12:05:35 PM »
Trying to define a way forward for Android.
There are 3 situations that need to be handled:
The header files can be found in a recent Android NDK. Unfortunately I cannot attach them here, and they are probably too long for embedding.
To handle the possibilities in wmelite, all file access should be abstracted, in order to implement the various methods described above. I could imagine coding the storage type in the file path, i.e. like an URI (file:///your/path/file.dcp, package:///your/path/package.dcp, asset:///asset/path/filename.xml, obb:///location/of/obb/to/be/mounted/path/inside/obb/filename.txt, and so on) and to instanciate a matching implementation of an abstract (I think in C++ speak it is "virtual") file access class.
Mnemonic, what are your thoughts about this? I think that if all file access in the end goes via "BFileManager.cpp", it should not be too hard to implement something like described. But since there are methods that return a FILE* its probably not that easy I guess?
There are 3 situations that need to be handled:
- Game resources are shipped inside the application bundle (.zip file [although called .apk], maybe compressed). They are not safely accessible by low-level file operations, and should (for best compatibility over all devices, Android versions and the future) only be accessed using the functionality declared in the NDK's "asset_manager.h". This applies for apps that do not hit the 50MB limit.
- Game resources are shipped using Google's mechanism of "expansion files". If they are created using the "JOBB" tool, they are also not safely accessible by low-level file operations, and should (for best compatibility over all devices, Android versions and the future) only be accessed using the functionality declared in the NDK's "storage_manager.h". Once they are "mounted", though, it looks like low-level file operations are possible, once the manager's query for the mount path has succeeded. But an expansion file can be anything else (a wme .dcp file for instance), and can be accessed by low-level file operations then, but the file name itself is changed to "[main|patch].<expansion-version>.<package-name>.obb" in any case.
- Game resources are shipped with a custom mechanism, i.e. the app implements its own "package downloader" to download the resources from a custom path (not the Google Play store). It is now up to the app/game publisher what format the resources are and where they are placed.
The header files can be found in a recent Android NDK. Unfortunately I cannot attach them here, and they are probably too long for embedding.
To handle the possibilities in wmelite, all file access should be abstracted, in order to implement the various methods described above. I could imagine coding the storage type in the file path, i.e. like an URI (file:///your/path/file.dcp, package:///your/path/package.dcp, asset:///asset/path/filename.xml, obb:///location/of/obb/to/be/mounted/path/inside/obb/filename.txt, and so on) and to instanciate a matching implementation of an abstract (I think in C++ speak it is "virtual") file access class.
Mnemonic, what are your thoughts about this? I think that if all file access in the end goes via "BFileManager.cpp", it should not be too hard to implement something like described. But since there are methods that return a FILE* its probably not that easy I guess?
143
WME Lite / Re: Any Linux developers out there?
« on: June 09, 2013, 12:11:52 PM »
Debug mode is actually working fine (when enabled in the code), I just used an incorrect project which did not have a valid startup scene when in debug mode 
It runs a little slower than non-debug mode with the true type font used to show debugging info on the screen, but that's probably normal.
Now I tried to enable debug mode with the settings.xml file. That's more tricky. I used the file with a small fix so that the XML parser recognizes it
Although I haven't yet understood everyting about Android's file systems and paths yet, I am afraid that this won't work for this platform.
As far as I understand, the package creation process doesn't simply package all files from the project. It will package the Java code, add native shared libraries when they exist (actually, wmelite is "only" a native shared library on this platform), parse and add GUI elements (icons, layout xml, resource xml files), and so-called "assets". The only way to ship an arbitrary file in an app package is to place it in the "assets/raw" subfolder (50MB limit when the app is to be published in Google Play). All these files could actually remain in the app package (some even compressed) and will not be extracted to the file system. I think shared libraries are extracted so that they can be loaded with standard system calls when the virtual machine requests them.
When an app is started, it has a "private folder" to store application-private data. This is separated from the folders that are present in the app package. One consequence of this is (maybe also when you consider that Android tablets support "multi user" with different settings per user) that there is not an obvious relation between the paths where app settings are stored and where the app itself is installed. And it could be implemented differently by different manufacturers.
If game data exceeds 50 MB, another storage location for these so-called "expansion files" is added. They are stored on a different path, which depends on the location of Androids "external storage" concept.
Again, not 100% sure about all of this, but that's how it looks to me at the moment.
Long story short, the problem is that wmelite does not support that many different paths resp. methods to read (compressed) files that would be required for proper Android support. I'll need to think about this. In the meantime, I'll probably leave things as they are at the moment.
It runs a little slower than non-debug mode with the true type font used to show debugging info on the screen, but that's probably normal.Now I tried to enable debug mode with the settings.xml file. That's more tricky. I used the file with a small fix so that the XML parser recognizes it
Code: [Select]
<?xml version="1.0" encoding="UTF-8"?>
<Settings>
<Debug>
<DebugMode>1</DebugMode>
</Debug>
</Settings>
but then I found out that its not as easy as I thought. The Debug mode will only be used if read from the "local" settings.xml, because that happens very early, before the "non-local" settings.xml is read.Although I haven't yet understood everyting about Android's file systems and paths yet, I am afraid that this won't work for this platform.
As far as I understand, the package creation process doesn't simply package all files from the project. It will package the Java code, add native shared libraries when they exist (actually, wmelite is "only" a native shared library on this platform), parse and add GUI elements (icons, layout xml, resource xml files), and so-called "assets". The only way to ship an arbitrary file in an app package is to place it in the "assets/raw" subfolder (50MB limit when the app is to be published in Google Play). All these files could actually remain in the app package (some even compressed) and will not be extracted to the file system. I think shared libraries are extracted so that they can be loaded with standard system calls when the virtual machine requests them.
When an app is started, it has a "private folder" to store application-private data. This is separated from the folders that are present in the app package. One consequence of this is (maybe also when you consider that Android tablets support "multi user" with different settings per user) that there is not an obvious relation between the paths where app settings are stored and where the app itself is installed. And it could be implemented differently by different manufacturers.
If game data exceeds 50 MB, another storage location for these so-called "expansion files" is added. They are stored on a different path, which depends on the location of Androids "external storage" concept.
Again, not 100% sure about all of this, but that's how it looks to me at the moment.
Long story short, the problem is that wmelite does not support that many different paths resp. methods to read (compressed) files that would be required for proper Android support. I'll need to think about this. In the meantime, I'll probably leave things as they are at the moment.
144
WME Lite / Re: Any Linux developers out there?
« on: June 08, 2013, 05:07:07 PM »
No, the log to file should not be enabled permanently. It is a temporary solution until I understand why enabling debug mode (incl. log to file) keeps the game from running.
Similar to iOS (I guess) the logging to the in-memory ringbuffer is always enabled, which is probably fine (a lot of applications do this even when they are released); when the Android device is attached to a PC, that ring buffer can be displayed. But I guess not many people have the SDK installed (if comes for free, but if you don't really need it, there is not much reason to install), so having a log file is still desirable.
The real question is, as you say, why debug mode behaves so badly. I'll try to find that out.
Similar to iOS (I guess) the logging to the in-memory ringbuffer is always enabled, which is probably fine (a lot of applications do this even when they are released); when the Android device is attached to a PC, that ring buffer can be displayed. But I guess not many people have the SDK installed (if comes for free, but if you don't really need it, there is not much reason to install), so having a log file is still desirable.
The real question is, as you say, why debug mode behaves so badly. I'll try to find that out.
145
WME Lite / Re: Any Linux developers out there?
« on: June 08, 2013, 08:50:09 AM »
I uploaded a new build which unconditionally logs into "/mnt/sdcard/wme.log" for the moment. Please try if you have time.
Unfortunately, enabling debug mode itself is not a good idea - the engine will only run with 0,00000001 fps
probably due to the amount of font rendering in debug mode.
Mnemonic, what do you think about separating logging to file from debug mode? Currently you can't have one without the other, but it's not optimal for Android at least.
Unfortunately, enabling debug mode itself is not a good idea - the engine will only run with 0,00000001 fps
probably due to the amount of font rendering in debug mode.Mnemonic, what do you think about separating logging to file from debug mode? Currently you can't have one without the other, but it's not optimal for Android at least.
146
WME Lite / Re: Any Linux developers out there?
« on: June 07, 2013, 08:25:05 AM »
I'm sorry for not checking this in advance. It is currently indeed difficult to get wmelite on Android to find and use the wme.ini file.
Mnemonic, is there any reason why you chdir() to the directory where wme.ini resides (in CBPlatform::Initialize) instead of supplying the full path to CBRegistry::SetIniName?
I also saw that actually reading values from that file is #ifdef __WIN32__ only. For other platforms you probably had a settings.xml in mind. Do you have a template for that? Or is this not the place that is meant to enable debug mode?
In CBRegistry::CBRegistry the settings.xml is tried to be loaded from the local directory. Is it safe to call CBRegistry::LoadValues(false) afterwise, even if there were already settings loaded during constructor call?
Yes, this is quite a confusing collection of questions
In the end I just want to find out how to get a wme.log file for people who are not familiar with the Android developer tools, and even if they are, the logging ringbuffer of Android doesn't have an endless capacity 
so having a log file functionality handy would be nice.
Mnemonic, is there any reason why you chdir() to the directory where wme.ini resides (in CBPlatform::Initialize) instead of supplying the full path to CBRegistry::SetIniName?
I also saw that actually reading values from that file is #ifdef __WIN32__ only. For other platforms you probably had a settings.xml in mind. Do you have a template for that? Or is this not the place that is meant to enable debug mode?
In CBRegistry::CBRegistry the settings.xml is tried to be loaded from the local directory. Is it safe to call CBRegistry::LoadValues(false) afterwise, even if there were already settings loaded during constructor call?
Yes, this is quite a confusing collection of questions
In the end I just want to find out how to get a wme.log file for people who are not familiar with the Android developer tools, and even if they are, the logging ringbuffer of Android doesn't have an endless capacity so having a log file functionality handy would be nice.
147
WME Lite / Re: Any Linux developers out there?
« on: June 06, 2013, 08:11:12 PM »
I have uploaded a new build which forces the app to go to landscape mode independent of the screen orientation. Please test if you like.
I also added some debugging output to understand problems with touch offset. Please look for lines like these in the output of "adb logcat" (resp. in "/mnt/sdcard/wme.log" if you have debugging enabled):
V/org.libsdl.app(20467): 21:05:54: Orig w=1024 h=600 Transformed w=800 h=480 ratiox=0.78 ratioy=0.78
V/org.libsdl.app(20467): 21:05:54: BorderLeft=0 BorderRight=0 BorderTop=5 BorderBottom=6
The last line looks already suspicious to me, I will need to look into this.
I also added some debugging output to understand problems with touch offset. Please look for lines like these in the output of "adb logcat" (resp. in "/mnt/sdcard/wme.log" if you have debugging enabled):
V/org.libsdl.app(20467): 21:05:54: Orig w=1024 h=600 Transformed w=800 h=480 ratiox=0.78 ratioy=0.78
V/org.libsdl.app(20467): 21:05:54: BorderLeft=0 BorderRight=0 BorderTop=5 BorderBottom=6
The last line looks already suspicious to me, I will need to look into this.
148
WME Lite / Re: Any Linux developers out there?
« on: June 05, 2013, 06:30:53 PM »
I tried 2 versions of codelite which both denied to load the libtheoraplayer project 
I'll have to investigate whats going wrong there.
I merged my changes into the repo now, now I'll have to do some cleanup to be able to package all Android dependencies into one .zip like for the other platforms. For LInux things are different, distributions package (almost) all dependencies already, except for SDL2, which is easy to install from source.
I have uploaded a sample Android app into the BitBucket wmelite project (https://bitbucket.org/MnemonicWME/wmelite/downloads/SDLActivity-debug.apk). If you want to test it, please install the app and put your data files in "/mnt/sdcard" (which hopefully exists on most devices and has enough space - and sometimes it is even identical to the physical SD card).
I have not worked with the emulator a lot - if you actually have a device, it is far more convenient to quickly upload the app onto it for testing & debugging. But I don't want to stop you from trying, just download the Android SDK (and NDK if you want to compile from source). After installing at least one platform incl. ARM system image, you can setup & run the emulator.
I'll have to investigate whats going wrong there.I merged my changes into the repo now, now I'll have to do some cleanup to be able to package all Android dependencies into one .zip like for the other platforms. For LInux things are different, distributions package (almost) all dependencies already, except for SDL2, which is easy to install from source.
I have uploaded a sample Android app into the BitBucket wmelite project (https://bitbucket.org/MnemonicWME/wmelite/downloads/SDLActivity-debug.apk). If you want to test it, please install the app and put your data files in "/mnt/sdcard" (which hopefully exists on most devices and has enough space - and sometimes it is even identical to the physical SD card).
I have not worked with the emulator a lot - if you actually have a device, it is far more convenient to quickly upload the app onto it for testing & debugging. But I don't want to stop you from trying, just download the Android SDK (and NDK if you want to compile from source). After installing at least one platform incl. ARM system image, you can setup & run the emulator.
149
WME Lite / Re: Any Linux developers out there?
« on: June 04, 2013, 08:02:55 PM »
Removing boost worked for Linux and Android as well. No more boost dependency 
The libtheoraplayer looks quite difficult, so I did a quick-and-dirty #ifdef to disable it temporarily, so that the builds are working again.
What do you think about merging the changes from the src/ subdirectory of the fork to your main repo? I can do that if you're fine with that. I would also like to add the linux/ and android/ subdirectory. Then I could delete these from the fork, and keep the fork itself just for compiling the dependencies.
Do you have an Android device and are interested in testing the current state of the port?
The libtheoraplayer looks quite difficult, so I did a quick-and-dirty #ifdef to disable it temporarily, so that the builds are working again.
What do you think about merging the changes from the src/ subdirectory of the fork to your main repo? I can do that if you're fine with that. I would also like to add the linux/ and android/ subdirectory. Then I could delete these from the fork, and keep the fork itself just for compiling the dependencies.
Do you have an Android device and are interested in testing the current state of the port?
150
WME Lite / Re: Any Linux developers out there?
« on: June 02, 2013, 05:54:08 PM »Quote
* I removed boost dependency.Let me check whether Linux/Android still works.
Quote
* I added dependency on libtheoraplayer. That's a big one, I'm afraid. I guess it will complicate the Linux/Android build. Perhaps I could add a preprocessor switch to disable video functionality so that the engine builds without the video libraries?For the moment that would be a good idea. I can enable it once I have integrated it.
Quote
* For the iOS project I added a DejaVu font. It gets copied to the app bundle and the engine will use it as a fallback if loading a TrueType fails. Perhaps the Android version should do the same?Yes, I already added a callback to retrieve a path for searching fonts. Probably its not yet working, but at least I'm prepared