[00:37:16] <tomprince_loki> Gekz: Does cmake still work on win32/osx with all the cmake updates?
[00:38:59] <Gekz_> no idea
[00:41:29] <Gekz_> tomprince_loki: would you be able to statically compile rtorrent for me
[00:41:43] <Gekz_> or give me a temporary shell account so I may do this myself?
[00:41:46] <Gekz_> my linode shell account has a seriously broken compile environment
[00:43:16] <tomprince_loki> Maybe. What glibc/arch is it?
[00:43:51] <Gekz_> GNU C Library (EGLIBC) stable release version 2.10.1, by Roland McGrath et al.
[00:44:08] <Gekz_> 2.6.32-x86_64-linode11
[00:56:16] <-- Gekz_ has left IRC (Quit: Leaving)
[00:56:52] --> Gekz_ has joined #GemRb
[01:12:44] <-- Gekz_ has left IRC (Quit: This computer has gone to sleep)
[01:36:38] --> Gekz_ has joined #GemRb
[01:38:37] <-- Gekz_ has left IRC (Client Quit)
[01:38:56] --> Gekz_ has joined #GemRb
[01:38:59] <-- Gekz_ has left IRC (Changing host)
[01:38:59] --> Gekz_ has joined #GemRb
[02:55:46] <-- Gekz_ has left IRC (Quit: This computer has gone to sleep)
[04:34:18] <-- ratpor has left IRC (Quit: Get used to disappointment.)
[04:48:57] <tomprince_loki> Bug with widescreen mod: opening a container makes the bottom half of the screen unclickable. Actually, it seems there are a number of hardcoded screen size things that are buggy like this.
[05:39:16] <-- tomprince_loki has left IRC (Ping timeout: 245 seconds)
[06:41:37] <-- Gekz has left IRC (Read error: Connection reset by peer)
[06:43:08] --> lynxlynxlynx has joined #GemRb
[06:43:08] --- ChanServ gives channel operator status to lynxlynxlynx
[06:52:27] --> Gekz has joined #GemRb
[08:04:47] <-- Gekz has left IRC (Read error: Connection reset by peer)
[08:04:49] --> Gekz_ has joined #GemRb
[08:08:43] --> Nomad010 has joined #GemRb
[08:17:52] <-- Nomad010 has left IRC (Remote host closed the connection)
[08:22:44] --> Nomad010 has joined #GemRb
[08:30:29] <fuzzie> tomprince: oh? i was discussing the encumbrance in here in the last few days, but i don't see anything else hardcoded.
[08:32:52] <wjp> morning
[08:32:58] <fuzzie> morning :-)
[08:35:57] <-- Cable_ has left IRC (Remote host closed the connection)
[08:44:48] <Edheldil> hello
[11:22:27] <Gekz_> tomprince: it worked well
[11:22:28] <Gekz_> thanks brah
[13:30:49] <tomprince> mp.
[13:31:03] <tomprince> s/mp/np/
[13:31:53] <tomprince> fuzzie: I'm not sure it is hard coded.
[13:32:13] <fuzzie> Well, I respond to "hardcoded screen size things". :)
[13:33:36] <tomprince> I do know that when a container is open, the screen between the "normal" top of the container, and the actual top of the container window is unclickable, and not updated.
[13:33:48] <fuzzie> How did you apply the mod?
[13:35:38] <tomprince> weinstall widescreen, with GemRB option.
[13:36:22] <fuzzie> Do you get any errors on the console from the GameControl?
[13:37:59] <tomprince> [CHUImporter]: Cannot Load BackGround, skipping
[13:38:11] <tomprince> [CHUImporter]: Special Button Control, Skipping Image Loading
[13:38:22] <tomprince> Are the only vaguely relevant things.
[13:40:07] <fuzzie> The "normal" top of the container being the 1024x768 position?
[13:41:02] <tomprince> I think so.
[13:42:13] <tomprince> It seems that, for whatever reason, there is *no* window there.
[13:42:56] <fuzzie> And you have gemrb set to the same resolution you passed to the widescreen mod, I assume.
[13:43:56] <tomprince> The cursor stays whatever it last was, so the hand, if moving up, or the walk/no wallk if coming from the main window.
[13:43:59] <tomprince> Yes.
[13:44:30] <fuzzie> What is that resolution?
[13:45:29] --> tomprince_loki has joined #GemRb
[13:46:50] <fuzzie> The code to keep the GameControl window at the right size is irritatingly flaky, but I don't see why the widescreen mod would affect that.
[13:48:25] --> zefklop has joined #GemRb
[13:48:46] <tomprince_loki> http://www.math.uwo.ca/~rprince5/container.png
[13:49:04] <tomprince> 1280*1024
[13:50:38] <fuzzie> And gemrb is loading CGUI8024, not GUIW12?
[13:51:46] <tomprince> Yes.
[13:52:06] <fuzzie> How strange.
[13:52:23] <fuzzie> Could you send me the CHU file?
[13:52:27] <fuzzie> Or upload it somewhere, etc.
[13:54:32] <tomprince> cgui1210.chu at the same place.
[13:56:56] <fuzzie> That container.png didn't finish uploading?
[13:57:17] <tomprince> Maybe not.
[13:58:31] <fuzzie> (I can see the likely problem; the container window in that CHU file has empty space at the top.)
[13:58:46] <tomprince> Try container2.png
[13:59:10] <fuzzie> Oh, huh, that's a huge area.
[13:59:50] <fuzzie> The container window claims to be 502 pixels high, from the bottom of the screen.
[14:02:11] <fuzzie> And gemrb is being silly and assuming that it actually needs 502 pixels of vertical space. :)
[14:03:22] <tomprince_loki> Is it from the bottom of the screen? Look at dltcep, the position is 934, which seems sane.
[14:03:34] <tomprince_loki> At least, if I am reading it right.
[14:03:37] <fuzzie> Yes, that is why it renders fine.
[14:03:45] <fuzzie> The container window controls are at the top of the window.
[14:04:14] <tomprince_loki> But then, shouldn't the extra height be below the bottom of the screen?
[14:04:16] <fuzzie> Yes.
[14:04:25] <fuzzie> But the GameControl didn't expect CHU files to do that kind of stupid trick. :)
[14:04:52] <tomprince> Ah..
[14:05:07] <fuzzie> So when it calculates its own size, it reserves 502 pixels for the container window, hence all the space.
[14:05:53] <fuzzie> The easiest fix is probably to 'fix up' the window at load time to provide the correct height.
[14:06:26] <tomprince_loki> Well, would it not be easier to have the game control look at the top of the window instead?
[14:06:31] <fuzzie> But it's probably nicer to make the GameControl a bit smarter.
[14:08:30] <fuzzie> tomprince: Well, then we have to special-case "this window does not stack", but it looks like we do that anyway.
[14:08:38] <fuzzie> Try changing GameControl.cpp:2290?
[14:12:36] <-- tomprince_loki has left IRC (Ping timeout: 245 seconds)
[14:13:06] <fuzzie> (Don't try rewriting that code without access the other games, btw, it is a mess.)
[14:14:08] <-- tomprince has left IRC (Ping timeout: 265 seconds)
[14:16:04] --> tomprince has joined #GemRb
[14:17:44] --> tomprince_loki has joined #GemRb
[14:20:19] <-- Nomad010 has left IRC (Ping timeout: 258 seconds)
[14:22:20] <tomprince> Changing it to Height = win->Ypos doesn't do anything.
[14:22:53] <fuzzie> You changed Owner->Height?
[14:23:14] <tomprince_loki> Yes.
[14:24:13] <fuzzie> Oh, it's the case on line 2313.
[14:24:35] <fuzzie> That's kind of annoying, although I know why.
[14:24:52] <fuzzie> I guess you can at least see whether that's your bug.
[14:25:41] <tomprince_loki> It is.
[14:33:26] <Gekz_> guys
[14:33:34] <Gekz_> it's 00h33
[14:33:38] <Gekz_> and I am really tired
[14:33:43] <Gekz_> but I have a report due in 5 hours
[14:33:44] <Gekz_> what do I do
[14:34:06] <fuzzie> Pour coffee into your ears.
[14:34:52] <Gekz_> that sounds fucking stupid
[14:34:53] <Gekz_> but I'll go do it
[14:35:48] <fuzzie> Well, I live on coffee, so perhaps a bad person to ask. :)
[14:35:58] <Gekz_> I had two coffees
[14:36:00] <Gekz_> but I also had a vodka
[14:36:03] <Gekz_> I'm doing ti wrong
[14:36:08] <Gekz_> also, i've been sexually active today
[14:36:12] <Gekz_> DOIGN IT WRONG
[14:36:35] <wjp> maybe you also shouldn't be on IRC :-)
[14:36:59] <Gekz_> this is my 10 minute break
[14:37:02] <Gekz_> I've been working on it for 3 hours
[14:42:11] <Gekz_> oh shit
[14:42:13] <Gekz_> apparently I finsihed
[14:44:55] --> kettuz has joined #GemRb
[14:58:01] <tomprince_loki> I don't know what effect it would have on performance, but from a "correctness" point of view, would it make sense to always have the game control full screen.
[14:58:29] <tomprince_loki> That way, mods could even do crazy things like put the inventory at the top, and things would *just work*.
[14:58:37] <tomprince_loki> Maybe work, anyway.
[14:59:15] <fuzzie> No.
[14:59:21] <fuzzie> It would be incorrect for various reasons.
[14:59:55] <fuzzie> You need an accurate way to calculate the viewport, and the GameControl resizing itself is as good as any.
[15:01:56] <tomprince_loki> Is that for things like spells that affect everything in viewport? .... for scrolling.
[15:02:52] <fuzzie> For scrolling, for viewport centering, for "ensure object is on-screen", etc etc.
[15:03:36] <fuzzie> That doesn't mean you can't change the code so that mods can put windows wherever they want, though.
[15:04:38] <tomprince_loki> ... not that I know of any mods that want to do that. :)
[15:05:22] <tomprince_loki> I'm just not sure how to determine whether a given window should shrink the GameControl or not, if we let them be anywhere.
[15:06:39] <fuzzie> It's also something which some of the other games do quite differently.
[15:07:24] <tomprince_loki> PsT in particualr. :)
[15:07:48] <tomprince_loki> Does IWD2 do something similiar? That being the only game I never played the original of.
[15:07:57] <fuzzie> No.
[15:08:41] <fuzzie> It has a combined portrait/action bar and a combined message/menu bar, though.
[15:09:03] <fuzzie> PS:T's floating window is just handled seperately, so it is not so bad.
[15:28:12] --> Nomad010 has joined #GemRb
[15:48:41] <-- zefklop has left IRC (Read error: Connection reset by peer)
[15:49:01] --> zefklop has joined #GemRb
[16:31:46] --> |Cable| has joined #GemRb
[17:28:36] <fuzzie> "fix the viewpoint centering" is something on the todo list, actually. Hm.
[17:28:55] <fuzzie> No time right now, anyhow.
[17:29:42] <wjp> hm, speaking of centering: is it me or are the actors less centered in their circles than they used to be?
[17:29:54] <tomprince_loki> Well, I can carry the hack around locally, for now.
[17:30:41] <fuzzie> wjp: You seemed to have an off-by-one issue in the rectangle rendering around the top portrait in that screenshot.
[17:31:18] <wjp> which screenshot?
[17:31:32] <fuzzie> tomprince_loki: It would be nice to detect resizing for partially off-screen windows, as a fix for now.
[17:32:04] <wjp> http://www.usecode.org/gemrb/mask_post.png ?
[17:32:06] <fuzzie> I know it's nice having correct designs, but I would really like to get fixes for bugs committed, even if they're only temporary.
[17:32:13] <fuzzie> wjp: yes.
[17:33:36] <fuzzie> I noticed it yesterday, just mentioning it in case it's related in some way..
[17:38:06] <wjp> at some point there was an issue that actors weren't drawn in the right place relative to the searchmap grid. Any idea what the status of that is?
[17:39:15] <fuzzie> Um. No. I fiddled with it a few times.
[17:40:18] <fuzzie> Doesn't look like I changed anything relevant to the standing-still positions.
[17:42:10] <tomprince_loki> If I knew what the right temporary fix was, that didn't break other things. I don't understand the GUI interface well enough to be confortable hacking it.
[17:42:13] <fuzzie> I'm not very happy about what I *did* change.
[17:43:49] <fuzzie> wjp: 76c31a98 might've fixed some related issues.
[17:46:45] <wjp> hm, indeed
[17:48:50] <fuzzie> But I've just been copying and altering the existing code, I guess.
[17:52:20] <fuzzie> Another item in the "needs a complete rewrite, once we finished rearchitecting the callers" list.
[18:22:50] <tomprince_loki> How about d1f081f and 0c1c218?
[18:28:12] <tomprince_loki> That second one should be 66b8ff578b
[18:30:31] <-- tomprince_loki has left IRC (Read error: Connection reset by peer)
[18:32:55] --> tomprince_loki has joined #GemRb
[18:35:59] <fuzzie> does 66b8ff578b build?
[18:36:39] <fuzzie> not at machine right now, but i thought it didn't
[18:41:56] <wjp> it doesn't
[18:42:27] <tomprince_loki> No, it must have broken when I rebased it.
[19:19:47] <tomprince> or.cz/savegame is fixed.
[19:30:59] <fuzzie> s/return -1;/return false;/ ?
[19:31:10] <fuzzie> sorry, didn't think to commit this one first.
[19:33:54] <tomprince> Yes.
[19:34:15] <fuzzie> Any objection to making it a member of the class? Do you have further plans?
[19:35:07] <fuzzie> Hm, I guess there's a whole bunch of static functions lurking in there anyway.
[19:35:26] <tomprince> Nothing directly. But it doesn't need access to any of the members of SaveGameIterator, and this way, it doesn't get into the header file, and so doesn't cause spurious recompiles.
[19:35:44] <tomprince> I do want to do further cleanups there, but I am not sure what yet.
[19:37:17] <tomprince> We were talking earlier about where I want it to end up, but I am not sure how to get there yet. :)
[19:38:44] <fuzzie> *nod*
[19:39:09] <CIA-74> GemRB: 03tom.prince * r2feaca33f251 10gemrb/gemrb/plugins/Core/SaveGameIterator.cpp:
[19:39:09] <CIA-74> GemRB: SaveGameIterator: Factor out actual saving of the game.
[19:39:09] <CIA-74> GemRB: Signed-off-by: Tom Prince <firstname.lastname@example.org>
[19:44:40] <fuzzie> The Bitmap changes look fine to me now, but I don't have the time to test right now.
[19:46:02] <fuzzie> Not so sure about all of Image, but honestly it's going to be pretty harmless just for LightMap..
[19:46:30] <tomprince> No rush. How about moving the delete to Plugin::Release, rather than having all the subclasses do it. And moving Core out of plugins.
[19:46:55] <tomprince> I don't disagree with you about Image, but I think that it is a step in the right direction.
[19:46:59] <fuzzie> Both of those are pending someone making sure MSVC actually cooperates.
[19:47:04] <fuzzie> Yes, it is a step in the right direction.
[19:47:23] <fuzzie> The SmallMap -> Sprite2D seems harmless too.
[19:47:35] <fuzzie> The enum thing seems a bit change-for-the-sake-of-change, unless I miss something.
[19:47:55] <tomprince> And I think that the interface is right, just the implementation could be cleaned up, which shouldn't affect the callers now.
[19:48:10] <fuzzie> The more I think about the palette thing, the more I think passing a std::pair around is a crazy idea, but I would like to take the fix for the GetPalette thing, at least.
[19:49:14] <tomprince> I agree with you about the std::pair, but I couldn't think of anyhting better.
[19:49:20] <fuzzie> Sorry, by that I mean the PLT thing.
[19:52:36] --> Edheldil_ has joined #GemRb
[19:54:52] --> Maighstir_laptop has joined #GemRb
[20:04:41] <-- tomprince_loki has left IRC (Ping timeout: 245 seconds)
[20:05:42] <-- tomprince has left IRC (Ping timeout: 276 seconds)
[20:22:45] <CIA-74> GemRB: 03fuzzie * rc30a2657fc97 10gemrb/gemrb/plugins/Core/Game.cpp: set WB_HASWEATHER on all weather changes
[20:23:14] <fuzzie> That is still not quite right, but I'd like to clear it out of my queue.
[20:29:16] <Maighstir_laptop> Regarding cmake on Win32: I get "CMake Error at gemrb/plugins/Core/CMakeLists.txt:12 (INSTALL): install Library TARGETS given no DESTINATION!". So, no, it doesn't work here at least.
[20:41:48] --> tomprince has joined #GemRb
[20:41:55] <tomprince> wjp: I'd like BlitTile to handle 24bpp sprites. This is for TIZ format support, which gives us some tiles as 24bpp jpegs.
[20:42:53] <fuzzie> That works?
[20:43:18] <tomprince> It did, doesn't now, with the new BlitTile.
[20:43:41] <tomprince> Maighstir_laptop: You need to pass -DPREFIX to cmake.
[20:43:53] <tomprince> I guess there should perhaps be a better default.
[20:43:56] <fuzzie> Could we fix that?
[20:45:56] <fuzzie> I've been poking around at it myself, and the install bit doesn't seem to work at all.
[20:46:40] <fuzzie> LAYOUT is empty so none of the variables get set, I guess?
[20:47:12] <tomprince> Shouldn't the if at the top set layout if it isn't already set?
[20:47:22] <fuzzie> Yes, but it doesn't seem to work at all.
[20:47:37] <wjp> tomprince: TIZ? Do we have an importer for that?
[20:47:50] <tomprince> In my tree here.
[20:48:00] <wjp> ah
[20:48:05] <fuzzie> So how does it work, some tiles as 8-bit and some tiles as jpeg?
[20:48:16] <fuzzie> Or some jpeg and then individual tiles on top?
[20:48:31] <fuzzie> Or does it just support a very limited subset of functionality?
[20:48:49] <wjp> how much 32bpp support should BlitTile get? Just the data, or mask too?
[20:48:55] <tomprince> Some are just zlib compress tis tiles, some are jpeg, and some are jpeg with an 1bit alpha mask.
[20:49:21] <wjp> and how are they stored in gemrb?
[20:49:38] <fuzzie> Are the individual tiles jpeg-compressed?
[20:49:52] <wjp> (aside: why lossy compression?)
[20:50:25] <fuzzie> wjp: To cut down on download sizes.
[20:51:00] <tomprince> Classic Adventures has 1.2G of tiz files.
[20:51:32] <tomprince> I am just uncompressing again now to see how much as tis.
[20:52:16] <tomprince> 2.5G as tis.
[20:52:34] * wjp wonders how much they'd be as 8bit png
[20:52:51] <wjp> ah well, doesn't matter much for us
[20:52:59] <fuzzie> tomprince: Your LAYOUT block fails, and your MATCHES "opt" is always followed because you made it an 'ELSE' and not an 'ELSEIF' so the match is ignored.
[20:53:01] <wjp> how do you store the tiles in gemrb? data? mask?
[20:53:16] <tomprince> Just as Sprite2D.
[20:53:36] <wjp> and the mask tiles?
[20:53:45] <tomprince> Apply the mask at load time.
[20:53:48] <wjp> (specifically the colour key)
[20:53:56] <fuzzie> Apply the mask how?
[20:54:07] <wjp> I'm guessing those should just be 8bpp sprites
[20:54:10] <fuzzie> By modifying the alpha of the tiles?
[20:54:28] <wjp> (with two colours, one of which is the colourkey)
[20:54:41] <tomprince> Can't remeber off the top of my head. I just copied the code from tisunpack.
[20:54:49] <fuzzie> That doesn't work.
[20:54:58] <tomprince> Actually, that bit is broken in my tree now. :)
[20:55:44] <fuzzie> Oh, maybe I misunderstand. nm.
[20:55:49] <fuzzie> Would appreciate you fixing the cmake code, though.
[20:56:18] <fuzzie> I mean, not in a rush.
[20:56:46] <tomprince> Working on that now. :)
[20:57:42] <wjp> tomprince: I can try to implement something later this week. Remind me again sometime if I forget
[20:57:52] <tomprince> Thanks. :)
[20:59:03] <fuzzie> But at some point tisunpack just produced bad mask tiles, don't know if that got fixed.
[21:03:27] <Maighstir_laptop> tomprince: my command line for cmake right now is cmake ..\gemrb -G "MinGW Makefiles" -DCMAKE_INSTALL_PREFIX=C:\Games\_GemRB-32, how would you suggest it's changed? Append -DPREFIX=C:\Games\_GemRB-32 at the end?
[21:03:49] <tomprince> No, -DLAYOUT=HOME.
[21:04:15] <tomprince> I'm not familiar with cmake, so the test at the begining to set a default value isn't working.
[21:04:26] <tomprince> And I can't seem to get it to work. :(
[21:04:52] <Maighstir_laptop> same error, targets given no destination
[21:05:01] <fuzzie> The LAYOUT test is wrong too, so setting -DLAYOUT is no good.
[21:05:24] <tomprince> -DPREFIX is *supposed to be an alias for -DCMAKE_INSTALL_PREFIX, but I don't know if that works either.
[21:05:43] * tomprince goes to supper. Will try to fix later.
[21:05:45] <fuzzie> I'm not sure what's going wrong.
[21:05:53] <fuzzie> I did have a go myself, and had no more luck.
[21:09:28] <fuzzie> The tisunpack I'm looking at does the masking after converting to 8bpp.
[21:09:54] <fuzzie> It just refuses to apply the full-jpeg compression method on masked tiles.
[21:10:03] <fuzzie> I guess that works?
[21:11:17] <fuzzie> If that is how tomprince implemented it, you could just blit all 24bpp tiles as-is.
[21:18:42] <tomprince> Looking at it again now that is why that case isn't implemented. I get back a 24bit Sprite2D from JPEGImporter, and hadn't figured out how to apply the mask. :)
[21:19:17] <wjp> fuzzie: as-in but tinted :-)
[21:21:29] <tomprince> or.cz/tiz has my work in progress.
[21:21:39] <fuzzie> tisunpack is just making libjpeg generate a palette, I guess.
[21:22:05] <Lightkey> did I hear tiz?
[21:22:34] <fuzzie> And storing the original palette in most cases, using zlib.
[21:23:07] --> cfchris6 has joined #GemRb
[21:23:10] <Lightkey> eh well, guess that joke does quite work as well with english pronounciation
[21:23:14] * Lightkey ducks
[21:23:14] <fuzzie> If you want to completely ignore that and use 24bpp always, I guess that is a bit more complicated.
[21:23:18] <fuzzie> Lightkey: :)
[21:23:23] <wjp> heh
[21:23:27] <Lightkey> +not
[21:23:31] <Lightkey> dang
[21:24:06] <wjp> rendering them won't be hard if we store them as 32bpp RGB sprites (preferably with a fixed byte order)
[21:24:30] <wjp> of course storing them as 8bpp would be even easier for the rendering part :-)
[21:25:02] <-- Nomad010 has left IRC (Ping timeout: 246 seconds)
[21:25:07] <wjp> especially if we can skip the masking/50%-alpha case, it'll be a very simple blitter
[21:26:15] <fuzzie> Even rendering to 16bpp?
[21:26:35] <wjp> sure; the current one does repacking to 16bpp already
[21:26:39] <-- cfchris6_ has left IRC (Ping timeout: 260 seconds)
[21:27:17] <fuzzie> Does the 16bpp case actually help? Are there 16bpp graphics?
[21:27:40] <wjp> only if the output surface is 16bpp
[21:27:43] <fuzzie> I'm used to a 16bpp display being a huge performance boost.
[21:28:08] <wjp> I haven't benchmarked it with gemrb, but in theory that should be the same for us
[21:28:10] <fuzzie> Because I spent too much of my life working on stupid code which worked with 16bpp sprites. :)
[21:29:11] <wjp> :-)
[21:29:53] <fuzzie> But I wouldn't be surprised if the weird shifts/masking made it pretty awful for gemrb.
[21:30:38] <wjp> for 32bpp we do about the same amount of shifting currently
[21:31:17] <wjp> in 32bpp mode it operates on uint32's as a whole; not on a byte-level
[21:31:41] <fuzzie> There's no rloss for 32bpp, though?
[21:32:11] <wjp> true, but that's not at the moment known at compile-time
[21:32:17] <fuzzie> Oh, drat.
[21:33:27] <wjp> I've been too lazy to implement that optimization
[21:35:40] <tomprince> or.cz/cmake: This should fix it.
[21:35:59] <tomprince> Maighstir_laptop: Can you try the commit at or.cz/cmake?
[21:37:00] <fuzzie> Aha.
[21:37:20] <fuzzie> That still doesn't fix the IF afterwards, though? Or do you intend to make it default to the "opt" choices in the absence of "home" or "fhs"?
[21:38:57] <tomprince> I think that is more accident than anything, but we should default to one of them, so all the variables get set.
[21:39:12] <tomprince> Or perhaps it should error out.
[21:40:06] <tomprince> I'm fairly certain that the last case being default was deliberate, but not which one it was.
[21:41:52] <wjp> fuzzie: unfortunately removing the loss shifts doesn't seem to improve framerate in a fairly complex scene (sprite-wise). For some of the expensive types of blending the loss shifts are already done together with a tinting shift, so maybe that explains it partially
[21:41:57] <Maighstir_laptop> um... right... i actually have no idea how to pull from your repository, the only thing I ever do is pull the latest trunk from sf, using the graphical tortoisegit :-P
[21:42:39] <fuzzie> ok, i'll merge it into sf.
[21:43:34] <Maighstir_laptop> give me a command line and I can figure it out, I just haven't done it before
[21:43:37] <CIA-74> GemRB: 03tom.prince * r6d4b5a032e83 10gemrb/CMakeLists.txt: cmake: Fix setting of default LAYOUT.
[21:44:25] <wjp> tomprince: what would be an interesting side effect of templating the sprite renderer, is that it would give statistics on which types of rendering are the most expensive in practice (alpha, tint, ...)
[21:44:56] <tomprince> That would be useful. :)
[21:45:52] <wjp> of course given how full of effects your party is by the end of the game I'm guessing the most complex one will be used quite a bit :-)
[21:47:05] <fuzzie> Mm, if you set a flag and print "I saw effect X" on seeing an effect, you seem to get most of them pretty quickly.
[21:47:14] <fuzzie> Didn't look at combinations.
[21:48:51] <wjp> yeah, I did something like that back when I was determining which combinations to give their own '#include .inl'
[21:49:30] <tomprince> As did I. :)
[21:49:31] <wjp> there are some comments in SDLVideo::BlitGameSprite about it
[21:50:42] <Maighstir_laptop> By the way, no change as far as I can see. Of course, there may be something faulty with my setup, but there's the case of "it worked a few days ago".
[21:51:36] <tomprince> Try removing CMakeCache.txt, then running cmake again.
[21:52:05] <tomprince> Also, there should be a way to add another remote through tortiseSVN.
[21:53:47] <tomprince> And if that doesn't work, could post the log of 'cmake --trace . $OPTIONS'
[21:54:28] <wjp> time to go; good night
[21:55:00] <tomprince> Night.
[21:57:18] <fuzzie> tomprince: cc1plus.exe: error: unrecognized command line option "-fvisibility=hidden"
[21:58:13] <tomprince> 'gcc --version' ?
[21:58:45] <tomprince> We have -fvisibility by default with autools, so I copied it for cmake.
[21:58:50] <fuzzie> This is from the forums, but it'll be the standard mingw compiler, I guess, which is still 3.x or something similarly ridiculous.
[21:59:02] <fuzzie> And, well, this is why no-one uses autotools outside of Linux. :)
[22:02:48] --> tomprince_loki has joined #GemRb
[22:02:50] <Maighstir_laptop> Got further after removing CMakeCache.txt and renaming git's sh.exe which was in my path (MinGW didn't complain about it before, strangely enough).
[22:02:50] <Maighstir_laptop> Still the same error, but at a later point (first after "looking for ogg vorbis", now after "looking for strndup")
[22:03:33] <Maighstir_laptop> wait... that one has a cache as well, doesn't it?
[22:04:02] <fuzzie> Deleting the one cache file should be enough.
[22:04:05] <tomprince> Can you post the output of 'cmake --trace . $OPTIONS'?
[22:04:06] <Maighstir_laptop> I'll just clean the whole biuld dir and run again
[22:08:31] <Maighstir_laptop> it doesn't want to pipe the trace into a file, apparently, and it's way too much to copy off cmd
[22:09:39] <-- Gekz_ has left IRC (Read error: Connection reset by peer)
[22:09:40] --> Gekz has joined #GemRb
[22:12:58] <CIA-74> GemRB: 03fuzzie * r93f086e354df 10gemrb/CMakeLists.txt: cmake: check whether -fvisibility=hidden is supported before using it
[22:14:05] <tomprince> You beat me to it. :)
[22:16:11] <tomprince> although, or.cz/cmake has a more comprehensive one.
[22:17:37] <fuzzie> It doesn't make it very obvious you're using gcc-isms everywhere. :)
[22:18:11] <fuzzie> I'll look at it tomorrow, I just want to try squashing the immediate fires.
[22:18:14] <tomprince> Maighstir_laptop: Do you know which target is being given a destination.
[22:18:44] <tomprince> fuzzie: K. clang supports all of those, but isn't gcc, nor is it recongnized as such.
[22:19:24] <fuzzie> Well, gcc-clone-isms too.
[22:20:41] <-- Gekz has left IRC (Read error: Connection reset by peer)
[22:20:48] <Maighstir_laptop> finally, >300k of output... http://ops-area.net/annat/GemRB/cmakelog.log
[22:20:48] --> Gekz has joined #GemRb
[22:21:29] <Maighstir_laptop> see, I'm not completely worthless :-P
[22:22:38] <fuzzie> Does it work if you change the LIBRARY in gemrb/plugins/Core/CMakeLists.txt to RUNTIME?
[22:22:56] --> Gekz_ has joined #GemRb
[22:24:21] <-- Gekz has left IRC (Read error: Connection reset by peer)
[22:25:52] <-- zefklop has left IRC (Quit: ChatZilla 0.9.86 [SeaMonkey 2.0.4/20100317120533])
[22:25:56] <-- kettuz has left IRC (Quit: Leaving)
[22:26:09] --> zefklop has joined #GemRb
[22:29:47] <Maighstir_laptop> it passed cmake at least (yay!), but then mingw32_make gives a load of errors
[22:30:08] <tomprince> Should perhaps just drop the LIBRARY bit instead.
[22:30:08] <Maighstir_laptop> s/_/-/
[22:30:34] <fuzzie> I think the LIBRARY bit was necessary for someone.
[22:30:40] <fuzzie> Maighstir_laptop: Could you give the first example?
[22:32:27] <CIA-74> GemRB: 03fuzzie * r930101a4b39d 10gemrb/gemrb/plugins/Core/CMakeLists.txt: go back to actually copying the DLL on Windows
[22:32:47] <Maighstir_laptop> In file included from C:\Users\Maighstir\dev\GemRB-Git\gemrb\gemrb\plugins\Core\../../includes/win32def.h:82,
[22:32:47] <Maighstir_laptop> from C:\Users\Maighstir\dev\GemRB-Git\gemrb\gemrb\plugins\Core\Actions.cpp:21:
[22:32:47] <Maighstir_laptop> C:\Users\Maighstir\dev\GemRB-Git\gemrb\gemrb\plugins\Core\../../includes/../plugins/Core/VFS.h:40:21: fnmatch.h: No such file or directory
[22:32:47] <Maighstir_laptop> C:\Users\Maighstir\dev\GemRB-Git\gemrb\gemrb\plugins\Core\../../includes/../plugins/Core/VFS.h:41:19: dlfcn.h: No such file or directory
[22:34:30] <fuzzie> Okay, that one is weirder.
[22:34:41] <tomprince> That means WIN32 is being defined.
[22:34:52] <Edheldil_> fuzzie, btw, another way to improve on commit message quality would be to put ticket # to all commit messages.... And make sure that there's a ticket for the changes you are going to make
[22:35:29] <fuzzie> Edheldil_: You would first have to setup a reliable ticket system.
[22:35:50] <Maighstir_laptop> also other errors of varying types
[22:36:32] <tomprince> And one that was pleasant enought to use.
[22:36:44] <Edheldil_> SF's is not?
[22:36:48] <fuzzie> No.
[22:37:12] <Maighstir_laptop> I'll upload the log to my server, see if it is of any use
[22:37:13] <Edheldil_> I have seen worse
[22:37:13] <fuzzie> They don't care about it any more.
[22:37:28] <Edheldil_> no?
[22:37:35] <fuzzie> They moved all their own stuff to trac.
[22:38:04] <fuzzie> Maighstir_laptop: I don't see any obvious cause for that error, other than some corrupt cmake files.
[22:38:06] <Edheldil_> we use trac tickets at work as well
[22:38:25] <fuzzie> trac is .. usable, at least.
[22:38:38] --> ratpor has joined #GemRb
[22:38:57] <tomprince> Maighstir_laptop: Try adding ;WIN32=1 to the end of the line after COMPILE_DEFINITIONS in gemrb/plugins/Core/CMakeLists.txt
[22:39:02] <fuzzie> My experience is that sf-hosted trac is not, though, so it doesn't really help if the intention would be to host it there.
[22:42:41] <fuzzie> PARPG host theirs on cvsdude.com?
[22:43:18] <fuzzie> But, right, commercial provider with a "maybe free for open source if you host an ad"..
[22:43:22] <fuzzie> anyway, ninight
[22:43:28] <tomprince> Night.
[22:50:43] <Maighstir_laptop> tomprince: no change
[22:52:22] <Edheldil_> good night, fuzzie
[22:52:35] <tomprince> Puzzling.
[22:56:34] <tomprince> Can you post the output of 'make VERBOSE=1 Actor.o' , run from gemrb/plugins/Core.
[22:56:52] <tomprince> btw. Thanks for putting up with me breaking the build.
[23:00:01] <Maighstir_laptop> http://ops-area.net/annat/GemRB/actor.log
[23:00:56] <fuzzie> I guess Google Code would perhaps be a pretty good bug tracker, actually.
[23:01:05] <tomprince> Quick question, what version of cmake do you have?
[23:01:18] <Maighstir_laptop> 2.8.0
[23:01:28] <Maighstir_laptop> too old?
[23:01:44] <tomprince> Shouldn't be.
[23:01:45] <fuzzie> I just remembered (and came all this way to say!) that I started using it for another project - it is not ideal, but it's fast and reliable and etc.
[23:02:39] <tomprince> I got the impression that development was much more freewheeling than one that would have a bug ticket for every single change. :)
[23:03:01] <fuzzie> Yes.
[23:03:25] <fuzzie> But at the moment, our bug tracker is so awful that no-one uses it.
[23:03:36] <fuzzie> I tried closing some bugs the other day, it was not a fun experience.
[23:04:40] <fuzzie> Maighstir_laptop: Just comment out that entire SET_TARGET_PROPERTIES block, perhaps.
[23:05:03] <tomprince> Maighstir_laptop: How about the first bit of output from just 'make VERBOSE=1' in the same dir, up to the first couple of errors/warnings.
[23:05:15] <fuzzie> Just to make sure that is the cause.
[23:06:17] <fuzzie> Without any compiler flags it's never going to work.
[23:08:00] <tomprince> Is why I asked about cmake version, since that command gave me the normal flags, but I guess the mingw makefiles are different.
[23:10:24] <-- zefklop has left IRC (Quit: ChatZilla 0.9.86 [SeaMonkey 2.0.4/20100317120533])
[23:19:35] <Maighstir_laptop> fuzzie: commenting out or removing SET_TARGET_PROPERTIES in gemrb/plugins/Core/CMakeLists.txt doesn't seem to do anything at all
[23:19:56] <Maighstir_laptop> of course, including the entire block from ( to )
[23:20:24] <Edheldil_> brb
[23:20:28] <-- Edheldil_ has left IRC (Quit: Really?)
[23:22:18] --> edheldil_ has joined #GemRb
[23:25:18] <tomprince> Very puzzling.
[23:25:54] * tomprince goes to concert
[23:26:23] <tomprince> Will try to diagnose later.
[23:31:31] <edheldil_> enjoy the concert
[23:31:36] <edheldil_> night
[23:31:46] <Maighstir_laptop> g'night
[23:36:18] <-- edheldil_ has left IRC (Ping timeout: 276 seconds)
[23:40:59] <-- Maighstir_laptop has left #GemRb
[23:43:02] --> Gekz has joined #GemRb
[23:46:36] <-- Gekz_ has left IRC (Read error: Connection reset by peer)