#gemrb@irc.freenode.net logs for 25 Feb 2012 (GMT)

Archive Today Yesterday Tomorrow
GemRB homepage


[00:12:59] <-- Yoshimo has left IRC (Quit: Yoshimo)
[00:19:35] <-- SiENcE has left IRC (Ping timeout: 240 seconds)
[00:27:22] <-- brad_a has left IRC (Quit: brad_a)
[02:06:23] --> brad_a has joined #gemrb
[02:37:58] <-- edheldil_ has left IRC (Ping timeout: 245 seconds)
[02:53:42] --> edheldil_ has joined #gemrb
[03:01:13] <tomprince> I just saw this linked: http://software.intel.com/en-us/articles/intel-c-compiler-for-windows-compatibility-with-microsoft-visual-c-60/#2
[03:02:25] <brad_a> i was actually wondering why that very thing couldnt be done
[03:05:34] <tomprince> Well, it'd have to be something the generates the proper debug info. I'll admit I never considered the intell compiler.
[03:05:44] <tomprince> I don't think gcc generates the right debug info.
[03:07:08] <brad_a> what debug format does avenger need?
[03:07:25] <tomprince> Whatever it is that msvc6 expects.
[03:09:15] <-- brad_a has left IRC (Quit: brad_a)
[03:12:42] <lostLinSoul> Is it possible to figure out what resolution GemRB.LoadWindowPack() was called with, in code?
[03:18:38] <tomprince> At what point?
[03:18:48] <-- edheldil_ has left IRC (Ping timeout: 245 seconds)
[03:19:00] <lostLinSoul> In python GUI scripts
[03:19:52] <tomprince> It looks like that info is discared, and only used for a sanity check.,
[03:22:15] <lostLinSoul> Hmm, does that mean that i'll have to do special code for party portraits of inventry screen in GUICommonWindows then?
[03:23:54] <lostLinSoul> hardcoding for inventry screen? It never seem to scale with the game window, along with map screen spell screen, etc. in BGT
[03:25:04] <lostLinSoul> k
[03:25:19] <lostLinSoul> whoops, wrong window
[03:32:53] <-- lostLinSoul has left IRC (Quit: Page closed)
[03:37:34] <-- kida_laptop has left IRC (Ping timeout: 252 seconds)
[03:47:32] <tomprince> All the graphics are of fixed size.
[03:48:34] <tomprince> The widescreen mod works by replecating parts of the interface, to stretch it out. But hat only works easily for things that are repeatative/simple enough to just copy bits of.
[04:36:11] --> Gekz has joined #gemrb
[04:38:52] <-- Kiranos has left IRC (Read error: Connection reset by peer)
[04:39:03] --> Kiranos has joined #gemrb
[04:59:35] <-- gembot has left IRC (Ping timeout: 240 seconds)
[05:13:13] --> gembot has joined #gemrb
[06:20:06] --> kida_laptop has joined #gemrb
[06:37:20] <-- kida_laptop has left IRC (Ping timeout: 255 seconds)
[07:17:54] --> edheldil_ has joined #gemrb
[07:25:29] <-- edheldil_ has left IRC (Ping timeout: 244 seconds)
[08:57:05] --> Yoshimo has joined #gemrb
[09:25:57] --> alx3apps has joined #gemrb
[10:59:11] --> SiENcE has joined #gemrb
[12:56:55] <-- wrotek has left IRC (Ping timeout: 240 seconds)
[13:13:26] --> wrotek has joined #gemrb
[13:58:40] <wjp> can someone explain the current github situation?
[13:59:06] <fuzzie> is there one?
[13:59:12] <fuzzie> oh, you mean for gemrb
[13:59:17] <wjp> there's definitely a situation :-)
[14:00:01] <wjp> I thought I'd push my blitter branch somewhere public, but...
[14:00:03] <fuzzie> tomprince is waiting for github to support rerooting fork trees onto unrelated repos so that everything can be re-rooted on the mirror, I think
[14:00:14] <wjp> but the mirror is -old?
[14:00:36] <fuzzie> yes, that was *me*, just moving it out the way so that I could move my repository to be under the control of the github organisation
[14:00:55] <fuzzie> so feel free to rearrange as desired
[14:02:04] <fuzzie> my upstairs neighbours seem to have decided not to answer the doorbell after playing loud music since 9am, so I am sitting here grumping and failing to get much done
[14:02:45] <wjp> hrm :/
[14:05:36] * wjp ponders finishing up the non-RLE part of this new templated version of the sprite renderer
[14:05:52] <fuzzie> would be really nice to have something more readable..
[14:06:24] <wjp> https://github.com/wjp/gemrb/blob/170bbfe940e37195f4fe5abce4bab780fe64248e/gemrb/plugins/SDLVideo/SpriteRenderer.inl
[14:06:33] <wjp> ignore the huge blob of random notes at the top :-)
[14:08:05] <wjp> hm, also still have some random broken clipping experiments in there it seems (#if 0'ed out)
[14:09:18] <fuzzie> the _Cond naming confuses me
[14:09:46] <wjp> any alternative suggestions?
[14:09:48] <fuzzie> SRTinter_Cond::operator() adjusts params but SRShadow_Cond() does something else?
[14:10:00] <wjp> let me see
[14:10:23] <fuzzie> oh I see, they're completely different things
[14:10:27] <wjp> yes
[14:10:42] <fuzzie> i would say _Flags if they're flags-based
[14:10:52] <wjp> makes sense
[14:11:09] <wjp> the rendering pipeline is split up into shadow, tint and blend, each with its own functor
[14:11:17] <wjp> some variants are hardcoded, some flag-based
[14:11:38] <fuzzie> the *32 variants are used somewhere?
[14:12:13] <fuzzie> except, ooh, ouch, the flags aren't constants?
[14:12:56] <wjp> it's only 32bpp at the moment
[14:13:05] <wjp> yes, the flags aren't constant
[14:13:33] <fuzzie> i figured you were passing them as template params somewhere
[14:13:42] <wjp> (that's the same in the current cpp black magic, by the way)
[14:13:51] <fuzzie> ah, okay
[14:13:52] <wjp> the "common" flag combinations are handled like that
[14:13:58] <fuzzie> i thought they were high-level, sorry
[14:14:04] <fuzzie> if they're in the inner loop right now then fine
[14:14:29] <wjp> but to prevent complete combinatorial explosion, some cases go to the fallback check-every-flag-in-the-inner-loop code
[14:15:05] <fuzzie> right, just presumably the check-in-the-inner-loop case will be painful
[14:15:10] <wjp> yes
[14:16:02] <wjp> every once in a while we should re-evaluate which flag combinations are rare enough to get away with it
[14:16:41] <fuzzie> presumably it would be easy enough to profile the obvious cases
[14:17:26] <wjp> I did some analysis of common cases back in 2006 when I wrote the current version, but it might just be outdated a bit...
[14:17:41] <fuzzie> i think "it looks oh so much more readable at a glance" is an obvious plus though
[14:18:14] <wjp> the two big gaps are non-RLE and support for something else than my pixel format :-)
[14:18:45] <wjp> the former is just a matter of implementing it, the latter... well...
[14:19:36] <fuzzie> it is a bit frustrating how 16bpp had become completely irrelevant
[14:19:45] <wjp> my cunning plan was to ignore it long enough for the world to move entirely to 32 bpp :-)
[14:19:45] <fuzzie> and then mobile hardware has made it relevant again
[14:19:49] <wjp> right :-)
[14:20:20] <wjp> is there any consensus on pixel format, at least?
[14:20:28] <fuzzie> 565
[14:20:46] <wjp> with nothing LE/BE-specific?
[14:21:05] <fuzzie> not other than treating as uint16*, no
[14:21:14] <wjp> well, that's something
[14:21:22] <fuzzie> *some* hw supports 5551 and *some* supports 4444, but i assume we can ignore alpha
[14:21:54] <wjp> it'd make things a lot easier if we can just hardcode 16bpp to 565
[14:22:04] <fuzzie> it sounds fine to me
[14:22:08] --> edheldil_ has joined #gemrb
[14:22:53] <fuzzie> presumably you could even make 16bpp/32bpp a compile-time setting, really
[14:23:09] <wjp> how is the LE/BE situation in 32bpp?
[14:23:41] <fuzzie> again, fine if you treat as uint32*
[14:24:06] <wjp> good
[14:24:17] <fuzzie> *not* fine for direct byte access of course :)
[14:24:23] <fuzzie> but I haven't tested on BE for a while
[14:25:32] <fuzzie> the interesting target would be the Wii, but probably we don't run on it due to RAM usage
[14:26:05] * wjp has strange visions of people trying to control BG2 with a wiimote
[14:26:07] <fuzzie> but all the popular mobile stuff is armel
[14:28:47] <wjp> the SDLVideo object file isn't even the largest yet, so I guess there's some room for another factor 2 for the RLE stuff :-)
[14:29:27] <fuzzie> well, probably the blitter code explosion isn't particularly painful
[14:29:39] <fuzzie> since for performance all you really want is the code for the current blit in the cache
[14:30:43] <wjp> another few factors 2 will start to significantly blow up the final binary size though...
[14:31:00] <fuzzie> how big *is* it, stripped? :)
[14:31:15] <fuzzie> really shouldn't be that significant
[14:31:28] <wjp> yeah, not yet
[14:31:32] <wjp> around 100k
[14:59:39] --> kida_laptop has joined #gemrb
[15:20:18] <-- edheldil_ has left IRC (Ping timeout: 244 seconds)
[16:01:00] <wjp> http://www.usecode.org/gemrb/clip.png
[16:01:03] <wjp> not quite there yet ;-)
[16:24:19] <-- Gekz has left IRC (Ping timeout: 276 seconds)
[16:27:33] <fuzzie> hehe
[16:29:53] --> edheldil_ has joined #gemrb
[16:55:55] <-- SiENcE has left IRC (Read error: Connection reset by peer)
[16:57:26] --> SiENcE has joined #gemrb
[17:17:20] <CIA-28> GemRB: 03avenger_teambg * r000654dae701 10gemrb/gemrb/ (8 files in 8 dirs): rare action sounds option (for pst)
[17:17:21] <CIA-28> GemRB: 03avenger_teambg * rb820c59f2532 10gemrb/gemrb/core/ (GUI/GameControl.cpp Scriptable/Actor.cpp): play command sounds, use rare action sounds flag
[17:22:10] <CIA-28> GemRB: 03avenger_teambg * rcecba723a8b9 10gemrb/gemrb/ (3 files in 2 dirs): actor.cpp::update the variables depending on feedback settings
[17:33:59] --> brad_a has joined #gemrb
[17:37:16] <brad_a> whats the standard way in c++ for a constructor to fail?
[17:37:48] <brad_a> by fail i mean in my object something the object depends on utterly failed and the object would be useless
[17:38:35] <brad_a> id say maybe an exception but gemrb doesnt seem to use those :)
[17:40:38] <fuzzie> yeah
[17:40:40] <fuzzie> define 'failed'..
[17:40:51] <fuzzie> i mean, without exceptions you abort()
[17:41:04] <fuzzie> is the right answer, probably
[17:41:17] <tomprince> Yes.
[17:41:41] <brad_a> well im rewriting TTF to use freetype directly. and if freetype init failed the TTF importer is useless so how do i relay that information etc? currently we just ignore it
[17:41:59] <brad_a> but that shouldnt cause a catostrophic program failure :)
[17:42:06] <fuzzie> don't do the work in the constructor.
[17:42:32] <brad_a> fair enough
[17:42:57] <brad_a> im clearly too used to being able to return nil from initializers ;-)
[17:43:29] <fuzzie> the C++ exceptions situation is amazingly ridiculous, *still*.
[17:43:43] <brad_a> sad story
[17:44:09] <fuzzie> how are you building for iphone, gcc or clang?
[17:44:13] <brad_a> clang
[17:44:18] <fuzzie> so yeah, not good idea :)
[17:44:29] <brad_a> exceptions you mean?
[17:44:42] <brad_a> clang 3.0 if that makes a diffrence :)
[17:46:01] <fuzzie> clang still emits setjump/longjump(!) based exceptions
[17:47:01] <fuzzie> pelya's repository seems to do -fexceptions for android though, which I guess makes sense, since our use of the STL means you have to statically link a whole C++ library anyway.
[17:47:04] <brad_a> emits or omits?
[17:47:06] <fuzzie> emits
[17:47:27] <fuzzie> as opposed to some modern exception handling technique I mean :)
[17:48:02] <fuzzie> there were some signs of life in the bug [#7187 - Add zero-cost exceptions for ARM (EHABI)] but it's sort of died again
[17:48:33] <fuzzie> but anyway doing this kind of thing in the constructor is a very bad idea
[17:48:48] <brad_a> thats why i asked
[17:48:49] <fuzzie> am sure we could enable exceptions if we really needed, but hopefully not
[17:49:10] <tomprince> That is why we often have a free or static function, that returns NULL on failure, rather than calling the constructor directly.
[17:49:22] <brad_a> i can just init and destroy freetype in TTF::open
[17:49:40] <fuzzie> well, or you can do it in the plugin startup code?
[17:49:48] <tomprince> That is what I was thinking, too.
[17:49:59] <brad_a> tell me how :)
[17:50:22] <fuzzie> although we can't actually force the plugin load to fail from there? which would be nicest.
[17:50:31] <brad_a> indeed
[17:51:11] <fuzzie> tomprince is much better at this but there's PLUGIN_INITIALIZER and PLUGIN_CLEANUP macros
[17:52:00] <fuzzie> and you pass them void functions and they get called at plugin init and shutdown respectively
[17:52:04] <tomprince> There is no way to make the plugin load to fail, with the current macros.
[17:52:42] <tomprince> And, I guess no way that works with static linking.
[17:52:49] <fuzzie> ah right.
[17:52:53] <brad_a> heh
[17:52:59] <fuzzie> and, well, is that true?
[17:53:07] <fuzzie> I mean, you don't actually have to unload the underlying .so.
[17:53:17] <fuzzie> You'd just want to sabotage the PLUGIN_CLASS.
[17:53:56] <fuzzie> in fact I suppose you could simply not *have* a PLUGIN_CLASS, and just call RegisterPlugin inside your initializer.
[17:54:13] <fuzzie> or, well, a PLUGIN_RESOURCE here apparently.
[17:54:42] <tomprince> That would work, yes.
[17:54:56] <fuzzie> so: I think that is what I would advocate here myself :)
[17:55:21] <tomprince> Under what conditions can freetype fail to initialize?
[17:55:43] <fuzzie> of course that is also a very good questin :-)
[17:56:09] <tomprince> If it is exceptional enough, it might be reasonable to just abort.
[17:57:07] <brad_a> ˙it should be pretty exceptional
[17:57:10] <fuzzie> If this is just FT_Init_FreeType then the source makes it look spectacularly exceptional.
[17:57:25] <-- SiENcE has left IRC (Quit: cya)
[17:57:38] <fuzzie> Looks like it fails only if it was built incorrectly or if it has no memory at all.
[17:58:40] <brad_a> sounds about right
[17:59:51] <brad_a> heh i neglected to call ttf_closeFont after finishing with the font
[18:00:53] <tomprince> So: init in an PLUGIN_INITIALIZER and error on error.
[18:02:15] <brad_a> how do i cleanup?
[18:02:19] <brad_a> oh nevermind
[18:02:24] <brad_a> i see plugin_cleanup
[18:05:07] <brad_a> wait
[18:05:44] <brad_a> FT_Init_FreeType expects a parameter that i currently have as an ivar
[18:06:14] <brad_a> the FT library object that i need for all the interaction with FT :)
[18:07:20] <tomprince> Well, so what do you now, if somebody loads multiple ttf fonts?
[18:07:28] <tomprince> Or is it static?
[18:09:04] <brad_a> i believe we get to use the same one no matter the font
[18:09:27] <tomprince> In any case, it probably wants to be, so might as well make it global. Or make the init/cleanup functions static members.
[18:09:35] <brad_a> unless we want to use FT on multiple threads :D
[18:09:58] <tomprince> No.
[18:10:02] <tomprince> No.
[18:10:03] <tomprince> No.
[18:10:06] <tomprince> :)
[18:10:19] <fuzzie> But threads are *fun*.
[18:11:21] <tomprince> df style fun, which we don't want in our code. :)
[18:13:39] --> lynxlynxlynx has joined #gemrb
[18:13:39] <-- lynxlynxlynx has left IRC (Changing host)
[18:13:39] --> lynxlynxlynx has joined #gemrb
[18:13:39] --- ChanServ gives channel operator status to lynxlynxlynx
[18:30:40] <-- edheldil has left IRC (Remote host closed the connection)
[18:39:18] <-- edheldil_ has left IRC (Ping timeout: 260 seconds)
[18:44:59] <tomprince> I'll psot this again: http://titanpad.com/LHPyb9r96s <--- code style guidelines draft
[18:47:52] <fuzzie> well I think some of us are hardly likely to object :p
[18:48:25] <fuzzie> I guess red one is lynx?
[18:48:37] <fuzzie> also I think people liked m_ better than _
[18:48:48] <tomprince> Yes.
[18:52:06] <tomprince> Just _ is the python convention.
[18:53:05] <fuzzie> well obviously I am very used to it in C++ at this point..
[18:53:33] <fuzzie> so I don't have an unbiased view
[18:53:51] <tomprince> Just _?
[18:54:06] <fuzzie> yes, since all scummvm code is _memberName
[18:54:10] --> Gekz has joined #gemrb
[18:54:10] <-- Gekz has left IRC (Changing host)
[18:54:10] --> Gekz has joined #gemrb
[18:54:11] * tomprince summons Avenger
[18:54:39] --> haad has joined #gemrb
[18:59:04] <brad_a> so im trying to use FT_stream with our DataStream. it expects me to give if function pointers for stream manipulation. how could i give it what it wants?
[18:59:43] <-- Gekz has left IRC (Ping timeout: 260 seconds)
[18:59:45] <brad_a> just stream->Read?
[18:59:47] <tomprince> What types does it want?
[19:00:53] <fuzzie> you can presumably give it static functions, which then call the relevant function by casting whatever it gives you for user data
[19:01:07] <tomprince> Have a look at OGGReader, and if those functions haves the right type, move them elsewhere and use them.
[19:01:45] <brad_a> http://www.freetype.org/freetype2/docs/reference/ft2-system_interface.html#FT_Stream_IoFunc
[19:02:57] <tomprince> Yes, you'll have to write wrappers.
[19:03:11] <brad_a> i see
[19:07:04] <brad_a> yes i understand now
[19:08:24] <brad_a> he he all this work to rid us of a dependency :p
[19:08:38] <brad_a> oh and learning i guess :)
[19:10:35] <tomprince> Also, a cross plugin dependency.
[19:11:16] <brad_a> ah yes that too
[19:23:51] --> edheldil_ has joined #gemrb
[19:30:05] <-- brad_a has left IRC (Quit: brad_a)
[20:22:30] <-- alx3apps has left #gemrb
[20:24:34] --> Avenger has joined #gemrb
[20:24:44] --- ChanServ gives channel operator status to Avenger
[20:25:17] <Avenger> hi
[20:25:41] <wjp> hello
[20:27:04] <wjp> well, except for 16bpp I think this new templated blitter is working
[20:33:27] <tomprince> Avenger: http://titanpad.com/LHPyb9r96s
[20:39:50] <Avenger> tom, been there seen that :P
[20:39:57] <Avenger> already wrote on it too
[20:40:02] <edheldil_> Hi... Avenger, do you know how pst encodes dialog replies with lying etc?
[20:40:19] <Avenger> there is no encoding, is there?
[20:40:27] <Avenger> it is in the dialog option
[20:40:57] <Avenger> aren't we compatible ?
[20:40:59] <edheldil_> do you perhaps recall any such reply?
[20:41:11] <Avenger> no
[20:41:23] <edheldil_> ok
[20:41:28] <Avenger> i can only look for some
[20:41:41] <Avenger> i'm pretty sure ravel's dialog has at least one
[20:41:59] <Avenger> dravel.dlg
[20:42:11] <edheldil_> ok, thanks
[20:44:14] <-- lynxlynxlynx has left IRC (*.net *.split)
[20:44:14] <-- kida_laptop has left IRC (*.net *.split)
[20:44:15] <-- harijan2 has left IRC (*.net *.split)
[20:45:27] --> lynxlynxlynx has joined #gemrb
[20:45:27] --> kida_laptop has joined #gemrb
[20:45:27] --> harijan2 has joined #gemrb
[20:46:39] <Avenger> ok, found one in dgrace.dlg, node 281 :)
[20:47:23] <Avenger> it is just in the dialog text, i don't see any encoding. Is it different color, or what?
[20:48:28] <edheldil_> yes, I think it was
[20:48:46] <edheldil_> thanks for the ref, I will check
[20:57:07] <Avenger> well, we already give some alternate color for "Note:"
[20:59:56] <wjp> whee, templated blitter done
[21:00:50] <wjp> Avenger: did you mention some new effect for portrait overlays a few days ago?
[21:02:58] <Avenger> wjp i don't remember anything. To be honest, i don't even know do you mean by portrait overlay :)
[21:03:24] <Avenger> ahh, i know, the hp display
[21:04:29] <Avenger> i don't know if any of our current tints can result in the dark reddish tint you usually see in the original game portraits. The rgb value that results that is 10,0,0 (or 2,0,0)
[21:04:49] <Avenger> that 10/2 is just too little, i wonder how it causes anything discernible
[21:07:19] <wjp> our current effect looks quite a lot like the original, although maybe a bit less blood-red, doesn't it?
[21:08:01] <Avenger> yes, someone wanted it even more like original
[21:08:47] <Avenger> so i went and look at the code, but i looked only the surface, i didn't want to dig into the pixel juggler code
[21:09:26] <wjp> do you know off-hand where we draw it?
[21:10:34] <Avenger> SetHorizontalOverlay sets it, that i know
[21:10:39] <Avenger> in button.cpp
[21:12:13] <Avenger> video->DrawRect( r, SourceRGB, true ); is the actual line that changes something, i guess
[21:12:22] <Avenger> line 189
[21:13:08] <wjp> indeed
[21:13:27] <wjp> with a colour obtained from SetupDamageInfo in GUICommon.py
[21:13:47] <lynxlynxlynx> yes
[21:14:25] <Avenger> it is 2 colors given, to have a flash effect
[21:15:57] <wjp> is such a small alpha change actually visible?
[21:16:23] <wjp> hm, the original seems to have a pinch of blue in there
[21:18:01] <wjp> I'll see if I can deduce the exact formula
[21:19:11] <Avenger> no, that alpha is not visible
[21:19:26] <Avenger> i'm not sure this is the original value given by me, though
[21:19:43] <wjp> comparing screenshots, our portrait borders are quite ugly
[21:19:52] <Avenger> well
[21:19:55] <wjp> they shouldn't be just green rects
[21:20:13] <Avenger> maybe there are bitmaps we don't use
[21:22:53] <-- Avenger has left IRC (Quit: bye!)
[21:26:26] <wjp> ah, in BG1 they were plain green rects
[21:26:34] <wjp> in BG2 they are fancier
[21:27:04] <edheldil_> btw, I have checked and the highlight in pst is visually achieved by striping the red channel from a bitmap
[21:27:19] <edheldil_> stripping
[21:30:59] <wjp> that can be done with a 0,255,255 tint in our blitter
[21:33:45] <wjp> the red hitpoint overlay is also a multiplicative effect, rather than the current additive alpha blend: a 120,30,30 tint
[21:34:43] <wjp> (for future reference: I checked in some BG2 screenshots on mobygames)
[21:44:56] <edheldil_> btw, is there a problem with displaying pst avatars? FFG is ok when she moves, but when she stands her colors are wrong. And from my party only FFG exhibits this behavior
[21:53:30] <edheldil_> or is there just a 2da file I should tweak?
[22:51:04] <-- lynxlynxlynx has left IRC (Read error: Connection reset by peer)
[23:18:50] <-- Yoshimo has left IRC (Quit: Yoshimo)