[02:00:43] <tomprince> I'd be inclined to do SDLBase ---> SDL2/SDL12 if there is enough in common between the two.
[02:00:56] <tomprince> I don't know how true that is.
[02:02:50] <tomprince> Also, as fuzzie was suggesting, perhaps split off some of the non-video related code.
[02:04:41] <tomprince> At the very least, the shared init between SDLVideo and the sound drivers.
[02:11:49] <brad_a> hehe it works :)
[02:11:58] <brad_a> mostly
[02:12:08] <brad_a> intro videos are quite broken
[02:16:22] <brad_a> not using any fancy hardware textures tho...
[02:18:15] <brad_a> im confused at what the "extra" surface does
[02:20:49] --> joneirik has joined #gemrb
[02:52:52] <brad_a> well it works but im clearly doing something wrong since its slower than compatibility mode :)
[02:54:35] <brad_a> i would expect exactly the same speed or slightly faster
[02:55:42] <tomprince> Well, so may compatability mode was setting some flags that now aren't.
[02:55:51] <brad_a> probably
[02:56:20] <brad_a> it may have been my computer too
[02:56:34] <brad_a> jsut spontaniously deciding to be laggy temporarily
[02:57:58] <brad_a> yes repeated tests shows it was a fluke
[02:58:44] <brad_a> tho i would like to actually do something fancier than what compatibility mode was essentially doing
[02:59:21] <brad_a> im hoping just geting it working without the compatibility layer will be an acceptable start :)
[03:01:13] <brad_a> i dont know what SDL_CreateYUVOverlay is but apparently its gone now...
[03:01:25] <tomprince> Down to one use of GamePath outside of Interface/init-time.
[03:01:33] <brad_a> where?
[03:01:46] <brad_a> sounds good :)
[03:30:40] <brad_a> aw naw! loading a game crashes terribly :-P
[03:30:52] <brad_a> stupid drawing methods
[03:31:25] <brad_a> well getting videos and menu screen to work ws easy at least!
[03:58:47] <brad_a> tomprince: is there a reason DrawHLine and DrawVLine dont just call DrawLine?
[04:01:21] <tomprince> Cause it's simpler to do 90 degree lines, probably.
[04:02:07] <tomprince> It looks like neither of them are public, though.
[04:03:16] <brad_a> i just need to reimplement all the drawing methods is all
[04:04:24] <tomprince> Well, it looks like the only place DrawHLine and DrawVLine are called is in DrawRect.
[04:04:35] <brad_a> ooo
[04:04:41] <brad_a> then all i need is that
[04:05:00] <brad_a> SDL_RenderDrawRect is all i need ;-)
[04:05:21] <brad_a> so even if this driver isnt faster at least it should be simpler
[04:22:22] <-- joneirik has left IRC (Remote host closed the connection)
[05:02:04] <-- brad_a has left IRC (Quit: brad_a)
[05:21:23] --> brad_a has joined #gemrb
[05:21:48] <-- brad_a has left IRC (Client Quit)
[06:31:26] <tomprince> core/System/Loggers/Android.h or core/System/Logger/Android.h ??
[06:31:42] <tomprince> fuzzie?
[07:16:11] <tomprince> Logging: https://github.com/tomprince/gemrb/compare/master...logging
[07:16:40] <tomprince> ^--- that needs a sanity review, because I did way too much rebasing to fix silly typos.
[07:31:38] <tomprince> The logging functions there probably want to migrate towards the sample logging class brad_a posted a few days ago.
[08:40:47] <-- exultbot has left IRC (Ping timeout: 455 seconds)
[08:40:48] <-- exultbot has left IRC (signing off...)
[08:42:30] --> exultbot has joined #gemrb
[08:42:30] --- Topic for #gemrb is: GemRB 0.7.0 | http://gemrb.org | Be wary of your words for there are Modron sensors in this channel: http://log.usecode.org/gemrblog.php | Hey <CHARNAME>, we need some awesome screenshots! | import pdb; pdb.set_trace()
[08:42:30] --- Topic for #gemrb set by lynxlynxlynx!~quassel@sourcemage/warlock/lynxlynxlynx at Fri Dec 30 14:46:00 2011
[08:45:06] --> Yoshimo has joined #gemrb
[09:04:55] --> lynxlynxlynx has joined #gemrb
[09:04:55] <-- lynxlynxlynx has left IRC (Changing host)
[09:04:55] --> lynxlynxlynx has joined #gemrb
[09:04:55] --- ChanServ gives channel operator status to lynxlynxlynx
[09:14:55] --> edheldil_ has joined #gemrb
[09:24:11] --> Avenger has joined #gemrb
[09:24:11] --- ChanServ gives channel operator status to Avenger
[09:24:44] <Avenger> i think, we use the yuv overlay only in the bink player
[09:25:02] <Avenger> so if you don't want iwd2 compatibility, you can drop that
[09:27:12] <fuzzie> i'm pretty sure we *do* want iwd2 compatibility though :)
[09:28:18] <fuzzie> what brad wants is an SDL_Texture with format SDL_PIXELFORMAT_YV12
[09:28:25] <Avenger> yeah we do, i just guess iwd2 movies are not a priority on iphone
[09:29:25] <Avenger> hmm, you mean, it is now not a separate method?
[09:30:29] <fuzzie> yes
[09:31:34] <Avenger> if we want to keep backwards compatibility with 1.2 we cannot just switch?
[09:31:38] <fuzzie> yes
[09:31:45] <fuzzie> brad is writing a new SDL 2 plugin
[09:32:07] <fuzzie> because they dropped all the backwards compatibility APIs
[09:32:21] <Avenger> hmm, good, a separate plugin is good, it gives motivation to regroup functionality that is not sdl specific
[09:32:31] <fuzzie> yes.
[09:35:22] <Avenger> basic feats seem to work now, particularly those that just give some skill bonus, i haven't tested the complex ones, just shoveled them into gemrb
[09:37:13] <Avenger> the original iwd2 engine applies the dayblindness effect on drow/duergar in daytime when outdoors in every ai cycle. I repurposed our detect.spl for that.
[09:37:45] <Avenger> it looks like it applies the spell, but the effect isn't there yet, just debugging it now
[10:06:29] <Avenger> hmm, interesting, ai slowdown is really just a slowdown in iwd2/bg2. I wonder why actors get stuck without 'prevent ai slowdown' then.
[10:11:42] <-- edheldil_ has left IRC (Read error: Operation timed out)
[11:41:08] <Avenger> meeh, statdesc.2da is not continuous
[11:43:55] <Avenger> how do you create string from number in python?
[11:44:18] <fuzzie> str(numhere)?
[11:44:56] <fuzzie> you can do formatting ('%d' % num) if you need something more complex
[11:48:46] --> edheldil_ has joined #gemrb
[12:09:59] <-- Avenger has left IRC (Quit: bye!)
[12:25:51] <-- edheldil_ has left IRC (Ping timeout: 244 seconds)
[13:10:05] <gembot_> build #180 of nmake-msvc++10 is complete: Failure [4failed compile] Build details are at http://buildbot.gemrb.org/builders/nmake-msvc%2B%2B10/builds/180
[13:11:33] <gembot_> build #239 of nmake-msvc++6 is complete: Failure [4failed compile] Build details are at http://buildbot.gemrb.org/builders/nmake-msvc%2B%2B6/builds/239
[13:17:57] <gembot_> build #466 of msvc++6 is complete: Failure [4failed compile] Build details are at http://buildbot.gemrb.org/builders/msvc%2B%2B6/builds/466
[13:19:40] <CIA-125> GemRB: 03avenger_teambg * r4239618d7004 10gemrb/gemrb/override/iwd2/ (30 files): fixed effect targets
[13:25:03] <lynxlynxlynx> Interface.cpp(117) : error C2065: 'hConsole' : undeclared identifier
[13:25:28] <lynxlynxlynx> which i don't understand, since it is exported
[13:27:54] <tomprince> Those buils are from my logging branch.
[13:34:33] --> barra_home has joined #gemrb
[13:36:41] <gembot_> build #469 of mingw32 is complete: Failure [4failed compile] Build details are at http://buildbot.gemrb.org/builders/mingw32/builds/469
[13:38:06] <lynxlynxlynx> ah
[13:40:29] <gembot_> build #467 of msvc++6 is complete: Success [3build successful] Build details are at http://buildbot.gemrb.org/builders/msvc%2B%2B6/builds/467
[13:41:06] <tomprince> brad_a: Is there any reason that osx doesn't just set DATADIR to point into the bundle?
[13:48:37] --> wrotek has joined #gemrb
[13:51:20] <gembot_> build #241 of nmake-msvc++6 is complete: Success [3build successful] Build details are at http://buildbot.gemrb.org/builders/nmake-msvc%2B%2B6/builds/241
[14:10:48] <gembot_> build #182 of nmake-msvc++10 is complete: Success [3build successful] Build details are at http://buildbot.gemrb.org/builders/nmake-msvc%2B%2B10/builds/182
[14:16:06] <CIA-125> GemRB: 03avenger_teambg * r2834ca118a98 10gemrb/gemrb/GUIScripts/ (GUIREC.py iwd2/GUIREC.py): fixed status feedback problems (missing entries in statdesc.2da, wrong capitals in iwd2)
[14:16:18] <CIA-125> GemRB: 03avenger_teambg * r309fcf91f1b1 10gemrb/gemrb/plugins/IWDOpcodes/IWDOpcodes.cpp: fixed a leak in resist spell and message effect
[14:16:18] <CIA-125> GemRB: 03avenger_teambg * rc2e157f58611 10gemrb/gemrb/plugins/IWDOpcodes/IWDOpcodes.cpp: fixed dayblindness effect
[14:16:19] <CIA-125> GemRB: 03avenger_teambg * rd92d4a6d7718 10gemrb/gemrb/override/iwd2/splprot.2da: fixed splprot data for outdoor/daytime
[14:16:19] <CIA-125> GemRB: 03avenger_teambg * r8495a89ead20 10gemrb/gemrb/GUIScripts/GUICommonWindows.py: fixed ugly characters in iwd2 portrait icons (no blank chars)
[14:21:47] --> Avenger has joined #gemrb
[14:26:46] <-- barra_home has left IRC (Quit: Verlassend)
[14:28:21] <tomprince> std::string would make it so we don't have quite so many _MAX_PATH arrays lying around.
[14:33:45] <Avenger> i don't really see the benefit, std:strings also lie around
[14:34:55] <Avenger> sure, they won't take up a single block of ~256 bytes. instead they take up 16 + x bytes. plus a lot of code to manage it
[14:35:28] <Avenger> it is also a mess when you want to debug it
[14:37:08] <Avenger> i don't know what's wrong with this dayblindness stuff, it works perfectly on windows (with msvc6)
[14:37:42] <Avenger> the effect is applied only for a few moments, then it goes away without trace (when i run it on linux)
[14:38:32] <Avenger> its a pity i don't have a good debugger on linux
[14:45:09] <gembot_> build #470 of mingw32 is complete: Success [3build successful] Build details are at http://buildbot.gemrb.org/builders/mingw32/builds/470
[14:46:00] <tomprince> Avenger: I'm fairly certain _MAX_PATH is 4096, at least on unix.
[14:49:32] <tomprince> Which is much more that 16 + length of string.
[14:51:44] <tomprince> And it is probably large enough that it destroys some cache locality.
[14:53:37] <tomprince> For example, Interface is ~70k
[14:55:03] --> SiENcE has joined #gemrb
[14:56:42] <gembot_> build #471 of mingw32 is complete: Failure [4failed] Build details are at http://buildbot.gemrb.org/builders/mingw32/builds/471
[15:10:59] <-- wrotek has left IRC (Ping timeout: 252 seconds)
[15:14:14] <tomprince> I'd welcome a suggestion of some way of handling strings that 1) doesn't use fixed size strings 2) does require manually managing memory 3) isn't std::string
[15:14:30] <tomprince> I don't care about the last, but other people do, I guess. :)
[15:16:02] <lynxlynxlynx> not me, though I also don't understand why you want to manage memory manually
[15:17:46] <tomprince> s/does/doesn't/ of cours. :)
[15:19:41] <tomprince> And, I guess anything that satisfies 1+2 will also satisfy 4) can be put in containers.
[15:21:40] <fuzzie> we could simply take scummvm's string class
[15:22:51] <fuzzie> not sure of it's really better than stl string though
[15:24:41] <Avenger> oh hi fuzzie, can you help me finding the problem with dayblindness?
[15:24:53] <Avenger> or lynx, or anyone :)
[15:25:06] <fuzzie> sorry, am on android tablet :-(
[15:25:20] <fuzzie> will be around in evening if not fixed then
[15:25:38] <lynxlynxlynx> maybe later, i'm working now :/
[15:26:50] <gembot_> build #472 of mingw32 is complete: Success [3build successful] Build details are at http://buildbot.gemrb.org/builders/mingw32/builds/472
[15:27:25] <tomprince> The scummvm class is interesting: both refcounting and small string storage.
[15:29:10] <fuzzie> but it is intended for low-end systems rather than sane api and/or thread-safety..
[15:31:11] <tomprince> I wouldn't be opposed to that.
[15:31:49] <tomprince> I don't like copying code in from elsewhere, but I guess that's the best we can do without adding a dep.
[15:35:47] <fuzzie> well or we can just use stl string, certainly should be clear gain for paths
[15:37:31] <lynxlynxlynx> kiss
[15:39:47] <fuzzie> well which one is simple? :-)
[15:41:11] <tomprince> We can't just take the scummvm one, since it depends on other parts.
[15:42:50] <Avenger> probably everyone has different opinions about which is simple. i think the simplest is the current one :)
[15:43:28] <fuzzie> current one wastes a lot of memory, that is all
[15:43:55] <Avenger> how much? 70k is much?
[15:44:15] <fuzzie> we use paths in other places
[15:44:35] <Avenger> they are only temporary, no?
[15:44:45] <fuzzie> and we have to be caregul while copying
[15:45:09] <fuzzie> well i don't have source here to see what we fixed
[15:45:25] <tomprince> And there is the buffer overflow currently possible when joining paths.
[15:47:30] <tomprince> If 70k isn't much to waste ... how is using std::string code that is there anyway (since we link to libstdc++) ?
[15:48:17] <fuzzie> well it is annoying to debug sometimes
[15:49:32] <fuzzie> but i think avoiding annoying crash bugs and saving memory etc is worthwhile as long as it stays _simple_
[16:48:31] --> brad_a has joined #gemrb
[16:54:43] <CIA-125> GemRB: 03avenger_teambg * r1597d6d0a3dc 10gemrb/gemrb/ (4 files in 2 dirs): implemented spell focus feats
[16:57:31] <Avenger> testing spells in iwd2 is difficult, as the action buttons are messy. Only my cleric can cast spells :) But i tested spellfocus by setting the feat, and modifying the spell to be of the same school
[17:04:31] <wjp> FWIW, dayblindnes seems to disappear here too
[17:05:04] <wjp> (in IWD2, starting a new game with the pre-made sisters of the bloodmoon party)
[17:07:31] <wjp> I can't seem to get it to happen when running in valgrind
[17:10:27] <wjp> valgrind is showing some quickslot-related warnings, but that doesn't seem relevant here at first glance
[17:12:11] <tomprince> wjp: Are you going to have a look at autotools, or should I delete it?
[17:13:24] <wjp> hm, so it does happen in valgrind too, but no warnings show up around the time it happens
[17:14:09] <wjp> tomprince: I probably won't
[17:18:26] <tomprince> k
[17:26:27] <Avenger> oh i see, detect is used from the shared override...
[17:26:45] <Avenger> the game specific gemrb override should have precedence
[17:27:25] <Avenger> haha, it isn't even copied to the install dir
[17:27:30] <Avenger> aww
[17:27:42] <lynxlynxlynx> why remove autotools? just let it rot
[17:27:54] <lynxlynxlynx> still easier for 3rd parties to fix it up if they need to
[17:28:40] <Avenger> i agree with lynx
[17:29:01] <Avenger> if someone doesn't like its half working state, they would be more motivated to fix it if it is there
[17:31:41] <lynxlynxlynx> are you sure the shared override is overriding the rest?
[17:31:51] <lynxlynxlynx> should definitely be the other way around
[17:32:09] <lynxlynxlynx> it was an assumption from the start, so i doubt it
[17:33:15] <tomprince> You may need to rerun cmake to pick up new files.
[17:33:16] <Avenger> ok, there is nothing wrong with dayblindness :) wjp: press ctrl-t to advance time, the only slight bug is that it is apparently ignoring the first hour of morning. Make sure that detect.spl is executed from the iwd2 gemrb override
[17:33:43] <Avenger> i needed to touch CMakeFile
[17:37:20] <Avenger> lynx: i let some combat specific feats to you: ambidexterity, two weapons, etc :)
[17:38:19] <Avenger> short of those, i think i implemented all
[17:38:24] <lynxlynxlynx> those are just HasFeat checks, no need to wait for me
[17:38:44] <lynxlynxlynx> cool news :)
[17:38:51] <Avenger> not sure, they have some numbers attached to them
[17:39:00] <Avenger> but they could be hardcoded, yep
[17:39:30] <Avenger> hmm, the strong back feat isn't implemented, lets see
[17:40:28] <-- Avenger has left IRC (Remote host closed the connection)
[17:44:52] --> Avenger has joined #gemrb
[17:45:03] <Avenger> heh, we don't have any encumbrance related code yet?
[17:45:08] <lynxlynxlynx> nope
[17:45:09] <Avenger> like slowing down, etc?
[17:45:18] <Avenger> lol
[17:45:58] <lynxlynxlynx> we reuse it for weight now, while the original uses it as a state (0-2 iirc)
[18:01:38] <Avenger> anyone knows the weight allowance formula for 3rd ed?
[18:02:21] <Avenger> do you want me to change it to the state?
[18:02:29] <Avenger> i have the state calculated now
[18:11:05] <lynxlynxlynx> don't know about the ratios, but the limit is in the strenght table
[18:12:51] <wjp> Avenger: http://www.d20srd.org/srd/carryingCapacity.htm
[18:13:49] <wjp> (seems to match my 3rd ed PHB)
[18:20:50] <Avenger> well, i somehow doubt they have this table hardcoded in its entirety in the exe
[18:24:42] <wjp> it's not the nicest table
[18:25:05] <wjp> it's almost a simple exponential, but rounded to irregular "nice" values
[18:27:00] <wjp> Avenger: now I'm confused about dayblindness, though. I tried resting continuously, and after a few dozen times, the dayblindness icon would disappear permanently, and the "Try Apply DayBlindness" also didn't show up anymore in the terminal
[18:28:52] <Avenger> wjp: was it still daytime/outdoors?
[18:30:25] <wjp> I was resting all the time, so the time jumped around
[18:31:26] <wjp> but before, the "Try Apply DayBlindness" message was showing up both during the day and the night, and the icon showed during the day, and not during the night
[18:31:38] <lynxlynxlynx> the default sleep duration is 8h, so it will wrap quickly
[18:31:55] <lynxlynxlynx> WEIGHT_ALLOWANCE in strmod.2da holds the limit
[18:31:59] <wjp> wrap?
[18:32:34] <CIA-125> GemRB: 03avenger_teambg * rb58fa09b44d7 10gemrb/gemrb/core/Spell.cpp: fix a crash when there is no spell focus table
[18:32:44] <CIA-125> GemRB: 03avenger_teambg * r34011ad2a539 10gemrb/gemrb/ (7 files in 7 dirs): string refs for encumbrance
[18:32:49] <Avenger> lynx: does that apply to 3rd ed?
[18:33:02] <lynxlynxlynx> why not?
[18:33:17] <Avenger> well, some stuff is different
[18:33:21] <lynxlynxlynx> wjp: 3x8 = 24, so further sleep is useless
[18:33:34] <Avenger> ok, i will use the table until i peek into IDA
[18:33:47] <lynxlynxlynx> yeah, a good starting point
[18:34:18] <lynxlynxlynx> maybe you get heavy at 75% of it or something over
[18:35:25] <CIA-125> GemRB: 03avenger_teambg * rb8244d4e9a6e 10gemrb/gemrb/core/ (4 files in 3 dirs): handle encumbrance
[18:36:06] <wjp> lynxlynxlynx: I have no idea what you mean by further sleep being useless
[18:36:13] <Avenger> ctrl-t advances the time by 1 hour
[18:36:42] <lynxlynxlynx> the day starts and ends at the same ours
[18:36:43] <lynxlynxlynx> hours
[18:37:51] <Avenger> hmm, if you rested, it should work at least once from 3 :)
[18:37:54] <wjp> yes, but daylight is longer than 8 hours
[18:38:01] <wjp> right, what Avenger says :-)
[18:38:38] <wjp> in any case, the "Try Apply DayBlindness" should appear regardless of the time, right?
[18:38:58] <Avenger> no, there is a check in detect.spl
[18:39:27] <Avenger> it checks simple outdoor/daytime cases using the splprot mechanism
[18:39:45] <Avenger> that was a good test for the mechanism, all checks failed in some way :D
[18:40:32] <wjp> hm, aha, so if it is totally gone after resting, it comes back when doing ctrl-t
[18:41:19] <Avenger> it is weird it goes away with resting
[18:41:33] <Avenger> as you said, the daytime period is longer than 8 hours
[18:41:45] <Avenger> and resting should be only 8 hours
[18:42:14] <Avenger> we need to enable the tooltip over the clock :)
[18:42:26] <Avenger> that would be helpful
[18:42:31] <wjp> yes :-)
[18:42:53] <wjp> if you ctrl-t until the 'try apply dayblindness' messages are gone, and then rest until it's day, dayblindness stays away
[18:43:21] <wjp> I think :-)
[18:43:42] <Avenger> i can't imagine how can that happen
[18:44:04] <Avenger> both ctrl-t and resting use the same time advancement
[18:44:10] <Avenger> except the size
[18:44:28] <Avenger> pressing ctrl-t 8 times, is the same as one rest
[18:45:33] <Avenger> btw, there was a crashy version before rb58fa09b44d7, expect more phoning home :D
[18:46:12] <Avenger> i would delete the buggy versions but i can't bother finding them :)
[18:47:42] <Avenger> lynx: the strong back feat needs to be added to some script too, can you do it?
[18:48:05] <lynxlynxlynx> sure
[18:48:37] <Avenger> simply add half of the weight allowance if the feat is there
[18:50:51] <Avenger> there are weird things with the gui: if i pick up an item, the sum weight is printed as 0 :)
[18:52:17] <Avenger> if you need some method to know the encumbrance stat, tell me. I can either make it compatible and store the state (0,1,2) or have an alternate route for one of the numbers
[18:54:39] <CIA-125> GemRB: 03lynxlupodian * r0a3f7ec9870e 10gemrb/gemrb/GUIScripts/GUICommon.py: GUICommon: use the strong back feat when making the encumbrance labels
[18:54:51] <lynxlynxlynx> we need the weight somewhere, so the current way is fine
[18:55:05] <lynxlynxlynx> the script uses 80% to detect when encumbrance starts
[18:56:29] <Avenger> where you got that number? just guess or you know it for sure
[18:56:52] <Avenger> i could go and reboot to peek into the DB :)
[18:57:06] <Avenger> or just test it
[18:58:30] <Avenger> so it goes red at 100%, and yellow at 80?
[19:01:48] <lynxlynxlynx> i don't know
[19:01:58] <lynxlynxlynx> quite likely it wasn't me that put it there
[19:06:34] <brad_a> i thought i could be clever and draw lines/rects directly to the render, but since im then taking the backbuffter and rendering it the rects/lines are all destroyed :-/ not sure how best to make this work
[19:07:33] <Avenger> meh, then it was me, but i don't remember if it was a guess or checked fact
[19:09:14] <CIA-125> GemRB: 03avenger_teambg * rbe454bc956a3 10gemrb/gemrb/core/GUI/GameControl.cpp: don't run in PST if encumbered
[19:09:25] <CIA-125> GemRB: 03avenger_teambg * rf00b04b10692 10gemrb/gemrb/GUIScripts/GUICommon.py: Merge branch 'master' of ssh://gemrb.git.sourceforge.net/gitroot/gemrb/gemrb
[19:11:01] <Avenger> there are still some small problems, like the encumbrance strings are personalized in pst
[19:14:14] <CIA-125> GemRB: 03avenger_teambg * rbed054c5c3ea 10gemrb/NEWS: encumbrance in the news
[19:14:41] <-- Avenger has left IRC (Quit: bye!)
[19:24:18] <lynxlynxlynx> yeah, lots of strings like that in pst
[19:24:30] <lynxlynxlynx> silly silly developers
[19:37:00] --> Avenger has joined #gemrb
[19:37:00] --- ChanServ gives channel operator status to Avenger
[19:37:33] <lynxlynxlynx> don't you get tired of rebooting?
[19:38:07] <Avenger> brad_a: do you think we can ease the logging process? like sending stdout to a file. That would make the loops with alogcat unnecessary.
[19:38:25] <Avenger> yeah lynx, but i cannot sit in a single OS :) each has its own benefit
[19:39:05] <lynxlynxlynx> you could do atleast the commiting from windows too
[19:39:42] <Avenger> then i would never try to recompile in linux :D
[19:40:08] <tomprince> Well, gembot should start yelling if you break things ...
[19:40:09] <fuzzie> Avenger: the plan is just to move to a modular logging system and then we can customise stuff trivially, see tomprince's logging branch
[19:40:12] <Avenger> when move the files from win to linux, i usually review the changes
[19:40:36] <tomprince> Logging: https://github.com/tomprince/gemrb/compare/master...logging
[19:42:37] <Avenger> hmm, looks nice, conservative types :D
[19:43:03] <tomprince> And then change the interface similar to the macros here http://dl.dropbox.com/u/13866402/logger.patch
[19:44:08] <fuzzie> oh dear, I shouldn't have clicked that in Chrome. forgot I wasn't using Firefox and open-in-browser.
[19:44:11] <Avenger> yeah, logging to a file will definitely make this phone stuff easier
[19:44:48] <Avenger> what happened fuzzie? did it patch something? ;D
[19:45:07] <fuzzie> no, it tried waking up some GNOME thing and crashed, ofc..
[19:45:19] <fuzzie> hate computers so much :)
[19:45:47] <Avenger> yeah, my firefox is still crashing/rebooting on startup... actually, one of my reboots was involuntary
[19:45:56] <fuzzie> got to say, LOG is completely hideous as macro name
[19:46:20] <Avenger> if it is too long i scream, if it is too short, you do :D
[19:46:25] <lynxlynxlynx> logarithm
[19:46:31] --> wrotek has joined #gemrb
[19:46:43] <Avenger> hmm, isn't that log( ?
[19:46:59] <Avenger> but i agree, it might collide with something
[19:47:20] <Avenger> what about GEMLOG
[19:47:46] <fuzzie> i would go for descriptive names like debug()/info()/warning()
[19:48:00] <lynxlynxlynx> LOG_INFO maybe
[19:48:08] <lynxlynxlynx> fits with the rest
[19:48:12] <tomprince> Well, I wasn't suggesting those exact macros, but just forcing everything we write to be a complete log message, rather than this incremtal thing we have right now.
[19:48:41] <fuzzie> tomprince: but then you can't do 'Loading <xxx>' + '[ERROR]/[OK]'?
[19:49:06] <fuzzie> that's already sabotaged in one code path and it's kinda annoying
[19:49:13] <Avenger> which i like
[19:49:19] <Avenger> i mean, the original thingie
[19:49:40] <Avenger> it is good to print the 'loading ...' part, so you know what crashed
[19:49:52] <Avenger> and it is good to print the status in the same line
[19:49:55] <tomprince> Well, the problem is, the android logging for example, can't emit partial log lines.
[19:49:56] <Avenger> so... incremental
[19:49:58] <-- Yoshimo has left IRC (Ping timeout: 265 seconds)
[19:50:09] <fuzzie> tomprince: but we should indeed probably be writing to a log file there anyway
[19:50:25] <Avenger> yeah
[19:50:33] <fuzzie> and only writing disasters to the actual system log
[19:50:57] <Avenger> disasters like cannot write the file log :D
[19:50:59] <fuzzie> (the android log is a *kernel* ring buffer which can be very small on some devices, so it's a bit awful)
[19:50:59] <tomprince> The other problem with incremental logs is that we often log in the middle of logs.
[19:51:49] <fuzzie> well, you could differentiate between "this is a log we should write and flush" and "this is a log we can delay on"
[19:52:10] <Avenger> it would be good if we can autoindent the log :)
[19:52:17] <Avenger> but that would be too much, isn't it
[19:52:39] <fuzzie> well, we spend an awful lot of time staring at logs
[19:52:52] <fuzzie> so i don't think it's effort wasted to make them more readable
[19:53:12] <Avenger> as long as it isn't my time, i welcome it :D
[19:53:22] <brad_a> i already have stdout/stderr redirect to a file in iOS anyway (if they enable debug mode in the wrapper)
[19:53:45] <Avenger> heh, then we should suggest that, instead of alogcat?
[19:53:58] <brad_a> i think you are confusing android and ios :)
[19:54:01] <fuzzie> the android filesystem layer is not to be trusted with syncing stuff
[19:54:18] <fuzzie> so logging *only* to a file is perhaps not the best idea
[19:54:36] <fuzzie> but it's trivial to add logging to a file if it's all classes
[19:54:37] <brad_a> it slows things down and makes a huge file too ;-)
[19:54:50] <Avenger> yeah brad, i do :)
[19:56:20] <Avenger> well, it is still a good option, also when everything is fine, we should be able to make the logging less obnoxious, with only errors printed
[19:56:59] <Avenger> the loglevel stuff will be useful
[19:57:27] <brad_a> i was trying to avoid a total rewrite for sdl 2 but i guess i may as well…
[19:58:35] <Avenger> you can try to move some of the common parts to Video?
[19:58:46] <fuzzie> let's please not move SDL specifics to Video :p
[19:58:53] <brad_a> yes that part is going very smoothly
[19:59:15] <brad_a> its the drawing of things like lines/boxes/etc that dont work
[19:59:15] <Avenger> uh, yes, i meant... the common parts that would be common with directx and everything else :)
[19:59:30] <fuzzie> it's pretty bad as it is
[19:59:40] <brad_a> i think i have a pretty slick inheritance hierarchy going on
[19:59:46] <fuzzie> Video has all this CreateAlpha/etc stuff which pokes directly at pixels
[19:59:53] <brad_a> crap
[20:00:06] <Avenger> hmm, those pixels are not the same everywhere?
[20:00:45] <brad_a> well with sdl 2 you cont have pixel access to textures. i guess i will have to keep using surfaces then
[20:00:49] <fuzzie> those pixels will be in video RAM and thus a bad idea to poke at
[20:00:56] <Avenger> eep :D
[20:01:42] <fuzzie> i thought it was possible to get the pixels out of the textures though, just very very slow
[20:01:47] <brad_a> yes
[20:01:52] <brad_a> you can "query"
[20:02:07] <brad_a> havent tried it or read about it
[20:02:12] <fuzzie> yeah, so you can do that in theory
[20:02:29] <fuzzie> but I think your performance might be pretty awful if you try doing textures naively
[20:02:35] <brad_a> yes
[20:02:42] <Avenger> then it maybe needs a rewrite, so we stuff the pixels into the video ram AFTER all pre-processing
[20:03:17] <Avenger> naively or natively?
[20:03:21] <fuzzie> naively
[20:03:38] <fuzzie> SDL 2 doesn't even try handling e.g. paletted textures, right?
[20:03:50] <brad_a> im not sure
[20:04:20] <brad_a> the only thing of real value i have now is abstraction code:0
[20:04:54] <brad_a> i do set up a window and a renderer and then jsut do a simple convert of backbuffer to a texture and render it
[20:05:05] <brad_a> which works but obviously isnt going to stick around
[20:05:21] <fuzzie> and of course it will completely fail to create a texture for something like mos
[20:05:48] <Avenger> see you tomorrow
[20:05:48] <-- Avenger has left IRC (Quit: bye!)
[20:05:59] <fuzzie> so i would really stick with surfaces for everything for now
[20:06:29] <brad_a> yes :( but there must be a better way then converting surfaces to textures everytime you want to blit
[20:06:40] <fuzzie> well, that is just going to fail, you'd think
[20:06:40] <brad_a> thats is expensive and wasteful
[20:07:57] <brad_a> i need to do a lot more thinking
[20:08:09] <fuzzie> but loading 100mb of textures into video RAM is presumably also going to fail hilariously
[20:08:23] <brad_a> he he
[20:08:33] <fuzzie> and this kind of thing is *way* more important for the holy grail of an opengl backend
[20:08:38] <brad_a> yes
[20:08:41] <fuzzie> so any thinking you can do about it will be much appreciated in the future
[20:08:56] <wjp> CreateAlpha probbly isn't worth worrying about initially, by the way
[20:09:21] <brad_a> the parts i do have that do work nicely is drawing of lines/boxes in opengl but as i said earlier once i display the backbuffer they are wiped :(
[20:09:27] <fuzzie> yeah, CreateAlpha and CreateLight and etc were totally broken on my machine for ages and I hadn't realised why some things looked so funny
[20:09:51] <fuzzie> brad_a: well, one option is to keep track of what's onscreen and re-render
[20:09:55] <wjp> but the things those functions do can likely be done far better in an opengl-specific way
[20:09:57] <fuzzie> it's pretty annoying though
[20:09:58] <brad_a> yes i thought of that
[20:10:09] <brad_a> and decided it was pretty annoying too :)
[20:11:57] <tomprince> So the logging branch looks good?
[20:12:03] <brad_a> if i could at least throw the background down as a texture first then lines and boxes would partially work...
[20:12:17] <fuzzie> tomprince: +1
[20:12:43] <fuzzie> brad_a: yes, things would go much better if the video plugin had a better idea of the *context* of what was rendered
[20:12:51] <brad_a> exactly
[20:16:58] <brad_a> i could make an argument or new function to create sprites with hardware acceleration (if available) and then sdl12driver would jsut ignore it and make a regular surface and sdl2driver could make a texture instead of surface
[20:17:28] <tomprince> How would you decide when to pass that paramater?
[20:18:21] <brad_a> well immediately im thinking of the background
[20:18:23] <fuzzie> yeah, that's the tricky bit
[20:18:27] <fuzzie> the background is going to be huge in 32bpp
[20:18:35] <fuzzie> and a bit annoying even in 16bpp
[20:18:51] <fuzzie> really you want some kind of communication about what is important (i.e. on-screen or likely to be on-screen soon)?
[20:20:26] <CIA-125> GemRB: 03tom.prince * rc1188286c397 10gemrb/gemrb/core/ (4 files in 2 dirs): Introduce Logger class, to abstract logging targets.
[20:20:39] <CIA-125> GemRB: 03tom.prince * r440b7291e2f6 10gemrb/gemrb/core/ (6 files in 3 dirs): Factor out win32 console logger.
[20:20:39] <CIA-125> GemRB: 03tom.prince * rf4e90ad8f2cb 10gemrb/gemrb/ (5 files in 2 dirs): Initialize logging explicitly.
[20:20:40] <CIA-125> GemRB: 03tom.prince * re2e91057b15c 10gemrb/gemrb/core/System/Logger/ (Stdio.cpp Stdio.h Win32Console.cpp Win32Console.h): Make NOCOLOR controllable (in-principle) at runtime
[20:20:43] <CIA-125> GemRB: 03tom.prince * r15632dcb788f 10gemrb/gemrb/ (13 files in 4 dirs): Merge branch 'logging'
[20:20:43] <CIA-125> GemRB: 03tom.prince * r541c4a3aa478 10gemrb/gemrb/core/ (6 files in 3 dirs):
[20:20:43] <CIA-125> GemRB: Make base Logger class abstract.
[20:20:43] <CIA-125> GemRB: This factors out the common parts of stdio and win32 logging.
[20:20:43] <CIA-125> GemRB: 03tom.prince * r1092dc1f6791 10gemrb/gemrb/core/ (7 files in 3 dirs): Factor out android logging.
[20:21:26] <brad_a> im not sure if its possible, but since the problem is ensuring lines//boxes/etc are drawn after the backbuffer is rnedered, is it possible to have 2 drawing contexts? then send them to the renderer in the proper order?
[20:21:56] <tomprince> Well, don't you have control of that.
[20:22:15] <brad_a> im sure i do i jsut dont know much about opengl or even sdl
[20:22:26] <fuzzie> basically, no
[20:22:28] <tomprince> I wonder if the driver should keep a cache of hardware textures that have been displayed recently.
[20:22:39] <fuzzie> and besides we want to render things on top of the boxes
[20:22:40] <brad_a> i googled a bit but i am probably using the wrong termanology or something
[20:22:42] <tomprince> And regenerate them as needed.
[20:22:59] <brad_a> we do want to render stuff on top of the boxes?
[20:23:24] <fuzzie> brad_a: e.g. the floating GUI in pst
[20:23:45] <fuzzie> i mean, i don't know if we actually do
[20:23:47] <brad_a> well i have no idea what you are talking about since i havent played pst :) but it was probably a silly idea anyway
[20:23:53] <fuzzie> right now i seem to remember we're really bad at clipping, but that could be fixed
[20:27:34] <brad_a> the only methods that i have working currently are: 1. setting disp = SDL_GetWindowSurface in every function that blits to it and 2. instead of blitting to disp/backbuffer convert to texture and send to renderer then destroy texture
[20:28:06] <brad_a> 1. means no opengl drawing for boxe/lines/etc
[20:28:14] <brad_a> 2. is stupid wasteful
[20:28:24] <tomprince> brad_a: Are you trying to factor as you go along?
[20:28:53] <tomprince> It wouldn't suprise me if rewriting, and then factoring afterwards might be easier.
[20:29:08] <brad_a> i have only factored a bit. since i dont know much about graphics libraries its a bit hard to factor things
[20:29:48] <tomprince> Also, can you use a verision before they drop 1.2 compatability to migrate piecemeal?
[20:30:09] <brad_a> the thing i was going to do was use sdl_texture for sprites but apparently there is some pixel manipulation in the way
[20:30:29] <brad_a> and thats waht im doing now. i have the latest version before they droped that + some back ported fixes
[20:30:29] <fuzzie> well, BAM will force you to use surfaces anyway
[20:31:20] <brad_a> well that wouldnt be hard since create bam sprite can jsut always do a surface
[20:32:05] <brad_a> i will have to do some reasearch and learn more about gemrb internals before i can do a good refactoring
[20:35:25] <brad_a> ok here is a thought that may not make sense
[20:36:40] <brad_a> what if i jsut keep blitting to backbuffer until one of the opengl methods is called then convert what has been done to a texture and push it out and reset backbuff to empty?
[20:36:51] <fuzzie> i think you will probably go mad trying to do this kind of thing
[20:36:58] <brad_a> he he
[20:47:23] <lynxlynxlynx> i don't say this often enough, but i think you're all doing a great job
[20:47:43] <tomprince> :)
[20:47:50] <tomprince> I'll second that sentiment.
[20:47:54] <brad_a> i agree. I think everybody has done some tremendous work the pats feew weeks
[20:59:16] <brad_a> i am at least fairly certain cursors can and should be textures :)
[20:59:38] <fuzzie> yes, and those *do* have to be on top, right?
[20:59:46] <fuzzie> so that is a nice special-case
[20:59:59] <brad_a> no that i know of
[21:00:08] <brad_a> and it is easy to do
[21:01:02] <brad_a> shouldnt anything that is recyclable like that be a texture ideally?
[21:01:13] <brad_a> so like our font spritemap
[21:03:54] <brad_a> i guess palettes kinda mess with taht
[21:04:16] <fuzzie> yeah
[21:04:32] <fuzzie> i hear things mumbled about shaders for rendering paletted textures nicely
[21:04:54] <brad_a> that sounds promising
[21:05:01] <fuzzie> probably not for SDL :/
[21:05:24] <brad_a> well i want to say you can combine pure opengl with sdl 2
[21:05:58] <fuzzie> unless they do it, of course, but I don't see any way to set a palette on a texture at a glance
[21:23:51] <brad_a> is my understanding of this "extra" surface that it is just a screen sized rectangle of some semitransparent fill color?
[21:24:46] <brad_a> i mean vewport sized
[21:25:22] <fuzzie> yes
[21:25:36] <fuzzie> if you can fade in e.g. hardware, you don't need it
[21:25:55] <brad_a> yes :)
[21:26:10] <brad_a> well i can do a semi transparent rect anyway
[21:26:59] <brad_a> wouldnt SDL_FillREct have worked for this tho?
[21:28:29] <fuzzie> yes i don't see what we're doing
[21:31:04] <brad_a> i may not understand. im pretty sure its jsut "overlaying" a semi-transparent color over the viewport
[21:38:19] <lynxlynxlynx> maybe for the modal window "effect"?
[21:38:49] <fuzzie> i assume because doing the fill once and then blitting the result is faster
[21:39:00] <brad_a> ah yes. that makes sense
[21:43:14] <wjp> that code/construction is also ancient, so I wouldn't make too many assumptions about it... :/
[22:08:40] --> gfamt has joined #gemrb
[22:09:10] <gfamt> When compiling the engine, how do I disable the openal component?
[22:09:27] <brad_a> you dont need to
[22:09:43] <fuzzie> well, if it fails to build we'd like to know about it..
[22:10:14] <gfamt> It does not recognize my openal installation, and I figured I don't really need sound.
[22:10:38] <brad_a> if it doesnt recognize it it wont try to build it...
[22:10:40] <brad_a> right?
[22:11:21] <gfamt> cmake configures fine, but it reaches a lot of errors when actually trying to compile it.
[22:11:26] <fuzzie> ah
[22:11:47] <fuzzie> well we'd appreciate a look at the errors (paste.debian.net) to see if we can look into it
[22:12:09] <gfamt> O.k.
[22:12:10] <fuzzie> but i assume you can sabotage it..
[22:12:16] <brad_a> well just disable werror or whatever and the compile should continue and you just wont have the openal plugin.
[22:12:41] <gfamt> How do I disable it? I do not have much experience with cmake.
[22:12:59] <brad_a> im saying the wrong thing anyway
[22:13:28] <fuzzie> that is a good question
[22:13:40] <brad_a> indeed
[22:14:02] <lynxlynxlynx> really, we'd like to see the cmake and compile output
[22:14:23] <fuzzie> but if you edit gemrb/plugins/CMakeLists.txt then you can just remove the openal line
[22:14:39] <fuzzie> which is brute-force but a simple immediate solution
[22:15:49] <brad_a> prolly has something to do with sdl :P
[22:33:09] --> lostLinSoul has joined #gemrb
[22:34:28] <lostLinSoul> Does anyone know why branwen and prism die when I enter their respective maps?
[22:35:16] <fuzzie> for the first time?
[22:36:01] <lostLinSoul> anytime...if I relad and enter the map again they die before any of the map is uncovered...
[22:36:19] <lostLinSoul> relad->reload
[22:37:02] --> kalimann has joined #gemrb
[22:38:44] <fuzzie> hm, i don't know, i thought branwen at least was known to be fine
[22:39:13] <kalimann> is there a way to make a pinch kind of zoom feature in gemrb?
[22:39:36] <lostLinSoul> If I try entering those map when playing in WINE, they do not die...
[22:41:07] <brad_a> kalimann: no, but if small text is your problem that can be solved.
[22:41:49] <kalimann> no its not small text, just convenience (:
[22:41:58] <kalimann> maybe its something thatll get implemented in the future?
[22:42:11] <brad_a> no likely
[22:42:19] <brad_a> not likely
[22:42:25] <kalimann> awww :(
[22:42:41] <kalimann> its difficult code?
[22:43:22] <brad_a> yes difficult and not worthwhile
[22:43:24] <fuzzie> it would be pretty painful to do, I think
[22:43:47] <brad_a> these games cant really effectively be played on a small screen even with a zoom feature
[22:43:49] <fuzzie> we'd prefer to just extend things so that it's less annoying to play
[22:44:14] <fuzzie> brad_a: well the dpi on devices is annoying too
[22:44:23] <lynxlynxlynx> lostLinSoul: version info
[22:44:56] <brad_a> the dpi may not be a problem with SDL 2
[22:44:59] <kalimann> you sure? i think a zoom would be pretty ideal... is there any alternative to when its difficult to hit precisely?
[22:45:24] <brad_a> zoom isn't going to happen. sorry. :)
[22:45:32] <lynxlynxlynx> btw, someone did already implement zoom
[22:45:40] <lynxlynxlynx> for his custom port to one of the real linux phones
[22:45:57] <brad_a> o_O
[22:45:59] <kalimann> is it possible to use his zoom thingie?
[22:46:14] <brad_a> well we dont have it for one
[22:46:28] <lynxlynxlynx> http://www.youtube.com/watch?v=Ru-m2BGrnsc
[22:46:33] <fuzzie> it's not a good zoom :p
[22:46:54] <fuzzie> brad_a: well, either you zoom or it's annoying at high dpi
[22:47:43] <fuzzie> but the naive pixel-doubling approach needs 1280x960 which is iPad 3 territory, so ugh
[22:47:57] <kalimann> aww i just read from a comment from the video that its not possible to use keyboard?
[22:48:11] <kalimann> how do i enter a name?
[22:48:12] <fuzzie> it isn't?
[22:48:30] <fuzzie> you should have an overlay button to display keyboard, by default, no?
[22:48:35] <fuzzie> if you have no hardware keyboard
[22:48:44] <brad_a> what os for starters?
[22:49:07] <fuzzie> well I am assuming on iphone it does auto-popup anywhere relevant :p
[22:49:21] <brad_a> yes
[22:49:29] <kalimann> droid ics
[22:49:45] <brad_a> there is code for andoid to show the soft keyboard too tho...
[22:50:14] <brad_a> SDL_ANDROID_SetScreenKeyboardShown(1);
[22:50:44] <brad_a> i guess that doesnt always work? or maybe it requires sdl higher than 1.2
[22:50:56] <brad_a> oh
[22:51:09] <brad_a> actually try setting UseSoftKeyboard in your config file
[22:51:46] <brad_a> it would be silly if the android port jsut doesnt have that set by default in their config
[22:52:22] <brad_a> that should be UseSoftKeyboard=1 if it wasn't obvious :-P
[22:52:58] <lostLinSoul> After what you said I did a bit more playing around and it seems that 2 chickens die when I enter the carnival map now, but branwen does not. Maybe it was because I loaded a savegame from WINE...
[22:56:06] <fuzzie> and it is a recent version of gemrb?
[22:56:18] <lostLinSoul> Yes
[22:56:50] <lostLinSoul> Though not from git, it was the last 0.7.0 release
[23:00:22] <lynxlynxlynx> how old is the save?
[23:00:27] <lostLinSoul> Prism still dies however...
[23:00:41] <lynxlynxlynx> if it is from before 0.7, then it is a known bug
[23:01:21] <lostLinSoul> No it is 0.7.0
[23:02:53] <lynxlynxlynx> you entered the area the first time with 0.7?
[23:02:55] <lostLinSoul> must have been beause it was a save from loaded from a WINE save. If I use that save file she dies...
[23:03:07] <lostLinSoul> Yes
[23:03:19] <lynxlynxlynx> ok, let's blame the difference then
[23:03:49] <lostLinSoul> I prism a known problem?
[23:04:11] <lostLinSoul> Sorry, having finger trouble....
[23:04:24] <lostLinSoul> Is Prism a known problem?
[23:06:53] <kalimann> i put the UseSoftKeyboard command in my cfg file, what is it supposed to do once im in gemrb?
[23:12:50] <brad_a> well when creating a character a keyboard should come up when you need to enter a name
[23:12:56] <brad_a> on android not much else
[23:13:08] <lostLinSoul> I've also been fiddling with enlarging party size. Is there any way to stop loading a savegame with a party larger than 6 from taking me straight to the reform party screen?
[23:13:12] <kalimann> there aint..
[23:14:07] <brad_a> hopefully the android situaltion will imporve significantly after i finish this sdl 2 driver
[23:14:21] <brad_a> you will at least get multi touch input
[23:15:38] <lynxlynxlynx> stuff dying on load is probably related to hp adjustments
[23:16:02] <lynxlynxlynx> gemrb vs gemrb should be consistent now, but i didn't test vs the original
[23:16:22] <lynxlynxlynx> so stuff with minimal hp and horrible constitution can just die
[23:17:44] <lostLinSoul> @lynxlynxlynx - what do you mean by gemrb vs gemrb?
[23:18:06] <lynxlynxlynx> gemrb saves
[23:18:31] <lostLinSoul> I have not been into the nashkel mines area before, so it is a first...
[23:19:05] <fuzzie> re party size: it is not too difficult to do in theory, but you'd have to fix an awful lot of game scripts to actually play like that, so no-one's very motivated
[23:21:18] <lynxlynxlynx> if you create a save right before entering the mine for the first time, i can take a look
[23:21:54] <lostLinSoul> Well I've been using the console commands, to test it out, but the problem is the reform party on reload...
[23:25:37] <lynxlynxlynx> there are much more problems like fuzzie says
[23:26:01] <lynxlynxlynx> besides the scripts breakage, which wouldn't be immediately apparent, you lack portrait slots
[23:26:52] <-- kalimann has left IRC (Quit: Page closed)
[23:26:53] <lynxlynxlynx> but if you want to fix it properly, we're here to offer help and advice :)
[23:28:39] <lostLinSoul> ...thanks, but it would be a bit much for me...
[23:30:16] <lostLinSoul> @lynxlynxlynx - I tried a new game and used Ctrl-J to get to the edge of the maps and move to the next area, when I reached the map with prism on it as soon as I entered the map he died!
[23:31:01] <lynxlynxlynx> like i said, i'll need a save
[23:31:11] <lynxlynxlynx> and info on any mods you have installed
[23:31:38] <lostLinSoul> Where do I send it? I am using the web chat
[23:32:07] <lostLinSoul> Would a Weidu log file suffice?
[23:33:50] --> kalimann has joined #gemrb
[23:34:43] <lostLinSoul> Also do you just want the .gam file or the whole save folder?
[23:36:34] <kalimann> is there any easy way to handle the scrolling on the maps?
[23:44:23] <lynxlynxlynx> whole folder, zip it up
[23:44:38] <lynxlynxlynx> upload it somewhere if you can otherwise mail will do
[23:44:50] <lynxlynxlynx> my nick @ sourcemage.org
[23:45:03] <lynxlynxlynx> weidu log too
[23:50:38] <-- kalimann has left IRC (Quit: Page closed)
[23:51:40] <brad_a> kalimann: either you have to get an iPAd or wait till the SDL 2 driver is done :)
[23:58:05] <lynxlynxlynx> we don't have the touch borders anymore?