Skip to content

If you were holding your breath for the Android release... stop.

Shogun_Named_MarcusShogun_Named_Marcus Member Posts: 13
in Android (Archive)
"We've hit a snag with BG resource handling and ship panel APK files. We're going to be a while yet on Android. "



So, this is even more frustrating than no update on where we stand with an Android release. I can understand a reticence to come forward with a concrete release date after the first delay fiasco, but announcing further problems with the Android version in such an uninformative way seems a bit baffling to me.
«13456

Comments

  • tomty89tomty89 Member Posts: 47
    Well I think it's natural that they would have to struggle for this. Games or programs with such size are never meant to be exist in any tablet before BGEE, or at least before the evil retina ipad. So just be a little bit more patient for them to make the revolution. After all the twit isn't saying "we are struggling to port it in java, it's much worse than objective-c".
  • rkp71rkp71 Member Posts: 16
    I was really hoping for a Neverwinter Nights for android anyway, this was a nice surprise tho. Then again I mainly enjoy playing with others online, and reports are that multiplayer pretty much is lacking in a big way right now. Guess I can wait some more. I only have bg2 currently to work with gemrb, tho decided it was too buggy last I tried. Maybe I'll just give it a go on my nexus 7, it was ok on my Acer a500 except for traps.... and of course no multiplayer.
  • amftronamftron Member Posts: 109
    The longer this goes on the more and more pleased i am that i didn't buy the PC version.
  • tomty89tomty89 Member Posts: 47
    Well I wonder if NWN would be still that nice with tablet. Even if the 3D graphic is not a problem for high end product, the UI will loose its advantages without keyboard and mouse, while BG's UI is almost like a natively designed one. Besides, you'll need a really fast network, especially if what you enjoy are those 3rd party MMO-like modules.
  • FungostarFungostar Member, Translator (NDA) Posts: 179
    Next Tweet:

    Trent Oster ‏@TrentOster

    @roblef BG does some direct memcopy to structs in file access. To access .zip files properly we need to add the decompression into the read



    This is much more informative, the BG codebase isn't prepared for Android (obviously, it's from '98)... it's not an Overhaul fault
  • tomty89tomty89 Member Posts: 47
    edited January 2013
    Not a programmer so don't really understand. But why .zip files suddenly? Probably Android's fault?
  • FungostarFungostar Member, Translator (NDA) Posts: 179
    The problem is in how BG does want to read files from the disk, it tries to do it directly from disk to memory which works well on the PC and probably on the iPad but not on Android where zip files are used.
  • tomty89tomty89 Member Posts: 47
    edited January 2013
    Then why zip files are used in Android? Because it has some sort of file size limit? Anyway you can just ignore me if you want. Keep answering me these questions is not that "constructive" LOL. It only fulfils my curiosity.
  • FungostarFungostar Member, Translator (NDA) Posts: 179
    I don't really know why Overhaul used zip files... very like for size constraints.

    For example, when publishing an android app, Google imposes that it MUST be less than 50 MB... a little more than the BG launcher size.

    This means that all additional contents have to be downloaded from elsewhere, be it the Beamdog site or the Google cloud.
    Downloading something of the size of Baldur's Gate can scare many peoples, then I suppose they zipped the game data to save space and size.

    What I don't really understand is why they discovered this only now... sounds a little late in the project time :(

    By the way, don't worry, I rarely ignore peoples :)
  • PsivenPsiven Member Posts: 5
    Fungostar said:

    This is much more informative, the BG codebase isn't prepared for Android (obviously, it's from '98)... it's not an Overhaul fault

    Eh, really? Seems like since it's their job to prepare the old codebase for Android, it's very much their fault that it isn't done yet. There's not much point in bitching about it taking too long, but let's at least agree that they're the ones responsible for doing it.

  • smartroadsmartroad Member Posts: 47
    Fungostar said:


    For example, when publishing an android app, Google imposes that it MUST be less than 50 MB... a little more than the BG launcher size.

    That changed ages ago. I just downloaded a game that was near 2GB in size direct from Google Play

  • SouthpawSouthpaw Member Posts: 2,026
    tomty89 said:

    Games or programs with such size are never meant to be exist in any tablet before BGEE, or at least before the evil retina ipad.

    Not true. There are other games the size of about 2gigs on the market already. Plus things like GemRB or the port of HOMAM3.
    In another tweet, Trent mentioned that it will take'weeks'. And that happened few days ago=more than a month after the game's release.

    Correct me, if I'm wrong but isn't Apple's iOS also a linux-based system, just like Android? Why didn't the iOS release have similar problems?



    TL;DR- unhappy with the delays, but still buying it as soon as it hits GooglePlay.

  • FungostarFungostar Member, Translator (NDA) Posts: 179
    edited January 2013
    @Southpaw

    iOS is based on BSD, Android on Linux, very similar indeed but not identical.
    iOS apps can be made as a solid BIG archive, Android apps bigger than 50 megs uses Expansions (see below)... that's why (probably) iOS does not need zips and Android does.

    @smartroad

    Please, think twice before screaming out inaccurate information based only on your phone experience:

    http://support.google.com/googleplay/android-developer/bin/answer.py?hl=en&answer=113469

    "APK file: maximum supported size for a single .apk is 50MB. You can use expansion files to upload additional assets such as graphics."

    And:
    http://support.google.com/googleplay/android-developer/bin/answer.py?hl=en&answer=2481797

    "Small applications that download quickly generally give the best user experiences. However, if your application requires more than 50MB of space, you can use expansion files to store additional APK assets. We will store two files (in addition to the original 50MB) of data per application at no additional cost. The maximum file size for each of these two files is 2GB, but it’s better to make those files as small as possible for the best user experience."

    @Psiven

    Yes, sure, it's their task to do such update, the zip problem is one of the things they have to fix to complete it.
  • SouthpawSouthpaw Member Posts: 2,026
    I trust you misread me @Fungostar. I was never talking about minimums or maximums, just the fact that there are bigger games on the market. I've seen couple of those and they had to download additional content during first start. Which was mentioned on the game's GooglePlay page.
    Seems it's their workaround for the rules you've cited.
  • FungostarFungostar Member, Translator (NDA) Posts: 179
    @Southpaw sorry, I edited my post while you were writing your one... I added above the reason why iOS does not need zips around and Android does
  • mlnevesemlnevese Member, Moderator Posts: 10,214
    edited January 2013
    Psiven said:

    Fungostar said:

    This is much more informative, the BG codebase isn't prepared for Android (obviously, it's from '98)... it's not an Overhaul fault

    Eh, really? Seems like since it's their job to prepare the old codebase for Android, it's very much their fault that it isn't done yet. There's not much point in bitching about it taking too long, but let's at least agree that they're the ones responsible for doing it.

    Considering there wasn't an Android version planned, original release was going to be Windows, OSX and iOS only, and it only was added to the list in August, after Overhaul pressured the IP holders, I don't think it's taking that long.

    I'd say a development cycle close to 1 year is to be expected, mainly now that they came to the conclusion they'll have to change the way the game reads/writes files to cope with zipped apk extensions.

    The same applies to the Linux version that was approved late in December and, AFAIK, isn't even in development yet.
  • tomty89tomty89 Member Posts: 47
    edited January 2013
    Fungostar said:

    I don't really know why Overhaul used zip files... very like for size constraints.

    But the thing I don't understand is, why would zip matters? At least not in the way Oster said. Everything should be decompressed before the game is actually run, shouldn't it? It has nothing to do with the codebase or memcp or sort of.

    UNLESS...
    Unless they are trying to change the whole "structure"...making all those bam, bif, bcs or whatever compressed. Is it really a good way? Load time, specific bugs and maintenence...Not to mention that it might not be that helpful in making the size small.

    I don't know then. But I think it's hardly LINUX's fault. It's at most ANDROID's fault. Or Google's fault. Maybe Java's fault. Java is never something good, is it? :P
  • FungostarFungostar Member, Translator (NDA) Posts: 179
    edited January 2013
    @tomty89

    Let's start with some suppositions:
    1) they used zip files because Google Play admit only one additional file of 2 GB max
    2) they does not uncompress it because this whould require more than double the space while installing
    - download (2gb)
    - unzip: 2gb + the uncompressed for example 2.5gb: 4.5gb in the middle of the installation process, way too much!
    - delete the zip, leave with the 2.5gb uncompressed

    So the only option is reading directly the zip file.

    Here is the very technical part...

    Trent nominated the memcpy function (it's not a typo, it's really called this way: http://www.kernel.org/doc/man-pages/online/pages/man3/memcpy.3.html) which does copy an array of bytes to a memory mapped structure.

    Take the TLK file for a simple example... this is the header structure (http://www.ugcs.caltech.edu/~jedwin/baldur_TLK.html)
    TLK V1 Header Offset Size (datatype) Description 0x0000 4 (char array) Signature ('TLK ') 0x0004 4 (char array) Version ('V1 ') 0x0008 2 (word) unknown (always 0?) 0x000a 4 (dword) Number of Strref entries in this file. 0x000e 4 (dword) Offset to string data

    Baldur's Gate just expects to be able to read 18 bytes and map them to this structure directly in the above structure.

    This can't be done with a zipped file, because it has first to be uncompressed on the fly and then read like a stream, so a little (?) adaptation of the code base is necessary.

    at the end it's not a Linux, Android or Java fault (btw, BG is written in C++/C)... it's simply made without zip files in mind :)

    PS: Java rocks, but C rocks even more !!
  • AristilliusAristillius Member Posts: 873
    Thanks for posting @Fungostar, do you reckon it is a large job? And might this introduce bugs or impact gameplay/speed?
  • KubusKubus Member Posts: 15
    edited January 2013
    Fungostar said:


    1) they used zip files because Google Play admit only one additional file of 2 GB max

    They should go for sideloading of the data from their own servers. This would also make incremental updates WAY easier. I dunno about the current status of the PlayStore, but I don't suppose updates using delta files are supported, or are they?
    Fungostar said:


    This can't be done with a zipped file, because it has first to be uncompressed on the fly and then read like a stream

    It is actually very simple to get the InputStream of a file inside a zip in Java. I don't know exactly how much of the code remains native and how much is ported over, but if the stream can be prepared before a native call happens this is as simple as writing a wrapper. I'm positive they will resolve the issue in near future.
    Fungostar said:


    PS: Java rocks, but C rocks even more !!

    I beg to differ :D
  • FungostarFungostar Member, Translator (NDA) Posts: 179
    @Aristillius
    no, I think it's a very fine grained change, it can be solved quickly... and it will have (if any) a minimal impact only on loading times, never on gameplay and overall speed.

    @Kubus
    by quickly reading this page (http://support.google.com/googleplay/android-developer/bin/answer.py?hl=en&answer=2481797) seems that a sort of incremental patching is supported by using the second zipped file, but I never tried that... however it sounds limited
    Kubus said:


    It is actually very simple to get the InputStream of a file inside a zip in Java....

    yes, I know, but there is no way to do a memcpy in java :( anyway, since BG is written in a mix of C and C++, I bet on the Android part to be limited to setting up the GL context and driving touch inputs, nothing else.

    I also love Java.... but C is part of my life :)
  • tomty89tomty89 Member Posts: 47
    edited January 2013
    Android's support is not a MUST, if the devs WANT to have incremental update service. They can just make the latest complete package and the "cumulative" patch file into two different apps. Alternatively they can do it with their launcher by the NWN2 way.
    The only points are the time for developing a update service, and the network resources they could provide on their own. Now I don't even see they seed the official torrent. Not sure if if any port already have incremental update service, nor the installer is making use of any http download.
    Fungostar said:


    1) they used zip files because Google Play admit only one additional file of 2 GB max

    Fungostar said:


    We will store two files (in addition to the original 50MB) of data per application at no additional cost. The maximum file size for each of these two files is 2GB

    It should be two, right? Which shouldn't be a problem to BGEE or further possible EEs.
    I think the main reason is the capacity issue. But I would only agree that if they would support older models of tablets (and phones?) which are without SD card slot.

    I seldom found what is written in Java is good. Android is probably the best already but I still thought it's kind of hindered by Java. It LOOKS crappy. Before it went open source it SEEMS to be the crappiest crap. In my opinion. So ignore it, no intentional harm :P
  • KubusKubus Member Posts: 15
    edited January 2013
    Fungostar said:


    yes, I know, but there is no way to do a memcpy in java :( anyway, since BG is written in a mix of C and C++, I bet on the Android part to be limited to setting up the GL context and driving touch inputs, nothing else.

    You don't have to have memcpy in Java in order to use it. Native calls work both ways. Even if it would be a pain in the a** to use zips as is in C/C++, they have the whole Java(ish) environment right at their hands by default. Thats what I was trying to say when I spoke about a wrapper, preceed every memcpy with a native call or wrap the entire thing up. I never really had to handle zips in C, but if it would be ridicilously hard to use them the few microseconds lost on a native call seem like a good alternative.

    EDIT: Although it might be easier / more efficient to replace the memcpy altogether.
    tomty89 said:


    It should be two, right?

    --->
    Fungostar said:


    ... that a sort of incremental patching is supported by using the second zipped file...

    tomty89 said:


    I seldom found what is written in Java is good. Android is probably the best already but I still thought it's kind of hindered by Java. It LOOKS crappy. Before it went open source it SEEMS to be the crappiest crap. In my opinion. So ignore it, no intentional harm :P

    Depends on how you have been "raised" :D To my mind, a surprising amount of people write horrific C++ code. #IFDEF me to oblivion... And C provides WAY too many security flaws, especially when used in a "MUST... MEET... DEADLINE..." manner :)
  • FungostarFungostar Member, Translator (NDA) Posts: 179
    @tomty89
    yes, they're two, the second seems to be used only as a sort of patching system, but it's rather obscure to me

    @Kubus
    all true, but they can't translate the entire BG codebase to java to use InputStreams and then call the native memcpy :)
    I prefer they try to keep an unified and portable base across all the platforms and keep it solid, even if this could take much more time to get our Android release...

    IMHO, all languages are valid and have their pros and cons... usually the flaw is between the chair and the keyboard :)
    BTW, C has the #define Hell... java has the dependency Inferno... see Maven !!
  • KubusKubus Member Posts: 15
    I didn't talk about the entire codebase, just a way to use the file stream. A stream of bytes should be equal in C and in Java. I'm not talking about interpreting or using the code directly in the latter, merely about providing a wrapper to make it accessible in a convenient way in C. Besides, it's all just smalltalk anyway.

    Oh and ofc all languages have their place and purpose, but I still like a bit of trash-talk when C is mentioned :D
  • FungostarFungostar Member, Translator (NDA) Posts: 179
    Sorry, I misunderstood you because plain C does not have the concept of streams like Java does :)

    When working with Java (99% of my time) I love its simplicity... but with C, I feel the Power !
  • smartroadsmartroad Member Posts: 47
    @fungostar
    Fungostar said:


    @smartroad

    Please, think twice before screaming out inaccurate information based only on your phone experience:...

    Generally I do think carefully about posting on sites for this very reason - people can be cruel if you get it wrong or are mistaken. Yes I was only talking about my user experience - I am not and have not claimed to be a programmer - I have only observed that apps have increased in size to about 2GB.

    Perhaps you could have simply state that I was referring to the whole application and that the 2GB is split between 50MB for the APK and the rest is for data only - rather then insulting me and accusing me of 'screaming'.

    I do honestly thank you however for updating me as to how the system works - the information you provided is quite interesting.
  • FungostarFungostar Member, Translator (NDA) Posts: 179
    @smartroad

    I'm sorry, I never intended to insult you.

    I just didn't like the way you stated "That changed ages ago. I just downloaded a game that was near 2GB in size direct from Google Play" as an absolute without any reference.

    As you know, forums posts do not pass along emotional information nor user experience backgrounds, so next time, please, prefix it with "From my point of view..." or something like that.

    Cheers
  • smartroadsmartroad Member Posts: 47
    @Fungostar

    Normally I do start with an "As I understand..." etc. as it is a get out clause if I am mistaken!! Not sure why I didn't for that post. :-S
  • SouthpawSouthpaw Member Posts: 2,026
    A forum user with a character strong enough to admit he overdid it and apologising? (respect @fungostar)

    The internet is not what it used to be...

    On the other hand -any thread slowly being diverted to a talk about programming languages? Yup. Good old internet...
Sign In or Register to comment.

2024 Overhaul Games, a division of Beamdog. © 2024 Hasbro, Inc. All Rights Reserved. Baldur's Gate, Dungeons & Dragons, D&D, Forgotten Realms, Baldur's Gate, Wizards of the Coast and their logos are trademarks of Wizards of the Coast LLC in the U.S.A. and other countries, and are used with permission. Hasbro and its logo are trademarks of Hasbro, Inc. and are used with permission. © 1998 BioWare Corp. All Rights Reserved. BioWare, the BioWare Infinity Engine and the BioWare logo are trademarks of Bioware Corp. Black Isle Studios and the Black Isle Studios logo are trademarks of Interplay Entertainment Corp. Atari and the Atari logo are trademarks owned by Atari Interactive, Inc. All other trademarks are the property of their respective owners.