Print

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

[HCDaniel]

In Android, main() is not the starting point of an app. If you want to run native code, this has to be done via the Java-Native-Interface. So even in the case of WME which itself does not contain any Java, a small Java skeleton app is provided by SDL2 in order to let it run.

Furthermore I assume that any way to fetch the packages with the game data will be done in the Java domain, before WME is started (unless they are <50MB and they can be bundled with the app). In case of fetching via Google Play, there are libraries distributed by Google for that purpose.

In either way, the Java part of the app knows the path to the game packages, and could supply it to WME. I thought that the easiest (and maybe most platform independent) way is to add a cmdline switch for that. It could be useful for Windows and Linux where you have a command line (maybe Mac OS as well), and on Android it is supplied by the Java skeleton app.

Agreed, anything that is possible in Java is also possible to do in C, but it is more difficult to achieve and certainly not platform-independent.

I hope this clarifies a bit.

[Mnemonic]

It would be certainly possible to add a command line switch for registering more search paths. In fact, there already is a similar switch (-project) that's used to run the game from sources. It does chdir() to the specified directory, so that the engine finds files using the default "./" search path.

In this case, though, I don't think it would be a problem to add some platform-specific code to FileManager. There already are #ifdefs for OSX and iOS anyway

Also, please keep in mind the ports should implement the PathUtil::GetUserDirectory() method, i.e. the path where WME Lite stores user settings.

[HCDaniel]

For the moment I have hardcoded "/mnt/sdcard" so that I can at least test how wmelite works on Android. Graphics output and sound work, font display is currently broken (might be due to the pretty old libfreetype that I am currently including) and touch input has a strange offset (it currently shows the mouse pointer some 50 pixels below where I touch), so I can walk around in the demo but not use anything or talk to the person.

In order to fill out the platform-dependent sections, are the two places you mentioned all that I should check? Or should I just grep the sources for all #ifdefs?

[Mnemonic]

These are the vital ones. If you search for __IPHONE__ you'll find many other tweaks, but I don't know which of these (if any) would be relevant to Android.
For example, in iOS when the user switches away from your app, the app is supposed to save its state. WME Lite is using this event to automatically save the game.

[HCDaniel]

Ok, so I can take a look at the various defines soon. A similar mechanism to ask the app to save its state exists in Android as well, so I think this could be implemented in a similar way.

Meanwhile I did some more tweaks so that true type font rendering works. The correct way to fix this will be to add proper search paths. The only remaining major issue is now the touch offset. The game screen is aligned to the left bottom of the display, but the y-offset of the touch event is somehow added twice, so that the cursor is located always below the point where the touch happened. Do you have any idea what might cause this?

[Mnemonic]

The pointer position is handled in CBPlatform::GetCursorPos(). It tries to convert from display position to game position using current viewport and screen scale. Perhaps try checking what's the original reported position (that comes from SDL_GetMouseState) and which of the conversion breaks it?

[HCDaniel]

Thanks for the pointer. I found that there no viewport translation happens, which was strange. The real problem was from my point of view that the query for possible resolutions was #ifdef __IPHONEOS__ only, so I added a define for android. Voila - fullscreen graphics and proper coordinates So while there's probably still a lot of work to do, I'm glad that wme lite seems to start looking interesting on Android now.

[Mnemonic]

Woohoo, you rock

I noticed one more function that should be probably re-implemented for Android, the Game::GetDeviceType() method. On iOS it returns either "tablet" or "phone". The package loader uses it to load packages specific to device type.

[HCDaniel]

I have just checked where platform specific code is used in wmelite. I found these defines

   cat $i | grep "__WIN32__";
   cat $i | grep "__MACOSX__";
   cat $i | grep "__IPHONEOS__";
   cat $i | grep "_MSC_VER";
   cat $i | grep "__APPLE__";
   cat $i | grep "__IPHONE__";
   cat $i | grep "__OBJC__";

which indicate that some platform specific stuff is going on. I can check the corresponding files, and maybe add a "LINUX" or "ANDROID" define where applicable, once I am sure about the actual implementation. What makes me wonder though are the different defines for Apple platforms. Is there any reason for that, or shall I just ignore the different labels and carry on?

As for the Game::GetDeviceType() call, I currently don't know how to implement it properly. I need to check whether Android actually has such a distinction. The game I tested runs fine on an old Samsung phone (probably 4''), as well as Googles Nexus 7 and an older Acer tablet (10''), so is there any need to distinguish between phone and tablet?

[Mnemonic]

The #defines are a mixture of those defined by xcode and those defined by SDL (see SDL_platform.h) - that's why the IPHONE/IPHONEOS inconsistency. SDL already contains #defines for android and linux, so perhaps you can use those?

As for the device type, when WME Lite is loading game packages, and the package name matches the pattern xdevice_[device type].dcp, the engine will only load the package if the device type matches. This was meant for being able to create a universal game that will, for example, use a different UI on tablets and different on phones (phones need typically larger controls than tablets).

[HCDaniel]

Ok, didn't know that SDL has its own defines, so I will use them.

I found quite some places in the code where platform dependent stuff is going on, so I was wondering whether you considered creating an OS abstraction layer to ease porting? I'm personally mainly interested in Linux and Android, so I'm also fine with just checking all the #defines, just wondering whether you want to collect all OS dependent stuff in one central place?

Now I understand where the device types come from. In Android I can probably ask for screen size and density - so maybe I can make a decision based on that. There are a lot of devices, and sometimes you cannot tell whether it is a phone or a tablet 

I'll continue with asking you for platform-dependent functions that I do not understand, once I encounter them

[HCDaniel]

Ok so here now a bunch of questions about platform dependent stuff which I do not understand:

CBGame::CBGame():CBObject(this)
what are the effects of setting "m_TouchInterface"  and "m_ConstrainedMemory"?

what do "ShowStatusLine" and "HideStatusLine" script commands do?

CBRenderSDL::Flip() and CBRenderSDL::SetViewport(int left, int top, int right, int bottom)
what kind of IOS or SDL "bug" is the workaround for?

CBSoundMgr::Initialize()
what is the IOS specific tweak to BASS?

CBPlatform::Initialize(CBGame* inGame, int argc, char* argv[])
what's the event watch, and why would I want it?

CBPlatform::HandleEvent(SDL_Event* event)
what does the IOS specific code do?

I don't get at all what CSXStore class is for

For the rest it is clear to me what is meant, so I can implement the Linux/Android part. BTW I would like to add my changes of the regular WME to WME lite. I have one pull request for you and one more to come. Could you have a look?

There's one thing (maybe specific to Android) which could be added somehow, if possible. Android can show an "Options" or "Menu" key if the App is set up appropriately. This could be used to display a menu or options window in wmelite (like in regular WME a window can be shown which overlays the game). Is that something that can be done?

[Mnemonic]

CBGame::CBGame():CBObject(this)
what are the effects of setting "m_TouchInterface"  and "m_ConstrainedMemory"?

'm_TouchInterface' currently mainly increases the height of the dialog responses so that they are easier to select on a touch screen.
'm_ConstrainedMemory' disables caching of TrueType fonts to consume less memory. Probably no longer needed, it was an issue only on the old iOS devices with very limited memory.

what do "ShowStatusLine" and "HideStatusLine" script commands do?

On iOS the app can choose whether the status line (the top line displaying battery status, clock, operator etc.) is visible or not.

CBRenderSDL::Flip() and CBRenderSDL::SetViewport(int left, int top, int right, int bottom)
what kind of IOS or SDL "bug" is the workaround for?

Well, back then the screen rotation in SDL didn't work properly. I hacked it in, but viewports were terribly broken so I just didn't use them. This probably needs a revision.

CBSoundMgr::Initialize()
what is the IOS specific tweak to BASS?

It's supposed to allow "audio ducking" (if other audio is on, it's smoothly silenced and the game audio crossfades in) and also sets a sound category that allows muting game audio with a hardware mute button. Now that you mention it, I think it the value should be 6, not 5:) Gotta fix that.

CBPlatform::Initialize(CBGame* inGame, int argc, char* argv[])
what's the event watch, and why would I want it?

This is used to handle app deactivation (to autosave the game). Because of the way SDL events are handled, on iOS the app didn't receive the SDL_WINDOWEVENT_MINIMIZED event when the user deactivated the application, but only after the app's been restored. For that reason WME Lite registers this event watcher to receive the event in time. It might be fixed in the current version of SDL, I haven't tried.

CBPlatform::HandleEvent(SDL_Event* event)
what does the IOS specific code do?

You should enable this for Android too. Without this it's hard to press GUI buttons on a touch screen.

I don't get at all what CSXStore class is for

It allows in-app purchases using AppStore API. This is highly iOS specific. Even though Google Play supports in-app billing as well, I don't know if the APIs are similar enough to provide the same interface for WME scripts. Probably not.

BTW I would like to add my changes of the regular WME to WME lite. I have one pull request for you and one more to come. Could you have a look?

I don't see any pull request currently. I can grant you write access to the main repository, if you think it will make your life easier.

There's one thing (maybe specific to Android) which could be added somehow, if possible. Android can show an "Options" or "Menu" key if the App is set up appropriately. This could be used to display a menu or options window in wmelite (like in regular WME a window can be shown which overlays the game). Is that something that can be done?

Since there's no standard way of displaying an in-game menu in WME (it's completely under the developer's control), I think the best way would be to send some named event to Game object, and the game developers could handle the event as they see fit?

[HCDaniel]

Thanks for all the explanations, it'll take a while until I have understood and ported everything to Android/Linux. You'll see the progress in the wmelite fork anyway

The pull requests I meant are for the original wme (wme1), I have one request and one more to come. Once this is all sorted out I would remove the fork.

[Mnemonic]

Oh yes, I'm aware of the pull request. I'm kind of neglecting regular WME while working on Lite

Speaking of WME Lite, some of the recent changes:
  * I removed boost dependency.
  * 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 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?