Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[HCDaniel]

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.

[HCDaniel]

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

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.

[HCDaniel]

Trying to define a way forward for Android.

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?

[Mnemonic]

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?

This blog post provides a solution for overriding the fopen() function  to access asset files. So that would solve reading. Then we'd "only" need to solve querying package files within the android asset files (should be doable, right?).

What about writing files? Will fopen work for creating files in some user's private directory? (for saving games, storing the settings, creating the log file)

[HCDaniel]

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:

• 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.

[2.0]

Hi!
Here is the log from Zopo C2 phone.

16:59: Scanning packages...
16:59:   Registered 323 files in 1 package(s)
16:59: Initializing scripting engine...
16:59:   Script compiler is NOT available
16:59: Loading string table...
16:59:   51 strings loaded
16:59: Orig w=1024 h=768 Transformed w=1920 h=1080 ratiox=1.41 ratioy=1.41
16:59: BorderLeft=240 BorderRight=240 BorderTop=0 BorderBottom=0
16:59: Engine initialized in 168 ms

The displayed art is OK, the cursor is displayed pixels 150-200 more right than the touch area.

[HCDaniel]

Hi Mnemonic,

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?

[Mnemonic]

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?

No, not really. The m_DrawOffsetX/m_DrawOffsetY are indeed not used by WME Lite (it's a remnant of regular WME code), but the actual mouse position translation is done elsewhere, specifically in CBRenderSDL::PointFromScreen() and CBRenderSDL::PointToScreen(). CBPlatform::GetCursorPos() does the translation so the physical display position *should* be properly converted to logical game position.

[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.

What I meant was combining your filename idea with the overridden fopen. This custom fopen would handle the different file types internally and the rest of the code using FILE* would just work. In theory anyway.

The other way would be getting rid of all direct calls to C file functions and wrap them into some abstract class, as you suggest. Doable, but it's used in many places. See below.

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.

CBFile is not the right place, though. It's a different level of abstraction. CBFile is a file abstraction from WME's point of view. WME doesn't care whether the file is a physical file, a file stored in a package, a memory file or whatnot.
What we need is an abstraction from operating system's point of view, if you know what I mean. So that the WME filesystem can ask "open a physical file, whenever it's stored in OS filesystem".
We need some kind of OSPhysicalFile class, that will encapsualte all FILE*, fopen, fclose, fseek etc. calls everywhere in WME code.
On most OSes it would just call the C functions as before, but on Android it would handle all the necessary translations.

[HCDaniel]

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.

[2.0]

Hi! Seems that this build is without logging. wme.log file isn't created in the root of sd card.
As for cursor coordinates - seems that they shifted in the X-axis for ~1.5 of width of black bar and remains unchanged everywhere independently of touch position.
The idea that the black bars on the sides of the scene uncertainty associated with the shift of cursor - quite possibly may be true. In this case shift width = width of the black stripe * scaling coefficient.

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.

[HCDaniel]

Ooops, sorry. I uploaded a build with debugging enabled now.

[2.0]

Here is the log:

Code: [Select]

23:18: ********** DEBUG LOG OPENED 13-05-2013 (Release Build) *****************
23:18: WME Lite ver 1.0.2beta, Compiled on Jun 13 2013, 21:03:22
23:18: Platform: Android
23:18:
23:18: Scanning packages...
23:18:   Registered 323 files in 1 package(s)
23:18: Initializing scripting engine...
23:18:   Script compiler is NOT available
23:18: Loading string table...
23:18:   51 strings loaded
23:18: Orig w=1024 h=768 Transformed w=1920 h=1080 ratiox=1.41 ratioy=1.41
23:18: BorderLeft=240 BorderRight=240 BorderTop=0 BorderBottom=0
23:18: Engine initialized in 160 ms
23:18:
23:18: Cursor point from screen x=0 y=0 <- left top of touch
23:18: Cursor point transformed x=69 y=0 <- in case of correct transform here is needed negative value of x etc
23:18: Cursor point from screen x=45 y=51
23:18: Cursor point transformed x=101 y=36
23:18: Cursor point from screen x=1896 y=29 <- right top of touch
23:18: Cursor point transformed x=1417 y=20
23:18: Cursor point from screen x=1887 y=42
23:18: Cursor point transformed x=1411 y=29
23:18: Cursor point from screen x=1887 y=42
23:18: Cursor point transformed x=1411 y=29
23:18: Cursor point from screen x=1879 y=1075 <- right bottom of touch
23:18: Cursor point transformed x=1405 y=764
23:18: Cursor point from screen x=44 y=1077 <- left bottom of touch
23:18: Cursor point transformed x=100 y=765
23:18: Cursor point from screen x=269 y=41 <- left top of scene
23:18: Cursor point transformed x=260 y=29
23:18: Cursor point from screen x=1679 y=1078 <- right top of scene
23:18: Cursor point transformed x=1263 y=766 <- right bottom of scene
23:18: Cursor point from screen x=260 y=1069 <-left bottom of scene
23:18: Cursor point transformed x=254 y=760
23:18: Cursor point from screen x=260 y=1069
23:18: Cursor point transformed x=254 y=760
On-screen debug log displays modified (transformed) coordinates, as I understand.
Seems that correct values are:
TransformX = (TouchX-BorderLeft)/ratiox
TransformY = (TouchY-BorderTop)/ratioy

[HCDaniel]

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

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?

[HCDaniel]

I have uploaded a new build with viewport transformation removed. It works for me using the demo project. Can you give it a try?