[00:47:18] <-- Canageek has left IRC (Ping timeout: 252 seconds)
[03:55:58] --> Canageek has joined #gemrb
[04:43:14] <-- Canageek has left IRC (Quit: KVIrc 4.0.4 Insomnia The future is here. It's just not widely distributed yet. - William Gibson)
[05:19:48] --> brada has joined #gemrb
[06:03:02] <-- brada has left IRC (Quit: brada)
[07:11:39] --> edheldil has joined #gemrb
[07:11:39] --- ChanServ gives channel operator status to edheldil
[07:38:09] <fuzzie> oh I see, wiki links to AUTHORS page under 'e-mail addresses' on front page :P
[07:51:56] --> cj_schnell has joined #gemrb
[07:56:50] <cj_schnell> psch: Let me know if I can help you out with the Android installer. As far as I can tell, the apk does not extract all gemrb files and folders
[07:58:44] --> WingedHussar has joined #gemrb
[10:08:38] <psch> cj_schnell: your post on the forums tells me that GamePath isn't set correctly in the config
[10:08:54] <psch> which is actually a slightly different problem, which i neatly overlooked
[10:09:35] <psch> as in, gemrb files and folders do get extracted correctly, same for the template config, but all of those files end up in a path that's not easily accessible for a non-developer, i.e. via usb mount
[10:11:06] <psch> i guess i'll have to have a closer look at how pelya set the path for the config file...
[10:11:51] <psch> the solution that's implemented right now is rather neat in so far as that all gemrb data is on the internal storage with the app and can get deleted, but actual game data can be read from whereever
[10:12:12] <psch> this break on GemRB.cfg, as mentioned, as most likely everyone will have to edit it to have games run
[10:12:55] <fuzzie> not on the external storage?
[10:13:19] <psch> no, you are correct
[10:13:33] <psch> internal wasn't the right word, it's app-specific external storage
[10:13:40] <psch> sorry, i just woke up half an hour ago
[10:37:55] <psch> im not sure how to sanely solve that for now, actually
[10:38:29] <psch> looking directly on the root of the sdcard might work for most devices, seeing as users should be able to put files there
[10:39:30] <psch> ideally we probably want a "where's your gamedata?" dialog, but that breaks multiple games; the alternative being "where's your config?"
[10:56:56] <-- edheldil has left IRC (Quit: Really?)
[11:02:33] <cj_schnell> That explains some of the issues I see. Just let me know if you want me to try out a new package when you get a good idea on how to move forwards. And a big thanks for your awesome work on getting the new GemRB apk up.
[11:03:30] <cj_schnell> Will we have two GemRB Android apps on the marketplace or should the current PLEYA distribution be disgarded?
[11:28:28] <psch> as far as i remember, the verdict is still out on that one
[11:28:58] <psch> (is that expression even correct? i mean it's not decided...)
[11:31:06] --> lynxlynxlynx has joined #gemrb
[11:31:06] <-- lynxlynxlynx has left IRC (Changing host)
[11:31:06] --> lynxlynxlynx has joined #gemrb
[11:31:06] --- ChanServ gives channel operator status to lynxlynxlynx
[11:33:29] <psch> cj_schnell: can you try this build? http://filebin.ca/fMvuRlsPp3i/gemrb-0.8.0-1.apk
[11:33:43] <psch> you need a correct config named GemRB.cfg on the root of your sdcard
[11:34:52] <psch> this is just a minor fix to get it working at all; im really not happy having overlooked that people usually don't put stuff in the app-specific external storage...
[12:02:49] <lynxlynxlynx> no?
[12:03:03] <lynxlynxlynx> i thought it was all stored in the external one
[12:05:28] <psch> im trying to confirm this right now, with a windows pc
[12:05:32] <psch> but it takes some time
[12:05:43] <psch> i don't know if the app-specific storage is accessible
[12:06:03] <psch> but even if it is, "/sdcard/Android/net.sourceforge.gemrb/files/GemRB.cfg" is quite a path...
[12:06:30] <psch> i really should get to writing the "where's your game data" dialog soon
[12:08:09] <psch> it is accessible, which is good
[12:08:16] <psch> so, yeah
[12:08:29] <fuzzie> is it different if you're using the per-user stuff?
[12:08:52] <psch> i think it should always show the data for the current user
[12:08:57] <fuzzie> also are you signing the apks with a non-debug key?
[12:08:58] <psch> when mounted as usb storage, that is
[12:09:07] <psch> no, im not signing them
[12:09:12] <fuzzie> that might be a good idea
[12:09:25] <psch> i should sign them?
[12:09:28] <fuzzie> yeah
[12:10:08] <fuzzie> well, unless you intend to talk to Pelya and get them all signed with that key..
[12:10:34] <psch> so we've settled on a new entry to the play store?
[12:10:47] <fuzzie> but as I understand it, you can't upgrade apks signed with different keys, you have to uninstall first
[12:11:01] <fuzzie> and of course you can't upload to the store with a debug key and they're only valid for a year anyway
[12:12:12] <psch> right
[12:12:26] <fuzzie> so whatever you plan to do, signing anything you make public with your own key can't be a bad thing, right?
[12:12:39] <psch> i guess
[12:12:42] <fuzzie> (or with some new gemrb-specific key)
[12:12:55] <psch> the latter sounds better, i think
[12:13:33] <psch> in any case, im getting in a bit over my head here, i just wanted to push out some kind of working build as a basis haha
[12:13:38] <psch> well, no easy way out, eh
[12:13:49] <fuzzie> signing is pretty easy I think
[12:13:56] <lynxlynxlynx> we need to investigate if project ownership can be changed on the store
[12:14:37] <fuzzie> yes, it can
[12:14:49] <fuzzie> but you can't switch signing keys
[12:18:24] <lynxlynxlynx> that shouldn't be a problem
[12:18:36] <fuzzie> well, except that pelya won't give you the pelya signing key
[12:18:37] <lynxlynxlynx> anyway, we should iron the build out first
[12:18:59] <lynxlynxlynx> oh, i misunderstood then
[12:19:14] <psch> well the build works
[12:19:29] <fuzzie> and as far as I can see the same key is used to sign both OpenTTD and GemRB for example
[12:19:36] <psch> people just have to edit their config in Android/data/net.sourceforge.gemrb/files/
[12:20:14] <psch> that path is accessible via usb MTP mount on my nexus7 and via usb mount on my nexus s
[12:20:31] <fuzzie> external storage data paths should always be accessibl
[12:20:31] <fuzzie> e
[12:21:11] <psch> that does make sense - i only go over adb on my nexus7 so i didnt want to assume blindly
[12:21:18] <psch> that hasn't worked so well in the past :P
[12:21:42] <fuzzie> did you get successful tests of it now?
[12:22:01] <psch> no, im waiting on cj_schnell to adjust his config
[12:22:55] <psch> i guess i could post the same on the forums, too
[12:23:38] <cj_schnell> psch: sorry was AFK a while. Let me check it.
[12:24:13] <psch> cj_schnell: just to reiterate, ignore the build above and adjust your config in /sdcard/Android/data/net.sourceforge.gemrb/files/
[12:24:31] <psch> the file GemRB.cfg should be there, you need to correct the GamePath var
[12:24:47] <psch> and CD1 etc, depending on your game
[12:25:26] <cj_schnell> Ok. Let me check it out.
[12:26:34] <lynxlynxlynx> heh, ishad's problem is real, something applies fx_death without a trace (delayed)
[12:27:07] <psch> im not getting path registration on the forums
[12:27:32] <psch> the challenge question is hard :P
[12:27:59] <psch> oh it only wants the year, alright
[12:30:51] <psch> ill wait for the test before posting the path in the forums
[12:34:43] <cj_schnell> psch: Do I have to have the BG1 files present or should it be fine to run the demo without the bg files?
[12:35:59] <psch> you need any one of bg1, bg2 or the bg2 demo
[12:36:19] <psch> the path to the game data of any one of those is what GamePath has to be set to
[12:38:07] <cj_schnell> OK, I will upload the BG1 files to my phone. Sorry, but it will take a while.
[12:41:26] <cj_schnell> Should I modify packaged.GemRB.cfg, or GemRB.cfg?
[12:42:08] <lynxlynxlynx> the gemrb demo should work too, but the paths are different
[12:42:29] <psch> modify GemRB.cfg
[12:46:31] <cj_schnell> Are the folders and files case sensitive?
[12:47:07] <psch> that depends on your phones external storage - when in doubt go with "yes"
[12:52:54] <cj_schnell> The changes I do to Android\data\net.sourceforge.gemrb\files\GemRB.cfg does not seem to be read by GemRB. Event hough I set GamePath=/XXX I still see in /sdcard0/gemrb/bg1/GemRB.log that: Invalid path given: /sdcard/gemrb/bg1/override
[12:53:17] <psch> right, my bad
[12:53:32] <psch> check GameOverridePath
[12:53:41] <psch> i should be commented
[12:53:53] <cj_schnell> It is
[12:54:12] <psch> ok, that's good
[12:54:24] <psch> what's your folder structure below /sdcard/gemrb/bg1?
[12:55:05] <lynxlynxlynx> notice sdcard vs sdcard0
[12:55:15] <cj_schnell> In the bg1 folder I have all the goodies including chitin.key, Override etc
[12:55:40] <lynxlynxlynx> this dir is the gemrb override
[12:55:58] <lynxlynxlynx> the game one is different
[12:56:07] <cj_schnell> Yeah, In my Android file explorer it says sdcard0/gemrb..
[12:56:12] <psch> oh right lynx
[12:56:30] <psch> where did you copy your game data cj_schnell?
[12:57:17] <cj_schnell> Yeah, the game data is there, but it seems as my initial path given in the config gets overridden
[12:57:52] <cj_schnell> Btw, I'm using the GOG version if that is any help/issue
[12:58:29] <psch> okay
[12:59:34] <psch> well, as for the process: you should install gemrb 0.8.0, edit GamePath in Android/data/net.sourceforge.gemrb/files/GemRB.cfg and point it to your game data, which should be copied anywhere on the sdcard except inside the Android/ folder
[12:59:56] <psch> to me it seems you copied bg1 into /sdcard/gemrb/
[13:00:10] <psch> iirc the GOG version doesn't need CD1, but im not sure
[13:00:33] <cj_schnell> Yeah, the GOG version does not have CDx
[13:00:53] <lynxlynxlynx> invalid entries don't make a difference
[13:01:09] <psch> incidentally the template config has GamePath set to /sdcard/gemrb/bg1
[13:01:17] <psch> and im using GOG bg1 to test
[13:01:30] <psch> so, actually, it should work, unless something else breaks somewhere
[13:01:41] <cj_schnell> Yeah, and I copied my BG1 files to gemrb/bg1
[13:01:56] <lynxlynxlynx> these iwd2 actors are suicidal, sending Kill to themselves :o
[13:02:04] <cj_schnell> Let me start from scratch and see if I did something wrong during the process.
[13:06:56] <lynxlynxlynx> /sdcard0/gemrb/bg1/ for data and /sdcard0/gemrb/override/bg1/ for gemrb stuff should be fine
[13:07:09] <lynxlynxlynx> gemrb doesn't come with any bg1 toplevel dirs
[13:07:54] <lynxlynxlynx> so /sdcard0/gemrb/ can contain all gemrb folders and then subfolders for games just fine
[13:08:24] <psch> lynxlynxlynx: gemrb override etc are extracted to Android/data/net.sourceforge.gemrb/files on launch
[13:08:50] <psch> so they should always be separate from actual game data
[13:08:59] <lynxlynxlynx> ok
[13:09:04] <cj_schnell> When I install gemrb apk I only get the bg1 folder created for me. I guess this is ok
[13:09:34] <psch> cj_schnell: "the bg1 folder" means /sdcard/gemrb/bg1?
[13:09:37] <cj_schnell> bg1 game is now uploaded to sdcard0/gemrb/bg1
[13:09:46] <cj_schnell> Yes
[13:10:06] <psch> ok
[13:10:10] <cj_schnell> well, still unsure if I should use sdcard or sdcard0
[13:10:28] <psch> how are you accessing your device's storage?
[13:11:37] <cj_schnell> Windows Explorer throgh USB to upload files to the bg1 folder, and then Android file explorer to see the actual bg1 path in order to edit the config file correctly.
[13:12:32] <lynxlynxlynx> http://forums.gibberlings3.net/index.php?showtopic=25241&pid=208598&st=15entry208598
[13:12:34] <Pepelka> GemRB 0.8.0 released! (Fork Me edition) - The Gibberlings Three Forums - Page 2
[13:12:35] <Pepelka> »Same for me: black screen, then dropped back to the home screen. It's not a "real" force close, though, because there's no pop up err...«
[13:12:40] <cj_schnell> Without editing the GemRB.cfg-file I start the GemRB app and get the usual black screen. Now time to check the logs.
[13:12:42] <lynxlynxlynx> some extra bits
[13:13:44] <psch> yeah, i saw that lynx; tbh to me that still sounds like "didnt edit GamePath in Android/data/net.sourceforge.gemrb/files/GemRB.cfg", but seeing as i can't even get cj_schnell running im starting to have doubts
[13:14:21] <lynxlynxlynx> movies are usually in a cd path, so either that or the gamepath must be correct
[13:14:28] <lynxlynxlynx> he wouldn't be able to see them otherwise
[13:14:43] <psch> oh
[13:14:55] <psch> there's a new reply from Xelasarg, my bad
[13:15:17] <lynxlynxlynx> yeah, gamepath is fine
[13:16:35] <psch> well, i know why he can't start it again at least
[13:16:36] <cj_schnell> Hmm.. I did not get any logging in the /sdcard0/gemrb/bg1 folder. Btw, does GemRB use the information in Baldur.ini in the bg1 folder?
[13:16:55] <psch> i think
[13:17:06] <lynxlynxlynx> all looks fine in his log, it just crashes on game entry
[13:17:09] <psch> iirc, the segfaulted process doesn't get killed
[13:17:17] <psch> so when he restarts it it restarts at the crash
[13:17:42] <psch> which is kind of weird i think, but heck if i understand android
[13:17:47] <cj_schnell> Yeah, it seems to be running even though it takes me back to the dashboard.
[13:17:57] <psch> workaround would be killing the process in Settings -> App -> GemRB
[13:18:09] <psch> or swiping it off the switch app screen thingy
[13:18:58] <psch> but rotation crashing gemrb is known, to me at least, i dont know if i mentioned it
[13:19:23] <psch> i havent found a way to force and maintain a certain orientation, currently it should automatically switch to landscape but can rotate back to portrait, which crashes
[13:19:30] <cj_schnell> I did the swiping before each of my tests so I should be killed.
[13:20:10] <psch> anyway, yeah, ill talk to the guy in the forum in a bit
[13:20:36] <psch> cj_schnell: your GemRB.cfg is in Android/data/net.sourceforge.gemrb/files, right?
[13:20:50] <psch> probably /sdcard0/
[13:21:12] <cj_schnell> psch: Yes.
[13:21:19] <psch> what android version are you on anyway?
[13:21:26] <cj_schnell> I can't find any other config file
[13:21:28] <cj_schnell> 4.1.2
[13:21:35] <psch> ok
[13:21:52] <psch> your gamedata is in /sdcard/gemrb/bg1, and that's what you put in the config file, right?
[13:23:31] <cj_schnell> Well, that is the default value in the config. I am still not sure if /sdcard or /sdcard0 is the correct value for me.
[13:25:37] <psch> does the android file explorer you mentioned allow you to see the root folder of the device?
[13:25:58] <psch> as in, if you go all the way up, to you have folders like system, mnt, proc
[13:26:32] <cj_schnell> Yes, it is rooted. In my / I have /sdcard0 and /extSdCard
[13:26:56] <psch> right, so you don't even have a /sdcard folder
[13:27:07] <psch> which explains why /sdcard/gemrb/bg1 doesnt work
[13:27:14] <cj_schnell> Not as far as I can tell. But that probably differs from android vendor
[13:27:28] <psch> yeah, it does differ across hardware vendor and android version both
[13:27:54] <psch> does /sdcard0/gemrb/bg1 exist and contain the game data?
[13:27:59] <psch> if so, try that in your GemRB.cfg
[13:31:52] <cj_schnell> Will do
[13:38:46] --> brada has joined #gemrb
[13:40:17] <lynxlynxlynx> aha! it's the worg riders dismounting
[13:40:21] <lynxlynxlynx> ActionOverride(LastMarkedObject,Kill(Myself))
[13:41:22] <lynxlynxlynx> the trigger is still the player
[13:46:21] <cj_schnell> Ok, after reinstalling the apk and then open the app I get the opening movie of BG1. I did not change the GamePath in the config, it still was set to /sdcard/gemrb...
[13:46:59] <cj_schnell> Maybe it worked because the bg1 game files were already in place.
[13:47:46] <psch> do you get past the intro movies?
[13:48:53] <cj_schnell> Nope. After "Nietche" it exits.
[13:49:11] <psch> can you try locking your phone to landscape orientation?
[13:51:02] <cj_schnell> I opened the app in landscape mode and the movies were fine. Still exit though. I do not now how I lock the orientation to landscape only.
[13:52:22] <cj_schnell> The last entry in GemRB.log is: [OPENAL]: Music in INITIAL State. AutoStarting
[13:52:54] <psch> logcat is actually the more interesting one
[13:54:06] <lynxlynxlynx> fuzzie: http://paste.debian.net/1115/ looks like more things set LastMarkedObject than just the action
[13:54:07] <Pepelka> debian Pastezone
[13:54:33] <lynxlynxlynx> the killer script is muddier
[13:55:23] <fuzzie> yes this is documented
[13:55:36] <fuzzie> > See(), Entered(), Clicked(), LOS(), and others will set LastMarkedObject if the trigger evaluates to TRUE.
[13:58:50] <lynxlynxlynx> do you have a complete list?
[13:59:15] <fuzzie> no, I have no idea about this iwd2 stuff, sorry
[13:59:18] <cj_schnell> My logs complains on the paths still I see: Invalid path given: /sdcard/gemrb/bg1/data/data (CD1/data), Invalid path given: /sdcard/gemrb/bg1/CD2/data (CD2/data)
[13:59:50] <cj_schnell> And Brads TTF stuff: Invalid path given: /usr/share/fonts/TTF (CustomFonts)
[14:01:49] --> edheldil has joined #gemrb
[14:01:49] --- ChanServ gives channel operator status to edheldil
[14:03:08] <lynxlynxlynx> just defaults
[14:05:58] <lynxlynxlynx> looks like CreateCreature must be on the list too
[14:07:02] <fuzzie> Adding whatever fixes your issues sounds like a pretty good start to me.
[14:07:25] <psch> cj_schnell: do you have logcat output?
[14:08:53] <cj_schnell> Where are they logs located?
[14:08:56] <cj_schnell> they = the
[14:09:37] <cj_schnell> Btw, the correct path for my bg1 folder actually seems to be /storage/sdcard0/gemrb/bg1
[14:10:04] <psch> that's the sdcard behind the multi-user FUSE mount
[14:10:20] <psch> if you have the folder /sdcard0 on the root level it should be exactly the same device
[14:11:03] <cj_schnell> I guess so. The movies started fine in both cases
[14:11:25] <psch> im not sure how android multi-user handles data copied over via usb - if you're using multiple users you might have problems when refering to the game data with a user-specific path, but i really don't know for sure
[14:12:22] <brada> psch: unrelated to your current problem, we should probably loc GemRB to landscape mode
[14:12:24] <brada> SDL_SetHintWithPriority(SDL_HINT_ORIENTATIONS, "LandscapeRight", SDL_HINT_OVERRIDE);
[14:12:27] <brada> something like that
[14:12:41] <psch> brada: yeah i did that just now, differently though
[14:12:46] <brada> ok
[14:12:49] <brada> whatever works
[14:12:53] <psch> specifying landscape in the manifest and override the config change method
[14:13:03] <psch> i guess doing it through SDL would be more consistent
[14:13:04] <brada> sounds good
[14:13:20] <psch> but in any case, i tested it on my device and it works
[14:13:49] <brada> it might be more consistant if we did it in a common code file :p
[14:13:59] <brada> but alas im not atm
[14:14:46] <psch> well, i dont think i have to specify anything in the manifest; i could set to landscape in the activity
[14:15:02] <psch> but that hardly changes anything, seeing as all we do starts with the SDL surface anyway
[14:15:58] <psch> so it could happen somewhere in Init() i guess?
[14:16:37] <cj_schnell> Alright, I have to run. Sorry for not be able to help out that much.
[14:17:05] <psch> don't worry, we can get back to this somewhen else
[14:17:16] <psch> oh
[14:18:13] <psch> the data subdir is automatically search below GamePath, isn't it?
[14:18:43] <psch> but even if not, the template config has it set as CD1 so that shouldnt stop cj's config...
[14:20:02] <psch> well, i'll get on setting up signing i think
[14:20:13] <cj_schnell> Here is my GemRB.log if you are interested: http://pastebin.com/NkmwBdbj
[14:20:18] <Pepelka> GemRB.log Android - Pastebin.com
[14:21:07] <psch> thanks
[14:22:43] <lynxlynxlynx> worked nicely :)
[14:24:40] <Pepelka> [commit] lynxlynxlynx: CreateCreatureCore: also set LastMarked https://github.com/gemrb/gemrb/commit/bb90878959b4dee646aa64cff5047c0fe8ac5b1b
[14:29:42] <psch> suggestions for first/last name for the signing key? i don't want to link this anyhow to me as a person
[14:30:00] <psch> seeing as i might stop working on it and stuff will get really messy when it's literally me who signed gemrb
[14:30:15] <fuzzie> you shouldn't need to provide one..?
[14:30:26] <psch> oh
[14:30:31] <psch> seems i dont need to
[14:30:54] <psch> yes, everything unknown seems to fine for keytool
[14:30:56] <psch> nevermind then
[14:31:09] <fuzzie> well, a CN involving GemRB in some way might be nice
[14:31:16] <fuzzie> don't think google care though
[14:31:56] <psch> i can do that
[14:32:56] <psch> except i don't know which of the possible fields is CN
[14:33:12] <psch> organizational unit?
[14:33:22] <fuzzie> um
[14:33:47] <fuzzie> what does it offer you?
[14:33:54] <fuzzie> you'd think it'd offer you CN if it offers OU
[14:34:52] <psch> http://pastebin.com/d64cSEBm
[14:34:57] <Pepelka> What is your first and last name? [Unknown]: a b What is the name of your o - Pastebin.com
[14:34:57] <psch> CN is first/last name it seems
[14:35:02] <fuzzie> ah
[14:36:31] <psch> "Is CN=GemRB.org, OU=Android Build Maintenance Team, O=GemRB.org, L=the Internet, ST=Unknown, C=Unknown correct?"
[14:36:37] <psch> i'm thinking this might be a little silly
[14:36:40] <fuzzie> well, no
[14:37:21] <psch> so just GemRB.org for CN and everything else unknown
[14:37:31] <fuzzie> does it not let you just pass -dname "CN=GemRB Android Signing, O=GemRB"?
[14:37:44] <fuzzie> anyway it totally doesn't matter
[14:37:46] <fuzzie> Unknown is fine
[14:38:22] <psch> -dname as you stated works
[14:38:29] <psch> i wouldnt have thought of that
[14:43:47] <cj_schnell> Here is the LogCat: http://pastebin.com/cpcjCnHD
[14:43:52] <Pepelka> GemRB Android LogCat - Pastebin.com
[14:44:30] <edheldil> don't the parts of DN that are empty get left out?
[14:44:42] --> Xelasarg has joined #gemrb
[14:44:52] <fuzzie> edheldil: not if you're asking keytool to leave them as Unknown, no. :p
[14:45:13] <-- Xelasarg has left IRC (Client Quit)
[14:45:26] <fuzzie> cj_schnell: so that's assert()ing with no assert output, how helpful
[14:46:05] <fuzzie> oh
[14:46:18] <fuzzie> so, brad's fault :P
[14:46:40] <brada> ?
[14:46:49] <cj_schnell> How typical of brad :-)
[14:47:14] <brada> wish i knew what i did
[14:47:16] <fuzzie> brada: you left the assert in SwapBuffers rather than copying line-by-line
[14:47:31] <brada> yeah
[14:47:39] <brada> i havent had time for gemrb lately
[14:48:24] <psch> alright, i have a release signed apk with a fix for the screen orientation
[14:48:29] <fuzzie> (and that's the only possible assert I see)
[14:49:03] <brada> yes it is
[14:49:04] <brada> quick
[14:49:07] <brada> fix it :D
[14:49:19] <fuzzie> yeah, except I have to go :P
[14:49:30] <fuzzie> I'll be back, uh, tomorrow!
[14:49:31] <brada> i can do it latter on if nobody does it sooner
[14:49:39] <brada> should be a trivial loop
[14:50:06] <fuzzie> #02 pc 0001f0bf /system/lib/libc.so (__assert2+30)
[14:50:10] <fuzzie> #03 pc 001aa480 /data/data/net.sourceforge.gemrb/lib/libmain.so (GemRB::SDL20VideoDriver::SwapBuffers()+208)
[14:50:18] <fuzzie> ^- this is relevant bit of the backtrace if someone wants to confirm it can't be anything else
[14:50:30] <brada> i dont see any other asserts there
[14:50:32] <brada> as you said
[14:51:17] <fuzzie> but I really have to vanish
[14:51:28] <fuzzie> I can of course try and fix it if no-one else does but I suspect I won't be back for hours.
[14:51:48] <brada> probably before i have time then
[14:52:03] <brada> its only 9 AM here and i have a full 8-10 hours of work ahead of me
[14:52:06] <fuzzie> yes, obviously if you have no time then you have no time
[14:52:28] <fuzzie> so, no worries, we'll fix it. just, alas, not me right now.
[14:52:35] <brada> maybe for my lunch break if i feel like it
[14:54:22] <psch> im curious why it works for me though, i've been working of a fresh pull because i couldnt get changing the origin url to work
[14:55:31] <brada> it works for you for the same reason it works for me
[14:55:54] <brada> because our source pitch is == to dest pitch
[14:55:56] <brada> sorry i dont have a more specific answer
[14:56:10] <brada> i dont think the format is diffrent tho
[14:56:17] <brada> shouldnt be
[14:56:31] <brada> that is probably something that should be asserted
[14:58:40] <fuzzie> yeah, the other issue is that it might well be another bug
[15:02:39] <brada> true, it could be failing because of a more fundamental issue
[15:02:44] <brada> leading pitch to be 0
[15:03:10] <brada> that loop still need to be done either way
[15:04:33] <-- WingedHussar has left IRC (Quit: WingedHussar)
[15:23:51] <gembot> build #339 of nmake-msvc++6 is complete: Failure [4failed] Build details are at http://buildbot.gemrb.org/builders/nmake-msvc%2B%2B6/builds/339 blamelist: Jaka Kranjc <email@example.com>
[15:32:38] <brada> everybody decided to be late for our meeting today so I took the liberty of writing that loop
[15:32:49] <Pepelka> [commit] bradallred: SDL2: remove lazy assert and actually copy pixels by src/dest pitch https://github.com/gemrb/gemrb/commit/d23d20135227f91c295e792a6876fb443e5b1c46
[15:32:56] <brada> fuzzie: no need to waste your time now
[15:33:39] <brada> psch/cj_schnell: that should either fix your problem or expose a deeper problem
[15:33:49] <brada> just need a new build
[15:34:44] <psch> alright
[15:39:00] <lynxlynxlynx> psch: just ping me when you need another upload done
[15:40:29] <psch> i have the build finish just now
[15:41:20] <psch> im gonna stick with debug builds for now i think, i'd have to change stuff around to not use the net.sourceforge.gemrb namespace anymore first
[15:41:28] <psch> before i can sign as release, that is
[15:44:03] <psch> http://filebin.ca/fO9a9CqBrFJ/GemRB-0.8.0-git-d23d201.apk md5 ac36ec1e343b94d723ffe84130c87da8
[15:45:05] <psch> lynxlynxlynx: that file please, i can post to the forums myself if you want
[15:45:32] <lynxlynxlynx> sure, that'd be great
[15:47:54] <lynxlynxlynx> https://sourceforge.net/projects/gemrb/files/Other%20Binaries/android/0.8.0/?
[15:47:57] <Pepelka> GemRB Game Engine - Browse /Other Binaries/android/0.8.0 at SourceForge.net
[15:47:58] <Pepelka> »GemRB is a portable open-source implementation of the Infinity Engine«
[15:48:06] <lynxlynxlynx> by the time anyone sees it, it will have propagated to the mirrors
[15:52:45] <psch> the instructions don't actually matter for my build anymore, as i think you are aware
[15:53:06] <psch> but then, the files don't exist anymore either so i guess it doesnt matter
[16:17:18] <psch> alright, first post!
[16:35:59] <gembot> build #340 of nmake-msvc++6 is complete: Success [3build successful] Build details are at http://buildbot.gemrb.org/builders/nmake-msvc%2B%2B6/builds/340
[16:37:41] <lynxlynxlynx> let me know if you want some specific text to be put there instead
[16:38:52] <psch> i guess the instructions i have in the forum post could go there
[17:05:41] <-- brada has left IRC (Quit: brada)
[17:09:30] --> thefiddler has joined #gemrb
[17:27:44] --> brada has joined #gemrb
[17:29:13] <-- thefiddler has left IRC (Ping timeout: 245 seconds)
[17:36:46] <-- brada has left IRC (Quit: brada)
[18:17:13] --> Yoshimo has joined #gemrb
[18:50:16] --> thefiddler has joined #gemrb
[19:04:59] --> fizzle has joined #gemrb
[19:09:38] <-- thefiddler has left IRC (Ping timeout: 245 seconds)
[19:30:45] --> brada has joined #gemrb
[19:44:05] <brada> psch: the android build doesnt account for the "mouse" being left at the edge of the viewport
[19:44:16] <brada> so the sceen can uncontrollably scroll
[19:48:22] <brada> ios does it in a fairly stupid way i guess so im not lsure what we want to do about that
[19:49:47] <brada> we should figure out something less hacky than ios
[19:49:55] <brada> since android can use a mouse
[19:50:02] <brada> i suppose ios can too for that matter
[19:50:37] <brada> maybe i should turn the mouse cursor settings into a mouse enabled setting
[19:50:45] <brada> makes sense to me anyway
[19:51:00] <fuzzie> sounds fine
[19:51:03] <fuzzie> thanks for the fix earlier
[19:51:33] <brada> yeah
[19:51:51] <brada> it was my fault anyway, as people keep reminding me :p
[19:55:35] <fizzle> for those who've played bg2: are trolls supposed to go invisible when they are "faking death"?
[19:56:28] <brada> you mean the "corpse"?
[19:56:35] <fizzle> yes
[19:56:35] <brada> if so, then no
[19:56:45] <fizzle> okay, thought so, thanks
[19:58:19] <psch> the scrolling thing is the only issue as far as i can tell
[19:58:27] <psch> taps not registering happened to me too on low fps
[19:58:28] <brada> yeah
[19:58:30] <-- Yoshimo has left IRC (Quit: Yoshimo)
[19:58:35] <brada> yeah
[19:58:40] <brada> i imagine its the event timing out
[19:58:42] <brada> or some such
[19:59:05] <brada> so really we need to educate people on setting a suitable resolution for now
[19:59:21] <brada> probably about half of waht they are doing now
[19:59:34] <psch> SyntaxError seems to be doing a decent job of that, at least in the 0.8.0 thread
[19:59:41] <brada> hopefully by next release we will have more hardware acceleration
[19:59:46] <brada> thats me...
[19:59:49] <psch> oh
[19:59:52] <psch> how should i know? :P
[19:59:57] <brada> heh
[19:59:58] <brada> true
[20:00:27] <brada> i have/had a working proof of concept where everything was hardware accelerated except the game control
[20:00:34] <brada> and that should help quite a bit
[20:00:44] <psch> game control?
[20:00:53] <brada> the part where the actors a drawn
[20:01:15] <psch> that seems like it could still be a sizeable chunk
[20:01:26] <brada> yes
[20:01:38] <brada> but the most processing intensive part is the game control :(
[20:01:47] <brada> cuz of spells fog of war etc
[20:01:53] <psch> yes, that's what i mean
[20:01:56] <brada> complex blitting operations
[20:02:08] <brada> but shoudl be able to get you up to 30 fps
[20:02:20] <brada> and enable a pinch to zoom game control :p
[20:02:41] <psch> well, i am at around 28 fps in 640x480 right now
[20:02:53] <brada> cool
[20:03:04] <brada> id like to be able to bump up to 800xwhatever
[20:03:06] <psch> native resolution, i.e. 1280x800, at that speed is probably not what you mean
[20:03:13] <brada> right
[20:03:32] <brada> android users should avoid native resolution for the time being
[20:03:49] <fuzzie> there was someone on forum talking about opengl, right?
[20:04:18] <psch> yeah, brada replied there already
[20:04:23] <brada> fuzzie: yes
[20:04:44] <brada> but in my mind the biggest obsticle is not the opengl implementation
[20:05:07] <fuzzie> well, it's all stuff to do with the opengl implementation
[20:05:21] <brada> yeah, reworking the sprite class
[20:05:24] <brada> etc
[20:05:25] <fuzzie> like handling which textures are in memory
[20:05:35] <brada> it would be nice if we didnt have to redraw the whole screen too
[20:05:52] <fuzzie> that's a non-opengl thing only though
[20:06:04] <brada> welll
[20:06:21] <fuzzie> it really doesn't work in opengl
[20:06:24] <brada> yeah
[20:06:33] <brada> but i was talking about my hybrid design
[20:06:40] <fuzzie> oh, sure
[20:06:42] <brada> since i had a proof of concept
[20:06:46] <fuzzie> at some point we *didn't* redraw the whole screen
[20:06:51] <brada> really?
[20:06:55] <fuzzie> but I think that has slowly been sabotaged
[20:06:59] <brada> ah
[20:07:15] <fuzzie> in particular the animated clock ruins it
[20:08:03] <brada> well is there anything existing that would help me not repush the entire screen texture
[20:08:04] <brada> ?
[20:09:24] <fuzzie> you could dirty-rect it at a somewhat high level
[20:09:38] <fuzzie> it depends how inefficient multiple copies are..?
[20:09:49] <fuzzie> since you'd have to copy at least the game screen, and the bit around the animated timer
[20:10:01] <brada> yeah but as far as i can tell we dont track the dirty regions
[20:10:09] <fuzzie> no, because it's not very interesting in software
[20:10:10] <brada> i did look beforehand
[20:10:13] <brada> eyah
[20:11:00] <fuzzie> but you can do it per-window
[20:11:10] <brada> probably better to invest my time in finishing the GUIs for mac/ios then going full bore into at least prepping the code for opengl
[20:11:26] <brada> ie the sprite classes
[20:12:09] <fuzzie> anyway, WF_CHANGED is set on a window when it's invalidated
[20:12:19] <brada> i see
[20:12:56] <fuzzie> and the window-drawing code has a rect there ready for use too
[20:13:13] <brada> maybe ill play with it
[20:13:18] <brada> and see how many fps it will give
[20:13:40] <fuzzie> two disclaimers are (a) it probably doesn't work for GameControl and (b) I probably screwed up the implementation :)
[20:13:49] <brada> aw naw!
[20:16:41] <fuzzie> oh, also you have to check clip_regions
[20:16:47] <fuzzie> which I guess were an attempt to deal with the animation
[20:16:55] <fuzzie> if you think it helps the framework it might be cool though
[20:17:21] <brada> i jost dont know if its the most effective use of my time is all
[20:17:37] <fuzzie> Probably not.
[20:18:34] <brada> too bad everybody that comes along talking about adding opengl support disappears...
[20:18:43] <brada> figure they see the code and get scared off lol
[20:19:05] <brada> I could do most of it myself i have no doubt
[20:19:14] <brada> tho effect shaders...
[20:19:20] <brada> no idea what to do there
[20:19:38] <fuzzie> well, it's clearly possible with the fixed-function pipeline
[20:20:11] <fuzzie> which is not particularly future-proof but might potentially be a starting point
[20:23:16] <brada> one easier way to get an FPS boost would maybe be to lock the screen texture and blit directly to its write buffer instead of to the SDL surface
[20:23:35] <brada> by write bufer i mean the pointer given by the sdl_lock_texture api
[20:24:54] <brada> can we do that simply by passing the buffer at surface creation time?
[20:25:11] <brada> that would eliminate an entire screens worth of memcpy
[20:25:29] <fuzzie> memcpy is cheap
[20:25:46] <brada> even at 1200x800
[20:25:50] <fuzzie> unless the texture is a direct map of gpu memory in which case I guess drawing to it would be terrible
[20:26:35] <fuzzie> but it sounds possible and not too tricky to try..
[20:26:51] <fuzzie> i mean you can't actually do it that way, presumably
[20:26:52] <brada> yeah if it even gets a mesurable boost at all its worth it
[20:26:54] <fuzzie> since you can't keep the texture locked
[20:27:00] <brada> since its so easy afict
[20:27:09] <fuzzie> but at least in SDL 1.2 you can just replace the pixels pointer in the surface struct..
[20:27:26] <brada> well i would unlockit to push to the renderer then relock every frame
[20:27:38] <brada> worth a shot
[20:28:20] <fuzzie> yes, but the pointer changes
[20:29:07] <fuzzie> well, in theory. I seem to remember that SDL's opengl drivers all just alloc a permanent buffer.
[20:29:57] <brada> oh it changes?
[20:30:04] <brada> i thought sdl kept a buffer for it
[20:30:09] <fuzzie> that's not guaranteed though
[20:30:16] <brada> i see
[20:30:21] <fuzzie> i mean, a sensible implementation would *not* keep a buffer
[20:30:42] <brada> true
[20:30:50] <fuzzie> which is why the documentation says "As an optimization, the pixels made available for editing don't necessarily contain the old texture data. This is a write-only operation, and if you need to keep a copy of the texture data you should do that at the application level. "
[20:31:29] <fuzzie> ah, no, SDL is smarter
[20:31:40] <fuzzie> ah, no, it isn't
[20:31:45] <brada> never thought id hear you say that
[20:31:52] <brada> well spoke too soon :P
[20:31:53] <fuzzie> yes it was only a momentarily lapse of sense!
[20:32:17] <fuzzie> i'm just checking
[20:32:54] <fuzzie> opengles, opengles2, opengl allocate a buffer
[20:33:24] <fuzzie> psp does too, direct3d does not
[20:33:31] <fuzzie> but i assume you can safely ignore those anyway
[20:34:26] <brada> yes
[20:35:00] <brada> so are you saying I could use that idea for a stop gap till i or somebody else get around to better hardware accel?
[20:35:17] <psch> im itching to justify the decision behind the in-tree android build, seeing as so many people are complain
[20:35:22] <psch> but i think that'd be a bad idea
[20:35:31] <psch> where "so many" == 2
[20:36:03] <fuzzie> in-tree android build?
[20:36:05] <psch> in any case, it's almost exclusively developer reasons anyway, so it wouldn't do anything
[20:36:07] <brada> mostly they jsut want a gui to help config and report errors
[20:36:09] <psch> yes, what i did vs pelya
[20:36:26] <brada> if you could just make a gui alert box for init failures that would help so much
[20:36:34] <brada> pelya didnt even have that
[20:36:40] <brada> only ios/mac has it
[20:36:55] <fuzzie> well, the idea is we can do a much better build with the full SDL 2.0 API, in theory
[20:37:20] <brada> yeah
[20:37:27] <psch> but that is a developer reason, is it not
[20:37:28] <fuzzie> obviously you're going to annoy people if you ship a 32bpp build though
[20:37:43] <fuzzie> but there's also nothing stopping someone from compiling a pelya build too
[20:37:47] <brada> did you ask sdl? :p
[20:37:48] <psch> i mean, i not i shouldnt let it get to me, but i'm a bit disappointed
[20:37:56] <fuzzie> as a stopgap here
[20:37:57] <psch> *i know i shouldnt
[20:37:59] <brada> yeah
[20:38:15] <fuzzie> just no-one was doing that anyway
[20:38:18] <brada> if sdl could use 16bpp then that would help performance for them
[20:38:29] <brada> wehn i said better performance i meant 32bpp vs 32bpp
[20:38:31] <fuzzie> there's always people complaining though.
[20:38:37] <brada> or if you were to use a lower res
[20:38:43] <brada> since now we can fill the screen
[20:38:45] <fuzzie> for scummvm, I just send people to whoever is doing pelya builds, if they're unhappy with ours.
[20:39:02] <psch> yeah, i realize that; i just haven't directly been subjected to user feedback before haha
[20:39:05] <fuzzie> but that kinda only works if someone is actually doing that.
[20:40:04] <fuzzie> but for example I think no-one can keep up with pelya's stuff for the variety of input options.
[20:40:34] <fuzzie> just, you can't *do* anything with pelya's SDL, it's just a look-we-can-recompile-the-desktop-version in the end :)
[20:40:45] <brada> yeah
[20:40:45] <psch> well, feature-wise we are definitely ahead already; two-finger scrolling doesn't work with pelya
[20:40:52] <fuzzie> but you're right that it's a bit of a looking-to-the-future thing
[20:40:52] <brada> and that not what we want
[20:40:57] <brada> or at least not what i would want
[20:41:17] <brada> basically keep it up and eventually we will get a better rendering system
[20:41:27] <brada> or at least a less terrible one
[20:41:32] <brada> if we use my hybrid
[20:41:44] <psch> i'll try and see wrt error notifications, probably during the weekend
[20:42:04] <psch> thinking of that, i could probably even notify users on first-run, which file to edit
[20:42:15] <psch> possibly even directly fire an intent that launches some kind of text editor
[20:42:26] <psch> seeing as the config is well commented, that should actually be enough
[20:42:57] <fuzzie> well I guess most people won't have one :)
[20:43:08] <psch> oh, right
[20:43:20] <psch> same goes for file browsing i guess
[20:43:40] <brada> you could always kill the cfg entirely :p
[20:43:45] <psch> well, firing the intents won't hurt anyone i guess; i'll have to read up and/or test that
[20:43:53] <brada> if you are comfortable with making a nice gui alternative
[20:44:23] <psch> my gui would actually write to the cfg; i don't really trust my c/c++ enough to get ndk calls and whatnot working
[20:44:41] <brada> well thats fine too
[20:45:07] <brada> as long as its not text based its an imrovement
[20:45:56] <psch> well, seeing as file-browser intents aren't guaranteed to get handled on android (because file browsers aren't stock) we'd still have to have a type-the-path-to-your-game-data dialog
[20:46:04] <psch> but that's probably not the kind of text-based you mean
[20:46:35] <psch> right, thanks for cheering me up anyway
[20:46:51] <fuzzie> isn't it an improvement if it *is* text based anyway?
[20:46:55] <brada> in the end we will have something better than before
[20:47:18] <brada> unfortunately in this case that means removing features for a time
[20:50:58] <fizzle> hm, a comment in Inventory::RemoveItem says the EQUIPPED flag should not be set; anyone know why not?
[20:51:11] <fizzle> because I have a dialog here that needs it...
[20:53:11] <fuzzie> you do?
[20:53:47] <fizzle> it has a GiveItem() for an equipped one
[20:54:34] <fuzzie> so this code is really annoying
[20:55:49] <fuzzie> flags should be 0 here, right?
[20:56:09] <fizzle> they are, yes
[20:56:20] <fuzzie> so you can sabotage that code I think
[20:57:37] <fizzle> what do you mean?
[20:57:56] <fuzzie> you can modify it if you want :)
[20:58:07] <fizzle> oh
[20:58:18] <fuzzie> if you pass EQUIPPED then I think you have to work out how it works, though, since you switch codepaths
[20:58:31] <fizzle> well, do you know why equipped is excluded in the first place?
[20:58:37] <fuzzie> it isn't
[20:58:51] <fuzzie> but you mean, why it's not default?
[20:59:08] <fizzle> yeah, whichever way you want to put it
[20:59:19] <fizzle> why it's handled the same as undroppable
[21:00:15] <fuzzie> because of Item:Remove effect i think..
[21:00:24] <fuzzie> don't know what iesdp says
[21:01:18] <fuzzie> ok so avenger added a rambly note to 0x7b which I guess would be the right one
[21:01:36] <fuzzie> so I don't know.
[21:01:43] <fuzzie> sorry. it might well just be crazy.
[21:01:50] <fuzzie> remove it and see who screams :P
[21:02:00] <fuzzie> you may blame me in the commit msg if you want
[21:02:10] <fizzle> :)
[21:02:13] <fuzzie> "fuzzie said it was ok!"
[21:02:20] <fizzle> there seem to be two remove item effects
[21:02:38] <fuzzie> right, 0x7b seems intended to *not* remove equipped
[21:02:42] <fuzzie> except avenger has sabotaged it to allow it
[21:03:22] <fuzzie> apparently?
[21:04:15] <fizzle> hm, DestroyItem is different
[21:04:58] <fizzle> and both effects use that
[21:05:12] <fuzzie> right, things have changed
[21:05:15] --> thefiddler has joined #gemrb
[21:05:19] <fuzzie> you can see me sabotaging it at 8d6f69fe156623c55120fb7741340d3e03ad911e for example
[21:05:40] <fuzzie> and 402349174bcbca8edbcfd1cdbd031dac2e7afa94 also
[21:06:04] <fuzzie> but you see that later commit doesn't handle the 0 case in GiveItem
[21:06:23] <fuzzie> so we went back/forth a bit and fixed/broke the EQUIPPED case a bit
[21:06:51] <fuzzie> and I could say, go back/forth some more, or we could just get rid of the EQUIPPED flag like the first half of that later commit does to DestroyItem
[21:06:55] <fuzzie> and wait for the screaming.
[21:07:47] <fizzle> sounds good to me :)
[21:15:31] <psch> thanks for the post in the 0.8.0 thread brada
[21:18:55] <lynxlynxlynx> eeeeee
[21:19:18] <lynxlynxlynx> so which dialog requires this change?
[21:27:48] <fizzle> renal.dlg
[21:27:58] <fizzle> yay, screaming!
[21:32:16] <fizzle> why? do you think the change is problematic?
[21:32:39] <fuzzie> we've all learnt to live in fear of changing these flag
[21:32:39] <fuzzie> s
[21:34:54] <lynxlynxlynx> no, just curious
[21:35:08] <lynxlynxlynx> and yes, these flags are annoying
[21:35:32] <lynxlynxlynx> i think i played through the renal plot, but it was probably on a fixpacked game
[21:36:19] <lynxlynxlynx> more importantly, i don't remember any equippable quest items from there
[21:37:10] <fizzle> the fixpack notes don't mention anything about it, I checked
[21:37:36] <lynxlynxlynx> is it about the guy's dagger?
[21:37:39] <fizzle> you (should) get a sword of backstabbing
[21:37:56] <lynxlynxlynx> oh, as a reward
[21:38:14] <fizzle> yes
[21:38:15] <lynxlynxlynx> or loot perhaps, i remember renal giving armor
[21:38:55] <lynxlynxlynx> but the internet agrees with you
[21:39:03] <lynxlynxlynx> maybe you have to be a thief, nevermind
[21:39:11] <fizzle> I checked that, too :)
[21:40:41] <lynxlynxlynx> mea'var is the one giving armor
[21:43:38] <Pepelka> [commit] fizzet: more animation tweaks for IE_ANI_CODE_MIRROR_2 https://github.com/gemrb/gemrb/commit/661eeaff2fe74e1d7bab655e4208aecd1c8f5c03
[21:43:39] <Pepelka> [commit] fizzet: allow GiveItem() to transfer equipped items by default https://github.com/gemrb/gemrb/commit/27dfdcf4737363bcadc64d3954a6cc9b0db62836
[21:48:21] --> edheldil_ has joined #gemrb
[21:53:19] <-- fizzle has left #gemrb
[22:20:55] <-- brada has left IRC (Quit: brada)
[22:27:44] --> brada has joined #gemrb
[22:40:44] <Pepelka> [commit] lynxlynxlynx: added LastMarked setting to some more triggers https://github.com/gemrb/gemrb/commit/8d6a3beba0b11d06fc9b14a478480355ee7688e4
[22:45:12] <-- brada has left IRC (Quit: brada)
[22:49:40] --> brada has joined #gemrb
[23:04:34] <-- brada has left IRC (Quit: brada)
[23:06:09] --> brada has joined #gemrb
[23:09:17] <-- edheldil_ has left IRC (Ping timeout: 252 seconds)
[23:11:53] <-- lynxlynxlynx has left IRC (Remote host closed the connection)
[23:13:42] --> edheldil_ has joined #gemrb
[23:26:08] <-- edheldil_ has left IRC (Ping timeout: 255 seconds)
[23:34:13] <-- thefiddler has left IRC (Ping timeout: 245 seconds)
[23:38:39] <-- brada has left IRC (Quit: brada)
[23:53:59] --> brada has joined #gemrb