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

Archive Today Yesterday Tomorrow
GemRB homepage


[00:06:23] <-- lynxlynxlynx has left IRC (Remote host closed the connection)
[00:32:27] <-- edheldil has left IRC (Ping timeout: 260 seconds)
[02:08:17] --> brada has joined #gemrb
[03:53:47] <-- Coriander2 has left IRC (*.net *.split)
[03:53:48] <-- |Blaze|_ has left IRC (*.net *.split)
[03:53:49] <-- psch has left IRC (*.net *.split)
[03:53:52] <-- edheldil_ has left IRC (*.net *.split)
[03:53:52] <-- ermo^ has left IRC (*.net *.split)
[03:53:54] <-- Seniorita has left IRC (*.net *.split)
[03:53:55] <-- fireglow has left IRC (*.net *.split)
[03:53:56] <-- nutron has left IRC (*.net *.split)
[03:53:57] <-- xrogaan has left IRC (*.net *.split)
[03:53:58] <-- brada has left IRC (*.net *.split)
[03:53:58] <-- wjp has left IRC (*.net *.split)
[03:53:59] <-- fuzzie has left IRC (*.net *.split)
[03:54:00] <-- Gekz has left IRC (*.net *.split)
[03:54:01] <-- PixelScum has left IRC (*.net *.split)
[03:54:03] <-- DrMcCoy has left IRC (*.net *.split)
[03:54:03] <-- |Cable| has left IRC (*.net *.split)
[03:54:04] <-- gembot has left IRC (*.net *.split)
[03:54:09] <-- tomprince has left IRC (*.net *.split)
[03:55:44] --> brada has joined #gemrb
[03:55:44] --> Coriander2 has joined #gemrb
[03:55:44] --> |Blaze|_ has joined #gemrb
[03:55:44] --> DrMcCoy has joined #gemrb
[03:55:44] --> Gekz has joined #gemrb
[03:55:44] --> PixelScum has joined #gemrb
[03:55:44] --> edheldil_ has joined #gemrb
[03:55:44] --> fuzzie has joined #gemrb
[03:55:44] --> |Cable| has joined #gemrb
[03:55:44] --> tomprince has joined #gemrb
[03:55:44] --> nutron has joined #gemrb
[03:55:44] --> fireglow has joined #gemrb
[03:55:44] --> psch has joined #gemrb
[03:55:44] --> wjp has joined #gemrb
[03:55:44] --> gembot has joined #gemrb
[03:55:44] --> xrogaan has joined #gemrb
[03:55:44] --> Seniorita has joined #gemrb
[03:55:44] --> ermo^ has joined #gemrb
[04:58:48] <-- brada has left IRC (Quit: brada)
[05:30:12] --> brada has joined #gemrb
[07:43:02] <-- brada has left IRC (Quit: brada)
[08:06:29] --> edheldil has joined #gemrb
[08:06:29] --- ChanServ gives channel operator status to edheldil
[08:15:10] --> WingedHussar has joined #gemrb
[08:38:00] <-- edheldil has left IRC (Ping timeout: 264 seconds)
[10:16:01] --> lynxlynxlynx has joined #gemrb
[10:16:01] <-- lynxlynxlynx has left IRC (Changing host)
[10:16:01] --> lynxlynxlynx has joined #gemrb
[10:16:01] --- ChanServ gives channel operator status to lynxlynxlynx
[10:16:45] <-- Coriander2 has left IRC (Read error: Connection reset by peer)
[10:17:41] --> Coriander has joined #gemrb
[12:06:39] <-- lynxlynxlynx has left IRC (Remote host closed the connection)
[12:13:14] --> lynxlynxlynx has joined #gemrb
[12:13:14] <-- lynxlynxlynx has left IRC (Changing host)
[12:13:14] --> lynxlynxlynx has joined #gemrb
[12:13:14] --- ChanServ gives channel operator status to lynxlynxlynx
[12:37:37] --> kida has joined #gemrb
[16:35:33] --> edheldil has joined #gemrb
[16:35:34] --- ChanServ gives channel operator status to edheldil
[16:39:11] --> thomcom has joined #gemrb
[16:41:36] <-- edheldil has left IRC (Ping timeout: 264 seconds)
[16:45:19] <thomcom> psch: build script worked great, seamless with no trouble at all.
[16:46:18] <thomcom> I'm able to build and install the android project in ./build/gemrb but it always crashes with a ClassNotFoundException
[16:48:58] <thomcom> Probably a JNI problem with ADT 17
[16:51:14] <psch> can i see the stacktrace?
[16:51:58] <psch> ive never had that problem with the script as i gave it to you
[16:53:48] <thomcom> http://pastie.org/6348677
[16:53:50] <Seniorita> #6348677 - Pastie
[16:54:06] <thomcom> prep_env.sh ran and finished with no problems
[16:54:29] <thomcom> it didn't provide a way to actually build the android project that I could see though, so i found my way into build/gemrb and tried building that using ant and eclipse
[16:56:40] <psch> it should echo something after finishing
[16:56:40] <psch> you need to run ndk-build inside build/gemrb
[16:56:40] <psch> oh
[16:56:40] <psch> no, it doesn't echo that haha
[16:56:40] --> fizzle has joined #gemrb
[16:56:40] <psch> i wrote a function to echo that and a bit more, but don't call it, inside prep_env.sh
[16:56:40] <thomcom> I tried that and got an error that suggested it was already done
[16:56:40] <psch> ndk-build shouldn't give an error when it's already done
[16:56:40] <thomcom> http://pastie.org/6348696
[16:56:40] <Seniorita> #6348696 - Pastie
[16:56:40] <psch> it should copy the binaries again
[16:56:40] <psch> ugh, i thought i fixed that yesterday before uploading :/
[16:57:02] <psch> hold on
[16:57:13] <thomcom> its cool that's why I'm guinea-ing for you, in part :)
[16:57:17] <psch> yeah, as i thought
[16:57:33] <psch> your build/gemrb/src/Android.mk has an include
[16:57:35] <psch> line 252
[16:57:41] <thomcom> I'm loving having all this android build process already done and extremely thankful that it wasn't me! lol
[16:57:43] <psch> that's the freetype2 makefile
[16:57:59] <psch> but im calling the same makefile recursively from ndk-build
[16:58:02] <psch> so the module gets redefined
[16:58:10] <psch> delete line 252 and it should build
[16:58:44] <thomcom> and its off!
[16:59:06] --> brada has joined #gemrb
[16:59:50] <thomcom> and it fails in SDL build for a bunch of apocalyptic C errors
[16:59:56] <thomcom> stuff like '::memchr' has not been declared
[17:00:06] <psch> huh
[17:00:14] <thomcom> I'm guessing it is because OS X 10.8 uses LLVM by default instead of GCC, I'll switch it to GCC in a bit and try again
[17:00:16] --> vampi-the-frog has joined #gemrb
[17:00:19] <psch> maybe cloning sdl2 head isn't a good idea hah
[17:00:23] <psch> that could be it too
[17:00:33] <psch> another thing though
[17:00:51] <psch> you need to modify GemRB::Interface too to run gemrb succesfully
[17:00:55] <thomcom> errors like "/Users/thomcom/Current/android-ndk-r8/platforms/android-14/arch-arm/usr/include/wchar.h:79: error: 'FILE' was not declared in this scope"
[17:01:04] <vampi-the-frog> I'm getting PS:T to work with higher resolutions (without any mod, just modifying the python scripts), are patches welcome?
[17:01:28] <psch> i can give you a hackish patch, brada said we should get this into the VFS stuff eventually, but i don't really have a clue how to do that
[17:02:06] <thomcom> this is the conversation yesterday about how to get the path to override from Java while running in JNI?
[17:02:26] <psch> yeah, bits of it
[17:02:30] <brada> thomcom: thats the same crap that happens when i try to build using mac os 10.8
[17:02:50] <brada> i have yet to find a solution
[17:03:01] <thomcom> brada: well consistency is good news! :D
[17:03:19] <thomcom> Have you tried switching default compiler?
[17:03:22] <-- vampi-the-frog has left IRC (Remote host closed the connection)
[17:03:32] <brada> no, but afik ndk only has gcc
[17:03:35] <thomcom> OS X 10.8 is a perversion
[17:03:43] --> vampi-the-frog has joined #gemrb
[17:03:50] <thomcom> ah that's a good point prolly true
[17:04:06] <brada> im in no way an android dev :p
[17:05:15] <thomcom> Well its not purely an Android problem if psch can build SDL 2.0 on his linux box but we can't on 10.8
[17:05:32] <brada> right
[17:05:42] <brada> but gemrb is the only thing i had problems compiling
[17:05:54] <brada> i compiled all the deps just fine
[17:05:56] <thomcom> brada: You get all that crap when you try to build using ndk on 10.8, but you don't get it if you build gemrb for desktop on 10.8?
[17:06:18] <brada> gemrb builds without complaint for mac itself
[17:06:53] <thomcom> same here, psch's dependency script worked like a charm
[17:06:58] <thomcom> but ndk-build fails
[17:07:02] <brada> yes
[17:07:04] <brada> well
[17:07:10] <brada> the deps are ndk as well
[17:07:16] <thomcom> I'll ask a buddy of mine who spent hundreds of hours hand holding JNI
[17:07:20] <brada> but only gemrb fails
[17:07:48] <brada> pelyas build failed in the same place for me
[17:07:57] <thomcom> hehe well psch's build script doesn't build SDL, only openal, vorbis, libpng, and freetype
[17:08:22] <thomcom> Have you tried it on a 10.7 machine? 10.8 broke a lot of things.
[17:08:24] <brada> im pretty sure it does build sdl
[17:08:44] <brada> i do but im not inclined to go put the android ndk on it :p
[17:09:31] <brada> psch's build is using the SDL java stuff. i assume gemrb and sdl are intertwined in the build
[17:10:16] <psch> yes, sdl2 isn't prebuilt
[17:10:32] <psch> the whole project template comes from upstream
[17:12:03] <psch> http://filebin.ca/YUVfSgKiZqK/0001-hackish-fix-for-finding-config-and-data-directories-.patch
[17:12:18] <psch> wait
[17:12:25] <psch> we have the pixelformat thing in-tree, right?
[17:12:34] <thomcom> lol fuck
[17:12:41] <thomcom> SDL build problem is because of case insensitive filesystem
[17:12:48] <psch> hah
[17:12:48] <thomcom> String.h/string.h
[17:13:19] <psch> hm, i gotta learn git better :/
[17:13:36] <thomcom> probably not going to get around to fooling with this for a bit
[17:13:36] <thomcom> http://forums.gibberlings3.net/index.php?showtopic=24504&view=findpost&p=202615
[17:13:38] <Seniorita> GemRB for Android compilation attempt.. - The Gibberlings Three Forums
[17:14:43] <psch> yeah i think the ndk currently only really supports building on linux
[17:15:16] <psch> you could allocate an .img of some size somewhere, format that with any case-sensitive filesystem, mount it and put all the build stuff there...
[17:15:31] <psch> or run linux in a vm, which probably would be easier
[17:15:33] <thomcom> I used to always run OS X on a case sensitive file system, but photoshop and certain other bigwig apps fail if you ARE case sensitive, so I stopped
[17:15:47] <thomcom> that's a good idea about the .img
[17:15:53] <brada> i hate that gemrb has files named like that
[17:16:02] <brada> there are a few more iirc
[17:16:09] <psch> yeah it's a crutch at best
[17:16:11] <brada> stdio.h
[17:16:18] <thomcom> GRString.h
[17:16:21] <brada> no there is no reason for it
[17:16:32] <brada> its not to fix or work around anything
[17:16:35] <psch> i mean, relying on a case-sensitive filesystem is crutchy
[17:16:37] <thomcom> that's pretty destructive. GemRB has its own stdio.h???
[17:16:48] <psch> deciding to name the files the same is just not so clever
[17:16:55] <brada> its not what you think it is either
[17:17:04] <thomcom> it'd be good for windows developers too, to get away from case sensitive requirements
[17:17:29] <thomcom> not like it was done on purpose though. implicit constraints exist with every implicit design decision and they cascade through the whole dependency tree
[17:18:34] <thomcom> Well sounds like you've made awesome progress psch, sorry I can't build it yet :)
[17:18:58] <brada> i think its pretty safe to run os x CS these days
[17:19:25] <brada> but nobody does because they come performatted CI
[17:19:26] <psch> as i said, i can give you an .apk if you really want
[17:19:53] <psch> ill check it once more, to see if i do have everything i need on my tree
[17:19:58] <brada> so much for me being able to buildbot gemrb android :/
[17:20:07] <thomcom> Really the main reason I stopped is because all of my mac using colleagues wouldn't think to use CS, and were boggled when they saw I did, and pissed when some implicit constraint reared its head to bite us.
[17:20:22] <thomcom> Just trying to drink the koolaide, too bad I'm an Android developer now instead of an iOS dev haha
[17:21:01] <thomcom> ndk-build
[17:21:18] <brada> fuzzie: thomcom figured out why gemrb for android doesnt build on mac
[17:26:36] <thomcom> Making a case sensitive disk image and moving the build attempt there is definitely the shortest path.
[17:26:49] <thomcom> I'll try that today or tonight and see if the build progresses farther
[17:27:17] <thomcom> brada: then we'll know if I did or did not figure out why it doesn't build on mac ;)
[17:27:26] <brada> ha
[17:27:32] <brada> well it seems likely
[17:29:01] --> edheldil has joined #gemrb
[17:29:01] --- ChanServ gives channel operator status to edheldil
[17:33:44] <fuzzie> brada: I didn't know it didn't, don't tell me :P
[17:38:30] <fuzzie> i don't see where we have any case-sensitivity conflicts though
[17:39:21] --> rocket_hamster has joined #gemrb
[17:41:07] <fuzzie> we have one String.h, and it's in core/System which isn't in any include path, and it's referenced only by full path from non-global #include statements..
[17:41:34] <fuzzie> oh I see, the forum post explains.
[17:43:05] <fuzzie> i.e. the NDK build system produces broken paths.
[17:43:28] <thomcom> haha
[17:43:33] <fuzzie> that's pretty idiotic.
[17:43:35] <thomcom> high five, Android development team!!!
[17:44:34] <fuzzie> Every time I see anything involving Google's fascinating Android build stuff, I am more and more cheerful that I don't use it.
[17:45:44] <fuzzie> although sometimes I am exposed to the stupid, e.g. apkbuilder complains "THIS TOOL IS DEPRECATED. See --help for more information.", and then crashes when you run it with --help.
[17:45:59] <psch> haha
[17:46:04] <fuzzie> (admittedly I didn't try that with a recent SDK, I hope they fixed it by now)
[17:46:17] <psch> nope, still broken
[17:46:25] <fuzzie> nice.
[17:47:07] <psch> it's an ArrayIndexOutOfBounds...
[17:47:09] <thomcom> system libraries unable to include their other system library dependencies
[17:47:23] <fuzzie> psch: right, it requires two params, try '--help --help'
[17:47:35] <psch> Unknown argument: --help
[17:47:39] <psch> ahahaha
[17:48:12] <psch> this is truly entertaining to me
[17:48:18] <thomcom> your mistake was asking for help
[17:48:54] <fuzzie> for reference, "THIS TOOL IS DEPRECATED" = "why aren't you using ant or eclipse? you should be using ant or eclipse!"
[17:49:00] <fuzzie> rather than any actual problem of any kind at all
[17:49:30] <fuzzie> anyway sorry, totally off-topic.
[17:49:45] <psch> thomcom: you did point me towards two missing things inside prep_env.sh, in any case
[17:50:10] <thomcom> yeah totes
[17:50:34] <psch> we have to run "android update project -t android-17 -p build/gemrb" and the SDLActivity thing was something i overlooked in AndroidManifest.xml
[17:50:47] <psch> i did change the package but not the name of the activity class
[17:51:11] <psch> those should be fixed now, im building again
[17:51:33] <fuzzie> so is this in a state where we can hopefully easily do builds soon?
[17:51:54] <psch> i have 5 changes in my local gemrb tree
[17:52:12] <psch> one of those definitely warrants some further engineering, brada said something about VFS
[17:52:27] <psch> the others are just the fixes with openal from pelya vs the port im building against
[17:52:38] <fuzzie> that sounds really positive
[17:53:00] <psch> i still have to figure out a way to package override, unhardcoded and GUIScripts into the apk, because that seems pretty user-friendly to do, and currently they have to be copied manually
[17:53:27] <psch> one minor gripe i still have with how we get the data is that uninstalling the gemrb apk also removes the gamefiles
[17:53:40] <psch> with 2.5gb that could probably annoy a few people quite much
[17:53:42] <brada> well i cant buildbot it on my machine till it builds for mac
[17:53:50] <brada> but somebody else can
[17:55:08] <thomcom> brada:
[17:55:18] <thomcom> why don't you create the case sensitive disk image
[17:55:39] <fuzzie> psch: they can't just go on the sdcard root?
[17:55:41] <thomcom> if you've got 3-4gb to spare you could make it, mount it, then check out/move gemrb source there
[17:55:57] <thomcom> try out pschs script, then see if ndk-build handles the case insensitivity issue
[17:56:03] <fuzzie> the idea google have that 'uninstalling app' means 'delete all app data' is really annoying
[17:56:24] <thomcom> psch: at one time uninstalling gemrb did not uninstall my game files
[17:56:27] <fuzzie> especially if savegames etc got saved in the same place
[17:56:39] <thomcom> i uninstalled it this morning to try your build. hope it didn't delete my game data lolol
[17:56:42] <fuzzie> but it's only the app data directories which get deleted
[17:56:54] <fuzzie> so as long as you put them somewhere else, all is well
[17:57:06] <psch> fuzzie: well, 4.2 has this multi-user thing, from my testing i can't directly access /sdcard/, but i can access /storage/emulated/0/, which is the same physical drive, but owned by the first (and only) user on my tablet
[17:57:23] <thomcom> my data is good still in sdcard/app-data/net.sourceforge.gemrb
[17:57:36] <psch> but we can't hardcode /storage/emulated/0/ because then every not-first-user can't use gemrb
[17:57:54] <psch> the only portable way seems to be ActivityManager.getExternalStoragePath()
[17:57:57] <fuzzie> yes
[17:57:57] <tomprince> Well, shouldn't you be able to find that path?
[17:58:01] <thomcom> psch: pelya's build on the play store doesn't require that you do any override/GUIScripts changes
[17:58:13] <psch> which points to /storage/emulated/0/$package/files/
[17:58:20] <psch> thomcom: i know, but i don't see through what pelya does
[17:58:45] <psch> where $package = Android/data/$javapackagepath
[17:58:48] <fuzzie> thomcom: it has this mess with zip files which it will auto-download but which are painful to update
[17:58:59] <psch> so not actually package...
[17:58:59] <-- kida has left IRC (Ping timeout: 248 seconds)
[17:59:01] <psch> but yeah
[17:59:25] <psch> i haven't found a way to cleanly get an absolute path on the sdcard for 4.2 that doesn't have the multi-user stuff in front
[17:59:34] <fuzzie> there isn't one
[17:59:55] <fuzzie> but getExternalStorageDirectory() should get you the per-user sdcard which is as good as you get
[18:00:08] <thomcom> seems good enough to me
[18:00:10] <psch> fwiw, pelyas build also looks in /storage/emulated/0/data/net.sourceforge.gemrb/
[18:00:13] <fuzzie> and that's a bit terrible if that gives you an app-specific one :(
[18:00:14] <psch> on my 4.2 device
[18:00:20] <thomcom> if you're using android at a multi user level then you're power user enough to copy the game files where they can be shared between users
[18:00:28] <thomcom> why bother trying to make Android user friendly anyway hurr hurr hurr
[18:00:39] <psch> fuzzie: to be fair, i use SDL_AndroidGetExternalStoragePath()
[18:00:41] <fuzzie> thomcom: right but of course you have no access to the files as another user to copy them :P
[18:00:48] <psch> which gives me $appData/files
[18:01:08] <psch> i.e. /storage/emulated/0/Android/data/net.sourceforge.gemrb/files
[18:01:19] <fuzzie> psch: right, that is not the same call
[18:01:32] <thomcom> i admit I haven't looked at the multi user stuff at all. shoudln't you be able to have some kind of admin user access to modify all files on the device other than root files?
[18:01:33] <psch> i figured
[18:01:34] <fuzzie> that calls context.getExternalFilesDir() which is indeed an app-specific one
[18:01:39] <thomcom> yuck
[18:01:45] <fuzzie> thomcom: Google knows all and sees all! Google is the admin!
[18:02:13] <fuzzie> I haven't played with a 4.2 device myself for long enough to work it out, so I'm just going by what people are complaining about on the internet.
[18:02:14] <psch> so we don't go with SDL but with JNI ActivityManager, which lets you get a non-app specific user-owned path
[18:02:47] <psch> that probably should still be wrapped somewhere in VFS, if i understand that correctly
[18:02:57] <fuzzie> well, you probably just want Environment.getExternalStorageDirectory
[18:03:03] <fuzzie> but yes make it brada's problem if you can :p
[18:04:24] <-- vampi-the-frog has left IRC (Ping timeout: 264 seconds)
[18:05:28] <psch> !
[18:05:41] <psch> brada: you're patch wrt pixelformat does nothing
[18:05:42] <psch> because
[18:05:49] <psch> and this i find highly interesting
[18:05:57] <psch> we don't get SDL_PIXELFORMAT_UNKNOWN
[18:06:10] <psch> but a pixelformat that doesn't exist
[18:06:12] <brada> you dont look at the commit history much do you? ;)
[18:06:21] <psch> no, i just glance at the code :/
[18:06:49] <psch> how do i read the commit history
[18:06:50] <psch> haha
[18:07:55] <rocket_hamster> what? git log?
[18:08:01] <psch> yeah that's what i meant
[18:08:57] <brada> http://gemrb.git.sourceforge.net/git/gitweb.cgi?p=gemrb/gemrb;a=summary
[18:08:59] <Seniorita> SourceForge - gemrb/gemrb/summary
[18:09:07] <psch> yeah, i saw the patch in the tree
[18:09:08] <psch> the commit
[18:09:12] <psch> "make a guess" etc
[18:09:15] <psch> i read that code too
[18:09:22] <psch> and you're comparing to SDL_PIXELFORMAT_UNKNOWN
[18:09:34] <brada> thats what we were getting before
[18:09:44] <brada> according to the log output
[18:10:19] <psch> well it still segfaults for me with that patch
[18:10:30] <brada> i dont know what to tell you
[18:10:39] <psch> i remember looking into the header for pixelformats and doing some math to find the numeric values that correspond to pixelformats
[18:10:50] <psch> and they didnt match
[18:10:56] <psch> or rather, weren't equal
[18:11:09] <psch> im think a) sdl2 is weird or 2) my device is weird
[18:11:13] <brada> they are just ints
[18:11:37] <rocket_hamster> pixel is device and context dependant isnt it
[18:11:40] <psch> yes, and the value that i saw when stepping to the call in gdb wasn't the same as for SDL_PIXELFORMAT_UNKNOWN
[18:11:41] <rocket_hamster> pixelformat
[18:13:19] <brada> isnt SDL_PIXELFORMAT_UNKNOWN just 0
[18:13:42] <psch> well the value i get isn't 0, it's something around 320000
[18:13:58] <brada> so log it using SDL_GetPixelFormatName
[18:14:37] <psch> okay
[18:14:44] <psch> that's a function i didnt think could exist
[18:16:41] <psch> im thinking the unknown pixelformat error message comes from trying to set an unknown pixelformat - not SDL_PIXELFORMAT_UNKNOWN
[18:16:44] <psch> if that makes sense
[18:16:55] <psch> but i'll just log the output of SDL_GetPixelFormatName
[18:20:36] <psch> I/GemRB ( 7181): [SDL 2 Video/]: Got pixelformat -2062217214: SDL_PIXELFORMAT_UNKNOWN.
[18:21:24] <psch> i was wrong once again, it wasn't something somwhere around 300000 it seems
[18:21:53] <thomcom> haha pixelformat -2062217214
[18:21:57] <thomcom> that's bad news
[18:21:59] <wjp> where do you get this value from?
[18:22:30] <thomcom> Got pixelformat SDL_PIXELFORMAT_BAD_POINTER_SOMEWHERE
[18:22:33] <brada> so cahnge that to <=
[18:22:55] <psch> wjp: SDL_GetWindowPixelFormat()
[18:23:06] <wjp> charming
[18:23:06] <psch> will do brada
[18:24:14] <brada> the docs say it will return SDL_PIXELFORMAT_UNKNOWN
[18:24:46] <brada> clearly it returns something that mearly evaluates to SDL_PIXELFORMAT_UNKNOWN when passed to SDL_GetPixelFormatName
[18:25:22] <brada> psch: you also need to set bpp in your gemrb.cfg
[18:25:24] <brada> to 16
[18:25:27] <psch> i have
[18:25:29] <brada> ok
[18:30:33] <wjp> interesting
[18:30:50] <psch> alright so, i think im mistreating Log()
[18:30:53] <wjp> that value is what the android SDL java code thinks is SDL_PIXELFORMAT_RGB565
[18:30:58] <wjp> int sdlFormat = 0x85151002; // SDL_PIXELFORMAT_RGB565 by default
[18:31:05] <psch> cause windowformat is uint32
[18:31:11] <psch> and that's unsigned right
[18:31:15] <psch> but %d prints signed?
[18:31:39] <wjp> (and 0x85151002 is -2062217214)
[18:31:54] <wjp> for values like this probably %08X is best
[18:32:30] <wjp> so if that isn't SDL_PIXELFORMAT_RGB565, then SDLActivity.java is broken
[18:34:22] <psch> SDL_header.h does some shifty things i can't follow in my head
[18:34:59] <psch> err
[18:35:01] <psch> SDL_pixel.h
[18:36:18] <wjp> but given that SDL_GetPixelFormatName doesn't accept it, I'd say it's broken :-)
[18:36:30] <wjp> and that (1<<28) at the start does strongly suggest it shouldn't be this large
[18:46:51] --> vampi-the-frog has joined #gemrb
[18:55:14] <-- vampi-the-frog has left IRC (Remote host closed the connection)
[19:00:25] <psch> four lines inc.
[19:00:27] <psch> (gdb) print/x SDL_GetWindowPixelFormat(window)
[19:00:27] <psch> $5 = 0x85151002
[19:00:27] <psch> (gdb) print/x SDL_PIXELFORMAT_RGB565
[19:00:27] <psch> $6 = 0x15151002
[19:00:33] <-- brada has left IRC (Quit: brada)
[19:00:38] <psch> that's the only thing i could think of
[19:00:55] <psch> so one of those two is broken i guess
[19:03:14] <thomcom> hahaha
[19:03:30] <psch> or is it bitorder?
[19:03:30] <wjp> this was a fairly recent change to PIXELFORMAT it seems
[19:03:43] <wjp> the (1<<28) was originally a (1<<31)
[19:03:51] <wjp> changed in Nov 2012
[19:04:08] <wjp> so I'm guessing if you change the leading 8 to a 1 in all those constants, it'll be fine
[19:14:38] <psch> this looks like someone missed the note in SDL_pixels.h
[19:15:04] <psch> which states to change SDL_GetPixelFormatName
[19:15:07] <wjp> no
[19:15:14] <wjp> unrelated
[19:15:47] <wjp> this is the java code getting out of sync with a C header
[19:16:01] <psch> oh
[19:16:11] <psch> right, you mentioned something about the activity
[19:16:12] <psch> my bad
[19:16:31] <wjp> I suppose I'll file an SDL bug report
[19:17:06] <fuzzie> that sounds dangerously helpful
[19:17:21] <wjp> I tried lazily just mentioning it on #sdl, but that doesn't seem to do much
[19:18:46] <wjp> but registering a bugzilla account is giving an internal server error, so...
[19:28:41] <rocket_hamster> that looks like big reporting dependency hell
[19:28:43] <rocket_hamster> :]
[19:28:48] <-- thomcom has left IRC (Ping timeout: 245 seconds)
[19:28:49] <rocket_hamster> bug*
[19:30:11] <-- edheldil has left IRC (Ping timeout: 260 seconds)
[19:30:51] --> brada has joined #gemrb
[19:32:39] --> edheldil has joined #gemrb
[19:32:39] --- ChanServ gives channel operator status to edheldil
[19:33:24] --> brada_ has joined #gemrb
[19:33:24] <-- brada has left IRC (Read error: Connection reset by peer)
[19:33:24] --- brada_ is now known as brada
[19:36:19] <-- rocket_hamster has left IRC (Quit: bye!)
[19:38:50] <brada> they are having db issues
[19:39:33] <wjp> I now have mail stuck in some moderation queue somewhere
[19:39:42] <wjp> so not my problem anymore :-)
[19:39:43] <brada> yeah
[19:39:49] <brada> happened to me too
[19:40:52] <fuzzie> as long as it doesn't bounce :-p
[19:41:21] <fuzzie> I mailed wireshark's security-bug-reporting alias the other day and was not amused to get a bounce mail in response.
[19:41:44] <fuzzie> (thankfully, their bugzilla works fine)
[19:47:50] <fuzzie> hm, my gemrb build is broken in a quite nutty way
[19:48:50] <fuzzie> ok, clearing the cmake cache fixed it.
[19:49:47] <fuzzie> now my fonts are broken.
[19:50:10] <fuzzie> who broke my fonts.
[19:51:16] <fuzzie> i mean, the fonts on the buttons in the intro are suddenly too small
[19:51:24] <fuzzie> in fact, all the fonts on buttons
[19:51:37] <fuzzie> this is very irritating for some reason
[19:51:57] <brada> bisect?
[19:52:06] <brada> i think it was some caps change
[19:52:08] <brada> not sure
[19:52:17] <fuzzie> well it's clearly incorrect at the first screen you see in bg2 :/
[19:52:21] <brada> yes
[19:52:23] <brada> i have noticed
[19:52:32] <brada> tho it was not me that broke them
[19:52:54] <fuzzie> gar
[19:54:01] <brada> probably just need to add a setting to the gemrb.ini for bg2
[19:54:29] <brada> or maybe the problem is that only english needs the caps
[19:54:51] <brada> because i think it was done due to polish text being far too large
[19:55:04] <fuzzie> it looks more like someone called jensgr breaking the button flags
[19:55:07] <fuzzie> is that fizzle?
[19:55:11] <fuzzie> i am not keeping track
[19:55:51] <fuzzie> commit 74bf3505ebd4919074dbf4b875274ebe368cddff breaks the flags, anyway
[19:56:00] <fuzzie> or, rather, breaks the CAPS flag
[19:56:16] <brada> yes that is fizzle
[19:56:23] <fuzzie> fizzle: you broke my battleship :(
[19:56:36] <fuzzie> this is very non-obvious: the top 8 bits of the flag are required to match the control id
[19:56:49] <fuzzie> and that commit makes the CAPS flag 0x01000000, which has the top 8 bits equal to 1
[19:57:00] <brada> ug
[19:57:10] <brada> better fix it AND comment
[19:57:45] <fizzle> eh, sorry about that
[19:58:24] <fuzzie> but in any case the bits from 8-15 come from the original game data..
[19:59:06] <fuzzie> so it's a bit weird that we re-use one of them anyway
[19:59:16] <brada> which one?
[19:59:37] <fuzzie> IE_GUI_BUTTON_DRAGGABLE is outside the 'hardcoded' comment
[19:59:50] <fuzzie> probably it's just not set in any original files
[20:00:04] <fuzzie> just maybe it'd make more sense to split the flags up somehow
[20:01:01] <fuzzie> the alternative is to shift the control id over a bit or two I guess?
[20:01:09] <fuzzie> but I'm not sure I dare touch this
[20:01:59] <brada> maybe some assertions with those will prevent future problems
[20:02:16] <brada> till you add a new flag
[20:02:24] <fuzzie> and then it all breaks again
[20:07:49] --> Yoshimo has joined #gemrb
[20:17:09] <psch> alright, i updated prep_env.sh with the change to SDLActivity.java, uncommenting the exit call in SDL_android_main.cpp and the fixes for the things thomcom pointed me at
[20:17:27] <psch> ill do some reading how to get the data folders into the apk and read them from there now i guess
[20:17:53] <brada> so that exit() does fix your hang then?
[20:18:17] <psch> yeah, it closes cleanly it seems
[20:18:26] <psch> as in, it doesn't stay up
[20:18:29] <brada> right
[20:18:44] <brada> and that hang is the expected behavior without that exit()
[20:18:52] <psch> not sure if it's actually clean
[20:18:52] <brada> because the app runloop is still running
[20:19:09] <brada> well any uncleanliness would be part of the java side
[20:19:19] <brada> and you should clean that up before launching gemrb
[20:19:32] <brada> but its exiting so who the hell cares
[20:20:00] <psch> well the ActivityManager logs that the activity died
[20:20:18] <psch> and after that i get a log message from WindowState that the window died
[20:20:22] <brada> ok well if you want it "clean" then i guess you would have to terminate the java runloop
[20:20:45] <brada> or what are you passing to exit?
[20:20:58] <brada> exit(0) should be clean no?
[20:21:24] <brada> you should pass whatever gemrb returns
[20:21:53] <psch> that's what the previously commented call does
[20:22:03] <brada> ok
[20:22:08] <psch> status = SDL_main(1, argv); exit(status)
[20:22:11] <psch> ;
[20:22:33] <brada> why 1, argv
[20:22:40] <brada> shouldnt that be argc, argv
[20:23:05] <psch> that's how it comes from the sdl hg
[20:23:12] <psch> with 1
[20:23:22] <brada> isnt there an arg c tho?
[20:23:25] <brada> argc
[20:23:53] <brada> i think its obvious by now that you cant assume the android sdl code is perfect
[20:24:10] <psch> im not assuming it's perfect
[20:24:30] <psch> but what they're doing is setting argv[0] to the name of the application and argv[1] to NULL
[20:24:47] <psch> thus calling SDL_main with 1, argv seems to make sense to me
[20:24:59] <psch> seeing as people hardly supply arguments to android apps
[20:25:08] <brada> ok
[20:26:00] <psch> mind, i have no idea if actually following the convention would have benefit, or if it wouldn't work
[20:26:22] <psch> but i think i made that pretty clear that i have close to no clue to what im doing here
[20:26:56] <brada> its fine the way you described it
[20:27:06] <brada> it obviously works
[20:27:19] <brada> i was jsut wondering why they hardcoded the 1 there
[20:27:29] <fuzzie> because there's no real argc/argv
[20:27:46] <brada> there we go
[20:27:48] <fuzzie> you just get a library loaded from a fork of the java runtime
[20:28:13] <fuzzie> and so presumably that gives you no way to pass command-line params
[20:28:37] <psch> there probably is a way somewhere, pelya allows additional command line arguments
[20:28:44] <psch> but he does lots of things
[20:29:09] <fuzzie> i think from the config though
[20:29:21] <fuzzie> i mean, i guess obviously from the config
[20:29:35] <fuzzie> so it's just making a different fake argv and passing a different fake argc, presumably
[20:32:53] <brada> yes
[20:34:03] <fuzzie> again this all comes with the usual disclaimer that I really have no clue about this :)
[20:37:32] <-- Yoshimo has left IRC (Quit: Yoshimo)
[20:42:27] <psch> hm, we do need some extra logic for reading override etc. from the apk i think
[20:42:45] <psch> packaging the folder with the apk is easy enough, but they're obviously not on the filesystem anymore then, but inside the archive
[20:43:00] <fuzzie> sdl has some code for it somewhere
[20:43:13] <brada> yes we already know we need special logic for getting android paths
[20:43:28] <psch> yes but this extra extra logic brada :(
[20:44:53] <fuzzie> the apk is just a zip file
[20:45:04] <psch> files in the "assets" folder [...] will get bundled [...] and you can load them with the standard function in SDL_rwops.h
[20:45:22] <psch> from README.android
[20:45:22] <fuzzie> and, right, SDL has the assets wrapped with rwops code
[20:45:27] <fuzzie> as inspired by scummvm's equivalent code
[20:46:10] <fuzzie> the easiest thing to do is presumably just to unzip them to a temp folder on every startup, honestly, if you can somehow hook that up
[20:48:38] --> Yoshimo has joined #gemrb
[20:49:43] <fuzzie> it doesn't sound like much fun doing anything else
[20:49:51] <fuzzie> also it comes with weird problems if you have zip files inside zip files
[20:49:56] <fuzzie> which haunt you forever
[20:51:24] <psch> the ndk and the shame from babbling inappropriately already haunt me, how much worse can it get!
[20:54:34] <fuzzie> well, you have users complaining that you have 5 minute freezes while rwops sits there and continually reopens the file again and again and again as the zip code tries to seek
[20:55:11] <psch> okay that does sound worse
[20:56:02] --> brada_ has joined #gemrb
[20:56:02] <-- brada has left IRC (Read error: Connection reset by peer)
[20:56:02] --- brada_ is now known as brada
[21:00:32] <-- Yoshimo has left IRC (Quit: Yoshimo)
[21:00:39] <fuzzie> well in any case, hopefully unzipping them once at startup should be pretty fast, and means you'd only have to care about rwops in one place, but maybe still not much fun
[21:01:47] <psch> we could do it similar to what pelya does, couldn't
[21:02:06] <psch> on start, check for an existing file, if not extract the folders into the config-set path
[21:02:07] <fuzzie> well, that seems error-prone
[21:02:13] <fuzzie> since we change these files quite a lot
[21:02:29] <psch> yeah, but if we don't download them but package them into the .apk they're always the right version for the apk
[21:02:47] <fuzzie> yes, but what happens on upgrade?
[21:03:22] <psch> true, we'd need meaningful subversioning for the apks then
[21:04:15] <fuzzie> android has java.util.zip.ZipInputStream which should make it trivial to do from the Java side, anyway
[21:04:18] <psch> but if the check file has the subversion as content, we read that and trunc the directory if it's outdated
[21:04:42] <psch> but yeah, the whole versioning stuff definitely seems like it requires more work in other places
[21:23:08] --> Yoshimo has joined #gemrb
[22:36:36] <-- Yoshimo has left IRC (Quit: Yoshimo)
[22:40:33] <-- fizzle has left #gemrb
[22:44:51] --> thomcom has joined #gemrb
[22:45:58] <-- |Cable| has left IRC (Ping timeout: 272 seconds)
[22:51:27] <-- thomcom has left IRC (Quit: Page closed)
[22:57:34] --> |Cable| has joined #gemrb
[23:04:55] --> brada_ has joined #gemrb
[23:04:55] <-- brada has left IRC (Read error: Connection reset by peer)
[23:04:55] --- brada_ is now known as brada
[23:15:23] --> brada_ has joined #gemrb
[23:15:24] <-- brada has left IRC (Read error: Connection reset by peer)
[23:15:24] --- brada_ is now known as brada
[23:18:42] --> brada_ has joined #gemrb
[23:18:43] <-- brada has left IRC (Read error: Connection reset by peer)
[23:18:43] --- brada_ is now known as brada
[23:27:25] --> brada_ has joined #gemrb
[23:27:25] <-- brada has left IRC (Read error: Connection reset by peer)
[23:27:25] --- brada_ is now known as brada
[23:36:44] --> brada_ has joined #gemrb
[23:36:44] <-- brada has left IRC (Read error: Connection reset by peer)
[23:36:44] --- brada_ is now known as brada
[23:47:08] <-- brada has left IRC (Quit: brada)