#gemrb@irc.freenode.net logs for 30 Nov 2011 (GMT)

Archive Today Yesterday Tomorrow
GemRB homepage


[00:26:52] --> brad_a has joined #gemrb
[00:31:46] --> joneirik has joined #gemrb
[02:48:01] <brad_a> i know everybody is asleep,but if you read the backlog: https://github.com/bradallred/gemrb/tree/iOS
[02:48:24] <brad_a> the TTF stuff should be at the stage we agreed on
[02:49:08] <brad_a> after getting this merged i can go back and remove the SDL_ttf dependency
[02:49:20] <brad_a> and use the sprite array directly
[02:50:02] <brad_a> and use a std::map in interface for mapping the font resrefs instead of each font keeping track of its resrefs
[02:51:02] <brad_a> tomprince: you awake still?
[02:51:14] <tomprince> Yep.
[02:51:31] <tomprince> SELF isn't acceptable.
[02:51:34] <brad_a> :(
[02:51:40] <brad_a> k
[02:51:53] <brad_a> what would you do?
[02:52:17] <tomprince> If you need it, use (*this)
[02:52:27] <brad_a> well thats what SELF is
[02:52:47] <brad_a> but i guess im the only one that prefers a macro here?
[02:53:29] <tomprince> Bad practice, to use macros like that. Makes it hard for somebody new to the code to figure out what it means.
[02:54:04] <brad_a> I have seen that in other projects...
[02:54:09] <brad_a> im not arguing
[02:54:12] <brad_a> im just saying
[02:56:27] <tomprince> Actually, in this case, I'd been inclined to avoid the operator[], which avoid the need for SELF.
[02:57:37] <tomprince> Actually the operator[] was confusing for me, cause I would expect it to return the sprite, if anything.
[02:57:57] <brad_a> the alternative to operator[] in those cases is size[char - FirstChar] which is ugly and i would prefer to just get a size based on char
[02:58:13] <brad_a> well it will return a sprite when i complete phase 2
[02:58:18] <brad_a> as we discussed
[02:58:32] <tomprince> Well, have a getSize then.
[02:59:13] <brad_a> i dont mean to be difficult but i would rather not add that method just to be removed in a month when i finish
[02:59:34] <brad_a> i would just go ahead an fininh TTF now but im too busy wiht final projects for school
[02:59:44] <brad_a> and i wanted to get this merged before next release
[03:00:34] <brad_a> i guess by TTf i just mean th font stuff in general
[03:05:14] <lloyd> So I'm still looking into my .2da errors....
[03:05:25] <lloyd> what happens is in
[03:05:29] <lloyd> ieStrRef Actor::GetVerbalConstant(int index)
[03:05:52] <lloyd> that a lets say a one of the cows in candlekeep
[03:05:58] <lloyd> when I click on it
[03:06:23] <lloyd> this function gets passed an index which from observation has been a number 26-28
[03:06:46] <lloyd> if it is 26,27 the function returns a number which corresponds to a moo sound
[03:06:56] <lloyd> if it gets 28 it returns -1
[03:07:45] <lloyd> the array it looks in for the number is StrRefs[idx];
[03:07:55] <lloyd> idx is the same as index afaik
[03:08:41] <lloyd> So Am I right in thinking that one Actor object is made for each person/animal thing when loading the area?
[03:09:08] <lloyd> and each Actor has its own StrRefs sound array
[03:09:42] <brad_a> lloyd: is that error causing you problems or are you just seeing errors and trying to fix them?
[03:09:58] <lloyd> seeing an error and trying to fix
[03:10:03] <lloyd> it does cause a problem though
[03:10:21] <lloyd> it leads to things not making the sound they should when clicking on them
[03:10:28] <brad_a> well just be aware that there are lots of crros in the console that aren't really errors
[03:10:47] <lloyd> crros?
[03:10:53] <brad_a> errors
[03:10:59] <lloyd> ah lol
[03:11:18] <lloyd> yeah this is a problem though :P
[03:11:37] <brad_a> well the thing is i dont think anybody else has it.
[03:11:41] <brad_a> i dont have BG1 tho
[03:11:52] <brad_a> so i cant verify
[03:11:59] <lloyd> well I tried BG1 on mac and linux both has it
[03:12:14] <lloyd> unless there is something wrong with my bg install
[03:12:37] <brad_a> what i mean t was that it seems like the BG1 data not the ma is at fault
[03:12:41] <brad_a> mac
[03:12:43] <brad_a> not ma
[03:14:01] <brad_a> id love to help you but if i dont get rolling on this homework im gonna be in trouble
[03:14:27] <lloyd> lol it's ok I'm making progress
[03:14:37] <lloyd> just asking questions
[03:14:43] <lloyd> about actor class
[03:15:27] <lloyd> maybe I'll try and see if I can get it to happen in BG2
[03:16:03] <lloyd> I want to play BG trilogy but it happens there as well >.<
[03:16:25] <brad_a> where did you get the games from?
[03:16:41] <brad_a> is BG1 modded too?
[03:16:46] <lloyd> some isos I had since ages go
[03:16:50] <brad_a> because maybe something got messed up in the mod
[03:16:52] <lloyd> nope it's a clean patched instlal
[03:17:01] <brad_a> english?
[03:17:06] <lloyd> ya
[03:17:19] <brad_a> maybe the ISOs are the original mac versions?
[03:17:25] <brad_a> instead of windows versions?
[03:17:26] <lloyd> nah its windows
[03:17:43] <brad_a> i dont think it should matter but you never know
[03:18:05] <lloyd> I've actually played BG1 with these isos on windows and they were fine
[03:18:12] <lloyd> I didn't have an error log then though :P
[03:19:01] <brad_a> well im sure you will learn a lot walking though gemrb in GDB
[03:19:09] <lloyd> yep that
[03:19:13] <lloyd> s what I'm doing
[03:19:24] <brad_a> did you patch your SDL to fix the font colors?
[03:19:43] <lloyd> no I didn't do that can I have the link again?
[03:20:17] <brad_a> http://dl.dropbox.com/u/13866402/SDLPatches.txt
[03:20:21] <lloyd> ty
[03:20:33] <brad_a> if you didnt know about it the IRC channel has a backlog: http://log.usecode.org/gemrblog.php
[03:20:53] <lloyd> kk
[03:21:35] <brad_a> tomprince: i have to go now but you can put any more feedback in IRC and ill read it tomorrow.
[03:21:46] <brad_a> thanks for the input
[03:22:15] <-- brad_a has left IRC (Quit: brad_a)
[03:31:56] <-- |Cable| has left IRC (Remote host closed the connection)
[03:32:44] <lloyd> mmm my problem happens in both bg1 and bg2
[03:35:05] --> |Cable| has joined #gemrb
[03:53:26] <-- |Cable| has left IRC (Remote host closed the connection)
[03:55:42] --> |Cable| has joined #gemrb
[04:07:52] <-- |Cable| has left IRC (Remote host closed the connection)
[04:11:40] --> |Cable| has joined #gemrb
[04:14:02] <-- |Cable| has left IRC (Remote host closed the connection)
[04:15:39] --> |Cable| has joined #gemrb
[04:19:08] <-- |Cable| has left IRC (Remote host closed the connection)
[04:22:42] --> |Cable| has joined #gemrb
[05:17:46] <-- joneirik has left IRC (Remote host closed the connection)
[05:39:26] --> jeremyagost has joined #gemrb
[05:40:46] <-- jeremyagost has left IRC (Client Quit)
[06:44:19] <gembot> build #282 of autotools g++-4.2.4 is complete: Failure [failed] Build details are at http://buildbot.gemrb.org/builders/autotools%20g%2B%2B-4.2.4/builds/282 blamelist: Brad Allred <bradallred@me.com>, Tom Prince <tom.prince@ualberta.net>, chiv <chilvence@gmail.com>, Avenger <avenger_teambg@sourceforge.net>, Alyssa Milburn <fuzzie@fuzzie.org>, Jaka Kranjc <lynxlupodian@users.sourceforge.net>
[06:44:24] <gembot> build #283 of cmake g++-4.6.0 is complete: Failure [failed] Build details are at http://buildbot.gemrb.org/builders/cmake%20g%2B%2B-4.6.0/builds/283 blamelist: Brad Allred <bradallred@me.com>, Tom Prince <tom.prince@ualberta.net>, chiv <chilvence@gmail.com>, Avenger <avenger_teambg@sourceforge.net>, Alyssa Milburn <fuzzie@fuzzie.org>, Jaka Kranjc <lynxlupodian@users.sourceforge.net>
[06:44:31] <gembot> build #281 of cmake clang++ is complete: Failure [failed] Build details are at http://buildbot.gemrb.org/builders/cmake%20clang%2B%2B/builds/281 blamelist: Brad Allred <bradallred@me.com>, Tom Prince <tom.prince@ualberta.net>, chiv <chilvence@gmail.com>, Avenger <avenger_teambg@sourceforge.net>, Alyssa Milburn <fuzzie@fuzzie.org>, Jaka Kranjc <lynxlupodian@users.sourceforge.net>
[06:44:38] <gembot> build #281 of autotools g++-4.6.0 is complete: Failure [failed] Build details are at http://buildbot.gemrb.org/builders/autotools%20g%2B%2B-4.6.0/builds/281 blamelist: Brad Allred <bradallred@me.com>, Tom Prince <tom.prince@ualberta.net>, chiv <chilvence@gmail.com>, Avenger <avenger_teambg@sourceforge.net>, Alyssa Milburn <fuzzie@fuzzie.org>, Jaka Kranjc <lynxlupodian@users.sourceforge.net>
[06:45:15] <gembot> build #287 of autotools g++-4.4.5 is complete: Failure [failed compile] Build details are at http://buildbot.gemrb.org/builders/autotools%20g%2B%2B-4.4.5/builds/287 blamelist: Brad Allred <bradallred@me.com>, Tom Prince <tom.prince@ualberta.net>, chiv <chilvence@gmail.com>, Avenger <avenger_teambg@sourceforge.net>, Alyssa Milburn <fuzzie@fuzzie.org>, Jaka Kranjc <lynxlupodian@users.sourceforge.net>
[06:48:45] <gembot> build #279 of autotools clang++ is complete: Failure [failed compile] Build details are at http://buildbot.gemrb.org/builders/autotools%20clang%2B%2B/builds/279 blamelist: Brad Allred <bradallred@me.com>, Tom Prince <tom.prince@ualberta.net>, chiv <chilvence@gmail.com>, Avenger <avenger_teambg@sourceforge.net>, Alyssa Milburn <fuzzie@fuzzie.org>, Jaka Kranjc <lynxlupodian@users.sourceforge.net>
[06:48:46] <tomprince> brad_a: Have a look at my fonts branch (yours cleaned up and reordered)
[06:48:57] <tomprince> It could probably use some more accurate changelogs though.
[06:55:58] <gembot> build #284 of cmake g++-4.6.0 is complete: Success [build successful] Build details are at http://buildbot.gemrb.org/builders/cmake%20g%2B%2B-4.6.0/builds/284
[06:58:30] <gembot> build #282 of cmake clang++ is complete: Success [build successful] Build details are at http://buildbot.gemrb.org/builders/cmake%20clang%2B%2B/builds/282
[07:03:06] <gembot> build #270 of autotools g++-4.5.2 is complete: Failure [failed compile] Build details are at http://buildbot.gemrb.org/builders/autotools%20g%2B%2B-4.5.2/builds/270 blamelist: Brad Allred <bradallred@me.com>
[07:13:05] <gembot> build #296 of msvc++6 is complete: Failure [failed compile] Build details are at http://buildbot.gemrb.org/builders/msvc%2B%2B6/builds/296 blamelist: Brad Allred <bradallred@me.com>
[07:14:57] <gembot> build #77 of nmake-msvc++6 is complete: Failure [failed compile] Build details are at http://buildbot.gemrb.org/builders/nmake-msvc%2B%2B6/builds/77 blamelist: Brad Allred <bradallred@me.com>
[07:19:16] <tomprince> brad_a: It crashes for me loading fonts, but you branch does, in the same place.
[07:35:43] <-- PixelScum has left IRC (Ping timeout: 248 seconds)
[07:36:29] --> Drakkar has joined #gemrb
[08:22:03] --> lynxlynxlynx has joined #gemrb
[08:22:04] <-- lynxlynxlynx has left IRC (Changing host)
[08:22:04] --> lynxlynxlynx has joined #gemrb
[08:22:04] --- ChanServ gives channel operator status to lynxlynxlynx
[08:40:43] --> Yoshimo has joined #gemrb
[08:43:25] <lynxlynxlynx> lloyd: sounds like a data issue; check the cre file in dltcep. Each actor has 100 slots for these verbal constants, but some are in the same group (eg. you have more than one selection sound)
[08:43:37] <lynxlynxlynx> we then do a random roll to pick one
[08:44:06] <lynxlynxlynx> now if the particular constant isn't set, which you should be able to see, we shouldn't be picking it
[09:56:50] <edheldil> so maybe it'd be an easy fix
[09:58:45] --> SiENcE has joined #gemrb
[10:40:15] --> boba has joined #gemrb
[10:40:19] <boba> hello
[10:40:27] <boba> i have a question
[10:40:43] <boba> can someone run icewind dale 2 with gemrb?
[10:41:11] <fuzzie> you can run it. it isn't playable.
[10:52:29] <lloyd> lynx: thanks, that helps
[10:52:33] <lloyd> I'll investigate
[11:04:20] <edheldil> boba: you are welcomed to help ;-)
[11:17:41] <boba> it runs?
[11:18:42] <lynxlynxlynx> sure
[11:21:05] <boba> k
[11:21:14] <boba> i haeo test it on my android
[12:50:36] <-- lynxlynxlynx has left IRC (Ping timeout: 240 seconds)
[14:49:57] <-- Yoshimo has left IRC (Quit: Yoshimo)
[15:46:07] --> brad_a has joined #gemrb
[15:49:47] <brad_a> tomprince: where is it crashing? i just did a clean build at my tip and it runs fine. does it crash every time? maybe i have an off by 1 error causing a random crash?
[16:08:29] --> Yoshimo has joined #gemrb
[16:19:23] <brad_a> yes :( valgrind tells me im overflowing on BAMImporter line 335. im puzzled because i built with my changes staged before patching out and got nothing in valgrind. o_O
[16:26:04] <-- brad_a has left IRC (Quit: brad_a)
[16:35:58] <tomprince> brad_a: the FreeSprite in Font::Font
[16:42:32] --> brad_a has joined #gemrb
[16:42:58] <brad_a> tomprince: sounds like th overfun valgrind found then
[16:43:03] <brad_a> lol overrun
[16:43:07] <brad_a> not fun at all really
[16:44:01] <tomprince> Do my changes look reasonable?
[16:44:34] <brad_a> i havent had a chance to look. im sure they are. what did you do aside from removing SELF?
[16:45:46] <tomprince> Mostly reordering the patches, so every commit builds, and and build stuff, but also some other things that fell out of that.
[16:48:03] --> Beh0lder has joined #gemrb
[16:48:07] --> Maighstir has joined #gemrb
[16:48:11] <Beh0lder> hi all
[16:50:12] <brad_a> well im sure the changes are reasonable. i need to come back in a bit less than a month to finish the rewrite anyway. in the end i think we will all like the result.
[16:51:26] <Yoshimo> im now able to test android builds on my new cell, in case its needed
[16:51:44] <brad_a> it never hurts :)
[16:54:17] <brad_a> tomprince: so are we at the point if i patch this overrun we can merge?
[16:54:39] <brad_a> im surprised i cant get this to crash also...
[16:57:33] <Beh0lder> Yoshimo, good news. I retired from my job and have some time to explore official SDL for android.
[16:57:55] <brad_a> that is exciting news! :)
[16:58:00] <tomprince> I'd been fine with the branch I pushed, once that and the bbot errors are fixed. Although the commit messages should be fixed up ... as I was squashing and rebasing I just grabbed the closed message.
[16:58:16] <Yoshimo> wasnt necessary to quit beholder ;)
[16:59:01] <brad_a> i wasnt aware those buildbot errors were from that. let me go look.
[16:59:08] <tomprince> Also I changed uint*_t to ie*, but I am not sure if I like that ... but I don't think msvc6 has them in any form.
[16:59:27] <brad_a> is that what the problem was?
[16:59:55] <tomprince> It would perhaps be better to define our on versions of those, if they aren't available.
[17:00:09] <brad_a> well fuzzie didnt like the way i defined it before ;-)
[17:00:17] <brad_a> she was right of course
[17:00:30] <tomprince> No, I got build failures with uint*_t, since the right headers weren't included.
[17:01:03] <brad_a> you need headers for that?
[17:01:10] <brad_a> strange that i dont...
[17:02:40] <Beh0lder> btw, where is Avenger? I have not seen him in chat a long time.
[17:02:52] <brad_a> good question
[17:03:06] <brad_a> maybe he has a very busy job
[17:04:39] <Beh0lder> probably so
[17:08:38] <brad_a> well we should probably have a typedef for a double byte char
[17:08:56] <brad_a> instead of either uint16 or ieword
[17:09:37] <brad_a> iirc fuzzie just didnt like me using unichar as the type because it wasnt always unicode
[17:10:27] <fuzzie> i forget where this was used in the patch
[17:11:30] <brad_a> i was replacing use of char in the font system
[17:11:30] <fuzzie> but in Font/BAM code we should just be using some generic 16-bit type, if possible, please
[17:11:40] <brad_a> why generic
[17:11:53] <fuzzie> well, i mean, not marked with 'unicode' or something :)
[17:11:58] <brad_a> i dont really care im just curious why it cant be labled as a double byte char
[17:12:04] <brad_a> right not unicode
[17:12:10] <brad_a> i do get why that was bad
[17:12:12] <fuzzie> if you want to typedef something up specifically for a char then i guess it doesn't matter, but i think it'll be unclear
[17:12:29] <Beh0lder> it's a very inconvenient that SDL forum in read-only mode. I hate mailing lists(
[17:12:31] <fuzzie> but no strong opinions
[17:12:43] <fuzzie> Beh0lder: well, everyone else hates forums :-)
[17:13:00] <Beh0lder> )
[17:13:52] <brad_a> well im fine with either way so if you feel using a double byte character type is unclear then i will use generic
[17:14:40] <fuzzie> well, from memory you weren't using it for any of the strings anyway, right?
[17:14:55] <fuzzie> to some extent i am just thinking about the patch for the Chinese version
[17:15:06] <brad_a> well i was using it for font lookup but the plan is in the end to actually support multibyte encodings
[17:15:16] <brad_a> this was a first step to that end
[17:15:23] <brad_a> me too
[17:15:36] <fuzzie> which obviously is somewhat incompatible with SDL_ttf's unicode world
[17:15:45] <brad_a> in fact after i am done rewriting the font system i was going to gut what is needed from that patch
[17:15:56] <Beh0lder> i tried to find any working example with multitouch for android, unsuccessfully(
[17:16:00] <brad_a> well remember i am getting rid of SDL_ttf
[17:16:26] <fuzzie> well, ok, is incompatible with freetype's unicode world :-)
[17:16:32] <brad_a> ah :)
[17:16:32] <fuzzie> i'm not sure what freetype exposes actually..
[17:16:37] <brad_a> me neither
[17:16:41] <brad_a> but i will be :)
[17:16:59] <brad_a> beholder: i think i may have a link to one
[17:17:09] <brad_a> give me a min to find it
[17:17:12] <brad_a> if i have it
[17:17:39] <Beh0lder> interesting, i'll wait
[17:18:21] <brad_a> bah! dead link
[17:19:19] <Maighstir> Would it be possible to convert the strings to unicode when reading them from dialog.tlk (or just after the original encoding is known), and then use unicode internally, rather than some homegrown multibyte encoding?
[17:20:10] <fuzzie> Maighstir: but then you'd have to convert them all for the fonts, too
[17:20:32] <Beh0lder> (
[17:20:50] <fuzzie> i'm not sure the hassle of trying to add multiple translation layers for code that we can't test well is a good idea for a first merge attempt
[17:21:32] <fuzzie> but i checked and as far as i can tell, all the relevant windows codepages for the *official* translations map completely onto the 16-bit unicode plane
[17:21:53] <-- SiENcE has left IRC (Quit: @all: cya)
[17:22:58] <Maighstir> right, all western scripts uses different encodings as well, forgot it's not simply "ansi or asian", where the latter doesn't use bam fonts anyway.
[17:24:10] <brad_a> i wasnt going to "home grow" an mb encoding but rather just let whatever MB encoding the strings are in allowed
[17:24:44] <brad_a> as far as TTF is concerned as long as your font glyps match your strings then it will work
[17:24:57] <brad_a> i guess the same applies to BAM
[17:28:51] <tomprince> So, if we had a gpl BAM that wasn't created in vim, we could added to the tests ...
[17:31:44] <edheldil> tomprince: http://www.eowyn.cz/gimp/text-separate.html . Dunno if it still works
[17:32:04] <brad_a> Beh0lder: as far as i know you shouldnt have to do any special setup for the multitouch events to get queued. all you should have to do is build sdl 1.3 and build gemrb with that and they should work at least to an extent. there may be a diffrence in android vs ios implementation tho
[17:32:35] <edheldil> I think Maighstir's idea to convert strings to unicode has some merits ;-)
[17:32:49] <brad_a> i do too, but that is something for a bit later
[17:33:37] <brad_a> is there a good cross platform string encoding conversion library?
[17:33:41] <fuzzie> yes; it would complicate things quite a bit in the core, but make things like TTF and mixing languages simpler
[17:33:45] <fuzzie> however, we cannot add a dependency :P
[17:34:06] <fuzzie> and that is why putting it in-core would be complex
[17:34:26] <brad_a> it probably doesnt need to go into core
[17:34:27] <fuzzie> since you'd want to build your own data files etc.
[17:34:37] <fuzzie> well, it would if you want Font to always use unicode..
[17:34:41] <brad_a> you could have a generic "convertter" in the core that just passes the string though
[17:35:19] <tomprince> I do find the avoidance of dependencies annoying, sometimes.
[17:35:44] <edheldil> bye
[17:36:16] <brad_a> well we could start with just unicode since ascii maps to that. then maybe add an optional plugin for converting other encodings to unicode
[17:37:14] <edheldil> all encodings map to unicode ... somehow :)
[17:37:31] <brad_a> well i mean 127 in ascii = 127 in unicode
[17:37:38] <brad_a> jsut with an exta byte
[17:38:08] <tomprince> brad_a: You need to be careful when you say unicode, because there are multiple encodings of it.
[17:38:12] <edheldil> brad_a: you are confusing unicode and a unicode encoding like ucs2, I think
[17:38:15] <tomprince> And most of them are variable length.
[17:38:51] <edheldil> tp: any other apart of utf8 and utf16? :)
[17:39:58] <edheldil> although there is utf16 le and be :)
[17:40:15] <edheldil> bye, now for real :)
[17:40:50] <Beh0lder> Brad, i built GemRB with official SDL, touchscreen does not work generally(((. Maybe I did something wrong
[17:41:32] <brad_a> well didnt you do that before they added multitouch to android SDL?
[17:41:40] <brad_a> they added it very recently
[17:41:59] <brad_a> i didnt know about the unicode stuff :\
[17:43:54] <Beh0lder> i used patched SDL from alternative repository
[17:44:05] <fuzzie> the trivial way to do it is just to use 32-bit values for unicode chars, but it's not at all trivial to render that, even, due to things like combining characters (e.g. 'combining acute accent', which combines with another character to add an acute accent)
[17:44:18] <brad_a> well official SDL 1.3 added android multitouch in revision f324bd81b52c
[17:44:28] <fuzzie> but the 'default' behaviour in core should be to support the original games
[17:44:43] <brad_a> agreed
[17:44:47] <fuzzie> and i think an optional plugin for supporting the original games would be silly
[17:44:48] <Beh0lder> i'll try recent
[17:45:29] <brad_a> yes it was less than 6 weeks ago that they addd that
[17:45:44] <fuzzie> tomprince: i think any portable project is an eternal fight between useful dependencies and easier builds
[17:46:57] <brad_a> fuzzie: i thought you said any official build maps to what we would be using in the core
[17:48:04] <fuzzie> brad_a: not if the core is using unicode, though
[17:48:22] <brad_a> its not important right now anyway. we are just going to have to have this discussion in january when i start trying to make gemrb MB compatible
[17:48:24] <fuzzie> and if not i'm not sure how your idea of conversion would work
[17:48:35] <fuzzie> perhaps i am just missing something
[17:48:41] <brad_a> no i think i am
[17:48:52] <brad_a> you definately know more about string encodings than me
[17:49:00] <fuzzie> i am a unicode nerd :(
[17:49:03] <brad_a> lol
[17:49:13] <brad_a> well then expect to be prodded by me in a couple months
[17:49:19] <fuzzie> but original data files are using windows encodings, treat them just as weird 16-bit values that map onto the BAM sprites
[17:49:36] <Beh0lder> performance is bad in any case, not critical in travel mode, but video is choppy
[17:50:19] <brad_a> yes i dont quite know why performance in SDL 1.3 is so bad on android
[17:50:33] <brad_a> i suspect the compatibility layer ahs something to do with it
[17:50:41] <brad_a> since there is no hardware acceleration
[17:50:54] <brad_a> we need true SDL 1.3 video driver :)
[17:51:17] <Beh0lder> SDL working through OpenGL
[17:51:23] <fuzzie> i think SDL 1.3 + opengl driver is smarter idea
[17:51:24] <brad_a> i know
[17:51:43] <brad_a> well its up to you since nobody else is likely to do it :)
[17:51:54] <brad_a> i know im not
[17:53:11] <Beh0lder> pelya's SDL 1.3 is not fast too
[17:59:47] <brad_a> like i said its probably due to the compatibility layer
[18:00:04] <brad_a> SDL 1.3 itelf is probably fast. using the old 1.2 apis is not
[18:02:43] <Beh0lder> i still want to find a simple working SDL 1.3 example for android with handling user input (touch&keyboard)
[18:07:23] <-- Beh0lder has left #gemrb
[18:26:14] <-- boba has left IRC (Read error: Connection reset by peer)
[18:37:23] <-- Drakkar has left IRC (Ping timeout: 252 seconds)
[19:46:18] --> Drakkar has joined #gemrb
[19:56:10] --> SiENcE has joined #gemrb
[20:24:05] <-- Yoshimo has left IRC (Ping timeout: 258 seconds)
[20:55:02] <gembot> build #288 of cmake g++-4.2.4 is complete: Failure [failed compile] Build details are at http://buildbot.gemrb.org/builders/cmake%20g%2B%2B-4.2.4/builds/288 blamelist: Brad Allred <bradallred@me.com>
[20:55:41] <tomprince> brad_a: That is fixed in my branch ^^^
[20:55:50] <brad_a> that is the type thing i assume?
[20:55:58] <tomprince> Nope.
[20:56:00] --> Yoshimo has joined #gemrb
[20:56:22] <brad_a> i dont know how to make sense of this buildbot page
[20:56:44] <brad_a> oh found it
[20:57:08] <brad_a> well sort of. i found the log but i still can find what went wrong
[20:57:26] <brad_a> some warning or another?
[20:57:27] <gembot> build #284 of mingw32 is complete: Failure [failed compile] Build details are at http://buildbot.gemrb.org/builders/mingw32/builds/284 blamelist: Brad Allred <bradallred@me.com>
[20:57:37] <tomprince> Cherry picking your commit, it doesn't crash, but a bunch of the text is shifted down.
[20:57:45] <tomprince> No, you didn't update the build.
[20:57:58] <brad_a> i dont know what that means
[20:57:59] <gembot> build #285 of cmake g++-4.6.0 is complete: Failure [failed compile] Build details are at http://buildbot.gemrb.org/builders/cmake%20g%2B%2B-4.6.0/builds/285 blamelist: Brad Allred <bradallred@me.com>
[20:58:21] <tomprince> It isn't compiling FontManager.
[20:58:31] <brad_a> because it not in cmake?
[20:58:38] <tomprince> Yes.
[20:58:40] <brad_a> oh
[20:58:49] <brad_a> i know i was forgetting something :-P
[20:59:09] <brad_a> odd that you get shifted text
[20:59:17] <tomprince> But, like I said, I fixed this in my branch. (execept the ttf still fails on autoconf)
[20:59:17] <brad_a> i assume you are using only BAM fonts
[20:59:22] <gembot> build #283 of cmake clang++ is complete: Failure [failed compile] Build details are at http://buildbot.gemrb.org/builders/cmake%20clang%2B%2B/builds/283 blamelist: Brad Allred <bradallred@me.com>
[20:59:28] <tomprince> That may be because I made a mistake in rebaseing.
[20:59:37] <tomprince> gembot: mute
[20:59:37] <gembot> Shutting up for now.
[20:59:45] <brad_a> thats a neat trick!
[21:00:22] <tomprince> There is also an msvc error .... for loop indicies.
[21:00:30] <tomprince> (that I didn't fix)
[21:00:46] <brad_a> where can i see that msvc error?
[21:01:28] <tomprince> brad_a: You should have a look at my branch, check that I didn't mess anything up (or fix it), and clean up the commit messages.
[21:01:30] <tomprince> http://buildbot.gemrb.org/builders/msvc%2B%2B6/builds/296/steps/compile/logs/errors
[21:01:50] <brad_a> oh that warning
[21:02:05] <brad_a> well error i guess
[21:02:31] <tomprince> If you click waterfall or grid, you get a list of all the recent uilds on all the builders.
[21:02:31] <brad_a> yeah odd that clang doesnt say anything aboutthat but when i build with gcc it warns me
[21:02:53] <brad_a> that is an easy fix
[21:03:03] <tomprince> That is because msvc is silly and out of date.
[21:03:12] <tomprince> It is valid C++.
[21:03:48] <brad_a> well i still think i was wrong to use i there wether or not it is valid. i assume i only did it because i didnt realize it was being used earlier
[21:04:22] <brad_a> ill just change that to a new index var
[21:04:42] <tomprince> Well, in standard C++, the scoe of a variable defined like for(int i = ...) is just the body of the for, but msvc6 doesn't do that.
[21:05:29] <brad_a> yes
[21:05:39] <tomprince> The standard fix we do is just define it outside the for.
[21:05:41] <fuzzie> The Dark Times Before Standardization
[21:05:46] <brad_a> lol
[21:06:22] <brad_a> tomprince how do i checkout your branch?
[21:06:41] <brad_a> i guess i need a new remote?
[21:06:47] <tomprince> yep
[21:07:04] <tomprince> the git checkout -b fonts tomprince/fonts
[21:07:09] <tomprince> s/the/gen
[21:08:25] <tomprince> And .... apparently I can't type.
[21:09:56] <brad_a> what does -b do?
[21:10:14] <tomprince> creates a new local branch tracking the remote one.
[21:10:23] <brad_a> ah
[21:10:51] <tomprince> And then I was rebasing with 'git rebase -i $(git merge-base fonts sf)'
[21:10:57] <tomprince> where sf is my sf remote.
[21:11:48] <brad_a> whats the diffrence between that and just rebase -i?
[21:12:21] <tomprince> Well, that just says where to rebase it. I just didn't want to rebase on head
[21:13:29] <brad_a> nice of you to make the cmake file for the TTF importer :)
[21:14:56] <tomprince> Well, I couldn't test if my changes at least compiled without it.
[21:15:15] <brad_a> ok doing a clean build and run to see about this text shift
[21:19:59] <brad_a> wow
[21:20:03] <brad_a> that is screy
[21:20:06] <brad_a> screwy
[21:20:26] <brad_a> its not just shifted down but all sorts of wacky
[21:21:01] <brad_a> so yes some diffrence between yours and mine
[21:26:08] <brad_a> did you just thow out my changes to BAMImporter::GetFont?
[21:26:16] <brad_a> thats probably why its screwy
[21:26:35] <brad_a> i guess you didnt cuz thats where it was crashing
[21:26:45] <brad_a> i just cant find where that got squised
[21:26:49] <brad_a> squished
[21:27:56] <brad_a> found it
[21:31:10] <-- SiENcE has left IRC (Quit: cya)
[21:34:43] <brad_a> tomprince: it looks like when you blit you get the size and xpos but not the ypos
[21:37:43] <brad_a> or rather a use of xpos instead of ypos
[21:39:28] <brad_a> well that was part of the problem
[21:39:50] <brad_a> the first blit region call needs to change to use ypos instead of xpos
[21:39:58] <brad_a> but the button text is still shifted down
[22:14:07] <tomprince> brad_a: That was probably caused by by reckless use of :s///
[22:14:12] <brad_a> yes
[22:14:26] <brad_a> but also it appears the space character is causing the shift
[22:14:36] <brad_a> apparently the space is 47 px tall
[22:15:53] <-- Yoshimo has left IRC (Quit: Yoshimo)
[22:16:42] * tomprince *grins*
[22:17:02] <-- Maighstir has left IRC (Quit: .)
[22:18:27] <brad_a> probably because whitespace is a region
[22:18:37] <brad_a> and not a GlyphInfo
[22:19:00] <tomprince> I thought I changed that.
[22:19:07] <brad_a> nope
[22:19:21] <brad_a> or if you did
[22:19:27] <brad_a> you didnt set the ypos and xpos
[22:19:52] <brad_a> whhitespace is a glyphinfo but it is being assigned regions
[22:19:58] <brad_a> thats what i mean
[22:19:59] <brad_a> :)
[22:22:34] <brad_a> im gonna shut up for a min since i dont know what im saying
[22:23:12] <brad_a> i cant find where whitespace is being initialized
[22:23:45] <brad_a> should i jsut do a memset to blank out the entire block?
[22:23:45] <tomprince> core/Font.cpp:114
[22:24:01] <brad_a> that is just setting the region of whitespace[1]
[22:24:16] <brad_a> i see no whitespace[0] nor the xpos/ypos
[22:25:18] <tomprince> brad_a: https://gist.github.com/1411385
[22:25:29] <tomprince> That seems to fix it.
[22:25:52] <brad_a> ok help me learn c++ and explain what is happening there
[22:28:18] <brad_a> or what is that syntax called so i can properly google it
[22:31:00] <brad_a> so variable(value) sets variable to value i guess, but variable() does what exactly?
[22:31:22] <tomprince> http://stackoverflow.com/questions/620137/do-the-parentheses-after-the-type-name-make-a-difference-with-new/620402#620402
[22:31:40] <brad_a> ty
[22:32:43] --> SiENcE has joined #gemrb
[22:33:36] <brad_a> ok so a compiler generated constructor that 0s everything out?
[22:34:56] <tomprince> Yes, more or less.
[22:35:28] <tomprince> Actually, if we chaned that to point, we wouldn't need that, probably.
[22:35:46] <tomprince> i.e. Point pos; in GlyphInfo.
[22:35:53] <tomprince> Since region and point have constructors.
[22:36:24] <brad_a> well lets not worry too much about something that is going to change drastically when we go to using individual sprits for characters
[22:36:50] <tomprince> fine with me.
[22:37:38] <brad_a> do i need to rebase these fixes or just new commit?
[22:38:12] <tomprince> I'd be inclined to rebase, but it is up to you.
[22:38:26] <brad_a> well i may as well rebase since i need to fix the messages
[22:41:44] <tomprince> while you are doing that, you should test that it runs at each stage.
[22:41:59] --> edheldil_ has joined #gemrb
[22:42:20] <tomprince> which I should probably have done .... ;)
[22:42:36] <brad_a> well i did that with mine but i see now that you made some radical changes
[22:45:26] <tomprince> Well, BAMFontManager wasn't compiling, once I added the build rules for it, but it is now.
[22:46:17] <tomprince> But, mostly I suggested that becuase I did do some major surgury. Especially in the ordering of changes.
[22:46:28] <tomprince> The total diff from tip to tip isn't as big.
[22:47:07] <brad_a> yeah tip to tip its mostly switching operator[] for getinfo and the supporting types
[22:51:22] <tomprince> Does all the cahnges look sane to you?
[22:52:48] <brad_a> well im rebasing now and ill speak up if anything isnt. it all seemed to work in the end so im inclined not to worry much since it wont be long until i come back to finish the rewrite.
[22:53:38] <brad_a> you wont mind me using operator[] to access the individual glyph sprites i hope :-)
[22:54:03] <tomprince> I am not sure what the buys you over a function?
[22:54:29] <brad_a> its shorter?
[22:54:50] <brad_a> its personal preference i suppose
[22:54:51] <tomprince> getGlyph(x) vs. (*this)[x]
[22:55:04] <brad_a> oh yeah you hate my self macro :)
[22:55:52] <brad_a> alright ill use a function since you care more that me ;-)
[23:02:11] <tomprince> brad_a: http://www.oualline.com/style/c06.html#pgfId=335 <--- about why not SELF
[23:05:29] <brad_a> i guess most ides dont make it clear when you are dealing with a macro?
[23:11:10] --> lynxlynxlynx has joined #gemrb
[23:11:10] --- ChanServ gives channel operator status to lynxlynxlynx
[23:11:19] <tomprince> They should.
[23:11:46] <brad_a> tomprince: about that msvc error, i dont understand why it hates that because that is how the loop was before i changed it
[23:12:20] <brad_a> i guess before it was a level deeper?
[23:12:28] <tomprince> That would do it.
[23:12:33] <brad_a> ah
[23:12:59] <tomprince> Since anything in {} is in a inner scope, evenin msvc, it is only the () of the for, where the scope is different.
[23:13:12] <tomprince> I thin it is even a separte scope.
[23:13:26] <brad_a> ok that makes sense but seems silly
[23:21:39] <brad_a> rebasing is kinda fun once you know what you are doing :)
[23:22:58] <brad_a> so to test each step i should do git checkout HEAD~1?
[23:27:30] <brad_a> tomprince: i see 2 commits that need rewording. does that sound right?
[23:31:43] <lynxlynxlynx> btw, git rebase -i
[23:37:58] <tomprince> brad_a: That sounds not unreasoable
[23:38:34] <tomprince> For testing, git rebase -i, and then edit each commit. Then make; run; git rebase --continue
[23:39:17] <brad_a> ah i see you prefer to test from the beginning ;-)
[23:49:56] <-- edheldil_ has left IRC (Ping timeout: 258 seconds)
[23:50:39] <-- lynxlynxlynx has left IRC (Remote host closed the connection)
[23:52:34] <-- SiENcE has left IRC (Quit: cya)