bog_dan_ro
-
Posts
27 -
Joined
-
Last visited
Posts posted by bog_dan_ro
-
-
You can try to reinstall it (uninstall the install again).
It should work on Nexus 10.
-
If you've update it, the you should have the last one. Don't forget that if your card doesn't have OES_mapbuffer extension the application will crash just before you'll start the game! You can use this application to check if your graphics card has it.
-
Still doesn't work for me. The icon glows and then nothing. If I press it enough, it will change to landscape really quick and then change back. I found a logcat file, but it was mostly unreadable do to the encoding? I did see an error in the 0ad logs though relating to GUI pages:
0 A.D. Main logCannot find config file "config/default.cfg" - ignoring
Cannot find config file "config/local.cfg" - ignoring
[...]
ERROR: CCacheLoader failed to find archived or source file for: "shaders/effects/gui_text.xml"
ERROR: Failed to load effect 'gui_text'
[...]
It seems you don't use the latest version. Please make sure you are installing *0.4 alpha* version not 0.3 !
-
[...]
E/libEGL (11890): called unimplemented OpenGL ES API
--------- beginning of crash
F/libc (11890): Fatal signal 11 (SIGSEGV), code 1, fault addr 0xefdcbd55 in tid 11937 (SDLThread)
I/libc (11890): Suppressing debuggerd output because prctl(PR_GET_DUMPABLE)==0
[...]
Thanks!
Sadly, I was right, your device doesn't have glMapBufferOES
.-
1
-
-
The crash happens because your devices don't have glMapBufferOES extensions needed by 16241 changeset (on my Nexus 10 I don't have that problem, but I've seen it on my ASUS Padfone Infinity). Anyway tonight I'm going to try revert that path locally to see if I can make it work without glMapBufferOES, if it works I'll publish a new version tonight.
I think Philip needs to check if there is a better way to fix the problem.
-
1
-
-
I'm going to make it simple to test. I'm going to use publish it on google play in the alpha area, using my own account and with a different package name to allow wildfiregames to publish it using the real package name when the game will be production ready.
People who want to test it, they need to do the following steps:
- join https://groups.google.com/forum/#!forum/wildfiregames google group. I just created it a few minutes ago and I really like to give it to windfiregames sysadmins, so sysadmins please send me a mail or PM and I'll pass you the ownership.
- after you've joined wildfiregames group, hopefully you'll get a message from google play when the package will be published (I upload it a few minutes ago, but it takes some time until it gets published, so please be patient!).
- This is the link to testing package
- follow the instructions from that link.
A few words about its status:
- You need a device with GLES 3.0 or better.
- You need a mouse because, currently, is not touch friendly at all. Sadly I have no idea how make it touch friendly ...
- Even now it looks stable (no more crashes I hope) don't forget that the game runs very slow even on high end devices.
- If it crashes, I need the logcat from your device!
I don't think I'll have enough time to update to than once in a week and only if there are changes that matters.
-
1
-
- Because the patches are big I did some mistakes and now (only) the fonts are screwed (on Android and on Desktop as well). Sadly I tried to fix it, but I failed ...
I managed to fix half of the fonts probems, now only the bold fonts are screwed
. I've also seen that there are a few problems with the terain textures and the corner of the message windows. -
In principle it should "work" on any GLES 3.x devices (GLES 3 is needed for ETC2).
Actually using KTX instead of DDS doesn't require the textures to be ETC2. You can compress them with anything that device supports and it should work without any changes in the game engine. Of course you need to find a way to compress them, so most probably you'll end up doing some changes in AcrhiveBuilder&TextureConvert classes.
-
I wonder how well the game would run on one of these Android mini pcs? I've had it barely run on a Raspberry Pi (not practical), but recent Android PCs-on-sticks appear to have much better specs like multicore CPUs and more RAM.
In principle it should "work" on any GLES 3.x devices (GLES 3 is needed for ETC2). The problem is that 0 A.D. struggles to run on my high-end devices
. I own one of these android mini pcs and from my experience they are not that powerful. Yes the hardware is *much* better than Pi (even much better than Pi2) but still not enough to run flawlessly 0 A.D. ... -
Hello folks,
I have some good and not so good news to share with you
Let's start with the good news:
- I managed to use ETC2 + KTX textures on Android!
- The memory usage (RSS) now stays under 750Mb which is great! On my phones the game is not killed anymore by the O.S.. It's still a lot but at least it survives
- The game speed is ~the same as using uncompressed textures. It feels faster when it starts.
Now the bad news:
- I could not make incremental changes, the S3TC was quite tight integrated into the engine.
- Because the patches are big I did some mistakes and now (only) the fonts are screwed (on Android and on Desktop as well). Sadly I tried to fix it, but I failed ...
If anyone can help to fix the fonts problem it will be very much appreciated!
The repo is on my github fork: https://github.com/bog-dan-ro/0ad ktx branch. Last 5 commits are KTX/ETC2 releated.
Steps to compress the textures for android using etc2:
- download Mali's texture tool
- unpack it and make sure etcpack is in your $PATH
- use the same branch to build a non-android version of the game, the run :
$ mkdir temp
$ binaries/system/pyrogenesis -archivebuild=binaries/data/mods/public -archivebuild-output=temp/public.zip -archivebuild-compress -etc2
$ binaries/system/pyrogenesis -archivebuild=binaries/data/mods/mod -archivebuild-output=temp/mod.zip -archivebuild-compress -etc2-
1
-
-
The Android Extension Pack requires ASTC. The AEP is not mandatory, but GLES 3+ isn't mandatory either - what matters is what the GPU vendors choose to support. (I think even GLES 2.0 wasn't mandatory until KitKat, but pretty much everyone supported it long before that.)
ASTC does seem like it will be widely supported in the future - Mali-T622, PowerVR Series6XT, Adreno 420, Tegra K1. Support is not great right now, but any decent Android port of the game is going to be a long-term project, and if we're going to spend effort on new texture compression formats I think it may be better to spend the effort on one with better long-term prospects.
(And ASTC has better quality at the same bitrate, and much more flexibility in choosing bitrates (possibly the most useful feature - we can trade off quality against memory usage and texture bandwidth), so if compatibility was equal, it would be the better choice.)
Well, if my proposed changes (using KTX, change Tex struct, etc) are ok with you, then we can switch at any time, to any texture type, without changing a single line in the engine
. All the information we need to upload and use the texture is in the KTX file.I still don't see how that's possible - S3TC and ETC2 are both 4bpp for RGB (and for RGB with 1-bit alpha), and both are 8bpp for RGBA, and the DDS/KTX headers should be negligible, so there should be no difference, as far as I understand.
I have no idea why , but I'm more than happy to share the changes that I did to the engine to compress the textures as ETC2. Considering that I did it in a few minutes, maybe I did something wrong ...
DDS is also flexible enough to be used in combination with any texture format, so I don't think that's an argument in favour of KTX
. Using two different texture containers seems needlessly complex. We could switch the generated textures to KTX on all platforms, but we still need to support DDS input because lots of the original textures in SVN are DDS (from the days before we supported PNG input), and it sounds like more work than just updating our DDS reader to support a new compression format.I *briefly* checked DDS format and it doesn't seem to be as good as KTX (at least for OpenGL, it's quite inferior). KTX header contains everything we need to use *any* texture without changing a single line in the engine (of course the GPU must support it, at least on Android, it will not be a problem). IMHO switching to KTX format is a step forward. I totally agree with you that we need to support DDS format an input (Mali's etcpack supports lots of formats for input, including DDS ;-) ).
In general, changing our texture code is perfectly fine - it has evolved slightly weirdly, and it supports features we don't need and doesn't support features we do need, so it would be good to clean it up to better fit how we want to use it now. (I don't know enough to comment on your specific proposals off the top of my head, though
. Probably need to sort out the high-level direction first.)Ok, then I'll start with incremental changes (e.g. adding TexCodecKtx, and changing the Tex struct.
NVTT hasn't had a release for about 5 years, and we want to rely on distro packages as much as possible, and they only really want to package upstream's releases, so changing NVTT is a pain
. (The distros include a few extra patches we wrote to fix some serious bugs, but I doubt they'll be happy with a big non-upstream patch adding KTX support and changing the API). It'd probably be less effort to write some code to transcode from DDS to KTX, than to get NVTT updated.Ah, I didn't know it is that difficult to upstream patches to NVTT. Ok, then I'll write a converter inside our project.
-
Hello folks,
I'd like to give you an update:
- Philip' started to upstream my android patches.
- I also checked more the compressed texture status on Android:
* our target should be GLES 3+ devices. Because pyrogenesis needs quite a lot resources, IMHO there is no need to try to target low/mid-end devices.
* use ETC2. Because is the only compressed texture format that is mandatory on all GLES 3+ devices. ASTC is not mandatory nor widely used. Here you can find more infor about the options that we have on Android.
* as you could see from this thread, the only problem is to find an FOSS tool/library the we can use to compress pyrogenesis images. I've found one which is fully FOSS, it's called texgenpack (it also has a page on sf.net). The problem with this tool is that it's quite slow and the compressed image quality is pretty low, comparing with Mali's texture tools.
* anyway, I wanted to check how good is Mali's etc2 comparing with S3TC, so I changed AchiveBuilder a little bit to use Mali's etcpack instead of nvtt and I compressed all textures (with RGBA and mipmaps where needed) using KTX format. After it finished I compare it with S3TC. The (raw) S3TC (dds) images size is ~800Mb and the ETC2 (KTX) images size is ~680Mb, as you can see ETC2 images have ~17% less size, which is good. I also compared a few random images and all ETC2 images looked better than S3TC, which is great
. The problem is still that we don't have a fast FOSS ETC2 library, as Ykkrosh pointed Ericsson's etcpack library is not quite FOSS because it doesn't allow us to change it. I checked a little bit more their source code and it seems that *only* etcdec.cxx has that stupid limitation, the rest of the files seems to be ok. With some effort we can replace etcdec.cxx functions with the one from mesa.
But before we do that, IMHO we should see what's the main use-case of pyrogenesis on Android:
- I think on the fly compression on Android is a no go, it will take ages until a tablet will compress all the textures ...
- On the fly compression on Android, is only needed for custom uncompressed mods and to be able to share a mod with other O.S. (e.g. push a mod from you desktop to your tablet). But is this the main use-case? IMHO no, I think the main use-case will be: wildfiregames will compress all the game data using the best tools available to create the best images, then create a big OBB, and publish it together with the pyrogenesis engine as 0 A.D. Application on google play. 99.99% of Android users will use the Google play application. Anyway, if somebody wants to create a custom compressed mod for android (os just wants to build it himself), then he just needs to have in his $PATH the tool that pyrogenesis ArchiveBuilder uses to compress etc2 textures. Of course the engine will still be able to load and use uncompressed textures, which are needed when we hack on pyrogenesis.
The next step that I'm working now is to add ETC2 support in pyrogenesis. But the engine seems quite tied to S3TC/DDS and I'd like to ask pyrogenesis developers if is ok to do the following changes:
- (at least on Android) use KTX format instead of DDS. KTX is flexible enough to be used in combination with any textures format.
- change a few things to Tex struct :
* instead to "guess" glType, glFormat, glInternalFormat, glBaseInternalFormat needed to upload the textures, I'd like to add this fields directly to Tex struct.
* remove most of TexFlags? The above fields will give us enough information about the texture type (e.g. is compressed, has alpha, etc.)
* do we need (or we'll do in the future) cubemap faces?
- add a new virtual function to ITexCodec which will handle the cubemap faces, mipmaps, this function will be used by "tex_util_foreach_mipmap" to get the cubemap face/mipmaps data instead to compute it itself.
- I think there is no need for TexCodecKtx (the codec that will handle the KTX files) to uncompress on the fly the ETC2 textures, because we know for sure that *all* GLES 3+ devices support it. Of course if pyrogenesis developers will like to use KTX also for desktop, then we'll need to uncompress S3TC textures where the hardware doesn't support it. But, IMHO it should be done ouside of TexCodecXXXXX. If pyrogenesis developers will agree to use KTX everywhere, then I'll volunteer to add KTX support to NVTT
.- change all the other places where the engine assumes that the compressed texture is S3TC and the container is DDS.
-
That looks like a non-GPL-compatible (and non-OSI) licence, e.g. you're only allowed to distribute source in "unmodified form" and only in "software owned by Licensee", so it's not usable.
That just calls into etcpack, so it has the same licensing problems.
Ah, I didn't read the license ...
Licence looks okay, but it sounds like quality may be a problem (from the blog post: "As for the resulting image quality, my tool was never intended for production usage").
That was his first version/blog about it, check his latest version/blog. IMHO the biggest problem is that it doesn't support ETC2/EAC ...
-
Hmm, ETC2 sounds like it might be good - same bitrate as S3TC (4bpp for RGB, 8bpp for RGBA) and apparently better quality, and a reasonable level of device support.
Yep, according to this site ETC2 is quite good ;-).
Also Google says: "The ETC2/EAC texture compression formats are guaranteed to be available when using the OpenGL ES 3.0 API. This texture format offers excellent compression ratios with high visual quality and the format also supports transparency (alpha channel)."
(Integrating it with the engine might be slightly non-trivial though - we use NVTT to do S3TC compression but also to do stuff like mipmap filtering and to generate the DDS files, so we'd need to find some suitably-licensed good-quality good-performance ETC2 encoder and find some other way to do the mipmaps and create DDS etc.)
I've found two:
- RwgTex - seems quite good, lots of input/output formats ...
- etcpak - Check this blogpost. It seems it doesn't support ETC2/EAC thought ...
- it seems there is another etcpack from Ericsson which might be open source, but I can't access any of their web sites ... I've found their source code in here https://github.com/paulvortex/RwgTex/tree/master/libs/etcpack , its opensource.
There are other closed-source (but free) encoders available for almost all major platforms.
-
Oh, sure, but then it's just a problem of the game being fundamentally not designed to run on that kind of hardware, which is a totally different problem to a memory leak bug (though probably a harder one to fix)
If the game stays under 1.3Gb it will not be a problem, but it grows way too much and Android kills it.
It's not available on any devices I've used (Adreno 320/330, Mali-400MP, VideoCore) - as far as I'm aware, only NVIDIA supports it on mobile. But I think the game will use it automatically whenever it's available. (public.zip always contains S3TC-compressed textures, and the game will detect whether the drivers support S3TC, and if not then it will just decompress the textures in software when loading them.)
You're right
. I digged a little more in this area, and I found that ETC2/EAC has alpha support and is mandatory in OpenGL ES3 (which is available on most Android 4.3+). Is ETC2/EAC a viable alternative?
-
Hello folks,
I've updated AndroidPort wiki page. It will be great if someone will try it, to see setup, compiling, running & debugging works
.I also upload the first patch set here
-
1gb of ram is huge for a device that has only 2gb for the entire OS.1GB isn't that much, depending on the map and game settings - if I run on desktop Linux with nos3tc=true (to mirror the lack of working texture compression on Android), on "Greek Acropolis (4)" with default settings, I see resident memory usage ~1.3GB. With S3TC enabled it's ~0.6GB. I think that indicates there's a huge volume of textures, and we don't (yet) have any options to decrease the texture quality or variety, so you just need a load of RAM.(Texture compression is kind of critical for Android, but ETC1 is rubbish and doesn't support alpha channels, and nothing else is universally available. It would probably be most useful to support ASTC, since that's going to become the most widely available in the future, and has good quality and features.)
It seems that s3tc is available on quite a lot of android devices. Is it enabled st runtime? Or I need to set some compile flags?
Here http://developer.android.com/guide/topics/graphics/opengl.html#textures is the complete list of supported formats.
The problem with having a very large number of GL calls is usually the CPU cost of those calls, so the bottleneck might still not be the GPU
as I said my gl skills sucks.
-
Hi!
I slowdown the development a little bit because of the GLES errors, and I focused on an easy way to "debug" the GPU on Android. I tried different tools (which none of them worked as I expected) and I end up using apitrace. But even with apitrace it wasn't perfect because it does the retrace on desktop and the GLES implementations are quite different, and I didn't get the same errors on Desktop. So I had to find a way to do the retrace on Android .... This way I end up working on an apitrace retracer for Android
.The good new are that I managed to finish the retracer and also I integrate it in the UI
. Last night I created the pull request ( https://github.com/apitrace/apitrace/pull/311 ). I need someone who knows GL(ES), to help me to fix these errors and also to check/debug the trace(s) to see why it eats that much memory (+1Gb), the problem is that when the game starts, it eats more and more memory until its killed by the OS
. At the beginning I suspect the engine has some leaks, that why it continuously eats memory, but I've seen the same thing happens with the retracer on Android, so now I suspect that the GL(ES) commands, somehow are responsible for the leaks. Even more, having an application that can replay the trace directly on Android, its great because I could run also benchmarks and it seems that not the CPU is the (main) bottleneck for the slowness, but the GPU. There are frames that have +10k of GL commands, which it seems is a little bit too much for an android tablet Anyway, I hope this weekend to have time to update the Android wiki page, this way anybody will be able to build, run & debug pyrogenesis on Android. Also I need to check what are the steps to upstream my 0 A.D. work ;-).
Apart that someone needs to make the UI touch friendly, the only "major" task that *I* need to do, is to bundle game data in an OBB, make sure that OBB is downloaded together with the game, mount it, set the game data paths to the mount location, and then we can start publishing it on Google Play! BTW does wildfiregames have an official Google Play account?
-
2
-
-
Folks I have great and also quite bad news on this matter
Let's start with the good news:
- I managed to enable all Pyrogenesis' features (audio, lobby, etc.). The sound sounds great ;-).
- I fixed all the visible crashes, there were two problems:
1. vswprintf is quite crappy on Android. It don't support %hs and %ls and it also don't add \0 at the end of the string in the output buffer
. This was the root cause for sound crash 
2. In XeroXMB there were some places where it reads unaligned memory, which on ARM will cause an SIGBUS in release mode.
- The UI looks great!
Now the bad news:
- Even in Release mode the game performs terrible 5-10 FPS
. The UI is quite acceptable (~30 FPS) though.- After the game starts I see GL_INVALID_OPERATION (0x502) error on every frame.
- It seems to have massive memleak, after the game starts it eats more and more memory until it gets killed by the OS. My hunch is that the memleak is caused by GL_INVALID_OPERATION, because every time I see it it eats more memory ...
Here you can find the log from the device.
Can anyone me with GL_INVALID_OPERATION problem? Sadly my GL skills are closed to 0 (B.C.
). Now it is so easy to develop & debug on Android !BTW I'd like to update the Android wiki page with the new stuff, do I need special permissions? Is there anyone who does this job?
-
The sprintf_s could be fixed by including lib/secure_crt.h instead.
I tried but for some reason it fails, is there any reason why you prefer to use sprintf_s instead of snprintf ?
g_XmppClient is defined and set to NULL if you build without the lobby (at least when using premake, so your build system is broken).
g_XmppClient is defined in source/lobby/Globals.cpp and I didn't add it to my build system. Anyway I'll try to enable lobby for android and I'll revert that patch.
You should use OS_ANDROID in cases where you have different ifdefs.
Done.
The changes to lib/config2.h should go into some build script or project file.
[...]
Seems like a good start
Got it, I'll keep them for a while until I'll fix the most important errors first.
Thanks!
-
2
-
-
Status update:
- The UI seems to be ok now : check this image (yep the FPS is very low because I'm using a debug build).
- I tried it also on release but it crashes ...
Next steps:
- I'll need some help to fix the GL errors.
- fix the crash in release mode.
- I'll try again to enable and fix the sound.
- move the game data to an OBB file.
Does anyone knows if and how I can set the DPI? The text and the controls are very small and quite unusable.
interestinglog.html
ERROR: CRenderer::EndFrame: GL errors 1280 occurred
ERROR:
ERROR: GUI page 'page_gamesetup.xml': Failed to call init() functionI also have tones of:
W/pyrogenesis(27096): GL_INVALID_OPERATION
W/pyrogenesis(27096): 000000 p=0.465000
W/pyrogenesis(27096): 5000
W/pyrogenesis(27096):
W/pyrogenesis(27096): 502
W/pyrogenesis(27096): ----------------------
W/pyrogenesis(27096): OpenGL error(s) occurred: 0502
W/pyrogenesis(27096): 000Most probably one of the reason(s) of the slowness ...
-
1
-
-
Hello folks,
I have some good news on this matter. I managed to:
- compile all dependencies (I upload the precompiled dependencies to https://dl.dropboxusercontent.com/u/67435935/0AD/android.tar.bz2 , untar it in 0ad/libraries).
- fix compilation for Android
- create new project files which can be used from QtCreator to manage, compile, deploy, run & *debug* on any Android Device (open 0ad/build/android/qtcreator/qtcreator.pro in QtCreator and choose an Android Qt 5.4 KIT).
What doesn't work:
- the old way to compile for android, didn't had time to fix premake files for Android.
- the game
the UI is completely screwed ...- I had to disable the audio because it crashes.
I upload the patches to https://github.com/bog-dan-ro/0ad (I'll upstream all patches as soon as I'm happy with their status).
Use a script to fetch dependencies and build them, see http://trac.wildfiregames.com/browser/ps/trunk/libraries/osx or even better http://trac.wildfiregames.com/browser/ps/trunk/build/android.
All right, I updated android script. Now it compiles & installs all project dependencies.
Breaking network compatibility and calling it a first class citizen is not the way it works.
HUH ?!?! what makes you believe that using another library for networking it will break its compatibility? The protocol is the same, it's just another library ...
Anyway, I'll stick with current dependencies
.The real changes needed to make the Android port anything more than a proof-of-concept is someone working on a usable user interface.
Yep, but having an easy way to deploy, run & debug the application on Android will speed up the development.
Supporting the editor on Android seems a bit strange for a platform where sharing the maps you created without any other tools will be a bit cumbersome.
It's not strange at all. You create a map and save it on the sd_card. There are lots of ways to share the map, much more than you have on your desktop
. It's so easy to start an Intent which share the map via any service which allows attachments: mail, bluetooth, dropbox, gdrive, etc.It will be nice if if the future the users will be able to share the maps directly from Atlas, e.g. a market (a small RESTfull webservice) which can be used by the games to upload & share their maps.
I think the real challenge will be to create a touch friendly UI ...
Nobody who wanted to rewrite Atlas (you're not the first) produced anything working, or pointed out a lot of things that were broken and not fixable without a complete rewrite (not that Atlas is without issues). If someone is actively going to work on something that big having an idea of what does not work now is a huge part of not introducing those bugs again, and that does not guarantee that no new bugs will be there.
As I said before this is the last step ;-). I know it is a big task, it will help a lot if there is a list with the things that works and those that don't.
-
Hi and welcome!
There is already some form of Android support, you may want to have a look at these two resources: 0 A.D. Android port forum thread and 0 A.D. Android port wiki page.
Hi Fabio,
I've seen it ... but is quite hard to maintain or contribute, and no debugging (well, at least not easy and not from the first line).
I prefer to spend more time now to prepare an easy to use development environment for Android, then to spend much longer time hunting bugs using the logs
.The changes you propose sound super-heavy, and we wouldn't choose to spend time on these only to ease Android porting, because we already have much work to do on the game itself!
The developers made a handful of choices across the years and now that things are settled it is better to avoid complete turnabouts. On top of that, the Android port should be more or less working already, the only missing thing is an active development of it.
But of course, no one will prevent you from working on a way to use QtCreator as IDE, and so on. Having more toolchains available for contributors can be very interesting.
They sound super-heavy, but they are not that heavy
. I don't want you to spend any time to do changes, I can do them myself. I just want to make sure developers will be open to discuss and check the patches for Android, because the last thing on earth I want, is to maintain them by myself in a separate place .I don't want to replace or to change the existing things, the old stuff will work as it worked before (e.g. the people can still use premake, etc.). I just need to add a layer where the engine uses these dependencies directly. I'll try to keep these changes minimal.
All these changes are needed because if you want Android to be a first class citizen platform for Pyrogenesis then we'll need and easy way to develop&debug Pyrogenesis on Android, and I'm afraid there is no other (easier) way to do it ...
-
1
-
-
Ah, I didn't know that programmers don't need to fill the application form
.Anyway, let's get back to the problem
. This are the steps that I'd like to take for the Android port:- I'd like to use QtCreator as IDE. QtCreator is a great cross-platform IDE and I choose it because it has a great support for C/C++ and also for Android. Regarding the build system, I'd like to use the brand new qbs [1], for a few reasons: it is well supported by QtCreator, and the (upcoming) Android support is great!
- The next step is to decide what to do with the dependencies, I see two solutions here:
- add all dependencies to the project tree (all their sources) and compile all of them for Android. Personally, I don't like this approach at all, because it takes a lot of time to "port" all dependencies to Android (make them compile) and it pollutes Pyrogenesis' source tree.
- at first look Qt has support for (almost) all Pyrogenesis' dependencies (image formats, xml, networking, etc.), so I'd like to make all dependencies optional and use Qt instead on Android. Qt 5 on Android is quite stable.
- Atlas: after first two steps are complete, I'd like to focus on the game editor. I propose to rewrite the UI in Qt Quick Controls [2]. Qt Quick Controls are great because they look and feel native on all supported platforms[3] (which AFAIK are quite more than wxWidgets supported platforms) not only on Android[4]. A big plus of QQC is that they are touch friendly, so we don't need to create another UI for mobile devices. They are also very easy to use, so anyone can contribute and maintain it.
[1] http://doc-snapshot.qt-project.org/qbs
[2] http://doc-snapshot.qt-project.org/qt5-5.4/qtquickcontrols-index.html
[3] http://doc-snapshot.qt-project.org/qt5-5.4/supported-platforms.html
[4] http://blog.qt.digia.com/blog/2014/12/03/native-android-style-in-qt-5-4/
Can I help with Android port?
in Game Development & Technical Discussion
Posted · Edited by bog_dan_ro
As fabio said, I had to add ETC2 texture compression, because 0 A.D.s uncompressed textures are way too big and they don't fit in memory (my devices have 2gb of ram). GLES 3 is mandatory only for Android (because ETC2 is mandatory in GLES3), but if you use Android you can still use GLES2. Actually if you are using KTX (check my repo, ktx branch) instead of DDS you can compress the textures using any compression your device supports. You just need to provide a simple script that compress the textures and put them in a KTX container. The beauty of using KTX is that the KTX header contains everything the engine needs to use textures, so you don't need to change a single line in the engine
.
It can, but somebody needs to find a workaround for OES_mapbuffer
I hope after alpha 18 will be shipped, developers will have more time to focus on GLES/Android.