bog_dan_ro

Community Members
  • Content count

    27
  • Joined

  • Last visited

Community Reputation

12 Good

About bog_dan_ro

  • Rank
    Discens
  • Birthday

Previous Fields

  • First Name
    BogDan

Profile Information

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