Jump to content

Android port


Guest afeder
 Share

Recommended Posts

oh, this is really a miracle, this game was finally able to run on a mobile platform, it can really play on this phone? I really look forward to, I have a Samsung I9220 mobile phone with a resolution of 1280 * 800it should be able to completely run the game, ha ha!

BTW: If it really be able to play on a mobile platform.:banana::victory::drunk::cheers::D(y):P

Link to comment
Share on other sites

Would it be able to be converted to iOS?

The technologies are pretty similar (C++, OpenGL ES, ARM, etc, with SDL doing most of the platform integration work) so it should be feasible if anyone cared to do it. Porting to Windows for ARM would probably be a bit more technically interesting - I guess you'd have to use ANGLE to translate GLES into DX9, but otherwise it still shouldn't be much different.

The biggest problem is that the current RTS gameplay design seems like an awful fit for phone-sized devices (since it requires presenting too much information to the player, and requires too much precision of input, and requires concentration for long periods), and not much good for tablet-sized devices either, so someone would have to solve that too :)

(To clarify my current interest in this: I don't care about making a proper playable game on Android, and I'm not intending to spend any time trying to achieve that. I'm just personally interested in learning about the technical aspects of the platform, and porting the game engine as a tech demo seems a better approach than spending the time on some throwaway toy project instead, since it encounters more interesting issues and produces a more impressive result, and it also indirectly helps the game on the proper desktop platforms (by cleaning up some of the rendering code (avoiding global GL state), and by adding GLSL support which will simplify new graphical features and may improve performance or driver compatibility, and by dealing with some portability problems, etc).)

Link to comment
Share on other sites

iOS support shouldn't be too hard, Apple has done a decent job of integrating the APIs for OS X and iOS (from what I've seen). Supposedly this will get even better, if we can create a bundle for OSX, it's feasible we can create an app for iOS, but I have serious doubts about whether it would qualify for the App Store. I would say focus on OS X and completing the game generally, then that will attract people with iPhones and iPads and whatever else, who can work on porting it. Although just having the basic Android demo is really exciting :)

The game's default resolution should be set to choose from, for example: 640 * 480 800 * 600 1024 * 768 ....... Thank you!

I agree, this would be a good feature not only for mobile devices but desktops as well. We should be able to detect supported resolutions and offer them as choices. It's easy to do that, but a functioning in-game options system needs to be designed first/concurrently.

Link to comment
Share on other sites

Can these devices can even support the quantity of processing the game requires? How long can we play before the battery's done? I think that IF the programmers one day think about releasing 0 AD for mobiles, it should be a spin-off title proper to mobiles, much simpler and with a different gameplay, caring more for the device than the game itself, as you will probably like if the game is complex, but when you play it you'll be bored to have to recharge your device again just because you wanted to play while at the bathroom and feel really bored about the battle you lost because you weren't fast enough to touch-screen your army to defend your base.

Link to comment
Share on other sites

This game can play on Android? I think we should make this game run on the Android system, which is a great game, we need it to run on the Android system can run on the Samsung I9100 mobile phone has beena great progress, I think our development team should be efforts to make the game better able to run on the Android system, our team can not give up on the Android system support, thank you!:banger::victory::flex:

Link to comment
Share on other sites

Please, stay judicious. Focus on developing the game in the right direction. I didn't thought that it would be ported so fast and as it is (partly) done now I think it's cool to see, especially the stuff that Ykkrosh told, but it doesn't really improve the game. However, my respect for everyone included porting the game.

Edited by Almin
Link to comment
Share on other sites

To clarify my current interest in this: I don't care about making a proper playable game on Android, and I'm not intending to spend any time trying to achieve that. I'm just personally interested in learning about the technical aspects of the platform, and porting the game engine as a tech demo seems a better approach than spending the time on some throwaway toy project instead, since it encounters more interesting issues and produces a more impressive result, and it also indirectly helps the game on the proper desktop platforms (by cleaning up some of the rendering code (avoiding global GL state), and by adding GLSL support which will simplify new graphical features and may improve performance or driver compatibility, and by dealing with some portability problems, etc).

Read this again guys. The porting that is going on right now is NOT about making a playable spinoff game, or anything about that. it is about cleaning up the Code. These days, as standardization is better than before, porting doesn't necessitate having to separate code trees, or quick hacks. If one does it right, (which these guys are), it means one's code will "play by the rules" better than ever, be "properly modular" (all the somewhat unsystematic #ifdef's are just an intermediary step).

Then you guys might say, "well if the point is just cleaning up the code, isn't this an inefficient, roundabout way to that? Well if one could consistently visualize every issue that would arise porting a program, then one's code wouldn't need to be cleaned up in the first place.

Link to comment
Share on other sites

Read this again guys. The porting that is going on right now is NOT about making a playable spinoff game, or anything about that. it is about cleaning up the Code. These days, as standardization is better than before, porting doesn't necessitate having to separate code trees, or quick hacks. If one does it right, (which these guys are), it means one's code will "play by the rules" better than ever, be "properly modular" (all the somewhat unsystematic #ifdef's are just an intermediary step).

Then you guys might say, "well if the point is just cleaning up the code, isn't this an inefficient, roundabout way to that? Well if one could consistently visualize every issue that would arise porting a program, then one's code wouldn't need to be cleaned up in the first place.

I agree with you, we should continue to develop it, our development team should work for it, our team can not give up the mobile platform, the lack of good games like this, we need this game to run on a mobile platform, please do notgive up, thank you! :flex:B)

BTW: the game should be the development of multiple platforms, thank you!:D

Edited by gameboy
Link to comment
Share on other sites

Nice Work, Team!:banana::victory::banana::crazy:(y):D:P

This is great, I saw, I want to know, the game lens can zoom, the camera can zoom in?:banana::victory:

BTW: But our team, they will continue to develop down you, I mean: they will continue to develop the Android version? I'm looking forward to the mobile version of the game, Android is a good operating system, an ad should run in Android system, thank you!:banana:

BTW: If I compile a version of Android (How do I compile the Android version of the game, on the patch colladacache + archivebuild_fixes-02172012.patch), can run on the Samsung I9220 mobile phone or tablet this game.

: "Note: it skips over broken DAEs, these would the trigger errors if used in the game anyway, so there's no advantage. In archiving them

Is it true that the game does not read games archive? Or can not be archived game?

Edited by gameboy
Link to comment
Share on other sites

OK, now it's time for you Android fans to take over the work :P

This is great, I saw, I want to know, the game lens can zoom, the camera can zoom in?:banana::victory:

Nope, it will need gestures for this, see http://trac.wildfiregames.com/wiki/AndroidPort#Userinterface

BTW: But our team, they will continue to develop down you, I mean: they will continue to develop the Android version?

Official developers probably won't spend much time on it, other than what's been done, possibly applying patches. It's up to the community now.

Link to comment
Share on other sites

Thanks quantumstate, that's good to know.

By the way, as you changed the file build/premake/extern_libs4.lua, the Troubleshooting at the wiki article for Building Instructions(http://trac.wildfiregames.com/wiki/BuildInstructions#Linux) is no longer correct:

"If you get linker errors like cannot find -lboost_signals-mt (particularly users of Slackware 13.37 and -current), edit the file build/premake/extern_libs4.lua and remove the -mt suffixes from the boost definitions in line 212, and then run update-workspaces.sh again. It should look like this:

unix_names = { "boost_signals", "boost_filesystem", "boost_system" },"

These are now stretched over a couple of lines, namely line 221 and line 230. Could someone correct that in the wiki article?

edit: and by the way the other troubleshooting tells you to delete a line from build/premake/premake.lua but the file is called build/premake/premake4.lua ;)

Edited by Almin
Link to comment
Share on other sites

This game should be developed into a multi-platform, it can not be selling out. Our team should (game development), but continue to develop the Android version must wait until the other platform versions of the formal launch of the multi-platform development, such as: Windows, linux version.:unsure::cheers:

BTW:We look forward to our team to Android version an ad to continue to develop down.

Thank you, the best game team.:drunk::victory:

Link to comment
Share on other sites

While on the subject of performance, I grabbed some profiles showing where time is spent during the processing of a typical frame (in the default view on Oasis, with no AI etc).

Top row: PC (Intel Core i5-2500K, 3.2GHz, 32KB L1I$, 32KB L1D$, 1MB L2$, 6MB L3$), MSVC. Vertical grey lines are 0.1ms.

Bottom row: Samsung Galaxy S II (Exynos 4210 / ARM Cortex-A9, 1.2GHz, 32KB L1I$, 32KB L1D$, 1MB L2$), GCC (-mthumb -mcpu=cortex-a9 -mfpu=neon). Vertical grey lines are 1ms.

android4.png

In both cases it seems to be primarily CPU-limited, not GPU-limited. "sim interpolate" is purely on the CPU (computing model transform matrices, fog-of-war status, etc), and is about 12x slower on ARM than on Intel, which sounds plausible as the general CPU performance difference for branch-heavy code; it would probably benefit from high-level optimisations that would work the same on all platforms. "prepare models" is more like 100x slower on ARM, which I guess is because it's mostly computing skinned meshes, which is SSE-optimised on Intel; ARM would probably benefit from similar low-level optimisations (using NEON) (or using vertex shaders, maybe). So there seems to be plenty of scope for improving performance significantly, and modern Android devices could probably sustain ~30fps on more complex maps. (Improvements to pathfinding, AI, multi-core support, etc would all be needed too, but they're important for PCs anyway.)

Link to comment
Share on other sites

While on the subject of performance, I grabbed some profiles showing where time is spent during the processing of a typical frame (in the default view on Oasis, with no AI etc).

Top row: PC (Intel Core i5-2500K, 3.2GHz, 32KB L1I$, 32KB L1D$, 1MB L2$, 6MB L3$), MSVC. Vertical grey lines are 0.1ms.

Bottom row: Samsung Galaxy S II (Exynos 4210 / ARM Cortex-A9, 1.2GHz, 32KB L1I$, 32KB L1D$, 1MB L2$), GCC (-mthumb -mcpu=cortex-a9 -mfpu=neon). Vertical grey lines are 1ms.

android4.png

In both cases it seems to be primarily CPU-limited, not GPU-limited. "sim interpolate" is purely on the CPU (computing model transform matrices, fog-of-war status, etc), and is about 12x slower on ARM than on Intel, which sounds plausible as the general CPU performance difference for branch-heavy code; it would probably benefit from high-level optimisations that would work the same on all platforms. "prepare models" is more like 100x slower on ARM, which I guess is because it's mostly computing skinned meshes, which is SSE-optimised on Intel; ARM would probably benefit from similar low-level optimisations (using NEON) (or using vertex shaders, maybe). So there seems to be plenty of scope for improving performance significantly, and modern Android devices could probably sustain ~30fps on more complex maps. (Improvements to pathfinding, AI, multi-core support, etc would all be needed too, but they're important for PCs anyway.)

Very good. Hi, Ykkrosh, I would like to know if a game, Samsung Galaxy S II will bring us what kind of effect?

In my opinion this game should support multi-core processors, not only is the PC platform, multi-core CPU for mobile platforms also need to be supported, thank you!:victory::cheers:

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

 Share

×
×
  • Create New...