Jump to content

bog_dan_ro

Community Members
  • Posts

    27
  • Joined

  • Last visited

Everything posted by bog_dan_ro

  1. 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.
  2. You can try to reinstall it (uninstall the install again). It should work on Nexus 10.
  3. 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.
  4. It seems you don't use the latest version. Please make sure you are installing *0.4 alpha* version not 0.3 !
  5. Thanks! Sadly, I was right, your device doesn't have glMapBufferOES .
  6. 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.
  7. 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 packagefollow 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.
  8. 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.
  9. 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.
  10. 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. ...
  11. 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
  12. 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 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 ... 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 ;-) ). Ok, then I'll start with incremental changes (e.g. adding TexCodecKtx, and changing the Tex struct. Ah, I didn't know it is that difficult to upstream patches to NVTT. Ok, then I'll write a converter inside our project.
  13. 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.
  14. Ah, I didn't read the license ... 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 ...
  15. 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)." 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.
  16. If the game stays under 1.3Gb it will not be a problem, but it grows way too much and Android kills it. 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?
  17. 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
  18. 1gb of ram is huge for a device that has only 2gb for the entire OS.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. as I said my gl skills sucks.
  19. 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?
  20. 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?
  21. 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 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. Done. Got it, I'll keep them for a while until I'll fix the most important errors first. Thanks!
  22. 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() function I 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): 000 Most probably one of the reason(s) of the slowness ...
  23. 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). All right, I updated android script. Now it compiles & installs all project dependencies. 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 . Yep, but having an easy way to deploy, run & debug the application on Android will speed up the development. 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 ... 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.
  24. 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 . 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 ...
  25. 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/
×
×
  • Create New...