#gemrb@irc.freenode.net logs for 28 Feb 2013 (GMT)

Archive Today Yesterday Tomorrow
GemRB homepage

[00:14:30] --> brada has joined #gemrb
[01:00:35] <-- edheldil has left IRC (Ping timeout: 246 seconds)
[01:13:55] <-- lynxlynxlynx has left IRC (Remote host closed the connection)
[02:52:06] <-- brada has left IRC (Quit: brada)
[03:55:05] --> brada has joined #gemrb
[04:04:51] <-- wjp has left IRC (Ping timeout: 248 seconds)
[04:17:51] --> wjp has joined #gemrb
[04:33:02] --> thomcom has joined #gemrb
[04:33:14] <thomcom> good news, case sensitive volume on OS X makes SDL build em up
[04:33:27] <thomcom> AL/android.h is completely missing from openal build however
[04:42:02] <thomcom> apparently just needed to comment it out
[04:42:12] <thomcom> jni/src/main/gemrb/plugins/OpenALAudio/OpenALAudio.h:53
[04:45:37] <thomcom> jni/src/main/gemrb/GemRB.cpp:37 needs to be changed from <SDL/SDL.h> to <SDL.h>
[04:45:42] <thomcom> maybe you already sent me this patch yesterday?
[04:46:19] <thomcom> yupyup
[04:46:21] <thomcom> here it is
[04:46:37] <thomcom> bit about openAL isn't in your patch tho
[04:51:42] <brada> yeah that android.h is for unneeded pelya stuff
[04:52:05] <brada> i forgod to ifdef that
[04:56:54] <brada> there
[04:56:56] <thomcom> What is with /Volumes/gemrb_cs/gemrb_android/build/gemrb/res/values/strings.xml-e:3: error: Resource entry app_name is already defined. ?
[04:57:16] <brada> not sure
[04:57:18] <thomcom> i commented it all out from the header and chugged ahead
[04:57:20] <brada> not an android guy
[04:57:26] <thomcom> o rite
[04:57:30] <thomcom> neither is psch right?
[04:57:47] <brada> well he has done more than i have :p
[04:57:57] <brada> but no he is just learning
[04:58:02] <thomcom> strings.xml-e looks like a localization file, of course here in USA we just use strings.xml. this proj has strings.xml and strings.xml-e
[04:58:13] <thomcom> well he did a good job with the build environment, how long did this take him?
[04:58:20] <brada> a few days
[04:58:24] <brada> afik
[04:58:39] <thomcom> I spent weeks improving a build system this summer for one of our products and it is still a piece of shit compared to what he's made. :D
[04:59:08] <thomcom> anyway you were right, CI is why you can't build on OS X
[04:59:19] <thomcom> things were pretty much seamless once I moved everything to a CS disk image
[04:59:22] <brada> you were the one that discovered it
[04:59:43] <brada> but im off to bed
[04:59:47] <thomcom> likewise
[04:59:48] <thomcom> peace out
[04:59:51] <brada> talk tomorrow
[04:59:54] <-- brada has left IRC (Quit: brada)
[05:19:41] <thomcom> Still getting SDLActivity ClassNotFoundException, going to bed won't find out tonight
[05:19:55] <-- thomcom has left IRC (Quit: Page closed)
[05:55:31] <gembot> build #276 of nmake-msvc++6 is complete: Exception [6exception upload] Build details are at http://buildbot.gemrb.org/builders/nmake-msvc%2B%2B6/builds/276 blamelist: Brad Allred <bradallred@me.com>
[07:25:23] --- ChanServ gives channel operator status to wjp
[08:00:56] --> edheldil has joined #gemrb
[08:00:56] --- ChanServ gives channel operator status to edheldil
[08:02:58] <-- WingedHussar has left IRC (Read error: Operation timed out)
[08:05:17] --> WingedHussar has joined #gemrb
[08:12:48] <-- edheldil has left IRC (Ping timeout: 264 seconds)
[08:27:28] --> edheldil has joined #gemrb
[08:27:28] --- ChanServ gives channel operator status to edheldil
[08:41:59] --> rocket_hamster has joined #gemrb
[08:52:05] <wjp> ah, good, that SDL ML message went through, so let's hope they fix the pixel formats :-)
[08:54:19] <wjp> oh, and they apparently migrated bugzilla to a new host :-)
[08:55:43] <fuzzie> whee
[09:33:21] <-- rocket_hamster has left IRC (Remote host closed the connection)
[10:50:47] --> lynxlynxlynx has joined #gemrb
[10:50:47] --- ChanServ gives channel operator status to lynxlynxlynx
[11:22:27] --> traveler_ has joined #gemrb
[11:48:19] --> rocket_hamster has joined #gemrb
[12:29:10] --> lynxlynxlynx_ has joined #gemrb
[12:30:20] --> WingedHussar1 has joined #gemrb
[12:35:44] <-- lynxlynxlynx has left IRC (*.net *.split)
[12:35:45] <-- WingedHussar has left IRC (*.net *.split)
[12:37:31] <-- rocket_hamster has left IRC (Quit: bye!)
[12:39:10] --> kida has joined #gemrb
[13:40:57] --> rocket_hamster has joined #gemrb
[15:35:22] --> brada has joined #gemrb
[15:35:39] <-- brada has left IRC (Client Quit)
[15:35:58] --> brada has joined #gemrb
[16:49:54] --> thomcom has joined #gemrb
[16:54:10] <psch> thomcom: the ClassNotFoundException comes from a wrongly set field in AndroidManifest.xml
[16:54:36] <psch> i fixed that, and a few other things, yesterday, ill test run the current state once more and upload for you then
[16:54:44] <psch> if everything works of course
[16:57:08] <thomcom> cooliebeans
[16:57:15] <thomcom> what's wrong with the manifest?
[16:57:20] <thomcom> pretty sure SDLActivity is in there
[16:57:26] <psch> yeah, but it shouldn't be :)
[16:57:38] <psch> the ClassNotFoundException is for net.sourceforge.gemrb.SDLActivity
[16:57:41] <psch> which doesn't exist
[16:57:55] <psch> org.libsdl.sdlapp.SDLActivity and net.sourceforge.gemrb.GemRB exist
[16:58:17] <psch> i did write the change to the package into prep_env.sh, but not the change to the Activity class
[16:58:44] <psch> you could also change SDLActivity in AndroidManifest.xml to GemRB
[16:59:12] <psch> but you'll still most likely get a crash after the intro videos, unless upstream already fixed the SDLActivity.java pixelformat confusion
[17:09:41] <brada> you are meant to copy the sdl activity to your project and customize it for your needs
[17:10:18] <brada> as in it probably should be net.sourceforge.gemrb.SDLActivity
[17:10:51] <brada> and that copy of SDLActivity should be commited to our repo
[17:11:34] <psch> no, you're meant to subclass the activity to get the correct application name
[17:11:40] <psch> which is what i am doing
[17:11:49] <brada> ah
[17:12:03] <psch> we still need a modified SDLActivity.java, because of our library dependencies
[17:12:37] <brada> that cant be done with the subclass?
[17:12:37] <psch> which is because java loads static initializer blocks of the super class before static initializer blocks of the extending class
[17:12:52] <psch> i tried it, but the vm loads the super class first
[17:13:01] <psch> and it runs the init block on load
[17:13:19] <psch> so it tried to load libsdl.so, which is fine, and libmain.so, which depends on other stuff but libsdl.so
[17:13:32] <psch> if i have the deps for libmain.so in the subclass, they aren't loaded yet
[17:13:34] <psch> and the app crashes
[17:14:32] <thomcom> In eclipse I think you can manage that just by specifying the order of dependencies, is that not possible with ant?
[17:14:52] <psch> thomcom: we're loading the libraries in SDLActivity, with System.loadLibrary()
[17:15:06] <psch> i'd assume the order of dependencies is just the order of the calls inside the java class
[17:15:10] <psch> which we can change however we like
[17:15:20] <psch> but we can't change the order in which the static initializer blocks are run
[17:15:37] <psch> so we'd either have to not load libmain.so from SDLActivity, or load all dependencies in SDLActivity
[17:16:35] <psch> i don't really like either approach, because it's fiddling with the upstream project, but in the end we should probably not copy the project from sdl but have everything neccessary in our repo anyway
[17:17:54] <thomcom> lol
[17:17:56] <thomcom> interesting
[17:18:28] <thomcom> that's true. unfortunately we have to fork all the dependencies
[17:18:39] <thomcom> otherwise we're always hinging on their project stability for ours
[17:19:07] <psch> well, we could probably somehow build dependencies without ndk-build but with the upstream makefiles
[17:19:13] <psch> at least i assume that should work for most of the dependencies
[17:19:28] <psch> if they officially support the android platform of course
[17:19:53] <psch> for the build env im building it doesn't matter how we precompile the libraries anyway
[17:20:23] <psch> im not really sure about which of the dependency libraries can be compiled for android without using ndk-build
[17:31:43] <thomcom> i don't see why all of them can't be prebuilt into .so files
[17:32:21] <thomcom> i'm not sure what kind of architecture support is created at the time of ndk-build, I suspect none
[17:32:48] <thomcom> if you write your jni code to support all mpteen android architectures and build an so with ndk-build then you can just distribute that .so to everyone afaik
[17:34:52] <psch> probably, yeah
[17:35:00] <psch> to be fair, prep_env.sh is to be run once
[17:35:37] <psch> i.e. there's no real difference between me giving you/the buildslave prep_env.sh and all the files that were in the tar or giving you the build/gemrb subfolder after running ant clean && ndk-build clean
[17:36:02] <psch> but i figured having it documented how the build envirnment is build is a good idea :P
[17:37:30] <thomcom> oh prep_env.sh is great
[17:37:32] <thomcom> please don't do the latter
[17:37:54] <thomcom> if a new buildslave wants to join, then they must check out prep_env.sh and work through the process - this teaches them what the dependencies are
[17:38:16] <psch> you can have a look at build/gemrb/jni/$dependency/Android.mk if you want
[17:38:29] <psch> those are all prebuild, which happens during prep_env.sh, as you probably noticed
[17:38:52] <psch> the only thing im not prebuilding is freetype2, because the makefile is weird, and sdl2 because it isn't finish and might get new stuff we want
[17:39:09] <psch> i think i could get freetype2 to prebuild, but i dont want to fiddle with that right now
[17:41:41] <brada> you are worrying too much about having to build the deps imo
[17:41:54] <psch> me? im not worrying
[17:41:58] <psch> i have it covered
[17:42:11] <psch> it works fully automated as long as upstream doesn't break
[17:42:22] <psch> i guess i could add current snapshots to prep_env.sh
[17:42:43] <brada> gemrb is disjoint from its deps
[17:43:16] <psch> yeah, which is why i wrote prep_env.sh as a "run this once and you can build for years to come!" kinda script
[17:43:21] <psch> which is how it should be, isnt it
[17:43:30] <brada> we have never worried about it before
[17:43:46] <brada> our cmake doesnt do and download and build the missing deps for you for example
[17:43:52] <brada> you just have to have it already
[17:44:00] <brada> same with xcode
[17:44:07] <brada> presumably for the msvc stuff too
[17:44:28] <brada> if you want to do that its fine
[17:44:36] <psch> so i should assume that whoever wants to build has the deps prebuilt for android, with android makefiles, and knows where to put them?
[17:44:39] <brada> but we wont require it from you
[17:44:56] <brada> there isnt a standard place to put them?
[17:45:00] <psch> no
[17:45:10] <psch> not from what i can tell at least
[17:45:25] <brada> you are welcome to have the script download and build deps if you want
[17:45:35] <brada> but id prefer it if it skipped already existing ones
[17:45:44] <brada> so that the buildbot doesnt take forever to build
[17:45:55] <psch> oh
[17:46:00] <psch> well
[17:46:31] <brada> let me see what i did for ios
[17:47:05] <psch> i have prep_env.sh, right? this builds openal, vorbis, ogg, png. additionally, it checks out freetype2 and sdl2
[17:47:34] <psch> then it creates the correct directory structure, copies makefiles for the prebuilt libraries, creates symlinks to the headers of the libraries and links the gemrb-git path
[17:47:58] <psch> and when it's done those things, it does a few modifications to the sdl2/android-project files
[17:48:08] <brada> yeah we want to avoid that
[17:48:16] <psch> after that, it tells the user that he can cd gemrb/build
[17:48:27] <psch> and that he can build gemrb with "ndk-build"
[17:48:50] <psch> the last part - ndk-build - is what i had assumed would be automated
[17:49:04] <psch> everything else is just me being nice and providing a way to automatically set up a build environment
[17:50:14] <psch> the modifications to sdl/android-project are in a copy, the place on the filesystem where the repo was cloned to stays untouched
[17:50:24] <brada> maybe tomprince should chime in
[17:51:20] <brada> or even fuzzie
[17:52:20] <brada> i would say any patches/modifications required ougth to be done on copies and then committed to our repo
[17:53:58] <brada> jsut put them under an addroid subdir
[17:55:19] <psch> the only thing im not copying is the freetype2 makefile, because it's broken
[17:55:21] <brada> and instead of symlinks to libraries and headers an env variable would be preferred
[17:55:36] <brada> i use GEM_IOS_INC_PATH for ios
[17:55:43] <brada> and GEM_IOS_LIB_PATH
[17:55:59] <thomcom> then we're just back to commandergenius though aren't we
[17:56:11] <thomcom> if we make changes to the dep libs and commit them to our/new repo
[17:56:19] <brada> no
[17:56:29] <thomcom> nine months later nobody knows what's in that repo anymore, just that it doesn't work with HEAD
[17:56:33] <brada> the changes im talking about are for files that you should customize
[17:56:57] <brada> the manifest files
[17:57:00] <brada> and such
[17:57:08] <psch> yeah, there's no problem there
[17:57:12] <psch> it's exactly how im doing it
[17:57:19] <psch> i can see env vars instead of symlinks too
[17:57:31] <brada> i in no way mean to change source code for the deps and commit it
[17:57:35] <psch> again, im not modifying any library code
[17:57:37] <brada> aside from the obvious java stuff
[17:57:48] <brada> since we want a custom java interface at some point
[17:57:52] <psch> oh, except for one thing but that's more of a workaround
[17:58:02] <psch> the exit call in SDL_android_main.cpp, because interface etc
[17:58:17] <psch> seeing as we don't have a proper Activity wrapper
[17:58:40] <brada> yeah maybe create a basic wrapper to properly exit the java activity
[17:59:22] <brada> of course you can define SDL_MAIN_HANDLED and do it yourself in your own source file
[18:00:03] <thomcom> What's wrong with SDLActivity?
[18:00:09] <thomcom> Doesn't that handle the Activity wrapper needs?
[18:02:10] <psch> the sdl thread doesn't exit
[18:02:20] <psch> in the template as it comes from upstream
[18:02:31] <psch> so the activity stays alive, because it waits for the sdl thread
[18:02:41] <psch> so we have to exit from the sdl thread to end the activity
[18:03:11] <psch> sdl assume that implementing parties want to do whatever between shutting down the sdl thread and closing the activity
[18:03:20] <psch> which is why they don't exit from the sdl thread
[18:03:39] <psch> at least that's how i understand it
[18:04:07] <thomcom> Yeah I remember this conversation :)
[18:04:41] <thomcom> Ok I think I follow you brada
[18:04:46] <psch> i don't really thing there's anything gemrb wants to do between shutting down the sdl thread and closing the activity, but i dont know
[18:04:49] <thomcom> What we need is to properly handle onResume and onPause in Android
[18:04:56] <thomcom> plus shutting down the Activity entirely
[18:05:16] <thomcom> Shouldn't there be reasonable code for that in pelya's stuff? I'm just taking a wild guess
[18:05:52] <thomcom> We don't want to modify SDLActivity directly? So we need a subclass of SDLActivity that will implement onResume, onPause, and onDestroy properly, communicating from java down to GemRB to do all the right interrupts
[18:13:17] <psch> anyway, http://filebin.ca/YbojPI32tIh is the hopefully fully working buildenv tar and http://filebin.ca/YbopxnXOaSx is the patch against git to have it compile and find files
[18:14:15] <psch> you need to copy override, unhardcoded and GUIScripts manually to /sdcard/Android/data/net.sourceforge.gemrb/files/
[18:14:39] <psch> i was told about a way to do it without needing that exact path, but i didnt get around to implementing that yet
[18:15:17] <psch> the entries in GemRB.cfg also all need to point to subdirs of that path i think, but i'm not sure
[18:16:50] <brada> thomcom: onResume/onPause is really just gravy
[18:17:18] <brada> we already pause/resume the game/audio.
[18:17:28] <rocket_hamster> [funny] http://martinvalasek.com/blog/pictures-from-a-developers-life
[18:17:33] <Seniorita> Pictures from a developer's life | martinvalasek.com
[18:19:25] <thomcom> brada: what else do we need in the java wrapper?
[18:19:29] <brada> i especially like the joomla one!
[18:20:54] <brada> thomcom: whatever we desire
[18:21:16] <brada> im working on a way to configure gemrb pre-launch using ios gui sontrols etc
[18:21:23] <brada> you could do the same with android
[18:25:24] <-- edheldil has left IRC (Ping timeout: 264 seconds)
[18:26:43] <psch> thomcom: can you try if the new tar with the patch works?
[18:29:04] <thomcom> yes
[18:29:29] <thomcom> psch: yes, sorry, I'm working on my for-real job of course
[18:30:05] <thomcom> oh a comment psch, please always tar stuff up in a subdirectory, not in ./
[18:30:13] <psch> right, my bad
[18:31:29] --> kingron has joined #gemrb
[18:33:53] <thomcom> psch: your patch lacks the AL/android.h fix
[18:34:08] <-- brada has left IRC (Quit: brada)
[18:34:24] <psch> that should be in-tree already
[18:34:31] <thomcom> oh good idea
[18:34:39] <thomcom> i'm just comparing your patch to mine before I delete mine :D
[18:38:26] <thomcom> https://github.com/gemrb/gemrb.git still has AL/android.h in it :D
[18:38:29] <Seniorita> gemrb/gemrb ยท GitHub
[18:38:33] <thomcom> is that the one I"m supposed to be on?
[18:39:07] <thomcom> it's not clear to me i OpenALAudio.h is from a dependency or GemRB
[18:39:18] <psch> it also should have a #if aroudn it
[18:39:25] <fuzzie> git://gemrb.git.sourceforge.net/gitroot/gemrb/gemrb is the repo
[18:39:44] <thomcom> i will switch to that one, what's the difference?
[18:39:49] <fuzzie> it's not 10 days out of date :)
[18:40:00] <fuzzie> in fact, 22 days, says github
[18:40:26] <fuzzie> but that sounds unlikely
[18:40:27] <psch> thomcom: the #include for "AL/android.h" is still in OpenALAudio.h, but it's conditional with preprocessor directive which should only include it if it's build against things pelya uses
[18:41:02] <psch> pelya doesn't -DPELYA or anything, so it's just a guess with SDLVERSION, but it seems reasonably safe to assume that
[18:41:26] <thomcom> #ifdef ANDROID is all I'm seeing for it still
[18:41:31] <thomcom> wrong repo though I think
[18:41:32] <thomcom> lol
[18:44:13] <thomcom> fuzzie: only difference between them is the OpenALAudio.h file :D
[18:44:20] <thomcom> werird
[18:52:36] <thomcom> psch: it'd be nice if I could run your patch from build/gemrb instead of having to drill down into jni/src/main, copy it, and apply it
[18:52:49] <psch> my patch is a git patch
[18:53:22] <thomcom> which is where jni/src/main links to?
[18:53:26] <psch> yeah
[18:53:35] <psch> i don't know anything about git and how to apply patches from outside the repo
[18:54:13] <thomcom> psch: how are you avoiding the "Originally defined here" issue with strings.xml-e and strings.xml?
[18:54:46] <thomcom> so patch is actually a linux command that is related to the diff command
[18:55:01] <thomcom> you can patch anything from anywhere as long as the filenames match up and the changes also match
[18:55:02] <psch> i don't have the issue
[18:55:12] <psch> with the xml files
[18:55:13] <thomcom> git provides some commands to use patch in your repo, which is pretty awesome
[18:55:26] <thomcom> it must be a localization thing
[18:55:41] <thomcom> being in USA I tend to just assume that I"m the default and never mess with it
[18:55:52] <thomcom> strings.xml-e looks like "english language version" of strings.xml, what's your default?
[18:56:39] <psch> let me run prep_env once more
[18:56:49] <psch> i dont really keep the whole stuff around after testing
[18:56:55] <thomcom> its ok, everything went great
[18:57:08] <thomcom> but in the android project there's a res/values/strings.xml and a res/values/strings.xml-e which contain identical code
[18:57:23] <thomcom> Android compiler doesn't like it because they have an identically named variable
[18:57:28] <thomcom> your android SDK is automagically resolving that, mine is not
[18:57:43] <thomcom> hehe I never really delete anything :D
[18:57:52] --> brada has joined #gemrb
[18:59:01] <thomcom> is the strings.xml and strings.xml-e something we inherited from pelya?
[18:59:44] <psch> you're talking about build/gemrb/res/values/strings.xml right
[18:59:47] <thomcom> or something out of SDL?
[18:59:49] <thomcom> yes
[19:00:00] <psch> that's the only file in that directory for me
[19:00:09] <thomcom> I've been writing android for 3 years and have never seen an xml-e file lol
[19:00:19] <thomcom> huh
[19:00:24] <thomcom> that's hecka mysterious
[19:00:31] <psch> i don't have strings.xml-e
[19:00:34] <thomcom> i definitely have a strings.xml and a strings.xml-e and I didn't make it :D
[19:00:46] <thomcom> it is easy enough to resolve I was just asking how you resolved it - you resolved it by not having it ;)
[19:01:25] <psch> no idea where it comes from, the directory structure inside build/gemrb comes from copying the android-project subdir from the SDL repo
[19:01:40] <thomcom> cool
[19:01:43] <psch> everything except the dependency subdirectory inside jni/ should be exactly as it is in SDL
[19:01:58] <psch> maybe my script uses some bashishm that works differently on macos?
[19:02:04] <psch> i honestly have no idea
[19:02:51] <thomcom> installed new gemRB build - where do I get override and GUIScripts and copy them to?
[19:03:06] <thomcom> yes I think we're clear to punt on the -e problem for now
[19:03:13] <thomcom> anybody who has ever written android who runs into the problem will be able to resolve it
[19:03:21] <psch> override, unhardcoded and GUIScripts are inside gemrb/
[19:03:41] <thomcom> http://pastie.org/6355795
[19:03:43] <Seniorita> #6355795 - Pastie
[19:03:46] <thomcom> here's how far I get so I'm guessing I need those :)
[19:03:59] <psch> you need to put them to /sdcard/Android/data/net.sourceforge.gemrb/files/ on your android device
[19:04:01] <thomcom> where do I copy them to on device? Sorry, I came from pelya's build into this living project :)
[19:04:34] <psch> i strongly suggest creating a subdir inside that path for the game, otherwise you might overwrite override contents or something, which happened to me at least once
[19:05:23] <thomcom> don't copy the game directly to the same dir as override unhardcoded and GUIScripts?
[19:05:38] <psch> brada says that is bad and we dont do that
[19:06:16] <brada> i jsut said dont copy the game files directly to the data dir
[19:06:36] <psch> no, you specifically said i can't copy game-override into override
[19:06:44] <brada> tho personally i would have $datadir/games/bg2 etc
[19:06:54] <brada> oh yeah dont do that either
[19:06:54] <psch> because that broke stuff
[19:07:06] <brada> our override should remain unaltered
[19:07:14] <brada> probably a good reason for it to be in apk instead
[19:07:24] <brada> unless you need to mod
[19:07:37] <brada> which begs the question how would i mod the override if its in apk?
[19:08:22] <psch> that's one of the things i feared would pop up if i followed fuzzie's suggestion of "keep override in the .apk and extract them to temp when we start the app"
[19:08:37] <psch> thomcom: for reference: http://nopaste.info/5946356b67.html
[19:08:38] <Seniorita> Nopaste - powered by project-mindstorm IT Services
[19:08:53] <psch> line 10 reads "$ ls bg2"
[19:09:06] <psch> adb shell cuts lines sometimes because it wants to be 80 chars wide or something i think
[19:09:13] <brada> the only thing that really worries me is wanting to use ttf fonts
[19:09:23] <brada> currently the only way requires modding fonts.2da
[19:13:20] --> thomcom_ has joined #gemrb
[19:13:48] <-- thomcom has left IRC (Ping timeout: 245 seconds)
[19:14:13] <-- traveler_ has left IRC (Ping timeout: 245 seconds)
[19:16:02] <thomcom_> just trying to resolve pathing on my Galaxy Note 2
[19:16:24] <thomcom_> GemRB is looking in /storage/sdcard0/Android/data/net.sourceforge.gemrb/files/GemRB.cfg
[19:16:33] <thomcom_> when I push to that directory, the file goes somewhere else! haha
[19:17:29] <psch> yea, cause /storage/sdcard0 is a fuse mount of /sdcard
[19:17:37] <thomcom_> right
[19:17:44] <thomcom_> fragmentation oh boyyyyyy
[19:17:52] <psch> are you running android 4.2 yet
[19:18:00] <psch> cause multiuser makes this even more fun
[19:18:13] <thomcom_> hehe
[19:18:14] <thomcom_> 4.1.2
[19:18:20] <thomcom_> i run whatever ATT tells me to run
[19:18:45] <psch> my nexus 7 is stock and got 4.2.2 OTA recently
[19:18:54] <thomcom_> yeah so its still puking on trying to open GemRB.cfg at that dir even though that file is at that dir
[19:19:10] <psch> that could be permissions i think
[19:19:10] <thomcom_> i'm going to leave it for now got a deadline coming up on work-for-pay
[19:19:24] <thomcom_> can I even change permissions?
[19:19:31] <psch> not really
[19:19:39] <thomcom_> files there are owned by root
[19:19:44] <thomcom_> they're in group sdcard_rw though
[19:20:05] <thomcom_> I'm in shell, I cannot navigate to that directory via android file transfer
[19:20:06] <psch> thing is, if you get the path inside the app you should also have rw there inside the app
[19:20:08] <thomcom_> sounds like protected space
[19:20:35] <psch> well, /storage is weird
[19:20:46] <psch> it doesn't work for ADT or adb shell, at least not as it does for apps
[19:21:16] <psch> for example, the gemrb app gets GemRB.cfg in /storage/emulated/0/Android/data/net.sourceforge.gemrb/files here
[19:21:27] <brada> psch: did changing the px format in SDLActivity.java to 0x15151002 fix things?
[19:21:27] <psch> but over adb shell, /storage/emulated/0/ isn't readable
[19:21:35] <brada> also what performance do you get with that?
[19:21:47] <psch> brada: yup, it fixes the crash
[19:21:58] <psch> performance is the same as forcing SDL_PIXELFORMAT_RGB565
[19:22:05] <thomcom_> i've got the opposite case
[19:22:20] <thomcom_> I can get to target directory from adb shell and verify that the files I pushed there exist, but gemRB doesn't see them
[19:22:36] <brada> so permission?
[19:23:02] <psch> well, we have android.permission.WRITE_EXTERNAL_STORAGE
[19:23:15] <psch> and google doc says READ_... is implicit when WRITE_... is needed
[19:23:32] <psch> additionally, WORKSFORME, as they say on bug trackers :/
[19:23:37] <psch> i wish i could reproduce though hah
[19:23:45] <thomcom_> hehehe
[19:23:48] <thomcom_> s'ok
[19:23:55] <thomcom_> its almost software development
[19:24:04] <thomcom_> not just working out dependencies :)
[19:24:12] <thomcom_> unfortunately, no
[19:24:13] <thomcom_> its more like IT
[19:24:26] <thomcom_> how to make computer do stupid mechanical task: "Dear computer, obey my command."
[19:44:19] <-- kida has left IRC (Ping timeout: 260 seconds)
[20:30:09] <rocket_hamster> where do you guys get your sdl2 knowledge i cant seem to find documentation
[20:39:38] <psch> the wiki has a bit, but your best bet is probably reading the source
[20:40:06] <psch> someone here said someone from sdl2 asked for help with the documentation a few days ago, but i dont remember either of those two persons names
[20:40:21] <rocket_hamster> yes thats what i was affraid of
[20:55:25] <fuzzie> http://thread.gmane.org/gmane.comp.lib.sdl/58637
[20:55:28] <Seniorita> Gmane Loom
[20:56:03] <fuzzie> plus other posts I am too lazy to dig out
[21:03:40] <rocket_hamster> why do they keep their source on hg?
[21:03:52] <rocket_hamster> isnt it a bit prehistoric?
[21:06:39] <psch> mercurial is actually 2 weeks younger than git
[21:08:48] <rocket_hamster> really? huh, dont like it :/
[21:09:01] <rocket_hamster> git seams easier to use
[21:09:43] <fuzzie> well, at this point, git seems to have 'won', given even microsoft announced support
[21:09:51] <fuzzie> so everyone is used to it, and annoyed by other things
[21:09:56] <fuzzie> which I imagine doesn't help
[21:11:54] <thomcom_> Google once did a tech review and preferred hg
[21:11:57] <thomcom_> back in like 2002 lolol
[21:12:25] <thomcom_> i like hg, it has less ways of doing things
[21:12:31] <psch> initial release of mercurial was 2005-04-19
[21:12:37] <thomcom_> git has far too many ways to accomplish the same goal over and over
[21:12:52] <psch> but 8 years and 11 years is close enough for me heh
[21:13:03] <psch> im just nitpicking cause i have the wikipedia page open right now anyway
[21:13:10] <thomcom_> hah!
[21:13:26] <thomcom_> I seem to be losing the ability to estimate time in the past more and more
[21:13:38] <thomcom_> https://code.google.com/p/support/wiki/DVCSAnalysis I think is what I'm talking about. I could have SWORN I read this in like 2006 though.
[21:13:39] <Seniorita> DVCSAnalysis - support - Analysis of Git and Mercurial - User support for Google Project Hosting - Google Project Hosting
[21:13:59] <thomcom_> their note says the analysis was in 2008
[21:14:10] <thomcom_> so I have no idea when or what happened to me
[21:14:20] <psch> yeah, aging is horrible
[21:14:36] <psch> the matrix was released 14 years ago
[21:14:55] <rocket_hamster> what about merging? ive red git has some uber merging/branching capability
[21:15:07] <psch> anyway, thomcom_, you got a bit of free time so maybe we can try to figure out your file finding issues
[21:15:10] <psch> ?
[21:15:18] <thomcom_> sorry no can do
[21:15:30] <thomcom_> big honcho deadline on Monday
[21:15:51] <thomcom_> tomorrow I can look at it again
[21:16:24] <psch> there's not really any rush i guess
[21:16:46] <psch> i mean, it's for your iwd and an eventual release, but the whole tree needs changes for the android builds to be releasable
[21:17:07] <psch> soo, what i gave you was pretty much "here, play iwd, but dont tell anyone yet"
[21:17:42] <thomcom_> thanks dude :)
[21:17:44] <psch> fuzzie: you have any idea wrt modding override with your extract-to-tmp-from-apk idea?
[21:17:46] <thomcom_> i won't step in your toes
[21:17:51] <thomcom_> i'm the newbiest gemrb developer of all
[21:18:12] <fuzzie> psch: isn't it the same as it is on desktop?
[21:18:31] <psch> maybe i misunderstood your idea then
[21:18:43] <psch> what i understood was, we have override, unhardcoded and GUIScripts in the apk
[21:19:11] <psch> we extract them on start of the activity and delete them on shutdown
[21:19:38] <psch> as i understand it, using ttf requires modding override somewhere, which wouldn't be possible with that approach
[21:20:01] <psch> or rather fiddly, as one would have to either mod before packaging the apk or resign the apk with the same debug key as was used for building it
[21:22:04] <psch> you voiced concerns wrt extracting from the apk and leaving the files around, as upgrade could break the files
[21:24:45] <fuzzie> using ttf shouldn't require modding override
[21:24:59] <fuzzie> that's why unhardcoded is split out
[21:25:12] <psch> then i misunderstood something brada said
[21:25:16] <psch> or overinterpreted it
[21:25:44] <psch> the issue remains though, doesn't it
[21:26:03] <psch> if it's not override it's unhardcoded that gets reextracted on each application restart
[21:26:21] <brada> i meant unhardcoded then
[21:26:27] <brada> either way its the same scenario
[21:30:36] <rocket_hamster> not very much documentation in SDL2 src :(
[21:36:32] <fuzzie> it isn't the same scenario
[21:36:37] <fuzzie> the issue doesn't remain
[21:36:54] <fuzzie> otherwise there'd be no point having two directories which did exactly the same thing :)
[21:37:13] <psch> i don't follow
[21:37:32] <psch> we have unhardcoded, override and GUIScripts in the apk
[21:37:34] <fuzzie> well, i don't understand why you think it's a problem
[21:37:44] <fuzzie> if a user wants to mod ttf fonts, they just put the relevant files in their game data
[21:38:03] <psch> okay
[21:38:19] <psch> so fonts isn't in any of override or unhardcoded, but in the game data
[21:38:24] <fuzzie> no
[21:38:30] <fuzzie> I mean, okay, let me start from the beginning.
[21:38:35] <psch> yes please
[21:38:51] <fuzzie> When GemRB wants a file, such as fonts.2da, it searches through a list of directories (or, rather, sources) which could possibly have the file.
[21:38:54] <fuzzie> It picks the first one it encounters.
[21:39:26] <fuzzie> The gemrb unhardcoded directories are deliberately put all the way near the end of the list.
[21:40:03] <fuzzie> So GemRB still finds stuff like fonts.2da there by default, but if the user puts a modified version in their game data, then the modified version will be in a directory earlier in the list, and be picked up first.
[21:40:47] <fuzzie> Make sense?
[21:40:51] <psch> yeah
[21:41:09] <psch> i wouldn't have assumed gemrb looks for file in unhardcoded inside the game data as well
[21:41:20] <psch> but that's clearly a lack of knowledge of the inner workins on my part
[21:41:37] <fuzzie> right, internally gemrb just goes 'ok, I need fonts.2da now, where is it?'
[21:41:47] <fuzzie> it has no special knowledge of where the file might be
[21:42:31] <fuzzie> it's also how the original games work: you have all the game data inside the BIF files, but then you also have an 'override' directory which is checked first.
[21:47:23] <psch> right, so modding in general isn't being done by modifying gemrb override and unhardcoded, but putting the modified files somewhere earlier in the search path
[21:47:40] <brada> ok that answers that
[21:48:29] <brada> so apk away good sir
[21:49:13] <psch> well packaging the folder is the easy part, that's actually pretty much done already
[21:49:32] <psch> i just gotta implement the whole extract-at-start-and-delete-at-shutdown thing
[22:24:38] <-- rocket_hamster has left IRC (Remote host closed the connection)
[22:26:24] <-- edheldil_ has left IRC (Read error: Connection reset by peer)
[22:26:44] <-- lynxlynxlynx_ has left IRC (Read error: Connection reset by peer)
[22:29:53] <-- kingron has left IRC (Quit: Leaving)
[23:55:28] <-- thomcom_ has left IRC (Ping timeout: 245 seconds)