#gemrb@irc.freenode.net logs for 1 Jun 2010 (GMT)

Archive Today Yesterday Tomorrow
GemRB homepage

[00:31:31] --> Gekz has joined #GemRb
[00:41:08] <Lightkey> !
[00:41:45] <Lightkey> Gekz: didn't you get what edheldil wrote?
[00:43:37] <CIA-24> GemRB: 03tom.prince * r950bd8d58c4f 10gemrb/gemrb/ (3 files in 2 dirs):
[00:43:37] <CIA-24> GemRB: TableMgr: Add function to get default value.
[00:43:37] <CIA-24> GemRB: This fixes a warning on gcc-3.4.6.
[00:43:37] <CIA-24> GemRB: Signed-off-by: Tom Prince <tom.prince@ualberta.net>
[00:49:28] <Gekz> Lightkey: nope
[00:56:40] <Lightkey> *scrollscrollscroll*
[00:58:07] <Lightkey> 09:57:14 < edheldil> Gekz: pirate party had 0.8% in general elections here :)
[00:58:19] <Gekz> where is here
[00:58:25] <Lightkey> hmm right, you were not even in the channel then
[00:58:52] <Lightkey> that was 18 hours ago
[00:59:04] <Lightkey> it is 3 am here
[01:00:45] <-- Gekz has left IRC (Quit: This computer has gone to sleep)
[01:01:36] <Lightkey> eh, 17 hours, whateva
[01:28:17] <-- barra_library has left IRC (Read error: Connection reset by peer)
[03:34:24] --> budlust has joined #GemRb
[03:34:38] <-- budlust has left #GemRb
[04:24:58] <-- CIA-24 has left IRC (Ping timeout: 265 seconds)
[04:41:56] --> CIA-24 has joined #GemRb
[05:20:11] --> raevol has joined #GemRb
[05:48:24] <-- raevol has left IRC (Quit: Leaving.)
[06:45:40] --> cubathy has joined #GemRb
[07:00:19] --> lynxlynxlynx has joined #GemRb
[07:00:19] --- ChanServ gives channel operator status to lynxlynxlynx
[07:00:35] <-- cubathy has left IRC (Ping timeout: 265 seconds)
[07:16:37] --> pupnik_ has joined #GemRb
[07:20:12] <-- pupnik has left IRC (Ping timeout: 276 seconds)
[07:32:57] --- pupnik_ is now known as pupnik
[07:52:46] <edheldil> hi all
[07:53:51] <lynxlynxlynx> oj
[08:10:56] --> Gekz has joined #GemRb
[08:43:27] <-- |Cable| has left IRC (Remote host closed the connection)
[08:47:27] <edheldil> reading the maemo thread, it's clear we need to get key map working. With a possibility to map MOUSE_ACTION (or whatever is it called) to LMB+some key
[08:48:08] <pupnik> ty ty!
[08:48:50] <fuzzie> well, it's trivial to do as long as you're happy just passing the problem off to python
[08:49:19] <pupnik> i am happy doing it myself but nicer to have it available for pandora and iphone etc upstream
[08:49:28] <fuzzie> but my patch never made the '<key>' bit appear in tooltips, and that is a lot easier to do with zefklop's idea, which is to bind keys to buttons, not python
[08:50:09] <fuzzie> but i have an exam in 3 hours so not going to look at it right now :)
[08:50:14] <edheldil> I am not, I still feel it would be too slow, but since I even have no time to turn on my comp these days, I will happily leave the implementation to whoever is willing to commit it
[08:50:40] <fuzzie> python really truly is zooooomy compared to the incredible amount of time sucked up by SDL :p
[08:51:05] <edheldil> I know ... but what about the latency? ;-)
[08:51:36] <fuzzie> :)
[08:52:34] <tomprince> Latency should be no worse than C++.
[08:52:57] <fuzzie> it is locked to frames anyway
[08:53:12] <fuzzie> the silly event processing order is a bigger problem there imo, as discussed a few weeks ago
[08:53:31] <edheldil> I have probably missed that discussion
[08:53:59] <fuzzie> i had to seperate that out anyway to make opengl-on-sdl work, must check if it helps
[08:54:19] <fuzzie> anyone want to take a Complexity exam for me so i can hack on gemrb instead? :)
[08:55:03] <edheldil> I am, but that you could just skip it for some GemRB hacking and the results would be the same :)
[08:55:13] <edheldil> s/that/then/
[08:55:20] <fuzzie> especially since it is in Dutch :( wjp should do it, i suppose
[08:56:05] <wjp> hm?
[08:56:10] <wjp> ah, no thanks :-)
[08:58:02] <fuzzie> but my initial experiment with opengl just basically overrid the relevant functions on SDLVideo
[08:58:24] <fuzzie> so i could let it deal with events, etc
[08:59:03] <fuzzie> i guess more sensible would be a base class SDLDriver or something
[08:59:55] <tomprince> Or split it into two parts?
[09:01:09] <tomprince> Hava an input and an video driver perhaps?
[09:01:15] <fuzzie> well, you can't do that cleanly
[09:01:48] <fuzzie> because they're not independent of each other
[09:02:12] <fuzzie> but you think of two classes which can only be used together?
[09:03:32] <fuzzie> hm, i guess gemrb is so simple that they're really not intertwined, but still, one of them is going to have to have 'ownership' of the SDL context
[09:04:01] <fuzzie> and same for any other backends i can think of
[09:04:20] <tomprince> That wouldn't be entirely unreasonable. At least, you seemed to be suggesting that OpenGL would want to reuse the SDL input handling, or somesuch.
[09:04:29] <tomprince> Although, maybe I misunderstood.
[09:04:56] <fuzzie> well, something has to do the window setup for OpenGL
[09:05:11] <fuzzie> one solution for that on some platforms is just to let SDL do it, yes :)
[09:05:37] <fuzzie> but you also have to call into SDL to do the fiddly things like changing resolution, going fullscreen, etc, so there's no clean seperation
[09:06:14] <tomprince> What one could do is have a private object that owns the SDL context, and have both driver objects hold a reference to it.
[09:06:50] <fuzzie> so you can't just have some SDLInput and then OpenGLVideo/SDLVideo, the opengl code still needs some SDL code
[09:08:11] <fuzzie> maybe a SDLDriver which manages input, the context and fullscreen/resolution/etc and an SDLVideo which depends on it? but then it seems you might as well be subclassing, really :)
[09:08:26] <tomprince> Well, in that case perhaps a common base class makes sense.
[09:09:22] <fuzzie> i was thinking of using multiple inheritance to just produce an SDLOpenGLVideo
[09:10:17] <tomprince> Multiple Inheritance?
[09:11:19] <fuzzie> SDLDriver + OpenGLDriver -> SDLOpenGLVideo
[09:12:03] <fuzzie> so you could just replace the SDLDriver in the class hierarchy with the platform specifics, and get an opengl driver for a new platform
[09:12:14] <fuzzie> i am not sure how viable this is in reality, given OpenGL ES is weird
[09:14:40] <fuzzie> (obviously OpenALAudio is quietly dependant on SDL too, but that is an easy fix)
[09:42:05] <wjp> hm, right, mutexes
[09:43:56] <-- pupnik has left IRC (Quit: leaving)
[09:51:40] <fuzzie> i think openal maybe isn't a realistic option for embedded devices anyway
[10:03:48] <fuzzie> i guess pupnik might be the one to ask, although maemo devices maybe all do VFP, which has got to help
[11:30:44] <edheldil> as I understand the thread, the sound with openal on n900 is ok
[11:33:07] <fuzzie> it slowed things down terribly on the n810
[11:34:23] <fuzzie> and my experience is that the newest openal soft is much worse for that, but i don't know if anyone has built that for maemo at all
[11:34:40] <-- Gekz has left IRC (Changing host)
[11:34:40] --> Gekz has joined #GemRb
[12:00:44] <edheldil> any comments on PP, Gekz? ;-)
[12:00:52] <Gekz> busy as all fuck
[12:00:53] <Gekz> no time
[12:00:54] <Gekz> NO TIME
[12:00:56] <Gekz> java assignment
[12:42:32] --> Maighstir|work has joined #GemRb
[13:11:47] <edheldil> Maighstir|work: the feature of using $0.cfg was from the beginning in #ifndef WIN32 block
[13:12:30] <edheldil> because I doubted it would work on windows, or st. like that
[13:42:27] <Maighstir|work> ah, I probably remembered wrongly, in that case
[13:54:11] <-- Maighstir|work has left IRC (Quit: Page closed)
[15:36:55] --> kettuz has joined #GemRb
[16:20:57] <CIA-24> GemRB: 03avenger_teambg * r3807e13361dc 10win32/MSVC6/GemRB/ (10 files in 5 dirs): new msvc6 project files after explosion of ACMImporter
[16:25:22] <tomprince> :`(
[16:29:42] <fuzzie> does cmake really produce good project files?
[16:30:12] <tomprince> I don't know about *good*, since I don't know what good is in the context, but it does produce working ones.
[16:30:29] <tomprince> With proper inter project deps and things.
[16:33:26] <fuzzie> well, producing project files with the different build types, and not requiring you to manually run cmake
[16:33:30] <fuzzie> i think i maybe already asked about this
[16:34:16] <fuzzie> and it seems drastically better since a couple of years ago
[16:37:07] --> Maighstir has joined #GemRb
[16:40:53] <fuzzie> but i think with the information available, i would not be convinced to move to cmake if i were using msvc with very little time :)
[17:39:44] <tomprince> http://localhost:4010/builders/cross%20armv6j-gnueabi%20g%2B%2B-4.4.3/builds/2/steps/compile/logs/warnings
[17:39:46] <CIA-24> GemRB: 03tom.prince * r850e2b438a1c 10gemrb/gemrb/core/Variables.h:
[17:39:46] <CIA-24> GemRB: Fix alignment warning armv6j.
[17:39:46] <CIA-24> GemRB: This is actually a problem, but it is easy to fix.
[17:39:46] <CIA-24> GemRB: Signed-off-by: Tom Prince <tom.prince@ualberta.net>
[17:39:57] <tomprince> s/localhost/hermes.hocat.ca/
[17:40:37] --> |Cable| has joined #GemRb
[17:41:05] <fuzzie> it isn't actually a problem, right?
[17:41:22] <tomprince> No, that one isn't.
[17:41:44] <fuzzie> but like i've been saying, -Wcast-align seems pointless due to the warnings
[17:41:59] <fuzzie> except the one in CREImporter which needs to be gone
[17:42:24] <fuzzie> you get different warnings depending on the alignment requirements of the arch you're building on too, obviously
[17:42:40] <fuzzie> that list of warnings can get a lot longer :-)
[17:43:46] <tomprince> Maybe I should try compiling for arm4 then. :)
[17:43:56] <fuzzie> i would suggest mips
[17:44:59] <fuzzie> gemrb is known-working on it, and you get a bunch of pages of completely stupid alignment warnings which you can't fix without adding crazy hacks because gcc got clever about noticing attempted alignment fudges
[17:45:51] <fuzzie> and then you just disable the stupid warning and it's all better again, with actual no misalignments..
[17:52:16] <tomprince> Is the code in Actor.cpp actually right? It looks like we overrite the first few characters of fistweap[i][0].
[17:54:27] <lynxlynxlynx> monk fist upgrades work, so it can't be bad if there's actually a problem
[17:54:30] <fuzzie> it is right
[17:54:53] <fuzzie> i went through the alignment stuff already, and discussed it on irc, it'll be in the public logs somewhere
[17:55:01] <fuzzie> it is, however, horrible
[17:55:13] <tomprince> Well, I wasn't refering to the alignment in this case.
[17:55:39] <tomprince> The monk fist upgrades work, since it only overwrites the first entry.
[17:55:41] <fuzzie> well, it shows up in the alignment warnings for MIPS
[17:56:26] <fuzzie> which is why i looked at it
[17:56:36] <lynxlynxlynx> the first entry is untested, since you don't start at level 1
[17:57:10] <tomprince> But the issue is that we overwrite the string in the first column with a binary number.
[17:57:28] <fuzzie> but the first column isn't used
[17:58:01] <lynxlynxlynx> what about bgt? :)
[17:58:03] <fuzzie> you see that?
[17:58:12] <tomprince> How about for pst? Or is that accesed somewhere else.
[17:58:17] <fuzzie> if (col<1) col=1;
[17:59:34] <fuzzie> and you can see from the data files that the first column is no resref, i thought
[17:59:42] <fuzzie> but it's been a few weeks
[18:00:39] --> kingron has joined #GemRb
[18:01:36] <tomprince> Partly I am just complaining that it is ugly to use the first entry of an array as something completely differnt.
[18:01:40] <fuzzie> oh, sure
[18:01:43] <fuzzie> i complained about it on irc
[18:01:44] <lynxlynxlynx> it is a resref, but it all starts at 0
[18:01:47] <fuzzie> and expected you to fix it, actually
[18:02:31] <fuzzie> lynxlynxlynx: which game version is a good example?
[18:02:56] <lynxlynxlynx> monks are only in bg2 and iwd2
[18:02:58] <fuzzie> my bg2/fistweap.2da has no resrefs in the first column
[18:03:06] <lynxlynxlynx> only hardcoded in bg2 afaik
[18:03:07] <fuzzie> but this checkout is a month or so out of date
[18:03:16] <Gekz> ok
[18:03:23] <Gekz> so it took me 6 hours to get my java assignment to be perfect
[18:03:23] <lynxlynxlynx> , 0
[18:03:28] <lynxlynxlynx> 20 MFIST1
[18:03:46] <lynxlynxlynx> hasn't changed recently
[18:03:50] <fuzzie> so that's a 20 in the first column, no?
[18:03:57] <tomprince> No, that is the row name.
[18:04:03] <lynxlynxlynx> yep
[18:04:06] <fuzzie> oh, horrors
[18:04:18] <lynxlynxlynx> iirc it is the class id
[18:07:08] <tomprince> So clearly, pst fist weapons are broken. :)
[18:07:55] <lynxlynxlynx> there is something special about them?
[18:08:23] <tomprince> Well, we just read in things from fistweap, and then overwrite them before we use them.
[18:08:35] <tomprince> Unless fistweap.2da is useless for pst?
[18:08:36] <fuzzie> lynxlynxlynx: teeth for morte, etc
[18:09:08] <lynxlynxlynx> oh, same slot
[18:09:09] <fuzzie> that code does work though
[18:09:36] <lynxlynxlynx> the 2da was added mainly for bg2 monks, the pst part is just unimplemented
[18:09:45] <fuzzie> we read things in from fistweap, and overwrite a single entry which we don't use anyway.
[18:11:06] <fuzzie> just seems strange we'd discard the first entry in the bg2/iwd2 case
[18:12:25] <fuzzie> ah, Avenger broke it for bg2/iwd2 while fixing it for pst.
[18:13:27] <fuzzie> it should be 'fistres[i][cols + 1]', predictably.
[18:14:17] <tomprince> Well, we could just change it to a struct, rather than abusing the first entry.
[18:14:24] <fuzzie> sure, but that doesn't really fix the problem
[18:15:00] --> cubathy has joined #GemRb
[18:16:04] <fuzzie> so if you change it to a struct, please don't cause an off-by-one there!
[18:16:32] <tomprince> K.
[18:17:09] <fuzzie> because if you want to leave the code as reading starting at fistres[i][0] then obviously the bounds check and accesses need fixing below
[18:17:25] <tomprince> Yes.
[18:17:34] <fuzzie> and i will never remember what changed if you don't fix it :-)
[18:17:58] <tomprince> Not today though.
[18:18:04] <fuzzie> i spent too long in exams today, so sorry if i state the obvious, v.tired
[18:20:33] <tomprince> You probably don't need to apologize so much, at least to me. :)
[18:23:41] <-- Gekz has left IRC (Quit: Leaving)
[18:49:10] <-- cubathy has left IRC (Ping timeout: 252 seconds)
[18:55:46] <Lightkey> edheldil: did you get my memo at least? ;p
[19:02:41] --> cubathy has joined #GemRb
[19:05:02] <-- kingron has left IRC (Remote host closed the connection)
[19:26:21] <-- tomprince has left IRC (Ping timeout: 265 seconds)
[19:26:55] --> tomprince has joined #GemRb
[19:56:54] <-- Maighstir has left IRC (Quit: Maighstir)
[20:17:34] <-- kettuz has left IRC (Ping timeout: 258 seconds)
[20:17:59] --> kettuz has joined #GemRb
[20:27:00] --> Maighstir has joined #GemRb
[20:28:59] <-- cubathy has left IRC (Remote host closed the connection)
[20:45:24] --> cubathy has joined #GemRb
[21:18:49] <lynxlynxlynx> fuzzie: still here?
[21:19:45] <fuzzie> mhm
[21:20:12] <lynxlynxlynx> i remember we talked at one point about the buggy percentage mode of fx_poison
[21:21:08] <fuzzie> yes
[21:21:12] <lynxlynxlynx> http://pastebin.com/HqwD6ERS <-- this is my attempt, but I don't have any appropriate trap handy to test it
[21:22:14] <fuzzie> i think the effect is meant to self-modify, let me check
[21:23:37] <lynxlynxlynx> it's also odd that RPD_TURNS multiplied the time by 30, not 60
[21:25:52] <fuzzie> hmm, i guess the original effect actually self-destructs
[21:27:08] <fuzzie> but self-modifying would work
[21:27:21] <fuzzie> i assume your version won't work because you'll do more and more damage the closer you get to the expiry time
[21:28:16] <lynxlynxlynx> it's also not /0 sage
[21:28:18] <lynxlynxlynx> safe
[21:28:55] <lynxlynxlynx> i can make it convert itself to a RPD_POINT version
[21:29:32] <lynxlynxlynx> the damage calculation will be fine on first application
[21:29:40] <fuzzie> i don't understand how the original effect does the timing, so i can't puzzle over that
[21:30:14] <fuzzie> but it works by doing all calculation on first application and then adding to a 'recurrent damage' queue
[21:31:06] <fuzzie> i think you're maybe better off checking first_apply
[21:31:26] <fuzzie> if (fx->FirstApply) do setup
[21:31:47] <fuzzie> otherwise with RPD_POINT it seems like you'll have troubles with long-duration poison on low-HP chars
[21:32:05] <fuzzie> but i don't know.
[21:32:25] <fuzzie> (and then leave it as RPD_PERCENT, i mean)
[21:32:51] <lynxlynxlynx> but the damaging code would be the same
[21:33:46] <lynxlynxlynx> or how did you mean that?
[21:35:57] <fuzzie> i think it's probably not worth the bother
[21:36:24] <lynxlynxlynx> http://pastebin.com/Tqk4PJLK <-- this is what i have now; just need to add some sanity checks
[21:37:01] <fuzzie> the original code calculates the total loss of hit points and then hands it onward, i assume it is cleverer about when to apply damage
[21:37:13] --> tomprince_loki has joined #GemRb
[21:37:32] <lynxlynxlynx> i'll use FirstApply to avoid the need to set the type to RPD_POINT otherwise it won't work on later applications
[21:37:36] <fuzzie> you don't check FirstApply nor modify Parameter2 there?
[21:37:44] <fuzzie> ok
[21:39:17] <lynxlynxlynx> ok
[21:43:00] <lynxlynxlynx> the RPD_TURNS thing was added like that, i'll just assume he miscalculated for now
[21:50:45] <lynxlynxlynx> do you know if the disease effect should behave the same? you left the same this-is-broken comment there
[21:52:18] <fuzzie> and regeneration, i think
[21:53:32] <fuzzie> all done using the same recurrent 'damage' stuff
[21:53:36] <lynxlynxlynx> indeed
[21:56:07] <fuzzie> perhaps fx_apply_effect_repeat too, but the comment says it crashes in original engine, so heh
[21:56:32] <fuzzie> (although it doesn't do any sort of percentage calculation ofc)
[21:57:19] <fuzzie> but nothing else which would make any sense, so those three are it, i guess
[21:58:46] <-- kettuz has left IRC (Ping timeout: 258 seconds)
[21:59:11] --> kettuz has joined #GemRb
[22:00:20] <-- kettuz has left IRC (Client Quit)
[22:09:16] <lynxlynxlynx> http://pastebin.com/WnL4pQvZ <-- any last comments?
[22:10:08] <lynxlynxlynx> maybe HandlePercentageDamage would be a better name
[22:11:00] <lynxlynxlynx> yeah, i'll rename it, everything else is recurrent too
[22:30:20] <-- lynxlynxlynx has left IRC (Remote host closed the connection)
[23:18:38] --> Gekz has joined #GemRb
[23:22:38] <-- cubathy has left IRC (Ping timeout: 240 seconds)
[23:52:56] <-- Gekz has left IRC (Quit: This computer has gone to sleep)