#gemrb@irc.freenode.net logs for 11 Apr 2010 (GMT)

Archive Today Yesterday Tomorrow
GemRB homepage

[00:49:46] --> tomprince_loki has joined #GemRb
[00:59:39] <tomprince> Does anybody follow the IE modding news? It seems there is a patch in beta right now that adds a ton of animations to BG2.
[01:35:02] <Gekz> what
[01:35:03] <Gekz> why
[01:35:04] <Gekz> haha
[01:35:10] <Gekz> modding for BG2 will never end, will it
[01:44:09] --- Gekz is now known as mortentete
[01:54:16] <tomprince> It does seem quite active.
[02:02:08] <mortentete> they need to reimplement it as a text-based game
[02:08:06] <tomprince> You try gemrb with SDL_VIDEODRIVER=aalib. I don't know if it would work.
[02:13:43] <tomprince> It works. It isn't playble.
[02:35:11] <mortentete> lol.
[02:35:16] <mortentete> that's not what I meant
[04:30:58] <-- ratpor has left IRC (Ping timeout: 260 seconds)
[04:35:28] --> ratpor has joined #GemRb
[05:30:59] <-- ratpor has left IRC (Ping timeout: 268 seconds)
[07:44:15] <-- raevol has left IRC (Quit: Leaving.)
[08:38:38] --> raevol has joined #GemRb
[08:40:44] <-- Nomad010 has left IRC (Ping timeout: 240 seconds)
[08:47:56] --> Nomad010 has joined #GemRb
[08:50:44] <-- raevol has left IRC (Quit: Leaving.)
[08:57:02] --> Avenger has joined #GemRb
[08:57:06] --- ChanServ gives channel operator status to Avenger
[08:57:10] <Avenger> hello
[08:57:25] <fuzzie> hi
[08:57:38] <fuzzie> bg1 projectiles aren't finished?
[08:57:57] <fuzzie> (see, i have something to ask every time, now!)
[08:58:31] <Avenger> i don't know bg1 projectiles are overlapped by bg2
[08:58:52] <fuzzie> <fuzzie> bg1 is missing the CG* ones, COLRSPRY, FIREBLGR, HLYMITE, HOLD, INAREANP, INAREANS, INAREAPA, LIGHTB, SKYBOLT2, SPBRNHND, SPCONECO and SPCONEFI. and it has SPFIREWL in the list, but an unused 'spfirebl.pro'.
[08:59:25] <fuzzie> i only noticed LIGHTB myself, and i don't copy it from bg2 because i thought the bg2 .pro has special flags.
[08:59:26] <Avenger> at least some of those should have been done, let me see
[08:59:57] <fuzzie> and the others have different copies for every game, so i don't know if i can just copy one of them
[09:01:20] <Avenger> inareans is the same as inarea, with the no self flag set
[09:02:01] <Avenger> hlymite is in bg2, cannot be used for bg1 too?
[09:02:12] <fuzzie> i really don't know anything about projectiles
[09:02:12] <Avenger> maybe just needs to be moved to shared
[09:02:51] <Avenger> if bg1 has a hlymite bam, then we are good
[09:03:08] <Avenger> then you can simply move the pro from bg2, to shared
[09:03:23] <fuzzie> 'hlymite.bam'?
[09:03:29] <Avenger> yes
[09:03:43] <fuzzie> $ ./weidu.asm.exe --game ~/src/gemrb/bg1 --list-files | grep HLYMITE
[09:03:43] <fuzzie> HLYMITE.BAM
[09:03:46] <fuzzie> ^- yup :)
[09:04:03] <Avenger> good, then it is easy, just move the pro
[09:04:12] <Avenger> i wonder if iwd1 has it
[09:04:24] <fuzzie> my copy does, with all expansions installed
[09:04:31] <Avenger> yup, iwd1 will be benefited by this too
[09:04:34] <fuzzie> not in pst, though
[09:04:58] <Avenger> no problem, if a projectile suddenly gets working, pst engine would support it too if the bam is there
[09:05:20] <fuzzie> i mean, the bam isn't in pst :)
[09:05:23] <Avenger> most old projectiles in pst are the same code as in bg1
[09:05:31] <fuzzie> but i guess they just don't use it
[09:05:36] <Avenger> yep
[09:06:01] <Avenger> they would work in the old engine, if you copy the bam to pst. And that's the same for us. so we are completely compatible
[09:06:46] <fuzzie> do you remember how you wrote GetGlobalTint?
[09:06:54] <Avenger> inareanp is the same as inarea, just with the no party flag set
[09:07:26] <fuzzie> at the moment it checks for the weather first, and then nighttime -- i want to swap those, but i don't know if it is correct
[09:08:02] <Avenger> it is mere guesswork, so feel free to reorder it
[09:08:32] <Avenger> i just threw in some code i thought should be there :)
[09:08:42] <Avenger> there is no reverse engineering behind it
[09:08:50] <fuzzie> the numbers also guesswork?
[09:09:01] <Avenger> yes
[09:09:06] <fuzzie> they looked actually pretty reasonable
[09:09:43] <Avenger> well, i just guessed them, so wjp's question if they are for a tint or blend, were also somewhat moot :)
[09:10:08] <Avenger> i don't know how it is done exactly in the original
[09:10:40] <fuzzie> well, the nighttime one looked pretty reasonable when tinted
[09:10:49] <fuzzie> i'll take some screenshots and work it out :)
[09:11:15] <Avenger> make sure you don't look at an extended night area :D
[09:11:31] <fuzzie> this is why i've been using bg1 :p
[09:11:37] <Avenger> oh, ok
[09:12:07] <fuzzie> i can't view big TIS files in DLTCEP, is that some wine bug?
[09:12:42] <fuzzie> if you scroll down in the tile view (editing the TIS file itself), it just stops working after a few hundred tiles
[09:13:25] <Avenger> never had this problem in windows
[09:13:32] <Avenger> which file
[09:13:43] <fuzzie> ar1700.tis from bg2, for example
[09:13:57] <fuzzie> it sounds like it could be a wine bug, i just thought i'd ask if you knew :)
[09:14:31] <Avenger> ok, so you open it with the tileset editor?
[09:14:38] <fuzzie> yes
[09:15:08] <Avenger> do you click on 'guess dimensions' ?
[09:15:24] <Avenger> or you let it have that long crippled bitmap
[09:16:01] <Avenger> tools/guess dimensions will set the 'original' dimensions of the tileset, based on matching edges
[09:16:10] <fuzzie> the long bitmap; the tiles are all a mess in the one i look at, but hey, it's much better with 'guess dimensions' :) i didn't see that
[09:16:22] <Avenger> hehe, it is magic
[09:16:43] <Avenger> i think the long bitmap has some bugs, this is a windows/wine bug (limitation)
[09:17:01] <Avenger> the bitmap is bigger than x. pixels --> no way
[09:17:03] <fuzzie> thankyou!
[09:17:33] <Avenger> on the bottom you will see garbled tiles, those are the extra overlays
[09:17:46] <Avenger> just telling, it isn't a bug :)
[09:18:00] <fuzzie> well, these tiles are a bit out-of-order anyway, so it looks all messed up
[09:18:08] <fuzzie> i mean, i look at some other TIS :)
[09:18:27] <fuzzie> but this is just what i wanted
[09:18:30] <Avenger> the overlay tile order is random, it is in the order they were created
[09:19:12] <fuzzie> wjp tried doing this tinting thing, and it reminded me that we still don't do overlay masks correctly
[09:19:41] <fuzzie> so i thought i would take a look. and ar1700 is one of the areas where they screwed it up :)
[09:20:22] <Avenger> yes, this is probably visible even in dltcep
[09:21:18] <Avenger> btw, i saw you changed the bcs parser
[09:21:37] <Avenger> be careful with that, there are many differences between the engines
[09:22:03] <Avenger> and most of the times, the original engine copes with slight syntax problems, it doesn't give up easily
[09:23:20] <fuzzie> yes, this is why i added the warning, so hopefully it is obvious if i screwed it up (although i checked as much as i could)
[09:23:28] <fuzzie> i hope that now it is more forgiving
[09:23:57] <fuzzie> can you think of some reason why MatchActor shouldn't retrieve the Scriptable by ID first, by the way?
[09:24:09] <fuzzie> maybe that is code you haven't touched in too long
[09:24:24] <fuzzie> (i know, Scriptables don't have IDs yet, that has to come first!)
[09:26:46] <Avenger> recently as 6 months ago?
[09:26:47] <Avenger> :)
[09:27:26] <fuzzie> well, I changed that code 6 months ago and I didn't remember it at all!
[09:27:58] <Avenger> i doubt i touched it after that
[09:29:21] <Avenger> There was a very good reason why i did it in that odd way, but i don't remember.
[09:29:37] <Avenger> the straightforward matching was not working
[09:30:05] <fuzzie> well, you've got to match the object stuff too, afterwards, and that is a bit tricky
[09:30:32] <Avenger> but i don't see why
[09:31:01] <Avenger> well, yes, that too
[09:31:04] <fuzzie> well, i'll have to look very carefully, i guess. we changed a lot of that code in the meantime.
[09:31:10] <Avenger> you need not only actors there, probably
[09:33:06] <fuzzie> you also added some stuff to AREImporter in b8071dec which don't quite match what Taimon says
[09:34:28] <Avenger> got a link for that?
[09:34:52] <fuzzie> starts on http://forums.gibberlings3.net/index.php?showtopic=17946&st=45 i think
[09:36:11] <Avenger> i meant the repository, i'm totally helpless with git, how can it show the svn changes
[09:36:28] <fuzzie> but no, i think you are right anyway
[09:36:39] <fuzzie> i get very confused by the different offsets
[09:36:48] <fuzzie> but for future note, 'git show b8071dec' :)
[09:37:32] <Avenger> thanks
[09:37:55] <fuzzie> i'm trying to work out how spawning works, but Taimon says "the difficulty sum of all spawns up to now (including the current) is compared against (party level * 0x9a)", and i'm not sure how you work out the difficulty of all spawns so far
[09:38:41] <Avenger> there is some code for spawngroups
[09:39:08] <Avenger> sometimes the spawned creature is not a single 'cre' but an entry in spawngrp
[09:39:37] <Avenger> i vaguely remember working on that
[09:40:15] <fuzzie> yes, he talks about some difficulty from a 2da
[09:40:24] <Avenger> maybe there is code that matches party level in some way, but it is not adjusted by 0x9a
[09:40:45] <fuzzie> but then i don't see how to work out the "difficulty sum of all spawns up to now", because we only have the CREs in the area to check :)
[09:40:49] <Avenger> and i'm almost sure i use the summary of levels, not the average...
[09:41:33] <Avenger> well, you can add up the spawn header difficulties, there is surely a flag in the spawn header that marks it as 'fired recently'
[09:41:58] <fuzzie> yes, but what if it fired multiple times recently? :)
[09:42:12] <Avenger> is it alloweD?
[09:42:20] <fuzzie> i think so, yes
[09:42:22] <Avenger> i think that flag is to prevent it from firing again :)
[09:42:54] <Avenger> most likely WE don't honour it, though
[09:43:11] <fuzzie> we spawn *all* the points at once, with full set of creatures
[09:43:25] <fuzzie> and then the poor level-1 party dies
[09:43:37] <fuzzie> it is kind of funny :)
[09:44:04] <Avenger> well, goodfor nightmare mode
[09:44:11] <fuzzie> but Taimon keeps referring to his notes, so i'm not so familiar
[09:47:08] <fuzzie> hm, i don't suppose you know anything about the bg1 'idle' sounds, while you're here?
[09:49:43] <fuzzie> oh, i guess the "verbal constant (bg2), we need a lookup table for other games" in GameScript.h says it all
[09:51:03] <wjp> hi
[09:52:47] <fuzzie> sometimes i forget that you didn't all implement everything before i got here :)
[09:53:06] <fuzzie> morning, wjp
[09:54:57] <Avenger> yes, though most things are hinted in the code, almost nothing is fully complete
[10:00:28] <fuzzie> do you know where the actor 'expiry time' is?
[10:01:45] <fuzzie> hm, IESDP claims it's after Orientation (in the ARE), and that the dword before that is "actor animation"
[10:02:07] <fuzzie> we just seek over both of those right now
[10:02:55] <fuzzie> we skip over the "has been spawned" field and another unknown, too
[10:04:12] <fuzzie> any idea if those are right?
[10:12:11] <Avenger> yes, i guess, it is right
[10:12:36] <fuzzie> no idea what actor animation is, but we need the others
[10:12:40] <Avenger> it would be worse if we don't skip them :) But since we skip, it is surely containing that info
[10:12:50] <Avenger> the actor animation seems to be useless
[10:13:09] <Avenger> it doesn't override the 'cre' and rarely contains useful info
[10:13:21] <fuzzie> good to know
[10:14:01] <Avenger> in some engine types, i think it usually contained the same number as the 'cre' animID, so we named it actor animation
[10:16:09] <fuzzie> *nod*
[10:19:28] <fuzzie> i should remember to work out what "no corpse" means
[10:22:12] <fuzzie> oh well, lots to do :) how is it going in the world of Avenger?
[10:23:04] <Avenger> i'm fine, if that's what you ask. I just don't do much with gemrb at the moment, i'm busy with other stuff.
[10:25:10] <fuzzie> Sorry, that is what I ask - I saw your post on the forum about being a bit out of motivation, understandable :)
[10:26:27] <Avenger> well, i could be motivated now, since you two work on it. Maybe i just need some time
[10:26:39] <lynxlynxlynx> http://forums.gibberlings3.net/index.php?showtopic=19660&st=0&#entry165808 <-- so is it ok to rename that unknown to unused? I don't see where a non-area class in gemrb
[10:26:41] <Avenger> i work on other coding stuff
[10:27:56] <lynxlynxlynx> is
[10:28:18] <fuzzie> lynxlynxlynx: Avenger says "so this field is not corrupted by gemrb in original saves" in 0bd0d991, so maybe it's used in another engine version?
[10:28:36] <Avenger> it could be
[10:28:42] <fuzzie> Avenger: anything fun? :)
[10:29:03] <lynxlynxlynx> that marshalling thing doesn't make much sense to me
[10:29:08] <Avenger> yes, totally fun.
[10:29:17] <lynxlynxlynx> ok, i'll leave it be
[10:29:28] <Avenger> i guess, you never played a mud? the predecessor of mmo.
[10:29:30] <fuzzie> lynxlynxlynx: it just means "this is the code which loads/saves this"
[10:29:46] <fuzzie> i never played a mud, but i've seen other people play them and try explaining it to me :)
[10:29:53] <lynxlynxlynx> i also noticed iesdp describing one of our door flags as non-closable, but i can't think of any door like that except for secret ones
[10:30:09] <fuzzie> lynxlynxlynx: what do we have for the flag?
[10:30:11] <Avenger> well, i play this mud for, hmm, 15 years now?
[10:30:17] <fuzzie> oh wow :)
[10:30:43] <lynxlynxlynx> DOOR_32, unused
[10:31:21] <fuzzie> what does the blue text mean, in IESDP?
[10:31:25] <lynxlynxlynx> 16 is described as "broken", but i can't tell if that means the flag makes the engine crash or if it has something to do with the door (=bashed)
[10:31:41] <lynxlynxlynx> my guess is that blue = unverified
[10:32:34] <fuzzie> it is worth adding as a comment to our code, perhaps
[10:34:18] <fuzzie> Avenger: but, if you have some fun thing to do, please don't neglect it for gemrb! gemrb has no rush, and even Edheldil committed again recently :)
[10:35:13] <lynxlynxlynx> shush :P
[10:35:39] <wjp> re. overlay tile masking: do I understand it correctly like this? When drawing ovtile->anim[0], it should only be drawing the parts that are colourkey-coloured in ovtile->anim[1]
[10:36:04] <wjp> and that's the only thing ovtile->anim[1] (the 'secondary' tile) should be used for?
[10:36:49] <fuzzie> you think of tile->anim[1]?
[10:37:09] <wjp> hm, I didn't think so, but maybe I do?
[10:38:31] <wjp> I thought the secondary tiles were attached to the overlay tiles since they're being parsed in WEDImp::AddOverlay
[10:38:43] <fuzzie> if you think of that, you match my understanding of bg2 (you can see the different code for bg1)
[10:39:20] <wjp> are bg1/bg2 the only games with overlays?
[10:39:50] <Avenger> yes wjp, there is some different overlay handling in bg1 and bg2
[10:40:20] <wjp> is bg1's currently working in gemrb?
[10:40:24] <fuzzie> yes
[10:40:24] <Avenger> yes
[10:40:32] <fuzzie> see Core/TileOverlay.cpp
[10:40:34] <Avenger> the way i coded it it works for both :)
[10:40:46] <fuzzie> it simply uses the original tile for the colour-keying, if there is no secondary one.
[10:40:50] <Avenger> except when bg2 has some unwanted pixels in otherwise masked out parts
[10:41:21] <Avenger> the best would be to overwrite those pixels before use
[10:41:39] <wjp> hm, with what?
[10:41:47] <wjp> wouldn't you need to know what they're drawn on top of?
[10:41:48] <Avenger> transparent pixel
[10:41:55] <fuzzie> yes, one of my thoughts was simply to write the correct colour-key mask onto the original tile
[10:42:26] <Avenger> it would spare the current code, without adding complexity to it
[10:42:32] <fuzzie> and the other thought is just to do the masking properly.
[10:42:50] <Avenger> that would add the overhead to drawing time, instead of load time
[10:42:51] <fuzzie> this came because the current code needs changing for the tinting :)
[10:43:02] <Avenger> well, that's true
[10:43:19] <wjp> Avenger: do we know at load time what the 'base' tile is?
[10:43:21] <fuzzie> and the accelerated colour-keys can't be tinted, so i thought: why not fix two bugs in one go :)
[10:43:45] <fuzzie> wjp: see the first TISImp::GetTile
[10:43:47] <Avenger> yes, we know, at one point of the load time
[10:46:50] <Avenger> tile = tis->GetTile( indices, 1, &secondary ); in wedimporter calls it
[10:47:11] <fuzzie> yep, and it has the base tiles when it retrieves the secondary ones, so it's easy enough to do it there
[10:47:13] <Avenger> well, i guess it is better to do in the tis importer
[10:47:29] <fuzzie> i don't really like it very much, it seems that it would be more flexible to do it properly
[10:47:55] <fuzzie> but i think for all existing games/mods, it would work fine to just modify the tile there.
[10:48:31] <Avenger> you probably mean, that the secondary tile could be used elsewhere?
[10:48:37] <fuzzie> no, that is ok
[10:48:38] <wjp> this 'tile' that's loaded in WEDImp::AddOverlay, does that end up being 'ovtile' or 'tile' in TileOverlay::Draw() ?
[10:48:51] <fuzzie> because the GetTile makes a new copy of the secondary every time
[10:49:17] <Avenger> well, then i guess, it should be ok to prepare it once :)
[10:49:26] <fuzzie> wjp: the 'tile'
[10:49:41] <wjp> ah
[10:49:44] <fuzzie> i mean, the first time around.
[10:49:55] <fuzzie> it is called multiple times: look at WEDImp::GetTileMap
[10:50:23] <fuzzie> the second times it just loads the actual overlay tiles (eg, water), which ends up being 'ovtile'.
[10:51:32] <fuzzie> but those have no secondaries etc to worry about.
[10:52:29] <wjp> I see; it makes more sense now, thanks :-)
[11:19:44] --> pupnik has joined #GemRb
[11:20:10] <pupnik> testing a new build .. strange error
[11:20:25] <-- lynxlynxlynx has left IRC (Remote host closed the connection)
[11:20:36] <fuzzie> hi, pupnik
[11:20:44] <pupnik> hi fuzzie
[11:20:46] <pupnik> [Core]: Cache path =/opt/cache doesn't exist, not a folder or contains alien files!
[11:21:00] <pupnik> no matter where i create cache
[11:21:30] <pupnik> can cache be totally empty/new? does it need the data subdit?
[11:21:37] <wjp> you need a / at the end
[11:21:54] <fuzzie> cache should be totally empty/new
[11:22:37] <fuzzie> but that '=' is worrying?
[11:23:09] <pupnik> indeed i did
[11:23:13] <pupnik> ty
[11:24:41] <pupnik> hmm package didnt supply a gemrb.ini
[11:24:54] <fuzzie> your paths are all messed up, it sounds like
[11:25:11] <fuzzie> the gemrb.ini files are in gemrb's override directory
[11:25:18] <fuzzie> are you using cmake?
[11:25:33] <pupnik> yea
[11:25:51] <fuzzie> tomprince changed a lot of cmake things yesterday
[11:26:23] <pupnik> ah ill catch up on news later :)
[11:26:44] <fuzzie> so maybe some paths got changed on you
[11:26:59] <pupnik> next gen smartphones gonna all be around 1ghz with 512MB ram
[11:27:06] <pupnik> yeah just gotta sort it
[11:32:46] <fuzzie> just got to persuade wjp to buy an iPad and port gemrb
[11:33:59] <wjp> haha
[11:37:43] <pupnik> im amazed they sell
[11:38:29] <wjp> I'm kind of curious where it'll go. Not particularly interested in owning a tablet myself, though
[11:41:00] <-- Avenger has left IRC (Quit: bye!)
[11:42:36] <fuzzie> the thought of Baldur's Gate 2 on one is rather tempting
[11:43:23] <wjp> true :-)
[11:44:32] <fuzzie> Alas, not a thousand dollars worth of tempting.
[11:45:33] <pupnik> is there an iPhone build?
[11:48:44] <fuzzie> I think the iPhone resolution is too low.
[11:49:31] <fuzzie> And I guess you'd have to bundle python/etc, not too much fun.
[11:57:02] <pupnik> they do 800x480 now
[11:57:36] <fuzzie> Not on the iPhone, right?
[11:57:53] <fuzzie> Android is a different story, I'm sure that would be easy for someone.
[12:00:07] <pupnik> yeh but id rather jailbreak out of android
[12:26:28] <Nomad010> i was planning on getting an android and developing on it
[12:26:44] <Nomad010> but the nexus one's aren't in SA yet i think
[12:28:48] <pupnik> how about samsung wave
[12:33:30] <Nomad010> well i decided to get a new laptop instead lol
[12:33:45] <Nomad010> cheers
[12:34:47] <-- Nomad010 has left IRC (Remote host closed the connection)
[12:34:49] <pupnik> i want something with a 6" screen and fantastic battery life
[12:35:02] <pupnik> still pocketable
[12:53:50] <mortentete> ergh
[12:53:50] <mortentete> The Kidnapping of Boo
[12:53:54] <mortentete> I cant remember what to do
[12:54:02] <mortentete> and I cant find anything on the internet to help
[12:57:29] <fuzzie> problems with the trolls?
[12:59:58] <fuzzie> hmm, i guess that is long-fixed
[13:01:05] <pupnik> well non-x86 portables are now natural candidates for gemrb
[13:12:50] <wjp> http://www.usecode.org/gemrb/mask_pre.png http://www.usecode.org/gemrb/mask_post.png
[13:14:04] <fuzzie> very good :)
[13:18:06] <fuzzie> need some testing?
[13:19:26] <wjp> yup, but first some cleanup :-)
[13:22:16] <wjp> hm, gemrb becomes significantly more responsive when I remove the frame limiting.
[13:23:31] <fuzzie> the SDL_Delay?
[13:23:40] <wjp> yes
[13:24:10] <fuzzie> i think SwapBuffers doing the event-handling first and then the draw immediately is likely responsible, no chance for the engine to respond in the middle
[13:24:58] <wjp> ok, this new and naive tile renderer slows things down from 750fps to 500fps
[13:25:18] <wjp> (in an area without overlays)
[13:25:39] <wjp> I guess I should use SDL_BlitSurface in the common case for now :-)
[13:26:19] <fuzzie> in fact that is likely my fault; I changed that logic
[13:26:41] <wjp> I think frame limiting wasn't even working before that
[13:26:49] <wjp> or not to spec, at least
[13:27:11] <fuzzie> see 248200fe
[13:27:37] <fuzzie> can't remember why that was important
[13:29:06] <wjp> hm, before that patch it would do the logic twice between frame updates (Logic. Delay. Logic. Draw. Logic. Delay. Logic. Draw. Logic, ...)
[13:29:12] <fuzzie> I guess because the main game loop does a redraw, which is often more expensive than the 17ms.
[13:30:06] <wjp> well, if redrawing costs X, it would do two logic updates per 17ms+X
[13:30:26] <wjp> um, no
[13:30:35] <wjp> if redrawing costs X < 17ms, it would do two logic updates per 17ms
[13:30:44] <fuzzie> i think before, it did a redraw + logic update, it would hit SwapBuffers and sleep, then another redraw+logic, and then hit SwapBuffers and blit
[13:30:53] <wjp> right
[13:30:56] --> lynxlynxlynx has joined #GemRb
[13:30:56] --- ChanServ gives channel operator status to lynxlynxlynx
[13:31:31] <wjp> hm, we should store the palette in a target format to speed up tile blitting
[13:31:50] <fuzzie> oh, tiles are paletted?
[13:32:08] <wjp> yes
[13:32:10] <fuzzie> oh, well, we could just apply the tint there!
[13:32:58] <wjp> yes, if tinting is used it doesn't matter
[13:33:07] <wjp> but often it isn't
[13:33:17] <fuzzie> i mean, we could just change the palette when we change the global tint
[13:33:36] <wjp> hm, yes
[13:33:49] <wjp> I wonder if those palettes are easily reachable
[13:33:51] <fuzzie> things which would've been nice to have thought of two days ago
[13:35:03] <wjp> I'm used to considering palettes as very dynamic for gemrb, but I guess for tiles they're pretty static
[13:35:49] <tomprince> Morning all.
[13:35:57] <fuzzie> morning :)
[13:36:04] <wjp> hm, each tile sprite gets its own palette from TISImporter
[13:36:08] <wjp> hi
[13:36:11] <tomprince> :)
[13:36:35] <pupnik> please keep performanced in mind
[13:36:47] <pupnik> OO people scare me :)
[13:36:49] <wjp> that's why we're even having this discussion of the last 10 minutes :-)
[13:41:51] <wjp> pre-bitshifting the palette at the start of each tile-blit gets fps back up to 725fps
[13:42:31] <wjp> even without caching the results for each tile
[13:43:25] <fuzzie> hehe, running SDLVideo without BAMs is pretty funny :)
[13:43:46] <wjp> running actor circles without actors? :-)
[13:43:55] <fuzzie> no, that works :)
[13:44:00] <fuzzie> but they're not paletted etc
[13:44:14] <wjp> ah, by saying SDLVideo doesn't support BAM
[13:44:17] <pupnik> wjp can you design it to be extendable to hardware pallettes (opengl or other)
[13:44:41] <wjp> pupnik: no
[13:45:03] <wjp> that would require a larger redesign of the video stuff first to be useful
[13:45:49] <wjp> and background tiles won't be a major issue for opengl support I think
[13:46:07] <fuzzie> you could just re-colour and re-upload them on tint change, no problem
[13:46:19] <wjp> actually tinting can be done with GL_MODULATE
[13:46:27] <fuzzie> that's supported everywhere?
[13:46:43] <wjp> it's pretty old, but I don't know
[13:46:57] <wjp> and if not, we do what you suggest :-)
[13:47:43] <fuzzie> it seems fine
[13:47:54] <fuzzie> not worried about old, but i would guess the interesting target is OpenGL ES, so :)
[13:49:04] <fuzzie> our paperdoll palettes certainly are odd
[13:49:54] <-- pupnik has left IRC (Ping timeout: 268 seconds)
[13:50:42] <wjp> that caused me a lot of headaches when I implemented that :-)
[13:51:02] <tomprince> Is that the PLT stuff?
[13:51:16] <fuzzie> well, the SetButtonPLT path, yes
[13:51:32] <CIA-74> GemRB: 03fuzzie * r9a8475053a8e 10gemrb/gemrb/plugins/BAMImporter/BAMImporter.cpp: don't fail assert if video driver doesn't support BAM natively
[13:52:06] <fuzzie> still fiddling with it
[13:52:33] <tomprince> Part of the weirdness is PLTImporter::GetPalette is actually SetPalette. ;)
[13:53:13] <fuzzie> well, i am concerned about the 'not working' bits, as usual :)
[13:53:21] <fuzzie> but i don't think it's a core issue
[13:54:41] <lynxlynxlynx> geez, what a long provider downtime
[13:55:11] <CIA-74> GemRB: 03lynxlupodian * rdc9a6248ae07 10gemrb/gemrb/plugins/WEDImporter/WEDImporter.cpp: WEDImporter.cpp: removed commented out declarations
[13:55:13] <CIA-74> GemRB: 03lynxlupodian * r03bc7f517dcc 10gemrb/gemrb/ (docs/en/Engine/Doors.txt plugins/Core/ActorBlock.h): added a few notes about doors
[14:04:22] <tomprince> Does anybody care about the old svn-imports on or.cz?
[14:04:36] <fuzzie> i don't think so, it is a bit too late now :)
[14:04:56] <wjp> not me
[14:05:47] <tomprince> lynxlynxlynx: ?
[14:05:57] <lynxlynxlynx> not me
[14:06:19] <tomprince> nuking.
[14:10:15] <wjp> this should somewhat work: http://www.usecode.org/gemrb/tilerenderer.patch
[14:10:35] <wjp> (it needs some more cleaning up, especially in how the internal rendering function is called)
[14:10:42] <wjp> I thought I'd experiment with a template approach too
[14:11:07] <wjp> it does global tinting, but only of the tiles
[14:14:01] <tomprince> I thought I'd post this again, since they are in parts of the code I am not familiar with : cmake errors http://pastebin.ca/1859334
[14:14:29] <fuzzie> that url seems non-functional?
[14:14:45] <wjp> works for me
[14:15:15] <lynxlynxlynx> not for me
[14:15:27] <lynxlynxlynx> now it's fine
[14:15:29] <fuzzie> hm, i get nothing for the whole site, in fact
[14:15:35] <lynxlynxlynx> keep reloading
[14:16:12] <wjp> hm, right, fails intermittently here too
[14:16:32] <fuzzie> i thought we fixed that bitshift one.
[14:16:55] <fuzzie> but apparently not.
[14:17:27] <fuzzie> last one is a trivial cast.
[14:17:38] <lynxlynxlynx> yep, already on it
[14:17:47] <lynxlynxlynx> (my fault)
[14:18:21] <wjp> I'll commit the gradient thing in Actor.cpp
[14:18:42] <wjp> (unless that's the one lynxlynxlynx referred to?)
[14:18:49] <lynxlynxlynx> the orient one
[14:19:01] <fuzzie> the gradient thing is just s/ieByte/ieDword/?
[14:19:02] <lynxlynxlynx> if (diff == (signed)tar_orient) return true;
[14:19:12] <fuzzie> it should be if ((unsigned char)diff, i think
[14:19:22] <fuzzie> because you already accounted for negative values in the line above
[14:19:30] <fuzzie> but it's really irrelevant
[14:19:52] <lynxlynxlynx> yep
[14:20:06] <fuzzie> both are fixed in one of my branches, but i'll leave it to you two :p
[14:21:05] <lynxlynxlynx> tomprince: any particular reason this flag isn't in -Wextra/-Wall?
[14:21:25] <fuzzie> that is not gcc, it is clang
[14:21:31] <lynxlynxlynx> ah
[14:21:43] <CIA-74> GemRB: 03lynxlupodian * r2a1a8a0398af 10gemrb/gemrb/plugins/Core/Actor.cpp: Actor::IsBehind: added a missing cast
[14:22:29] <CIA-74> GemRB: 03wjpalenstijn * rd0d4fe803dd2 10gemrb/gemrb/plugins/Core/Actor.cpp: Fix shifting past size of type
[14:23:11] <tomprince> It is, I am not passing sign-compare directly. It just helpfully reports the flag that controls it, in case you want to pass -Wno-sign-compare or something.
[14:23:55] <tomprince> Clang makes a point of having useable error message: http://blog.llvm.org/2010/04/amazing-feats-of-clang-error-recovery.html
[14:26:39] <tomprince> wjp: That template code is much nicer to read.
[14:28:21] <wjp> it's also of a much simpler case, but yes :-)
[14:28:37] <wjp> I wonder how the xflip/yflip stuff would work out in templates
[14:29:02] <fuzzie> constant multiplier if you pass it in the template parameters, no?
[14:30:31] <wjp> and setting the start/end?
[14:30:54] <wjp> use (1+mult)/2 * some optional thing?
[14:31:20] <wjp> oh, currently the xflip/yflip are resolved at runtime, by the way, not compile time
[14:31:43] <fuzzie> that would be a good thing to fix, no?
[14:31:49] <fuzzie> i have not really looked at the code :)
[14:31:59] <wjp> depends on how many copies of the renderer you want compiled :-)
[14:32:21] <fuzzie> difficult balance, i guess..
[14:33:51] <wjp> what would be the best way to avoid having a tree of ifs in the calling function?
[14:34:09] <tomprince> A couple of nitpicks. :) Should the structs be Tinter_ and Blender_, rather than the generic TileRenderer. And would it make sense for Blender_ to take backbuf->format, rather than all the members?
[14:34:24] <wjp> tomprince: both sound reasonable
[14:35:31] <wjp> re. tree of ifs: I could imagine a chain of template functions, each one adding an extra template argument
[14:35:52] <tomprince> I don't know about avoid the tree of ifs. I don't like the DO_BLIT, but I can't think of anything better at the moment. Although you should undef it after you are done with it.
[14:36:08] <fuzzie> wjp: i'm not sure how portable that would be.
[14:36:45] <fuzzie> things start melting at some template depth.
[14:37:10] <tomprince> No more or less portable than what we have, I think, or than what this is, anyway.
[14:37:47] <wjp> it wouldn't necessarily increase the template depth
[14:37:59] <fuzzie> well, maybe i misunderstand what you're suggesting.
[14:39:07] <wjp> something like call1(bool a, bool b) { if (a) call2<X>(b); else call2<Y>(b); } call2<T>(bool b) { if (b) call3<T,X>() else call3<T,Y>(); }
[14:39:32] <fuzzie> Ah, okay.
[14:40:09] <wjp> but in this 16/32 bpp case I don't think that would end up being cleaner than this DO_BLIT
[14:43:53] <fuzzie> looking through boost config again just makes me want to go mad.
[14:44:17] <fuzzie> template <typename T> void g() { std::cout << typeid(T).name() << ' '; }
[14:44:28] <fuzzie> int main() { g<int>(); g<double>(); }
[14:44:42] <fuzzie> ^- what does our friend vc++6 output?
[14:47:18] <wjp> tomprince: tilerenderer.patch updated with your suggestions
[14:47:25] <tomprince> wjp: I think it might end up being cleaner, at least if the list of paramaters that are passed can be pared down ... we are passing in backBuf->format anyway.
[14:48:56] <fuzzie> (that question is perhaps relevant to your patch!)
[14:50:21] <wjp> fuzzie: I could guess, but by the way you phrase it I expect it'll be wrong :-)
[14:51:14] <fuzzie> well, boost informs that the answer is 'double double', because the compiler resolves the types of all the arguments of 'g()', and then folds the instantiations because they're then identical.
[14:51:49] <fuzzie> easy enough to steal their workaround if necessary, though.
[14:52:12] <wjp> eep
[14:53:53] <tomprince> It'd be nice not to have to deal with VS6 insanity.
[14:54:13] <fuzzie> well, this is flaky in some later VS releases too, and the associated embedded compilers.
[14:54:28] <wjp> what's the workaround?
[14:54:50] <fuzzie> wjp: just include the type in the argument list somewhere.. see /usr/include/boost/type.hpp if you have it installed
[14:57:15] <fuzzie> That bug is also present in various other compilers, but I'm *fairly* sure the others have no use nowadays.
[14:57:50] <fuzzie> Other template bugs, on the other hand, somewhat less convenient. :|
[14:58:59] <fuzzie> And hence my paranoia about adding seemingly-harmless template bits everywhere!
[14:59:31] <mortentete> tomprince: how dare you call vc++6 a friend
[15:00:12] <tomprince> No friend of mine.
[15:00:22] * tomprince looks around cautiously
[15:00:47] * tomprince whispers " ... we could drop VS++6 support ..."
[15:00:53] * tomprince runs away and hides.
[15:01:09] <fuzzie> convince Avenger :)
[15:01:52] <mortentete> I could
[15:01:56] <mortentete> I'll make it my challenge
[15:02:03] <mortentete> there's no reason to support VC++6
[15:02:07] <fuzzie> step one would be to port all his code to a newer version ;p
[15:02:11] <mortentete> we have gcc!
[15:02:22] <mortentete> or just remove it for the sake of simplicity
[15:02:23] <fuzzie> VC++6-era MFC magic.
[15:02:40] <tomprince> Well, I notice that that VS project files aren't updated
[15:03:03] <fuzzie> Are they ever updated?
[15:04:06] <fuzzie> Ah, he did update them for BIKPlayer.
[15:04:46] <fuzzie> But before that, the last update was 2y9m ago.
[15:05:37] <mortentete> deprecate them
[15:05:42] <mortentete> remove them in 0.7
[15:05:49] <mortentete> vote on it
[15:05:50] <mortentete> :P
[15:05:57] <fuzzie> But Avenger has coded many times more code than anyone else put together, so again, convince him. :)
[15:06:28] <mortentete> "USE A REAL PLATFORM MOTHERFUCKER"
[15:06:44] <mortentete> I've idled here for longer than you've coded GemRB fuzzie
[15:06:44] <mortentete> hahaha
[15:06:48] <mortentete> that's tragic
[15:07:06] <tomprince> Well, have to ask him next time he shows up, then.
[15:07:49] <mortentete> bring Minsc
[15:08:04] <fuzzie> mortentete: not really idling :)
[15:08:21] <fuzzie> i am reassured by your lack of presence in my earliest irc logs, though
[15:08:27] <tomprince> Although, if there is a workaround to that template bug, I don't think we should worry about it before we add the new code.
[15:08:53] <mortentete> fuzzie: oh?
[15:09:02] <fuzzie> Sure, it's just that every time you say "no more or less portable than what we have", you kill a compiler kitten.
[15:09:08] <fuzzie> mortentete: 2004 ;p
[15:09:22] <mortentete> did you stop coming here for a time?
[15:09:29] <fuzzie> i came in here, chatted a bit, complained about how gemrb didn't work, ran off again for 4 years
[15:09:38] <mortentete> yeah
[15:09:42] <mortentete> I came around 05-06
[15:09:43] <mortentete> lol
[15:09:51] <mortentete> ELAPSED, I've been here longer -.-!
[15:10:30] <fuzzie> i am the invasive newcomer, as ever :)
[15:10:39] <tomprince> I like killing compiler kittens. :)
[15:10:44] <tomprince> No, that would be me.
[15:10:56] <wjp> fuzzie: 22 Aug 2004, Gekz: 21 dec 2007
[15:11:11] <fuzzie> wjp: a little misleading :-)
[15:11:21] <tomprince> You are the old hand who make sure that I don't mess up the code with my reckless changes.
[15:13:01] <fuzzie> but, yes, the pre-VC++8 support is entirely because Avenger uses it because he's stuck with a lot of old MFC code (the same reason everyone else is stuck with VC++6), and Avenger wrote most of the code. Convince him and the template issues vanish, but I'm not sure it's worth the bother.
[15:20:16] <tomprince> or.cz/sign-compare: fix the last remaing issues.
[15:21:12] <tomprince> Except one in BIKPlayer, that got missed.
[15:22:10] <fuzzie> why does that fix it?
[15:22:36] <tomprince> Because sizeof(int) > sizeof(short).
[15:23:05] <tomprince> So that every unsigned short is representable as an int.
[15:23:19] <tomprince> Which isn't the case for short vs. unsigned short.
[15:23:38] <fuzzie> so it silently promotes to a signed comparison?
[15:24:39] <fuzzie> well, i guess that works
[15:25:01] <tomprince> Yes, which is sensible, and has the expected effect, where as short vs. unsigned short, you would probably get unexpected values.
[15:25:32] <fuzzie> there seem to be seperate warnings for that promotion.
[15:26:52] <tomprince> /Users/cougar/src/gemrb/gemrb/plugins/BIKPlayer/GetBitContext.cpp:226:45: error: operands of ? are integers of different signs: 'unsigned int' and 'int'
[15:26:54] <tomprince> [-Wsign-compare]
[15:26:56] <tomprince> code_prefix2= code & (n_prefix>=32 ? 0xffffffff : (1 << n_prefix)-1);
[15:26:59] <tomprince> ^ ~~~~~~~~~~ ~~~~~~~~~~~~~~~~~
[15:28:13] <mortentete> that seems bad
[15:28:30] <mortentete> typeset one of them?
[15:29:01] <mortentete> wjp: I wasnt in here as Gekz initially
[15:29:04] <fuzzie> I am reluctant to start fiddling with ffmpeg code unless we can't avoid it.
[15:29:09] <mortentete> wjp: ... but I dont remember what my nickname was
[15:29:43] <CIA-74> GemRB: 03tom.prince * re38e09de1dba 10gemrb/gemrb/plugins/Core/Slider.cpp:
[15:29:43] <CIA-74> GemRB: Slider: Fix clang++ -Wsign-compare errors.
[15:29:43] <CIA-74> GemRB: Signed-off-by: Tom Prince <cougar@hermes>
[15:29:59] <wjp> mortentete: Gekz was the first nick with your hostname in my logs
[15:30:07] <mortentete> wjp: I also changed providers
[15:30:14] <mortentete> I cleared my internet identity
[15:30:18] <mortentete> apparently successfully haha
[15:30:48] <wjp> successful enough for 10 seconds of grepping anyway :-)
[15:31:02] <mortentete> yep
[15:31:13] <mortentete> hey, anyone who wants to find me wont find much even if they knew what to look for
[15:31:14] <mortentete> :)
[15:32:39] * wjp doesn't feel any particular need to look
[15:33:08] <fuzzie> oh, ffmpeg upstream changed all of that code anyway
[15:33:20] <wjp> gah, again?
[15:33:31] <fuzzie> fine
[15:39:32] <tomprince> fuzzie: or.cz/cmake has a patch to add the same warnings we have on autotools to cmake.
[15:43:00] <fuzzie> and it builds?
[15:45:15] <tomprince> Yes. Not with clang++, mind.
[15:45:25] <tomprince> Because of BIKPlayer.
[15:47:31] <fuzzie> it looks like n_prefix could simply be unsigned?
[15:48:05] <fuzzie> --no-undefined doesn't seem to check for platform
[15:48:15] <fuzzie> that would be bad to commit, no?
[15:49:18] <tomprince> Well, I think that OSX and WIN32 already have that, and it works on linux.
[15:49:40] <fuzzie> Where do they have it?
[15:50:33] <tomprince> Just that that is how things work on those platforms, as far as I can tell.
[15:51:03] <fuzzie> Yes, but I mean, you are adding the flag.
[15:51:03] <tomprince> If you look at 0c1931e1b, they were both linking the plugins against libgemrb_core already, I suspect for exactly that reason.
[15:51:10] <fuzzie> Which is a GNU linker option.
[15:51:27] <fuzzie> No?
[15:52:16] <tomprince> Yes. Perhaps it should be under if(not apple).
[15:52:39] <tomprince> It only does it against GCC.
[15:53:49] <fuzzie> I was under the impression that gcc generally doesn't back onto the GNU linker.
[15:58:26] <fuzzie> I mean, this is not a "this is wrong", I just don't know.
[15:59:56] <tomprince> Like I said, it might make sense to disable that on osx.
[16:00:17] <fuzzie> But what about *BSD, for example?
[16:00:23] <tomprince> I'm just trying to see if I can find any doc.
[16:01:21] <tomprince> I thought BSD used binutils.
[16:01:38] <tomprince> Solaris probably doesn't.
[16:02:57] <fuzzie> I have been assuming we are not going to be building on things like Solaris and AIX.
[16:03:04] <fuzzie> Otherwise we have other problems. :)
[16:03:35] <tomprince> :)
[16:04:19] <tomprince> I think solaris wouldn't be bad to support. Not that we should go out of our way, but if someone wants it to run there, and is active in reporting problems. :)
[16:04:22] <tomprince> Not AIX though.
[16:04:23] <fuzzie> But OpenBSD appears to have its own linker, or at least one is installed on this box I am shelled into.
[16:04:49] <fuzzie> I don't have access to any other *BSD machines.
[16:05:06] <fuzzie> (It does indeed fail on OS X, but that is no surprise.)
[16:05:50] <tomprince> Going to openbsd.org, and looking at the manpage for ld tells me it is GNU.
[16:07:59] <fuzzie> It changes from 3.4->3.5, if I poke at that. Odd, this is newer.
[16:16:06] <tomprince> Updated so that it is disabled on NOT APPLE.
[16:16:28] <tomprince> I don't have OSX to test that it actually works. :)
[16:18:20] <fuzzie> The whole thing looks like a nightmare, because GNU binutils is GPL3 now.
[16:20:44] <tomprince> That bit doesn't really matter to me. I just now that it has caught errors that are otherwise potentially hard to diagnose. Otherwise, we just silently not load the plugin.
[16:21:26] <fuzzie> Well, I mean, it looks like everyone is running away from GNU binutils again.
[16:21:41] <fuzzie> So just a NOT APPLE seems unlikely to last very long.
[16:21:50] <fuzzie> But if you want to apply it as-is now, ok.
[16:24:20] <CIA-74> GemRB: 03tom.prince * rd7f42e65e5e2 10gemrb/CMakeLists.txt:
[16:24:20] <CIA-74> GemRB: cmake: Add missing compiler and linker flags from autotools.
[16:24:20] <CIA-74> GemRB: - Warnings
[16:24:20] <CIA-74> GemRB: - Symbol hiding
[16:24:20] <CIA-74> GemRB: - (only cmake) resolve symbols in plugins.
[16:24:54] <fuzzie> I also don't have access to OS X enough to try building it, but I borrowed someone's machine for a moment to try ld.
[16:26:57] <tomprince> They may be running away for binutils, but I suspect that they will remain compatible. clang tries to be GCC compatible in its commandline, as does things like icc.
[16:27:28] <fuzzie> Well, for binutils, there is the advantage that there are already various platforms that don't accept the flags.
[16:27:57] <fuzzie> So it's not as if any common software is going to break. But to worry about when someone complains about it!
[16:27:59] <lynxlynxlynx> btw, binutils also has another linker
[16:28:18] <fuzzie> the gold one? it shares this kind of code.
[16:28:54] <tomprince> True, but I think --no-undefined is useful ...
[16:29:03] <lynxlynxlynx> gold, yes, but last time i checked it was almost dead
[16:29:31] <fuzzie> tomprince: Well, unfortunately I can't find a simple recipe to detect the GNU linker. :/
[16:29:37] <wjp> if anyone wants to test: http://www.usecode.org/gemrb/global_tint.patch (combines the new tile rendering and the earlier sprite global tinting)
[16:30:02] <wjp> fuzzie: test if the --no-undefined option works? :-)
[16:30:18] <fuzzie> Well, "simple" meaning "not requiring me to put actual thought into it".
[16:32:22] <tomprince> I've been running --no-undefined for a long time here.
[16:33:21] <fuzzie> He means, the cmake script could just try running ld with that option.
[16:33:38] * wjp nods
[16:34:32] <lynxlynxlynx> wjp: why isn't DO_BLIT at the end of the ifs - it is run in all four cases
[16:34:59] <lynxlynxlynx> optimisation thing?
[16:35:04] <wjp> different T's and B's
[16:35:23] <lynxlynxlynx> ah
[16:35:50] <wjp> (yes, for optimization)
[16:36:35] <tomprince> I know libtool checks to see if there is any additional output, to see if a linker supports a given option.
[16:37:00] <fuzzie> OS X's ld gives "ld: unknown option: --no-undefined", I imagine it is similar elsewhere.
[16:37:36] <lynxlynxlynx> we could use the silly check that is in autogen,sh
[16:44:40] --> Edheldil_ has joined #GemRb
[16:49:55] <tomprince_loki> Does anybody have an issue with *eventually* dropping autotools support?
[16:52:06] <wjp> the only experience I've had with cmake (several years ago) wasn't particularly good
[16:52:33] <wjp> I've kind of been ignoring it in gemrb
[16:53:04] <-- mortentete has left IRC (Read error: Connection reset by peer)
[16:53:26] --> Gekz has joined #GemRb
[16:53:37] <tomprince_loki> I do know that on a triple core machine, cmake is ~2.5-3 times faster than autotools.
[16:54:40] <tomprince_loki> And it doesn't seem like dropping cmake support is viable...
[16:58:53] <wjp> hm, 55s vs 12s even here
[16:59:18] <wjp> maybe I'm convinced :-)
[16:59:32] <wjp> I guess recursive automake is killing performance
[16:59:47] <tomprince_loki> Doesn't help. I think it is libtool.
[16:59:50] <wjp> (I really really dislike recursive automake)
[17:00:08] <tomprince_loki> I tried it with non-recursive make in the plugins dir.
[17:00:36] <tomprince_loki> Doesn't make a whole lot of difference.
[17:00:58] <wjp> libtool is building Core both shared and static
[17:01:14] <wjp> and all other plugins too it seems
[17:01:31] <wjp> so that alone will already double the time it takes
[17:09:01] <lynxlynxlynx> i'm using exclusively cmake too now
[17:10:43] <lynxlynxlynx> i think only cpack remains and it will be ready for making releases
[17:11:10] <tomprince_loki> wjp: If you can figure out how to get libtool not to make static libraries .... we tell it not to at least twice. :)
[17:11:29] <-- Gekz has left IRC (Read error: Connection reset by peer)
[17:11:35] --> Gekz has joined #GemRb
[17:11:55] <wjp> my first attempt resulted in a gemrb that couldn't load the guiscript plugin...
[17:13:08] <wjp> but I guess I have no real objections to moving to cmake if it seems to be working on all platforms
[17:14:14] <fuzzie> Well, if we do a release without autotools, I guess that will be quickly obvious?
[17:14:55] <fuzzie> Not that I suggest a release any time soon.
[17:17:39] <lynxlynxlynx> i wouldn't remove the system while it still works
[17:17:43] <tomprince_loki> Do we have many files in gemrb overrides, that are supposed to override files from the original game, rather than suplment them? I ask, because I would like to have a way for mods to override files in our override directory.
[17:18:05] <lynxlynxlynx> not many
[17:18:18] <fuzzie> It is a bit of an annoying problem.
[17:18:39] <fuzzie> How do you allow overriding of original game data by gemrb, but allow mods to override gemrb?
[17:19:01] <wjp> have mods in their own directories and use full search paths
[17:19:20] <fuzzie> That seems the best way.
[17:19:37] <tomprince_loki> I guess that means WeiDU hacking. :)
[17:19:38] <wjp> this whole 'dump everything into override' thing is just asking for trouble
[17:20:00] <wjp> (not to mention making it unnecessarily hard to uninstall mods)
[17:20:39] <fuzzie> tomprince: Are you looking at any files in particular?
[17:21:33] <tomprince_loki> Well, it seems there is a mod patch in beta to add a bunch of animations to BG2, and I'd like to add gemrb support to it.
[17:22:00] <fuzzie> Right. Yes. That is difficult, because you don't want to just override avatars.2da anyway.
[17:23:27] <lynxlynxlynx> wings for aerie and other 1pp stuff
[17:24:18] <tomprince_loki> A whole lot more now, because some one has written a patch for BG2 that allows you to have unlimited number of animations.
[17:24:23] <fuzzie> You could append onto an 'exavatar.2da' in weidu, perhaps.
[17:24:46] <tomprince_loki> Is there any reason not just to append to avatar.2da?
[17:24:59] --> raevol has joined #GemRb
[17:25:01] <fuzzie> No, if you're happy with hacking weidu to do that.
[17:25:11] <fuzzie> It doesn't sound like much fun.
[17:25:40] <fuzzie> And every time you upgrade gemrb you'll have to reinstall the mod, also not much fun.
[17:26:03] <lynxlynxlynx> and there has to be an appropriate animation type already
[17:28:19] <-- Gekz has left IRC (Read error: Connection reset by peer)
[17:28:23] --> Gekz has joined #GemRb
[17:29:38] <fuzzie> I'd be happy to add support for reading another 2DA if you wanted to work on the weidu side, though.
[17:29:43] <tomprince_loki> Although ... the trick with mods and a modpath, is that many mods change other mods, and often some parts have to be installed before, and some after.
[17:31:10] <fuzzie> Well, since later files could replace earlier files, you could fix weidu to just walk through the directories when reinstalling/uninstalling and re-apply changes.
[17:31:17] <fuzzie> It really doesn't sound like huge amounts of fun.
[17:31:31] <fuzzie> While you could just add an extra 2DA into override and have it working. :)
[17:32:46] <tomprince_loki> Well, my thought was, we could simply add a gemrb directory, and have that override are our overrides. Since nobody probably wants to override our overrides of the original game with theirs, and also the same override against the original engine.
[17:32:59] <tomprince_loki> And I don't know if what I wrote is intelligible. :)
[17:33:26] <fuzzie> Sure, but you can't just override avatars.2da.
[17:33:32] <fuzzie> gemrb's version is not static.
[17:33:42] <fuzzie> It might be in another few years, perhaps.
[17:34:50] <Edheldil_> regarding dropping of autotools .... if it can do what we need from it, why not. But I am a bit wary because too many ppl say that CMake sucks ;-)
[17:35:06] <fuzzie> So it kind of depends whether you want to make the animation mod work, or whether you want to add the infrastructure for overriding gemrb files.
[17:35:26] <tomprince_loki> Well, I might be the only one interested in running mods on a development release. And right now, everybody reinstalls the big world project every release anyway.
[17:36:25] <tomprince_loki> Well, both. :)
[17:36:27] <fuzzie> I'd prefer something I can install and forget, but I am not a huge mod user anyway.
[17:36:53] --> Gekz_ has joined #GemRb
[17:37:12] <-- Gekz has left IRC (Read error: Connection reset by peer)
[17:37:29] <tomprince_loki> I suspect neither BWP or gemrb are at the point where you can do that yet.
[17:37:34] <fuzzie> But the latter seems trivial, just append "gemrboverride/" to GamePath and add it at the appropriate place?
[17:37:44] <fuzzie> Does this animation mod require the BWP?
[17:38:09] <fuzzie> I mean, I am using gemrb against a years-old modded bg2, when I want to actually play.
[17:38:44] <fuzzie> But you'd have to do some serious hackery to get hold of gemrb's avatars.2da to mod, it seems impractical.
[17:39:17] <tomprince_loki> No, the animation mod doesn't do a whole lot to the original game. It is mostly to allow a lot of different mods to use extra animations. So, more like future versions of BWP will depend on the animation mod.
[17:39:29] <tomprince_loki> http://www.shsforums.net/forum/594-infinity-animations
[17:40:27] <tomprince_loki> Another thing that mods would like to hack is clskills.2da, since BGT starts the bg2 engine off at level one. As does classic adventures.
[17:41:54] <tomprince_loki> Quick question: do you know, off the top of your head, whether we allow talking to charmed creatures?
[17:43:12] <fuzzie> In gemrb? I doubt it, but we have huge bugs in targetting like that.
[17:44:37] <fuzzie> But, I mean, adding a gemrb override seems an entirely reasonable idea, I just think that specifically avatars.2da will be a nightmare if you start modding it.
[17:45:38] <fuzzie> You are, mind you, entirely welcome to finish our avatars.2da. :-)
[17:47:42] <fuzzie> Another option would just be to check certain paths in a different order.
[17:48:34] <tomprince_loki> Well, that was why I was wondering if we could just move the game override folder before our own.
[17:48:46] <lynxlynxlynx> Edheldil_: many people also say autotools suck
[17:49:28] <fuzzie> tomprince: Shouldn't be too hard to check, given that IESDP has lists of the 2DA/IDS files.
[17:50:41] <tomprince_loki> Are those the only files we override? Or do we override spell files as well. I get the impression that those are mostly for things that the original engine doesn't implement as spells, but I thought there might have been files there anyway?
[17:50:59] <fuzzie> I don't believe so.
[17:51:48] <fuzzie> We override some projectiles, but I don't think by resref.
[17:52:04] <fuzzie> If we *do*, we can fix that, I'd think.
[17:52:29] <tomprince_loki> Excellent.
[17:53:05] <tomprince_loki> I think that makes the most sense, just look in the game override first.
[17:54:36] <fuzzie> We deliberately override spells.2da, apparently.
[18:00:37] <fuzzie> But that is surely not in the game override folder.
[18:00:58] <tomprince_loki> No.
[18:03:30] <fuzzie> http://fuzzie.org/nfs/gemrb/override_listings.txt
[18:05:10] <fuzzie> Some of that is possibly slightly modded. Should be sufficient to compare.
[18:11:09] <tomprince_loki> star*.pro, baldur.bcs, stat.ids, weapprof.2da
[18:11:24] <tomprince_loki> Not taking into account which files come from which game.
[18:11:42] <tomprince_loki> So I think that the star*.pro are the only ones that mater.
[18:12:15] <tomprince_loki> s/star/spar/
[18:12:29] <fuzzie> oh?
[18:12:36] <fuzzie> For which game are they an issue?
[18:14:05] <tomprince_loki> Let me see. Anyway, we have a copy of them for each game, but they are all identical.
[18:14:20] <fuzzie> We should have a copy for non-bg2 only.
[18:14:35] <tomprince_loki> Well, that maybe what is going on.
[18:15:21] <fuzzie> Not sure if stats.ids is a problem.
[18:15:44] <fuzzie> Otherwise it seems fine, from your list.
[18:19:55] <fuzzie> It's maybe a terrible idea, though, we might well need to override things.
[18:20:02] <fuzzie> I don't kn ow.
[18:24:49] <tomprince_loki> stats.ids is a problem anyway, since a bunch of mods want to change it.
[18:25:23] <fuzzie> Not relevant to gemrb, I think.
[18:26:04] <fuzzie> I mean, in the sense that gemrb just wants to be able to look things up in that copy, I *think*. We could rename it.
[18:26:30] <fuzzie> Maybe a bit painful if mods wants to start changing gemrb-specific 2da files which reference it, but that's kind of their problem at that point, I think.
[18:28:55] <tomprince_loki> Well, perhaps we shuold rename that? I know that the mods use it along with modified spells, so that AI scripts can see if certain spells have been cast.
[18:29:03] <tomprince_loki> At least, that is what I seem to recall.
[18:30:31] <fuzzie> It doesn't need to be overridden in gemrb for that, though.
[18:31:26] --> Gekz has joined #GemRb
[18:31:39] <tomprince_loki> Do they all get compiled down to numbers in what gemrb sees then?
[18:31:40] <-- Gekz_ has left IRC (Read error: Connection reset by peer)
[18:32:08] <fuzzie> Yes.
[18:32:23] <fuzzie> Well, it's a bit complicated. I'm not quite sure what the original engine supports.
[18:33:13] <fuzzie> I don't see any possible references to these files from bg2's bgmain.exe, though.
[18:35:39] --> Gekz_ has joined #GemRb
[18:35:48] <-- Gekz has left IRC (Read error: Connection reset by peer)
[18:35:52] <tomprince_loki> Well, weidu has a script compiler, so it must be for that.
[18:36:10] <fuzzie> Well, weidu inherited it from the Bioware script compiler.
[18:36:16] <tomprince_loki> Although I wonder if any of the numbers conflict, if it will be a problem.
[18:36:32] <fuzzie> We use it for looking up values from 2DA files.
[18:37:02] <fuzzie> And, well, possibly. I'd like to see one of these mods which changes it for a reason.
[18:37:49] <fuzzie> There are a few mods which end up manually patching the compiled versions to work around weidu insisting on the ids files.
[18:38:10] <fuzzie> But the only ids files we use for scripting are referenced in 'script.2da'.
[18:38:53] <tomprince_loki> The detectable spell component of http://www.gibberlings3.net/scsii/, as well as a bunch of other mods.
[18:39:06] <tomprince_loki> But I think that they have standardized that now.
[18:40:03] <fuzzie> Very helpful documentation there.
[18:42:22] <fuzzie> I'm not sure how that interacts with gemrb.
[18:42:28] <fuzzie> It depends entirely on the input to the component.
[18:43:52] <fuzzie> The one included with scsII seems incompatible at a glance.
[18:44:19] <tomprince_loki> Well, I think that the input is more or less standardized now.
[18:45:06] <fuzzie> I'm not sure there's much we can do about that at the moment.
[18:48:17] <fuzzie> We could add a "stupid mods who stomp over wide ranges of the limited stats space" game feature.
[18:50:34] <fuzzie> Maybe I'm misunderstanding what this is doing.
[18:50:54] <CIA-74> GemRB: 03wjpalenstijn * r8a930ea03dad 10gemrb/gemrb/plugins/ (6 files in 2 dirs): Use new BlitTile function for tile rendering
[18:50:55] <CIA-74> GemRB: 03wjpalenstijn * r88c7f2b19762 10gemrb/gemrb/plugins/SDLVideo/SDLVideo.cpp: Apply global tint to non-anchored sprites in BlitGameSprite
[18:51:01] <tomprince_loki> Looking at CREImporter, we do all the stats by name, rather than by index? Could all our extra stuff be >255, if that is the original engine limit.
[18:51:39] <fuzzie> The original engine also uses various of this 'extra stuff', so I don't see how this works.
[18:52:26] <tomprince_loki> Presumably, at least for BG2, none of the new indicies in DS stomp on any indicies the original engine used.
[18:52:48] <tomprince_loki> I don't know though. I haven't played around with it at all yet.
[18:52:51] <fuzzie> DS doesn't stomp on any indices.
[18:53:10] <fuzzie> It takes an input file for what to stomp on, and the scsII one certainly seems to be stomping on indices the original bg2 engine uses.
[18:53:31] <fuzzie> Hence my wondering if I'm misunderstanding what it does.
[18:55:26] <tomprince_loki> I think the DS in scsii is the master copy, just that it is modular, so that different mods can add
[18:55:28] <tomprince_loki> *more* to it, but I think most of the mods nowadays all use the same input.
[18:55:40] <tomprince_loki> I also think that some of it might, for ex, iwd2 specific.
[18:55:50] <tomprince_loki> Some of the stuff ds/scsii stomps on.
[18:56:41] <fuzzie> Some of it is not.
[18:56:49] <tomprince_loki> But, I'll experiment with it, to see what is going on.
[18:57:02] <fuzzie> It seems there might have been a lack of sharing as to which stats were used.
[18:58:13] <fuzzie> There are some notes that older versions of Detectable Spells were a complete disaster in that sense.
[18:58:40] <fuzzie> These files are dated before that, too.
[18:59:58] <fuzzie> Yeah, Detectable Spells is just broken.
[19:00:21] <fuzzie> Idiots. :|
[19:01:28] <tomprince_loki> So IE stomps on the stats they use? :)
[19:01:38] <fuzzie> No, they stomp on stats which IE uses for other things.
[19:01:44] <fuzzie> Such as thief skill bonuses.
[19:02:05] <fuzzie> Not sure about the other way around.
[19:03:35] <tomprince_loki> I am suprised that no-one has noticed.
[19:03:55] <fuzzie> Well, at least one person has, now that I search for this in particular.
[19:05:21] <fuzzie> ( http://www.google.com/search?q=stats+176-182+%22detectable+spells%22 )
[19:06:40] <tomprince_loki> Speaking of stats, should, it looks like we have three copies of the association. Should I write a generator to turn the stats.ids into ie_stats.(py|h) ?
[19:06:59] <fuzzie> We might want to work out what stats.ids does, first.
[19:07:26] <fuzzie> We should maybe have something to re-run make_formation.py, too.
[19:07:50] <fuzzie> I mean, sorry: We might want to work out what to do with stats.ids first.
[19:11:28] <fuzzie> wjp: You didn't commit the GetGlobalTint() change?
[19:11:46] <wjp> oh, no
[19:11:52] <fuzzie> Oh, I guess there's bound to be a map if you're blitting tiles anyway.
[19:12:29] <fuzzie> Oh, but then you changed GetGameSprite too. :)
[19:13:50] <fuzzie> (Your patch earlier seemed to work fine, by the way. Don't know if you changed it since.)
[19:14:21] <wjp> just some cleanup
[19:21:51] <tomprince_loki> Is the DEBUG_SEARCHMAP useful as is, or would it make sense to display it as tinting over the whole map?
[19:22:06] <fuzzie> It is already viewable as tinting over the whole map.
[19:22:15] <fuzzie> I'm not sure whether the seperate view is useful or not.
[19:22:20] <CIA-74> GemRB: 03fuzzie * r42f35980d96f 10gemrb/gemrb/plugins/Core/Game.cpp: GetGlobalTint(): consider weather *after* daytime
[19:22:35] <fuzzie> I've certainly only found the tinted view useful.
[19:23:42] <tomprince_loki> I was just wondering if there were any other issues with the Bitmap patch?
[19:26:05] <fuzzie> Well, at another glance: it silently truncates data, and the s/GetPixelIndex/GetPixel/ seems a bit silly.
[19:29:38] <tomprince_loki> What data is it truncating? All the color data for bpp>8? Do we do anything sane in that case right now anyway?
[19:30:11] <fuzzie> No, but if it's not handled, we should really do a printMessage LIGHT_RED thing.
[19:30:35] <fuzzie> I mean, in my opinion.
[19:31:48] <fuzzie> And the generic implementation doing exactly the wrong thing without a similar warning doesn't seem ideal either.
[19:31:59] <tomprince_loki> I'll add that then. And delete all references to DEBUG_SHOW_SEARCHMAP, since it is not thought to be usefull, and the implementation would be slightly complex after this patch.
[19:32:04] <fuzzie> I mean, I know the existing code gets it wrong, but it would be quickly obvious where it went wrong.
[19:32:09] <tomprince_loki> With the warning in both cases.
[19:32:51] <fuzzie> What's going on with the LightMap there, anyway?
[19:34:06] <fuzzie> Seems like there are two commits in here.
[19:34:43] <tomprince_loki> Nothing? Other than the fact that we are storing the Sprite2D, rather than the ImageMgr.
[19:34:50] <fuzzie> Well, yes, that. :)
[19:36:11] <fuzzie> I mean, I don't mind what's stored, but Sprite2D->GetPixel shouldn't really get called (outside the screenshot functions).
[19:36:48] <fuzzie> This is where I hastily grep to make sure we don't do it anywhere else in HEAD, but we don't seem to..
[19:37:20] <fuzzie> In any case, it seems worthy of a seperate commit.
[19:37:25] <tomprince_loki> I can split that out. They were just all together, and I was getting rid of all the GetPixel stuff on ImageMgr.
[19:38:34] <tomprince_loki> Any reason Sprite2D->GetPixel shouldn't be called?
[19:38:50] <fuzzie> It's likely to be slow, because Sprite2D is private to the video backend.
[19:40:14] <tomprince_loki> Well, my motivation was not to create a new class just to hold full color information, when Sprite2D already did that.
[19:40:15] <fuzzie> And ideally we don't want to require the video driver keep the pixels around in any usable form anyway.
[19:41:36] <tomprince_loki> It might make sense then to turn Bitmap into a template. With the current one being Bitmap<unsigned char>, and LightMap being Bitmap<Color>?
[19:41:39] <fuzzie> That is kind of annoying.
[19:42:05] <tomprince_loki> Then they would be logically in one commit.
[19:42:29] <fuzzie> Not very logically. :) I'll split it up if you want, though.
[19:42:40] * fuzzie squints.
[19:43:02] <tomprince_loki> I meant, if they both used a new templated Bitmap<T> class.
[19:43:52] <fuzzie> Well, if you do that, it causes problems if we turn out to need the palette after all.
[19:45:41] <fuzzie> Which is the most annoying part of this whole change.
[19:46:30] <fuzzie> I mean, the bit where I'm not entirely sure what the consumer code is meant to be doing.
[19:47:28] <tomprince_loki> Well, I think that in that case, GetBitmap should take a function to map colors to the values we want.
[19:48:25] <fuzzie> I'm not sure.
[19:49:09] <tomprince_loki> What I mean, is that I don't think ImageMgr is the place for all that logic, whatever we end up needing to do. So, even if we need to change the interface later, I think this is still a good first step.
[19:49:56] <fuzzie> Well, I mean, moving it out is a good step. Moving into a template with multiple functions, I'm not so sure about.
[19:50:58] <tomprince_loki> Well, I was just think of Bitmap as a 2D array of some kind. Of which we need two, right now. One for searchmap/heightmap, and one for lightmap.
[19:51:30] <fuzzie> Well, my worry is that I don't want to add a 500kB/area memory hit because of bad design.
[19:52:11] <fuzzie> Although on the other hand, we don't actually need the stupid heightmap loaded for more than one area, in theory..
[19:52:59] <tomprince_loki> Is it actually 500kB/area for the heightmap?
[19:53:08] <fuzzie> For the largest areas.
[19:53:15] <fuzzie> Of which there are almost none.
[19:53:33] <fuzzie> So I wouldn't worry about it.
[19:53:58] <tomprince_loki> Well, don't we take the hit anyway, by keeping the ImageMgr around. We might take a 2x hit on that, if the heightmap is 4bits, and we expand it to 8.
[19:54:29] <tomprince_loki> The lightmap would be a 4x or 8x hit, going from 4/8bpp to 32bpp.
[19:54:34] <fuzzie> Anyway.
[19:54:35] <fuzzie> Sorry.
[19:54:36] <fuzzie> Go ahead.
[19:54:47] <tomprince_loki> One commit, with templated Bitmap?
[19:54:49] <fuzzie> I would prefer it in a "add Bitmap class" commit and another commit actually using it.
[19:55:02] <tomprince_loki> Okay. 3 then. :)
[19:55:05] <fuzzie> Assuming it's a trivial split, but I hope it is.
[19:55:43] <fuzzie> But you're right that logic like GetPixel definitely needs to be out of the ImageMgr.
[19:55:59] <tomprince_loki> I've done enough rebasing and reorganizing that it won't be hard to split. :)
[19:56:05] <fuzzie> I don't like changing 'GetPixelIndex' to 'GetPixel' everywhere when we're still retrieving the index, though.
[19:56:55] <tomprince_loki> Well, for Lightmap it will be an actual pixel.
[19:56:59] <fuzzie> Not sure whether there's a better name.
[19:57:54] <tomprince_loki> I could just overload operator () on it.
[19:58:07] <fuzzie> That doesn't really help the clarity I'm hoping for. :)
[19:58:08] <tomprince_loki> No, that wouldn't work, since we have it as a pointer.
[19:59:17] <tomprince_loki> I don't know what to call the function on ImageMgr, now that we will have two.
[20:02:21] <tomprince_loki> Can't be a template, since it needs to be virtual.
[20:02:33] <wjp> hm, how do I prevent cmake from putting back NullSound.so every time?
[20:02:46] <tomprince_loki> GetIndexData for Bitmap<unsigned char> and GetBitmap<Color>
[20:02:54] <tomprince_loki> SkipPlugin or DelayPlugin?
[20:03:10] <tomprince_loki> in gemrb.cfg
[20:03:50] <tomprince_loki> fuzzie: Do you mind me using Sprite2D to populate Bitmap<Color>?
[20:03:54] <tomprince_loki> So, only at load time?
[20:04:40] <wjp> tomprince_loki: ah, thanks. I guess I should revert to .cfg.sample again sometime :-)
[20:05:58] <fuzzie> tomprince_loki: I think we shouldn't be using GetPixel at all.
[20:06:18] <tomprince_loki> Or, just copy the relevant lines. If you -DDATA_DIR=$SRCDIR/gemrb -DPLUGIN_DIR=$SRCDIR/gemrb/plugins you don't need those in your config at all.
[20:06:33] <tomprince_loki> Or, at least you souldn't.
[20:06:53] <fuzzie> It seems like messing with Sprite2D is just going to restrict what a video driver can do.
[20:07:34] <tomprince_loki> Well, I don't want to duplicate the logic of gettinn all the pixel data into Color struct into each of the ImageMgr plugins, when we already have code to do it. I don't know how else to go about it.
[20:08:34] <fuzzie> Perhaps the individual ImageMgr plugins should just have private functions which hand the necessary data back to ImageMgr.
[20:09:31] <fuzzie> But that becomes quickly out-of-scope of just this change.
[20:10:19] <fuzzie> I think it would be more sensible to get Bitmap and the searchmap/heightmap into HEAD, and then worry about the rest.
[20:11:11] <tomprince_loki> Yes. Do GetIndexData and GetBitmap make sense for the ImageMgr functions?
[20:11:26] <fuzzie> I suppose we could then convert screenshots to return a Bitmap<Color> and sabotage Sprite2D::GetPixel.
[20:12:02] <fuzzie> wjp: thoughts?
[20:12:25] <fuzzie> tomprince_loki: GetIndexBitmap, maybe? but what you think is best, I think.
[20:13:05] <fuzzie> I think we might well be better off with seperate classes.
[20:13:49] <fuzzie> You could have an 'Image' which takes over things like the lightmap, and the screenshot resizing.
[20:16:15] <fuzzie> That stupid GetPixelTransparent is ruining my grand design, though.
[20:17:22] <fuzzie> Although it's called (at runtime) seldom enough that I guess it's not too bad.
[20:21:10] <fuzzie> We could certainly fix the calls, too.
[20:21:56] <fuzzie> But perhaps it's not worthwhile. Not hearing feedback! :)
[20:22:12] <wjp> hmm
[20:27:55] <-- tomprince_loki has left IRC (Ping timeout: 265 seconds)
[20:29:04] --> tomprince_loki has joined #GemRb
[20:33:50] <tomprince_loki> or.cz/bitmap: (testing now).
[20:34:03] <-- tomprince_loki has left IRC (Quit: tomprince_loki)
[20:34:06] <wjp> tricky issue
[20:34:19] --> tomprince_loki has joined #GemRb
[20:34:29] <tomprince_loki> or.cz/bitmap (testing now)
[20:35:32] * wjp implemented gamma-correct (2.2, anyway) scaling for screenshots and portraits
[20:35:46] <tomprince_loki> And it doesn't compile yet. :)
[20:37:12] <fuzzie> Removing DEBUG_SHOW_LIGHTMAP is not such a wonderful idea, one reason for my pondering.
[20:39:51] <fuzzie> I mean, not a showstopper, but not very nice either.
[20:40:20] <fuzzie> Since that one *is* removing functionality without a (runtime) gain, I think.
[20:41:18] <tomprince_loki> Which means that we need LightMap as a Sprite2D, or a Bitmap<Color> to Sprite2D converter.
[20:41:27] <fuzzie> Maybe read the log?
[20:41:51] <fuzzie> Oh, I'm not being very clear there.
[20:41:56] <fuzzie> Still.
[20:42:36] --> zefklop has joined #GemRb
[20:42:51] <-- zefklop has left #GemRb
[20:43:12] <wjp> well, that was a short visit after such a long time :-)
[20:43:50] <tomprince_loki> Well, if we split them up as two classes, that would essentialy be s/Bitmap<unsigned char>/Bitmap/, s/Bitmap<Color>/Image/, and we'd still need an Image->Sprite2D converter.
[20:43:57] <tomprince_loki> If that is what you meant.
[20:44:10] <CIA-74> GemRB: 03wjpalenstijn * r9945b63cafb8 10gemrb/gemrb/plugins/Core/ (Video.cpp Video.h): Correct for gamma in SpriteScaleDown
[20:44:12] <fuzzie> We'd need a Image->Sprite2D converter anyway, I think.
[20:44:29] <wjp> Video::CreateSprite already basically does that, right?
[20:45:32] <tomprince_loki> Yes.
[20:45:35] <fuzzie> I mean, if you converted the other logic to do that.
[20:45:43] <fuzzie> I just wanted discussion. :)
[20:46:37] <wjp> aside from any implementation issues, I kind of like the idea of having a bitmap class outside of any importers/video drivers
[20:48:14] <fuzzie> I like the idea of a sprite/image class, I just think it deviates quickly from the original intention for Bitmap.
[20:48:45] <tomprince_loki> Well, so we have both. Which is entirely reasonable.
[20:49:26] <tomprince_loki> We would probably want to rename ImageMgr::GetImage as ImageMgr::GetSprite.
[20:49:52] <fuzzie> Sounds fine.
[20:49:52] <tomprince_loki> Because I think we want to force Core/Image to be 32bpp.
[20:50:03] <fuzzie> I imagine that is fine.
[20:51:00] * wjp nods
[20:51:04] <fuzzie> I imagine { add Bitmap, remove unneeded searchmap bitmap view, modify searchmap/heightmap, s/GetImage/GetSprite, add Image, modify lightmap, remove unneeded bits from ImageMgr } set of commits?
[20:51:21] <fuzzie> I don't mean to imply you should be doing this, I'd be happy to do the work if you're fed up at this point.
[20:51:46] <tomprince_loki> No, not at all. I think I will start with s/GetImage/GetSprite2D/ ?
[20:51:57] <wjp> what would an 'Image' be?
[20:52:12] <fuzzie> wjp: An array of Color, I was thinking.
[20:52:25] <wjp> and Bitmap?
[20:52:41] <fuzzie> Bitmap would be an array of 'unsigned char', for searchmaps and heightmaps.
[20:52:58] <wjp> ah, instead of the templated one now in that branch
[20:53:07] <fuzzie> GetPixelIndex on BMPImporter is expensive enough that it shows up in profiles.
[20:53:22] <fuzzie> Because they're mostly 4-bit images, I think.
[20:53:34] <tomprince_loki> Have a look at the image branch for what Bitmap would be.
[20:53:57] <fuzzie> tomprince_loki: I don't mean to dictate the order of your commits, sorry. :)
[20:54:03] <tomprince_loki> No problem.
[20:54:54] <fuzzie> Would still like those warnings if possible.
[20:54:58] <fuzzie> But I can add them in another commit.
[20:55:01] <wjp> tomprince_loki: are Bitmap.{h,cpp} missing?
[20:55:51] <tomprince_loki> In the bitmap branch? Maybe. There are some compiler errors in what I pushed. I have the fixed locally, but since I am doing other something different anyway, I didn't push the fixes. :)
[20:56:36] <wjp> I'll look in the image branch
[20:59:35] <wjp> is there an easy way to enable profiling with cmake?
[20:59:50] <fuzzie> wjp: You can't use gprof-style profiling with gemrb.
[20:59:51] <tomprince_loki> Probably -DCMAKE_CXX_FLAGS=...
[21:00:15] <fuzzie> It only profiles the main binary, it won't trace into shared libraries.
[21:00:54] <fuzzie> Don't know if that's what you wanted.
[21:02:31] <wjp> hm, no oprofile in this kernel
[21:03:06] <tomprince_loki> There is perf, from the kernel source, which works on recent stock kernels.
[21:07:14] <fuzzie> I have not been profiling on x86, so it would be interesting to know what's different.
[21:07:45] --> ratpor has joined #GemRb
[21:13:05] <fuzzie> Although I have not recently been profiling on ARM, which is perhaps the only place it matters..
[21:21:45] <fuzzie> But I don't see any negative consequences to any changes suggested here, I hope?
[21:22:37] --> cfchris6_ has joined #GemRb
[21:25:38] <-- cfchris6 has left IRC (Ping timeout: 258 seconds)
[21:28:08] <fuzzie> wjp: I guess you can close that bug now, by the way.
[21:29:02] <wjp> ah, the green one
[21:30:26] <wjp> ooh, oldest open one :-)
[21:30:30] <fuzzie> yes. :)
[21:32:39] <fuzzie> I really don't understand what's going on with all this colouring stuff.
[21:37:26] <tomprince_loki> or.cz/bitmap now has the first couple of patches in the series.
[21:37:46] <wjp> fuzzie: any specific questions or functions/variables which are confusing?
[21:40:05] <fuzzie> I've been trying to work out why the paperdoll is flaky.
[21:40:16] <fuzzie> It seems that the colours are not being updated when you remove an item from an actor.
[21:42:05] <wjp> at all, or delayed?
[21:42:24] <fuzzie> delayed.
[21:42:50] <fuzzie> Pretty sure it's not anything colour-specific,now.
[21:43:35] <wjp> does it still do that with AC too?
[21:44:15] <lynxlynxlynx> yes, since pause also affects effects
[21:44:56] <fuzzie> The fxqueue.Cleanup() to remove dead effects is in Map::UpdateScripts.
[21:45:01] <tomprince_loki> At least after we apply the core patch, I think we should move config.h to includes. I ran into the wild thing of having some random file called list in the root directory, and the compiler picking it up as <list>. :)
[21:47:09] <fuzzie> I put it in Map::UpdateScripts, too. Bit too tired to work out if I can move/copy it around.
[21:49:05] <fuzzie> lynxlynxlynx: That happens in the original game?
[21:49:26] <wjp> hm, IsPixelTransparent shows up extremely high in the profile here
[21:49:27] <lynxlynxlynx> no, in the original the inventory refreshes immediately
[21:49:46] <fuzzie> wjp: Should only be during startup?
[21:50:03] <wjp> I started oprofile after loading a game
[21:50:13] <fuzzie> .. huh.
[21:50:30] <wjp> hm, or is it accumulating over multiple runs? *reads manual*
[21:50:44] <fuzzie> You have to flush the old data first, yes.
[21:51:22] <fuzzie> lynxlynxlynx: Which would you prefer?
[21:51:46] <wjp> right, gone from the profile now
[21:52:19] <wjp> BlitTile_internal and BlitGameSprite score highest now
[21:52:27] <lynxlynxlynx> you mean where to put the cleanup call? I don't have an informed opinion
[21:53:15] <fuzzie> wjp: And SDL itself?
[21:53:57] <tomprince_loki> Is it reasonable to depend on sizeof(Color) == 4, so I can use Color objects cast to ieDword as the masks to CreateSprite?
[21:54:21] <wjp> fuzzie: under BlitTile_internal now, but that's not surprising since tile blitting used to be SDL, but is now our own code
[21:54:43] <fuzzie> tomprince_loki: That is not quite the right thing to ask, I thin.
[21:54:45] <fuzzie> think.
[21:55:35] <fuzzie> But, you mean, you want to set the relevant bits to 0xff so you can pass a Color* in as the pixels?
[21:56:27] <tomprince_loki> Yes.
[21:56:54] <fuzzie> That seems fine to me.
[21:57:39] <fuzzie> I'm not sure if there would be terrible alignment disasters lurking?
[21:57:55] <fuzzie> But that can always be dealt with.
[21:58:23] <fuzzie> wjp: Ah.
[21:58:50] <CIA-74> GemRB: 03tom.prince * rb1c4c5d3a636 10gemrb/gemrb/plugins/ (19 files in 8 dirs):
[21:58:50] <CIA-74> GemRB: ImageMgr: Rename GetImage to GetSprite2D.
[21:58:50] <CIA-74> GemRB: This if so we can use GetImage for something else.
[21:58:50] <CIA-74> GemRB: Signed-off-by: Tom Prince <cougar@hermes>
[21:59:13] <fuzzie> tomprince_loki: The next commit still has 'GetPixel' and no warnings?
[21:59:46] <tomprince_loki> Still GetPixel, and I forgot the warning.
[22:00:04] <fuzzie> If it's not returning a pixel..
[22:01:04] <fuzzie> It seems an unnecessary change unless we're actually going to store non-indexes in it.
[22:01:09] <fuzzie> But I argued this before, so never mind.
[22:01:11] <tomprince_loki> It is a pixel of the bitmap. If you have something better than GetPixel and GetPixelIndex ...
[22:01:22] <tomprince_loki> Well, we might switch the explored bitmap over to it?
[22:02:27] <fuzzie> Well, I mean, GetPixel and GetPixelIndex seem as bad as each other, and at least the latter doesn't require changing anything and makes it obvious we're not fishing pixels out.
[22:02:40] <fuzzie> Should probably change all the 'unsigned int' to 'unsigned char', though.
[22:03:04] <fuzzie> So, *shrug*.
[22:03:55] <fuzzie> Going to have to touch all the lines for that anyway.
[22:04:47] <fuzzie> I'm just thinking about when I come to touch this code again, I'd prefer to say "right, this is a Bitmap" rather than "I wonder what this is calling GetPixel() on?".
[22:06:18] <tomprince_loki> Well, I think there is a better name, but I don't think it is GetPixelIndex. And I don't know what it is.
[22:06:53] <fuzzie> I agree with that.
[22:07:04] <lynxlynxlynx> what does it get?
[22:07:49] <fuzzie> An index into an imaginary BMP palette. Or, as an alternative view, a point of data from a 2D array.
[22:08:24] <tomprince_loki> I prefer the second view.
[22:08:36] <tomprince_loki> Which is why I don't like GetPixelIndex.
[22:09:14] <fuzzie> It is a reasonable view, but GetPixel doesn't work for me either way. :)
[22:09:30] <lynxlynxlynx> GetImaginaryPixel :)
[22:10:28] <fuzzie> 'GetElementAt' or similar, I think.
[22:10:40] <fuzzie> But 'GetElementAt' itself is just as awful as the others.
[22:10:52] <tomprince_loki> Just ->at(...) ?
[22:11:20] <fuzzie> I think 'GetAt' or something would be more consistent with everything else.
[22:12:24] <lynxlynxlynx> sounds fine to me
[22:12:32] <tomprince_loki> Me to.
[22:12:58] <tomprince_loki> Should I also change things to unsigned char?
[22:13:07] <lynxlynxlynx> this->PutAt(bed);
[22:13:12] <tomprince_loki> While I am changing those lines.
[22:13:30] <fuzzie> Please.
[22:13:31] <tomprince_loki> bed->Put(this)
[22:13:38] <-- lynxlynxlynx has left IRC (Remote host closed the connection)
[22:13:42] <tomprince_loki> s/this/that/ :)
[22:14:24] <CIA-74> GemRB: 03fuzzie * r34f713e92805 10gemrb/gemrb/ (docs/en/CheatKeys.txt plugins/Core/GameControl.cpp): remove DEBUG_SHOW_SEARCHMAP and update CheatKeys.txt
[22:15:47] <fuzzie> I've had that sitting in my tree; kind of amused that I seem to have ended up modifying even the comment the same.
[22:16:25] <fuzzie> why the - video->FreeSprite( spr );?
[22:16:32] <fuzzie> Some snippet of a future patch?
[22:17:05] <tomprince_loki> Yes.
[22:18:46] <fuzzie> Do you not leak the SearchMap/LightMap ImageMgr objects now?
[22:19:04] <fuzzie> Sorry, I know I'm looking at an older version here..
[22:19:07] <tomprince_loki> Yes ...
[22:21:00] <fuzzie> And sorry, question wasn't intended badly, was wondering.
[22:21:10] <tomprince_loki> I don't assume they do.
[22:31:41] <tomprince_loki> or.cz/bitmap pushed. It compiles. I haven't actually tested it. :)
[22:36:35] <fuzzie> Looks good to me.
[22:38:58] <tomprince_loki> Should I change SmallMap to be a Sprite2D as well?
[22:39:16] <fuzzie> Hmm.
[22:40:05] <fuzzie> Can't think why not.
[22:52:16] <tomprince_loki> There is everything.
[22:53:26] <tomprince_loki> Still uses Sprite2D::GetPixel, but I think that is cleaner than anything else right now.
[22:54:03] <tomprince_loki> Unless we want to implement GetSprite2D in terms of GetPalette/GetImage/GetBitmap. Which wouldn't be unreasonable, but is a more extensive change.
[22:57:27] <tomprince_loki> And am missing adding Image.cpp to Makefile.am ... :)
[23:03:56] <fuzzie> ok. looks good. will check it tomorrow. thankyou
[23:04:24] <tomprince_loki> With fixes for tomorrow. :)
[23:04:31] <fuzzie> i think we want to implement GetSprite2D and GetImage in terms of some more efficient internal function, really..
[23:05:02] <fuzzie> maybe there isn't a more efficient way than GetImage/GetBitmap though. we'll see some other time :)
[23:05:57] <tomprince_loki> Well, those two functions could probably be implemented more effeciently than they are now. By passing Bitmap/Image the array, rather than constructing it pixel by pixel.
[23:14:56] <Edheldil_> good night
[23:15:00] <-- Edheldil_ has left IRC (Quit: Really?)
[23:17:19] --> Gekz has joined #GemRb
[23:17:55] <-- Gekz_ has left IRC (Read error: Connection reset by peer)
[23:19:46] --> edheldil_ has joined #GemRb
[23:20:23] <-- edheldil_ has left IRC (Client Quit)
[23:38:53] --> Gekz_ has joined #GemRb
[23:38:58] <-- Gekz_ has left IRC (Changing host)
[23:38:58] --> Gekz_ has joined #GemRb