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

Archive Today Yesterday Tomorrow
GemRB homepage

[00:08:31] <-- edheldil__ has left IRC (Ping timeout: 265 seconds)
[00:31:19] <-- Edheldil_ has left IRC (Quit: Really?)
[00:34:10] <-- Maighstir_laptop has left #GemRb
[01:16:12] <-- Nomad010 has left IRC (Ping timeout: 276 seconds)
[01:16:50] --> Nomad010 has joined #GemRb
[02:25:30] --> Gekz has joined #GemRb
[02:53:43] --> _pickle has joined #GemRb
[03:39:29] --> tomprince has joined #GemRb
[03:39:33] <-- _pickle has left IRC (Remote host closed the connection)
[05:42:14] <-- Lightkey has left IRC (Remote host closed the connection)
[05:42:44] --> edheldil__ has joined #GemRb
[05:43:28] --> raevol has joined #GemRb
[05:50:34] <-- raevol has left IRC (Quit: Leaving.)
[06:16:16] <-- Nomad010 has left IRC (Ping timeout: 252 seconds)
[07:04:31] --> Nomad010 has joined #GemRb
[07:15:06] <-- Nomad010 has left IRC (Ping timeout: 258 seconds)
[07:21:01] <-- edheldil__ has left IRC (Ping timeout: 264 seconds)
[08:21:37] --> Avenger has joined #GemRb
[08:21:42] --- ChanServ gives channel operator status to Avenger
[08:21:45] <Avenger> hello
[08:22:19] <Avenger> i was wrong about declarations in if() it works correctly. even the scope is ok. I still think it is ugly
[08:23:01] <Avenger> on the other hand, i cannot get past the __cdecl problem
[08:38:31] <fuzzie> hm
[08:38:59] <Avenger> fuzzie you tried to compile this on msvc6? or even any other msvc?
[08:39:25] <Avenger> i fixed the project files and some other stuff, but i cannot fix this
[08:40:03] <Avenger> i really hate changes that just give more work
[08:40:06] <fuzzie> edit includes/plugindef.h
[08:40:27] <fuzzie> put the 'GEM_EXPORT_DLL' before the two 'template' lines
[08:40:42] <fuzzie> that would be my first thought
[08:41:02] <Avenger> i tried that, though only put it before one of the lines
[08:41:17] <Avenger> it causes a wall of error text, though
[08:41:53] <Avenger> warning C4091: '__declspec(dllexport ) ' : ignored on left of 'int' when no variable is declared +3 error lines, for both additions
[08:42:42] <fuzzie> huh. maybe it needs to go on the line afterwards, before the 'Plugin*' and 'Resource*'?
[08:42:49] <Avenger> i tried putting them after template
[08:42:52] <fuzzie> i did install msvc6 yesterday, but unfortunately i am somewhere else for the weekend :(
[08:45:11] <fuzzie> but it seems it should work fine before the Plugin* and Resource*
[08:46:53] <fuzzie> and i think we all agreed that declarations in if() is ugly, after you left
[08:46:53] <tomprince> Avenger: Try moving the declartion of PluginFunc outside of PluginMgr.
[08:48:08] <Avenger> fuzzie: yes, i know, i just mentioned, surprisingly its scope is perfect, contrary to for()
[08:48:31] <Avenger> both branches of if see the variable, but it is invisible outside
[08:50:23] <Avenger> tomprince: you mean move the two typedefs out of the class?
[08:50:30] <tomprince> Yes.
[08:51:32] <Avenger> nothing changed
[08:52:11] <fuzzie> huh :|
[08:54:29] <Avenger> what about this: GEM_EXPORT_DLL typedef Plugin* (*PluginFunc)();
[08:54:33] <Avenger> :)
[08:54:51] <Avenger> just because i'm desperate
[08:55:06] <Avenger> i now just randomly try things
[08:55:10] <fuzzie> would need to be inside the typedef anyway, i think, even if it worked
[08:55:55] <tomprince> How about adding a __cdecl to "Plugin* CreatePlugin()" in plugindef.h
[08:56:09] <Avenger> i tried that
[08:56:16] <Avenger> Plugin * __cdecl ...
[09:01:30] <Avenger> i don't even understand plugindef.h
[09:04:52] <tomprince> That is fairly straight forward. Every plugin needs some boilerplate code. On win32, DllMain needs to be defined, and there are 4 functions that PluginMgr expects.
[09:05:38] <fuzzie> it is really more of a plugindef.inl :)
[09:06:15] <tomprince> The macros at the bottom of plugindef define those functions, in such a way that the implemntation can be changed without affect the plugins themselves.
[09:06:39] <Avenger> well, now i try just separate RegisterPlugin from CreatePlugin<cls>
[09:07:19] <Avenger> #define PLUGIN_CLASS(id, cls) \
[09:07:20] <Avenger> Plugin* f = CreatePlugin<cls>); \
[09:07:22] <Avenger> if (!mgr->RegisterPlugin(id, f) \
[09:07:24] <Avenger> return false;
[09:07:29] <Avenger> doesn't work, of course
[09:07:38] <Avenger> ahh, that )...
[09:08:09] <tomprince> It would need to be Plugin* (*f)() = ...
[09:11:00] <fuzzie> i think that if adding __cdecl to the CreatePlugin and CreateResource definitions doesn't work, then there is something else going wrong
[09:12:08] <fuzzie> such as the fact there is no & before the CreatePlugin<cls>.
[09:13:42] <fuzzie> adding that maybe a more sensible idea, looking at the actual error :)
[09:14:53] <tomprince> Yes. I had wondered about that.
[09:15:30] <fuzzie> (why on earth doesn't gcc complain about that?)
[09:15:59] <Avenger> ok, lets separate them first, that would at least make the types clear
[09:16:05] <tomprince> Because functions coerce to function pointers?
[09:16:10] <fuzzie> ugh :(
[09:16:33] <fuzzie> Avenger: well, would be nice to see if it works :)
[09:16:46] <Avenger> type is: Plugin *(*f)(); ?
[09:17:36] <Avenger> E:\gemrb\gemrb\plugins\2DAImporter\2DAImporter.cpp(117) : error C2781: 'class Plugin *__cdecl CreatePlugin(void)' : expects at least 0 argument - 1 provided
[09:17:42] <fuzzie> - if (!mgr->RegisterPlugin(id, CreatePlugin<cls>)) \
[09:17:42] <fuzzie> + PluginMgr::PluginFunc f = &CreatePlugin<cls>; \
[09:17:42] <fuzzie> + if (!mgr->RegisterPlugin(id, f)) \
[09:18:16] <fuzzie> ^- this is what i did, but then you have an 'f' in scope, so you'd have to wrap it in one of those do/while things
[09:18:32] <Avenger> yes, good idea to actually use pluginfunc
[09:18:43] <Avenger> i couldn't use it earlier, because it was inside pluginmgr, LOL
[09:18:54] <fuzzie> well, i just use it from inside PluginMgr there :)
[09:19:09] <fuzzie> i would not bother changing the macros now, because they could do with some clarification anyway
[09:19:10] <Avenger> yes i see, still it fucks up
[09:19:21] <fuzzie> you have the '&'?
[09:19:29] <Avenger> E:\gemrb\gemrb\plugins\2DAImporter\2DAImporter.cpp(117) : error C2781: 'class Plugin *__cdecl CreatePlugin(void)' : expects at least 0 argument - 1 provided
[09:19:32] <Avenger> yes
[09:20:10] <fuzzie> strange, it sounds like you have an extra ()
[09:20:21] <Avenger> hmm, cannot pm you
[09:20:25] <Avenger> you are 'away'
[09:20:42] <fuzzie> oh. yes. i am not home, as i said :) i disabled it
[09:20:58] <Avenger> #define PLUGIN_CLASS(id, cls) \
[09:21:00] <tomprince> What do you have for line 117?
[09:21:01] <Avenger> PluginMgr::PluginFunc f; \
[09:21:02] <Avenger> f=&CreatePlugin<cls>; \
[09:21:04] <Avenger> if (!mgr->RegisterPlugin(id, f ) \
[09:21:06] <Avenger> return false;
[09:21:48] <fuzzie> you miss at the end of the RegisterPlugin line
[09:21:55] <fuzzie> erm, you miss a )
[09:22:04] <Avenger> oh
[09:22:24] <Avenger> thats true, still the error message is the same
[09:22:30] <tomprince> Is this the stupid thing that MSVC6 doesn't support explict template arguments to function templates?
[09:22:55] <fuzzie> i'm not sure; we could easily make it a macro, though
[09:23:32] <Avenger> it is already a weird hybrid of macro templates :)
[09:23:37] <fuzzie> yes
[09:24:08] <Avenger> if you can get rid of the template it will surely be more compatible with compilers
[09:24:35] <fuzzie> well, here it doesn't matter
[09:25:14] <Avenger> i would give up msvc if it hasn't such a good debugger :)
[09:25:33] <fuzzie> in SDLVideo there are speedups from templates, though, so we will have to work things out there anyway
[09:26:14] <tomprince> template <typename T>
[09:26:16] <tomprince> struct CreatePlugin {
[09:26:18] <tomprince> static Plugin* func()
[09:26:20] <tomprince> {
[09:26:22] <tomprince> return new T();
[09:26:25] <tomprince> }
[09:26:29] <tomprince> };
[09:26:34] <tomprince> With the registerPlugin line changed to CreatePlugin<...>::func
[09:27:33] <fuzzie> i'm not convincined that is the problem
[09:27:48] <fuzzie> i thought msvc6 just failed silently in those cases
[09:28:12] <fuzzie> i would think it is more likely that Avenger maybe broke some other code, earlier
[09:28:29] <tomprince> I was wondering if the argument thing was it complaining about too many template arguments.
[09:30:16] <Avenger> :\gemrb\gemrb\plugins\2DAImporter\2DAImporter.cpp(117) : error C2955: 'CreatePlugin' : use of class template requires template argument list
[09:31:43] <Avenger> i do this?--> if (!mgr->RegisterPlugin(id, CreatePlugin<cls>::func )) \
[09:31:47] <fuzzie> i mean, you could spend the whole day changing things, but i think there is likely a much simpler explanation
[09:31:49] <Avenger> i left <cls>
[09:31:53] <tomprince> Yes.
[09:31:59] <fuzzie> and you still need the &
[09:32:07] <Avenger> works
[09:32:18] <Avenger> phew
[09:32:58] <fuzzie> don't need the &?
[09:34:27] <Avenger> now i don't need *.def files?
[09:34:29] <Avenger> or what
[09:34:58] <Avenger> #define PLUGIN_CLASS(id, cls) \
[09:35:00] <Avenger> if (!mgr->RegisterPlugin(id, CreatePlugin<cls>::func )) \
[09:35:01] <Avenger> return false;
[09:35:02] <Avenger> this worked
[09:35:07] <Avenger> i guess it would work with the &
[09:35:36] <Avenger> but i guess functions without the () are addresses of functions anyway
[09:35:52] <fuzzie> apparently so, which is why the original bug was confusing
[09:36:16] <Avenger> the original bug is a missing feature of msvc6, as tomprince said
[09:37:58] <Avenger> cool, now 2daimporter compiles
[09:38:45] <tomprince> I don't know if you need a def file any more, is it smart enough to pick up the exports from the GEM_EXPORT_DLL lines?
[09:38:53] <Avenger> i wonder if i still need those .def files
[09:39:12] <Avenger> i removed it, and it asked for it, but... i guess that's a compile parameter somewhere
[09:40:46] <tomprince> If it does need it, the exports are now GemRBPlugin_*
[09:43:25] <tomprince> You'll also need to do the same trick for CreateResource.
[09:45:35] <Avenger> why do we have a bmpwriter?
[09:46:36] <tomprince> Because the reading and writing code was totally disjoint, as was the interface.
[09:47:12] <tomprince> And because we have multiple implemntions of reading, but only one of writting .. so to avoid having do nothing stubs.
[09:52:58] <Avenger> meh
[09:53:17] <Avenger> GUIScript.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) public: static class TypeID const PalettedImageMgr::ID" (__imp_?ID@PalettedImageMgr@@2VTypeID@@B)
[09:53:19] <Avenger> ../../plugins\GUIScript.dll : fatal error LNK1120: 1 unresolved externals
[09:54:00] <Avenger> is there a new class for palette mgr?
[09:54:16] <Avenger> oh i see it
[09:56:47] <tomprince> Good night all. Unless there is some other glaring errors?
[10:01:41] <fuzzie> yes, the BMPWriter was a mess
[10:01:45] <fuzzie> i mean, beforehand
[10:02:23] <fuzzie> it had endian issues and the such, because it tried sharing code with BMPImporter
[10:03:08] <fuzzie> Avenger: can you explain why there is a check for name being 0 and 1 in CREImporter::ReadChrHeader?
[10:03:24] <fuzzie> it is broken for other platforms, but i don't understand what it's doing
[10:03:44] <fuzzie> and i see nothing in DLTCEP or IESDP or NI
[10:04:52] <Avenger> i don't know what the 1 is doing there, maybe it was a wrong structure definition at one time
[10:05:26] <Avenger> the struct def was wrong, probably in pst or iwd2 so it read an '1' instead of the name
[10:05:54] <fuzzie> ok :)
[10:05:57] <Avenger> most likely that was the problem, and hmm, pst has no chr
[10:06:01] <Avenger> so it was iwd2
[10:06:22] <Avenger> the 0 is still needed :)
[10:06:32] <fuzzie> sure, i can fix the 0 check :)
[10:06:48] <Avenger> you don't need to make it endian safe
[10:07:20] <fuzzie> the cast is a problem due to alignment
[10:07:41] <fuzzie> i'll have to check whether it's actually a problem, or whether i just need to stop the compiler complaining
[10:08:21] <fuzzie> i have a bunch of other fixes, but i didn't commit them yet, because i am a bit unhappy about all the recent changes, and would like it to settle down first
[10:08:45] <fuzzie> but i got messages working, and they seem to fix all the problems i hoped they would
[10:10:29] <Avenger> well, i'm almost done with cleaning up the msvc part
[10:10:52] <fuzzie> well, if you got it all working with msvc, i would be a lot happier :)
[10:10:53] <Avenger> still screwed by the zlibmanager name change
[10:11:13] <Avenger> hmm you use msvc6 too???
[10:11:25] <Avenger> or you would just be happy for me ;D
[10:12:04] <fuzzie> well, i was worried that we would have to revert some things to make it work
[10:13:02] <fuzzie> and i don't think this is all msvc6-only problems
[10:13:15] <fuzzie> but i think: if it works with msvc6, it will work with all compilers :)
[10:20:58] <Avenger> btw, i don't like the include path changes either
[10:24:24] <fuzzie> well, it was in the TODO, but it could be easily changed back
[10:25:48] <fuzzie> i would prefer we change nothing, but others seem enthusiastic :)
[10:29:56] <fuzzie> i tried fixing iwd2 up a bit, but it goes quickly wrong: GUISTORE doesn't even have the right control ids :(
[10:31:30] <Avenger> let me clean this up first ;)
[10:31:52] <Avenger> now almost everything works (hmm, compiles)
[10:36:51] <-- kahen has left IRC (Read error: Connection reset by peer)
[10:39:57] --> kahen has joined #GemRb
[11:04:15] <Avenger> ok, why is this directoryimporter separated?
[11:06:22] <fuzzie> so we can re-use it, and cache results, and etc
[11:07:35] <fuzzie> is that a problem? it is one of the bits i am happiest about, it fixed bugs and it is faster
[11:10:28] <Avenger> no problem with it, except it is another fragment :)
[11:10:44] <Avenger> now iwd2 started
[11:11:56] <fuzzie> now we are using macros, it would be very easy to just change the macros and link everything into one .exe file
[11:12:30] <Avenger> there is a weird bug with the nullsound driver
[11:13:42] <Avenger> ahh it isn't a bug
[11:13:53] <Avenger> maybe it was always like that
[11:14:13] <fuzzie> cutscenes not waiting for speech to end?
[11:14:59] <Avenger> no, on plugin load i thought i saw excess complaints, but it is ok. first yellow is only about delaying nullsound
[11:15:17] <Avenger> the second yellow says there is already a plugin for sound
[11:15:19] <Avenger> that's right
[11:15:21] <fuzzie> :)
[11:15:43] <Avenger> it is delayed and not skipped to be extra failproof
[11:16:09] <Avenger> ok now i can check the iwd2 store you said
[11:16:47] <Avenger> oops
[11:16:50] <Avenger> MEH
[11:17:09] <Avenger> the tile rendering is bugged as in BUGGED
[11:17:42] <Avenger> only half of the screen has tiles, but sprites are drawn there
[11:17:57] <Avenger> and the color of the tiles is weird too
[11:18:09] <fuzzie> i thought that might happen
[11:18:15] <Avenger> it is purple instead of blue
[11:18:32] <Avenger> is it you or wjp ;D
[11:18:39] <fuzzie> comment out lines 908 and 909 of SDLVideo.cpp
[11:19:01] <fuzzie> that is the 'else' and the 'Uint16' bit of a macro
[11:19:14] <Avenger> btw, gemrb doesn't want to exit
[11:19:56] <Avenger> i have to break it
[11:20:04] <fuzzie> that is a *guess*, but i predicted at the time that you would hit a msvc6 miscompilation bug which always makes it choose the second 'else' there :)
[11:21:18] <Avenger> so, i should make it always use the 32 bits fun?
[11:21:24] <fuzzie> yes
[11:21:46] <fuzzie> if that fixes it, i'll look at fixing it properly
[11:23:52] <Avenger> yes it does
[11:24:37] <Avenger> ok, now i try to recompile in debug mode too (another hours of slaving on projectfiles) so i can see why it won't exit properly
[11:25:23] <fuzzie> the new tile code there does the overlay masking right, and it handles global tinting
[11:25:45] <fuzzie> in case you wondered why it changed :)
[11:25:55] <Avenger> that's cool, even faster than the original?
[11:26:02] <Avenger> hehe, i wonder
[11:26:25] <Avenger> i guess it cannot be faster and do more at the same time
[11:26:45] <fuzzie> i think it's the same speed if we don't tint - wjp optimised it until the fps was the same as the old :)
[11:27:38] <fuzzie> i guess it should be just as good when tinting, too
[11:28:33] <fuzzie> i forgot that.
[11:30:25] <fuzzie> yes, it seems just as good as the old code.
[11:31:48] <Avenger> and you already checked the windspear hills or what is the area name?
[11:32:23] <fuzzie> small teeth pass, i think? and yes, it works
[11:32:35] <fuzzie> and so does bg1 :)
[11:33:15] <fuzzie> i just wanted the tinting, it makes things look a lot better
[11:33:26] <Gekz> ?
[11:38:56] <fuzzie> ok, i have to disappear for a bit
[11:47:35] <-- Avenger has left IRC (Quit: ChatZilla 0.9.86 [Firefox 3.6.3/20100401080539])
[12:02:19] <-- Gekz has left IRC (Quit: Leaving)
[12:51:20] --> lynxlynxlynx has joined #GemRb
[12:51:20] --- ChanServ gives channel operator status to lynxlynxlynx
[12:54:36] --> Gekz has joined #GemRb
[13:30:22] --> Gekz_ has joined #GemRb
[14:15:23] --> barraAway has joined #GemRb
[14:21:14] <CIA-74> GemRB: 03avenger_teambg * r852d6b7ec11f 10win32/MSVC6/GemRB/plugins/ (77 files in 39 dirs): msvc6 project files
[14:21:17] <CIA-74> GemRB: 03avenger_teambg * r338590ef89d3 10win32/MSVC6/GemRB/core/Core.dsp: msvc6 project files
[14:21:52] <CIA-74> GemRB: 03avenger_teambg * r74c46799744d 10gemrb/gemrb/includes/plugindef.h: fixed msvc6 compile problem (plugin templates)
[14:21:55] <CIA-74> GemRB: 03avenger_teambg * r289dfb56f4a6 10gemrb/gemrb/core/Interface.h: fixed program database bug warning for msvc6
[14:21:58] <CIA-74> GemRB: 03avenger_teambg * r536fe3aee2b9 10gemrb/gemrb/core/PluginMgr.h: fixed msvc6 compile problem
[14:21:59] --> Avenger has joined #GemRb
[14:22:03] --- ChanServ gives channel operator status to Avenger
[14:26:53] <Gekz_> why not just deprecate msvc6 and move one
[14:26:54] <Gekz_> on*
[14:27:01] <Gekz_> it's not like you support DJGPP
[14:29:36] <Avenger> the weather tints are great!
[14:30:02] <Avenger> gekz: i said it already, msvc6 has the best debugger
[14:30:25] <Gekz_> I'm sure in the past 10 years better debuggers have been released
[14:30:37] <Gekz_> possibly within the same series of software
[14:30:43] <Gekz_> what are they up to now, VC++10?
[14:30:50] <Gekz_> 12?
[14:31:06] <Avenger> the same series show a gradually degrading usability to me
[14:31:31] <Avenger> msvc7 is usable, it has some good and some bad features, msvc9 and above, i didn't even try
[14:31:32] <Gekz_> I'd dare say the usability simply differs
[14:31:39] <Avenger> no
[14:31:40] <Gekz_> you fear change
[14:31:41] <Gekz_> :o
[14:31:49] <Avenger> i use msvc7 in my workplace
[14:32:01] <Avenger> for 5 years, or maybe more
[14:32:39] <Avenger> it is worse in some parts, better in some.
[14:32:41] <Gekz_> god thats old lol
[14:32:53] <Avenger> gdb is older :D
[14:33:09] <Gekz_> yes and constantly improved
[14:33:18] <Gekz_> the compiler with vc6 is never updated
[14:33:23] <Gekz_> and that's the problem
[14:33:24] <fuzzie> and yet, gdb is still awful
[14:33:31] <Gekz_> gdb is a piece of shit
[14:33:35] <Gekz_> there is no denying it
[14:33:48] <Avenger> tell me a better debugger than the one in msvc6 :)
[14:33:51] <fuzzie> msvc9's debugger is better than msvc6's, i think
[14:34:04] <Gekz_> there must be good debuggers out there however otherwise nothing on linux would exist lol
[14:34:13] <Avenger> well, how compatible is msvc9 with our source code?
[14:34:18] <fuzzie> but then you want to build DLTCEP, so you have to keep msvc6 :)
[14:34:33] <fuzzie> Gekz_: there are not :(
[14:34:40] <Gekz_> fuzzie: why not
[14:35:03] <Avenger> linus says: debuggers are bad. hehe
[14:35:14] <fuzzie> very latest gdb is much improved though.
[14:35:18] <Gekz_> i've never needed to use one to be honest
[14:35:27] <Gekz_> I just add flags
[14:35:44] <Avenger> but us, mere mortals with our limited brain capacity couldn't comprehend the code, so we resort to debuggers
[14:36:04] <Gekz_> an active debugger isnt the only way to debug code
[14:36:13] <Avenger> sure
[14:36:21] <Avenger> and i didn't say i use it only
[14:36:22] <Gekz_> but simply, surely it must be evident to you as much as us that vc6 is showing its age more and more
[14:36:30] <Gekz_> what happens when C++0x is defined
[14:36:59] <Avenger> there have been lots of languages defined that are unneeded for gemrb
[14:37:02] <fuzzie> then no-one can use it for 10 years :)
[14:37:46] <Avenger> just because something new is available, it doesn't mean we should jump on it and use it just to say we use it
[14:38:27] <Gekz_> I'm not saying that either
[14:38:37] <Avenger> besides, i compile code on msvc6 and 7 and gcc. So if something compiles on all 3 of those, it is likely it will compile elsewhere
[14:38:39] <Gekz_> I know that recently msvc6 support was making a mess of something
[14:38:43] <Gekz_> I just cant put my finger on what it was
[14:38:48] <Gekz_> some interesting workaround
[14:39:08] <Avenger> well, we just had to add some weird workarounds in gemrb
[14:39:20] <Avenger> the plugin hack is rather peculiar
[14:39:43] <fuzzie> the SDLVideo problem is really annoying in the sense that it is truly a *bug* in msvc6
[14:39:53] <Gekz_> yep
[14:39:54] <Avenger> on the other hand, the plugin system was working before
[14:39:56] <Gekz_> that's what I was talking about
[14:39:59] <fuzzie> msvc6's compiler simply 'optimises' several different piece of code into only one function in the .exe
[14:40:11] <Avenger> hmm, i didn't understand that problem yet
[14:40:14] <fuzzie> but it is easy enough to workaround, you just have to remind the compiler they are different.
[14:40:16] <Avenger> i didn't look at it, though
[14:40:50] <fuzzie> easiest way is to include some unused parameter of the relevant type in the parameter list, i think.
[14:41:17] <Avenger> it said T is unused to me
[14:41:17] <fuzzie> but elsewhere i don't see why we use templates at all, where macros would do just as well
[14:41:33] <Avenger> yeah, we use them just because they are 'new' ;D
[14:41:51] <fuzzie> but in SDLVideo, they are *better*.
[14:42:12] <Avenger> uhm, i still wonder how can a template be better than handwritten code
[14:42:22] <Avenger> shorter: yes, better ?
[14:42:37] <fuzzie> well, you could simply write 8 different copies of the function, each one with a small change
[14:42:59] <Avenger> that's how it will look like in compiled code anyway
[14:43:01] <fuzzie> that would be just as good, but .. then you wrote 8 different copies of the function :)
[14:43:05] <Avenger> so, macros can't do that?
[14:43:08] <fuzzie> and that is a nightmare to maintain, just look at the guiscript
[14:43:17] <fuzzie> everyone screws up the guiscript
[14:44:36] <Avenger> well, when do we have bytesperpixel != 4?
[14:44:38] <fuzzie> either someone only fixes it for one game, or they copy the fix into other games and the fix is bad for the others..
[14:45:02] <Avenger> hehe, yes
[14:45:21] <fuzzie> the bytesperpixel != 4 is for 16bpp displays
[14:45:57] <Avenger> i have a nasty question, why do_blit is in the end of all branches
[14:46:10] <Avenger> can't it simply be written ONCE ?
[14:46:26] <fuzzie> no
[14:46:29] <fuzzie> it is templated
[14:47:00] <fuzzie> BlitTile_Internal<data type, T, B>
[14:48:02] <Avenger> ahh, t and b are not always the same type
[14:48:06] <fuzzie> just msvc6 doesn't do the explicit template parameter properly
[14:48:41] <fuzzie> so that should be a parameter, which is easy to do, i just don't have msvc6 here and it's not as if 16bpp matters on Windows anyway :)
[14:51:05] <Avenger> well, it needs to be fixed somehow anyway
[14:52:30] <Avenger> see you later!
[14:52:33] <-- Avenger has left IRC (Quit: bye!)
[14:57:15] <-- barraAway has left IRC (Read error: Connection reset by peer)
[15:06:00] <Gekz_> lol
[15:06:03] <Gekz_> I tried fuzzie
[15:06:10] <Gekz_> he's a fanboy of a debugger
[15:06:11] <Gekz_> :o
[15:06:15] * fuzzie ruffles Gekz's hair
[15:07:01] <Gekz_> http://www.gnu.org/software/ddd/all.png
[15:07:39] <Gekz_> http://cgdb.sourceforge.net/ too
[15:07:47] <fuzzie> the problem is gdb
[15:08:09] <fuzzie> you cannot fix that by putting a GUI on top :)
[15:08:26] <Gekz_> I dont see the problem with it
[15:08:29] <Gekz_> what is the problem with it
[15:08:35] <Gekz_> what makes the debugger in MSVC6 so much better
[15:09:08] <fuzzie> when you break into something using the vc++ debugger, it doesn't get confused and forget half your program state :)
[15:09:35] <Gekz_> what about Eclipse CDT then
[15:09:51] <fuzzie> they are all built on top of gdb
[15:09:56] <Gekz_> lies
[15:10:00] <fuzzie> 'tis true
[15:10:04] <Gekz_> LIES
[15:10:34] <tomprince> Is it the lack of debug information in optimized code?
[15:11:01] <fuzzie> well, that is not gdb's fault
[15:11:05] <fuzzie> and they are fixing that on the gcc side
[15:11:32] <fuzzie> much improved in latest gcc, i believe?
[15:12:05] <tomprince> Undoubtedly. And gdb now has python support.
[15:12:20] <Gekz_> oh shit
[15:12:21] <Gekz_> that's interesting
[15:12:25] <Gekz_> I like python support
[15:12:33] <Gekz_> but WTF do you need a debugger for
[15:12:34] <Gekz_> I dont get it
[15:12:36] <tomprince> Very nice for working with stl.
[15:13:35] <Gekz_> how so
[15:13:59] <fuzzie> you can do 'print some_vector' and gives you useful information. :p
[15:14:41] <Gekz_> you can do that with gdb
[15:14:51] <fuzzie> not without the python pretty-printers
[15:15:33] <Gekz_> oh no
[15:15:36] <Gekz_> I have been slain
[15:15:41] <fuzzie> :)
[15:15:50] <tomprince> Well, not easily, or as clearly.
[15:16:00] <fuzzie> yes, vector is a bad example, i guess
[15:16:07] <fuzzie> sorry :)
[15:16:20] <Gekz_> should compare CDT to VC6 for the use within GemRB
[15:16:21] <Gekz_> and compare
[15:16:27] <Gekz_> compare and compare and compare
[15:16:42] <fuzzie> msvc10's debugger is ridiculously superior though
[15:16:52] <Gekz_> then why not use it
[15:17:28] <fuzzie> costs money :)
[15:17:36] <Gekz_> Express doesn't
[15:17:42] <fuzzie> it does not have the full debugger.
[15:17:53] <Gekz_> and I'm assuming that he has MSDN subscription
[15:18:02] <fuzzie> :p
[15:18:56] <fuzzie> there is certainly a VS2010premiumx86 lying on my uni MSDNAA server
[15:19:13] <Gekz_> with 10 cd keys?
[15:19:42] <fuzzie> but apparently you need 'Ultimate', not 'Premium'.
[15:19:54] <Gekz_> for the debugger?
[15:19:55] <Gekz_> lol
[15:19:56] <Gekz_> really
[15:21:44] <fuzzie> for the expensive debugger bits :)
[15:21:59] <fuzzie> although maybe that is just reversible debugging, which gdb can do, i hear
[15:22:12] <Gekz_> http://msdn.microsoft.com/en-us/library/dd264915.aspx
[15:27:11] <Gekz_> holy shit
[15:27:17] <Gekz_> ultimate is $11,899
[15:27:43] <Gekz_> Professional with MSDN Essentials: $799
[15:27:45] <Gekz_> none of it is cheap
[15:30:33] <Gekz_> oh well
[15:30:42] <Gekz_> they come with every piece of MS software known to exist
[15:30:43] <Gekz_> haha
[15:33:31] <tomprince> fuzzie: what did you mean by it doesn't get confused? Is it just the debug info thing?
[15:34:31] <fuzzie> it often gives me corrupted stacks, for example, where it would be capable of working things out
[15:34:46] <fuzzie> all this is known upstream, they just don't have the time to fix everything
[15:35:06] <fuzzie> and it's presumably something microsoft have a whole team working on :)
[15:36:19] <fuzzie> but i think it is indeed mostly *bugs* now
[15:43:38] <tomprince> Well, redhat does seem to have a team actively working on gdb.
[15:46:38] <tomprince> Looking at the mailing list, I saw some posted a prettyprinter for debugging into libpython.
[15:48:09] <fuzzie> oh?
[15:48:20] <fuzzie> there's some *very* impressive stuff in Fedora
[15:48:55] <fuzzie> https://fedoraproject.org/wiki/Features/EasierPythonDebugging I guess?
[15:49:28] <fuzzie> if that's what you saw, it seems to work well
[15:50:05] <fuzzie> but you're right, I guess all this recent 'Archer' stuff is Red Hat's team.
[15:53:44] <tomprince> Yes, I guess it is that, altough I just saw the orignal mailing list posting linked from there. :)
[15:55:47] <Gekz> they keep stressing "code reuse" and refactoring code in Java class
[15:55:58] <Gekz> I think the lecturer is smoking too much pot to know what that means
[15:56:05] <Gekz> it says my code uses too much code
[15:56:14] <Gekz> because I 'concatenate strings 75 times'
[15:56:25] <Gekz> it requires making a really long strong due to constraints
[15:56:27] <Gekz> >_>
[15:56:36] <tomprince> I wonder if it is possible to convince the msvc6 debugger to use code compiled by another compiler.
[15:57:15] --> Lightkey has joined #GemRb
[15:58:27] <Gekz> I know it isnt
[15:58:34] <Gekz> uses different symbols
[15:58:45] <Gekz> it's like how you cant link something cpomiled with gcc to something in msvc
[16:02:03] <tomprince> You can.
[16:03:50] <Gekz> nay sir
[16:03:53] <Gekz> I've googled it
[16:03:56] <Gekz> :o
[16:04:10] <Lightkey> IMPOSSIBLE!
[16:04:29] <tomprince> Merely difficult, I suspect.
[16:04:58] <Gekz> googles it
[16:20:57] <tomprince> I wonder if a newer msvc compiler could be used to generate code to run in the msvc6 debugger?
[16:29:13] <Gekz> http://sources.redhat.com/insight/screenshots.php
[16:29:15] <Gekz> oh god that's cool
[17:00:54] --> Edheldil_ has joined #GemRb
[17:03:15] --> tomprince_loki has joined #GemRb
[19:01:01] <tomprince_loki> fuzzie: or.cz/holder work in progress, but does this look reasonable, and deal with your concerns about ->release()?
[19:02:37] <tomprince_loki> And, related question, do you know if there are any interdependencies in ~Interface()?
[20:08:17] <-- lynxlynxlynx has left IRC (Remote host closed the connection)
[20:11:16] --> Nomad010 has joined #GemRb
[20:34:48] <fuzzie> well, in any case, that kind of Holder thing is always going to be adaptable to whatever we need, i think
[20:34:58] <fuzzie> but don't have time to look at it much right now
[20:40:18] <tomprince_loki> That is fine, it is nowhere near ready to commit yet.
[20:40:32] <tomprince_loki> So long as the idea seems reasonable.
[20:43:38] <tomprince_loki> It ends up at about 92files +311/-588 or so.
[20:45:16] <tomprince_loki> And right now it compiles but doesn't work, since I need to figure out how to get around include file interdependencies.
[20:49:48] --> raevol has joined #GemRb
[21:10:58] <-- tomprince_loki has left IRC (Read error: No route to host)
[21:16:42] --> tomprince_loki has joined #GemRb
[21:29:53] --> cfchris6_ has joined #GemRb
[21:32:44] <-- cfchris6 has left IRC (Ping timeout: 240 seconds)
[22:01:15] --> Avenger has joined #GemRb
[22:01:28] <CIA-74> GemRB: 03avenger_teambg * rfe1f4d0caa48 10gemrb/gemrb/core/ (Actor.cpp Actor.h): handle casting level bonus
[22:01:30] <CIA-74> GemRB: 03avenger_teambg * r68bff1ddc936 10gemrb/gemrb/core/ActorBlock.cpp: handle casting level bonus
[22:01:31] <CIA-74> GemRB: 03avenger_teambg * rdb9f45cc309e 10gemrb/gemrb/core/Interface.cpp: handle casting level bonus
[22:05:02] <-- Avenger has left IRC (Client Quit)
[22:44:41] <-- raevol has left IRC (Quit: Leaving.)
[23:40:31] <-- tomprince_loki has left IRC (Ping timeout: 245 seconds)