[02:45:02] <-- Marzo has left IRC (Ping timeout: 255 seconds)
[05:50:16] --> Dominus1 has joined #exult
[05:50:16] <-- Dominus has left IRC (Read error: Connection reset by peer)
[06:02:46] <-- sh4rm4 has left IRC (*.net *.split)
[06:43:10] <-- ettin has left IRC (*.net *.split)
[06:43:11] <-- Matt_O has left IRC (*.net *.split)
[06:48:32] --> Matt_O has joined #exult
[06:48:32] --> ettin has joined #exult
[07:42:55] <-- ettin has left IRC (*.net *.split)
[07:42:55] <-- Matt_O has left IRC (*.net *.split)
[07:44:40] --> Matt_O has joined #exult
[08:29:13] <-- Dominus1 has left IRC (Read error: Connection reset by peer)
[08:29:51] --> ettin has joined #exult
[09:00:11] --> sh4rm4 has joined #exult
[09:08:28] <-- sh4rm4 has left IRC (*.net *.split)
[09:14:01] --> sh4rm4 has joined #exult
[09:34:19] <-- sh4rm4 has left IRC (*.net *.split)
[09:34:24] <-- ettin has left IRC (*.net *.split)
[09:38:31] --> sh4rm4 has joined #exult
[09:38:31] --> ettin has joined #exult
[10:33:19] --> Dominus has joined #exult
[10:33:19] --- ChanServ gives channel operator status to Dominus
[10:57:25] <Dominus> damn, sleeping in beds really is buggy. you can't sleep in the upper floor bed in Christophs house in Trinsic :(
[11:07:27] <Dominus> find_closest is probably not checking for lift
[11:16:24] <Dominus> all that lift stuff is too complicated for me :(
[11:19:01] --> Marzo has joined #exult
[11:24:04] <Dominus> I get the feeling that there is some kind of offset in SI opposed to BG that often makes NPCs miss their schedule spot by some pixels
[11:24:37] <Dominus> apparent in the eat at in schedule but also othe rlittle things
[11:27:55] <Dominus> and walls in SI are no longer obstacles...
[11:29:08] <Dominus> place two crates on each other behind a wall and another crate next to the pile. get behind the wall (best in a house) and double click the crates. you will be able to open the piled up crate. but not the others
[11:29:33] <Dominus> when I begin looking at bug reports I do get the feeling that we have a very buggy game engine :(
[11:41:24] <Marzo> Dominus: that is just Murphy's law of computer programming
[11:41:41] <Marzo> That is: "any nontrivial program has bugs"
[11:43:37] <Marzo> Well, the xBR scalers are finally compiling; time now to see how many bugs I have to squash to get them in usable form
[12:27:46] <Marzo> Hrm. 3xBR is having several artifacts, and Exult with 2xBR uses two times more CPU than Exult with HQ2x.
[12:58:57] <-- Kirben has left IRC ()
[13:03:27] <Dominus> that's not how it was advertised :(
[13:04:36] <Dominus> and about the bugs, yes, I know ot's to be expected, it's just so frustrating at times. In SI the bugs seem to pile up and up and up... and especially stuff that is supposed to be fixed a long time ago
[13:09:50] <Marzo> Artifacts are gone, but CPU cost is still high
[13:23:26] <Dominus> how does it look? sounds as it is unusable with 3x and higher...
[13:40:35] <Marzo> It is usable, yes; I am eliminating a few artifacts due to the mouse pointer (due to improper bounds being set) and will take some screenshots of HQ3x vs 3xBR
[13:41:17] <Marzo> (and also will see if I can get it to correctly scale when starting Exult with NxBR scalers)
[13:42:27] <Marzo> I know that there are ways to speed it up, but some of them are very memory hungry
[13:43:21] <Marzo> For example, the original uses a large lookup table for RGB->YUV conversion which is fast (as long as it does not run afoul of the processor cache) but which makes Exult use 5 times more memory than it does
[15:02:32] <Eviltar_> did you use the CSV version of xbr, or the gpu shader version?
[15:03:28] <Eviltar_> my buddy took a shader that split the screen into red/blue for a fake3d and we put that in SDL so we could build fake-3d versions of a few apps like exult
[15:09:56] <Eviltar_> http://www.youtube.com/watch?v=ZtoQ-KWbMk0&feature=plcp
[16:09:07] <Dominus> Eviltar_: ah that hurts my eyes :)
[16:10:12] <Eviltar_> yeah it wasn't even real 3d since the whole picture was evenly seperated
[16:11:11] <Marzo> Eviltar_: what CSV version?
[16:11:12] <Eviltar_> i had an idea to combine that 3d effect but control the seperation with whatever 'embos' uses to find whats in focus
[16:11:28] <Eviltar_> hmm i saw refrence to one
[16:11:38] <Marzo> I took a few versions in C/C++ and did some massage to get it to work on Exult
[16:13:00] <Marzo> But of course, it seems that neither the original author nor the people that made the other versions know much about coding in these languages
[16:13:02] <Eviltar_> my bud lantus has xbr converted to fx for d3d that he uses in fba alpha
[16:13:11] <Eviltar_> if that helps you
[16:13:48] <Marzo> (for example: one condition check mixes || and && without using parenthesis to disambiguate the precedence)
[16:15:16] <Marzo> (while it is true that they have different precedences, most people don't know what their relative precedence is, so it gets hard to understand the code)
[16:17:14] <Eviltar_> it's a learning process, comments are great when they are there
[16:24:20] <Marzo> Hrm. I never noticed how many artifacts are introduced near the mouse in HQNx until I noticed them in NxBR...
[16:54:36] <-- Matt_O has left IRC (Ping timeout: 245 seconds)
[16:55:02] --> Matt_O has joined #exult
[17:02:53] --> Matt_O1 has joined #exult
[17:04:30] <-- Matt_O has left IRC (Ping timeout: 272 seconds)
[17:21:52] --> Matt_O has joined #exult
[17:22:36] <-- Matt_O1 has left IRC (Ping timeout: 240 seconds)
[17:24:01] <Eviltar_> can you snap a screenshot?
[17:24:18] <Eviltar_> also im curious, which xbr did you use A,B, or C
[17:24:33] <Marzo> Neither :-)
[17:24:42] <Eviltar_> hm?
[17:25:14] <Marzo> I started with Zenju's version for HqMAME, which Hyllian "blessed" as a fourth variant
[17:25:15] <Eviltar_> he has different variants from more round to more square
[17:25:20] <Eviltar_> ahh
[17:25:26] <Marzo> I then made some changes for better color metric
[17:25:35] <Eviltar_> neat
[17:25:59] <Marzo> I will commit the first version soon, as an experimental scaler
[17:26:35] <Marzo> Performance will be atrocious until I (or someone else) implement an intermediate decompression buffer
[17:26:59] <Eviltar_> there is also opengl version too
[17:27:08] <Marzo> The scaler will be disabled by default, and will require passing to --enable-nxbr to enable
[17:28:49] <Eviltar_> does it look nice?
[17:30:45] <Marzo> It does
[17:31:13] <Marzo> In some parts, better than HQx, in others, not so much
[17:32:09] <Eviltar_> it is strictly 3x?
[17:32:53] <Eviltar_> the mame filter wasnt using scanlines was it?
[17:33:31] <Eviltar_> sorry curiousity piqued
[17:35:38] <Eviltar_> no their screenshots don't have scanlines
[17:36:51] <Marzo> It has 2xBR, 3xBR and 4xBR versions
[17:37:17] <Marzo> From what I understand of the theory behind it, it works best for odd scale factors
[17:39:18] <Marzo> It is committed
[17:40:02] <Marzo> Dominus: try updating from SVN, then do ./configure with --enable-nxbr, then compile and run Exult
[17:40:32] <Marzo> I will investigate about improving performance later
[17:56:45] <Dominus> Marzo: gladly :)
[17:56:47] <Dominus> thanks
[18:07:44] <Dominus> marzo: beautiful
[18:08:11] <Dominus> the xbr is really keeping more details compared to the hq
[18:08:30] <Dominus> the hq seems much more washed out when compared directly
[18:12:17] <Dominus> it seems the 4xbr takes the same as the hq4x in cpu power
[18:12:41] <Dominus> (much!!! about 85% in Paws)
[18:14:12] <Marzo> It *does* look nice, doesn't it?
[18:14:46] <Dominus> yes it does
[18:15:35] <Dominus> the only odd thing I found was the vortex cube in the british museum. the br makes it much rounder than it should be. the hq4x makes it a real cube
[18:16:14] <Marzo> There are some variant rules that can be tried; some things will look better, others will look worse
[18:16:15] <Dominus> the opengl version of br would probably be much less cpu hungry :)
[18:16:37] <Marzo> It would require coding shader support in Exult, though
[18:16:43] <Dominus> our opengl scaler is the least demanding scaler of all our scalers in 4x
[18:16:56] <Dominus> hmm, that sounds not like fun :)
[18:17:01] <Marzo> That is because it uses the GPU for all its scaling
[18:18:16] <Marzo> Hm. Paperdoll quivers in female characters move around when putting on or removing pants
[18:18:43] <Marzo> Not fo much for men
[18:21:00] <Dominus> happens in all sclaers
[18:21:05] <Dominus> scalers
[18:23:36] <Marzo> Happens in original too, so nevermind
[18:24:45] <Dominus> he he, never saw this before :)
[18:25:58] <Dominus> there IS however a bug report that it is much harder to get to bolts/arrows in the quiver when wearing full armor. seems we are making the armor much bigger on the paperdoll than the original. you need to aim very careful to get to the quiver contents...
[18:26:09] <Dominus> but anyway... love the new scaler :)
[18:27:18] <sh4rm4> <Dominus> I get the feeling that there is some kind of offset in SI opposed to BG that often makes NPCs miss their schedule spot by some pixels
[18:27:25] <sh4rm4> interesting thought...
[18:30:03] <Dominus> marzo another artifacting with br: equip a death scythe. then watch the pulsating tip of the scythe. when it is dark red it warps some more pixels
[18:30:44] <Dominus> most recognizable when facing west
[18:31:00] <Marzo> Let me ruin HQx and xBR for you: if you look closely around the mouse as you move it, you will see tons of artifacts
[18:31:21] <Dominus> sh4rm4: there are a couple of other bug reports that somehow made me wonder
[18:31:37] <Dominus> Marzo: yeah you already did when you mentioned it before :)
[18:32:24] <Marzo> The only way to fix it would be to scale the screen without the mouse, then add the scaled mouse on top
[18:35:34] <Dominus> the british museum is great test case... you can see how it fails with the vortex cube (to round), the lenses (not round enough) and the ropes around the runes (not round enough)
[18:36:01] <Marzo> Wow... I did a quick profiling with gprof and I confirmed that I was right about the bottleneck
[18:37:17] <Marzo> Almost 60% of the time spent on the scaler is in 3 functions
[18:41:08] <Dominus> interesting how much fill quality plays a role, too
[18:45:05] <Eviltar_> it might look better with teh more square method
[18:45:12] <Dominus> hmmm, nice... in fullscreen watch at LB's royal carpet in the throne room. it looks really the best in br. the other scalers don't do it justice :)
[18:45:20] <Eviltar_> http://i41.tinypic.com/2uqob60.gif
[18:45:43] <Eviltar_> you can see the square/rounded leaning variants might look better/worse in different cases
[18:46:04] <Eviltar_> the loss of 'pixels' was brought up for using this with dosbox
[18:48:31] <sh4rm4> the C version looks best
[18:49:02] <Eviltar_> that was my opinion also, for that text at least
[18:50:46] <Dominus> one would need to look at other examples. for text, yes, c looks best, except for the 1990, 1991 at the bottom. the squares in the 9doesn't look too good. same for A, B, R....
[18:51:09] <Dominus> and more example of in game differences are needed...
[18:52:43] <sh4rm4> i wouldnt use any of these scalers, as they all modify the content. only point scaling is 100 % accurate
[18:53:02] <Eviltar_> http://forum.themaister.net/viewtopic.php?id=134
[18:53:20] <Dominus> scalers are highly subjective. many like them, I wouldn't go without them anymore
[18:53:29] <Eviltar_> bunch of ingame pics there
[18:53:34] <Eviltar_> results look amazing
[18:59:42] <Dominus> eviltar, I meant ingame comparison between ABC
[19:00:46] <Eviltar_> yeah he says those a a different combination all together but they just looked really nice, I'm looking for where i saw there was a CSV version
[19:03:00] <-- Philantrop has left IRC (Quit: -)
[19:06:02] <Dominus> Eviltar_: in the link you posted first some days ago
[19:06:37] <Dominus> or not... I think I saw that there
[19:07:34] <Marzo> So, which one: (http://img543.imageshack.us/img543/8105/screenshotfrom201210281.png)(https://imageshack.us/content_round.php?page=done&l=img840/8105/screenshotfrom201210281.png)
[19:07:59] <Marzo> Let me add some spaces: ( http://img543.imageshack.us/img543/8105/screenshotfrom201210281.png ) ( https://imageshack.us/content_round.php?page=done&l=img840/8105/screenshotfrom201210281.png )
[19:08:31] <Eviltar_> ahh yeah here is his 'repo' http://www.mediafire.com/?78p842uko34ce
[19:08:43] <Marzo> Direct links for both (groan): ( http://img543.imageshack.us/img543/8105/screenshotfrom201210281.png ) ( http://img840.imageshack.us/img840/8105/screenshotfrom201210281.png )
[19:10:17] <Eviltar_> http://img543.imageshack.us/img543/8105/screenshotfrom201210281.png
[19:10:25] <Eviltar_> that one imo
[19:10:38] <Dominus> yeah, it's much more shyny
[19:11:13] <Eviltar_> the text is more clear too
[19:11:34] <Marzo> You both chose the current version over version 'C' :-)
[19:11:50] <Eviltar_> nice
[19:12:26] <Dominus> didn't think c would lose so much information...
[19:13:01] <Eviltar_> looks nice man
[19:13:18] <Dominus> oh... bbl
[19:18:43] --> Philantrop has joined #exult
[19:19:58] <Eviltar_> does the chick avatar's eye always look so derpy?
[19:28:57] <Marzo> As it turns out, I had slightly botched the implementation of C; but the results were very minor (sharper corners and slightly shinier than previous C version) but not enough to make it better than what is currently in SVN
[19:30:11] <Eviltar_> it looks good what would it take to buffer what you were talking about
[19:33:20] <Marzo> Since it needs 5 lines at any given point, I will implement a 5-line rotating buffer
[19:34:19] <Marzo> Whenever a new line is needed, I remove the oldest line in the buffer and 'decompress' the new line into a format easier to work with
[19:34:42] <Marzo> This way, each pixel gets 'decompressed' once
[19:35:24] <Marzo> Currently, each pixel can be 'decompressed' up to 21 times
[19:36:50] <Marzo> I did something similar for the Scale2x algorithm some time back, but it only had 3 lines in the buffer
[19:37:23] <Marzo> (meaning Exult probably has the fastest Slace2x implementation around when the source and destination formats are different)
[19:37:38] <Eviltar_> sounds impressive
[19:47:40] <sh4rm4> <sh4rm4> this patch fixes that -g gets used even with --disable-debug http://sprunge.us/JRFF
[19:47:49] <sh4rm4> can someone review this ? ^
[19:50:28] <Marzo> Why not simply add -g0 to CXXFLAGS?
[19:50:52] <Marzo> (unless clang does not support this)
[19:51:37] <sh4rm4> yeah that could work, if it really ends up in the last position on the command line
[19:51:44] <Marzo> As is, your patch fails if CXXFLAGS=-O2 -g
[19:51:52] <sh4rm4> no
[19:52:06] <sh4rm4> because the default set by autotools is "-g -O2"
[19:52:43] <sh4rm4> if you have different CFLAGS, it's not the default ones
[20:58:45] --> Dominus1 has joined #exult
[20:58:59] --- ChanServ gives channel operator status to Dominus1
[20:58:59] --- Dominus is now known as Guest77937
[20:58:59] <-- Guest77937 has left IRC (Killed (verne.freenode.net (Nickname regained by services)))
[20:58:59] --- Dominus1 is now known as Dominus
[21:38:49] --> Malignant_Manor has joined #exult
[21:54:26] <Malignant_Manor> Marzo: What's the state of your prescaled image patch, Exult HQ (or whatever it was called)?
[21:54:50] <Marzo> Same as it was way back then
[21:55:07] <Marzo> I haven't worked at it any more than what is at SVN
[21:55:19] <Marzo> Why?
[21:55:50] <Malignant_Manor> I just think about how it could be so much better than scalers.
[21:56:01] <Marzo> I agree completely
[21:56:12] <Marzo> But it will also be a huge amount of work
[21:57:07] <Malignant_Manor> I made a patch for chunk cache distance a while back that needs someone to look at it.
[21:57:22] <Marzo> Let me see it
[21:57:38] <Malignant_Manor> I need to find the patch first.
[21:58:03] <Dominus> I think I stumbled over that in the open bugs
[21:58:33] <Malignant_Manor> I don't think I added it to the tracker. I put a pastebin link in irc.
[21:58:42] <Malignant_Manor> This was a long time ago.
[21:59:08] <Malignant_Manor> I think I made minor working copy changes.
[22:00:57] <Malignant_Manor> I haven't looked at it for a long time.
[22:01:43] <Marzo> Oh, hey, this is the first time ever that a transfer from IRC worked for me
[22:02:05] <Malignant_Manor> This worked pretty well from minor testing. It would need a warning that higher settings could possible cause issues.
[22:02:55] <Malignant_Manor> That patch also needs a configuration setting and all that comes with it.
[22:04:52] <Marzo> Hrm. I can't see how it could work as is -- the line "int nearby[5*multiplier][5*multiplier];" should result in a compilation error
[22:05:43] <Marzo> Except that GCC probably is seeing that multiplier is only ever set once, to a constant value, and is replacing it by the constant value assigned to it
[22:06:24] <Malignant_Manor> int nearby;
[22:06:30] <Malignant_Manor> was the original line
[22:07:08] <Marzo> Yes; it allocates a constant array of 5x5 integers
[22:07:21] <Marzo> What is between the brackets must be constant
[22:07:49] <Marzo> (it must be a *compile time* constant)
[22:08:01] <-- Rottingbeef has left IRC ()
[22:08:31] <Marzo> For other cases, allocation/deallocation must be handled with operator new
[22:08:47] <Malignant_Manor> would int foo = 5*multiplier;
[22:08:59] <Marzo> No
[22:08:59] <Malignant_Manor> be valid or just be the same problem?
[22:09:12] <Marzo> int const foo = 5*multiplier;
[22:09:25] <Marzo> And multiplier would have to be const too
[22:09:59] <Marzo> As I said, you probably didn't run into problems before because the compiler recognized that multiplier was effectively a constant
[22:10:29] <Marzo> But as soon as it could be changed (for example, from Exult.cfg), the compiler would reject that line
[22:10:41] <Marzo> (or a different compiler might reject it altogether)
[22:10:45] <Malignant_Manor> I have no idea how to make it configurable then.
[22:11:27] <sh4rm4> int nearby[5*multiplier][5*multiplier]; is valid C99 tho
[22:11:40] <Marzo> This is C++
[22:11:40] <sh4rm4> a so-called VLA
[22:13:47] <sh4rm4> how about int *nearby = malloc(5*multiplier * 5*multiplier * sizeof int)
[22:15:05] <Marzo> I think I will simply make a square matrix class to make it more transparent
[22:15:45] <Marzo> And properly using "new" instead of "malloc": this is C++, not C
[22:16:29] <Malignant_Manor> Hopefully this won't cause more leaks.
[22:16:49] <Malignant_Manor> Exult is already so horrible in that department.
[22:17:13] <sh4rm4> it will leak, if you dont free it ;)
[22:17:57] <sh4rm4> int nearby[5*multiplier][5*multiplier], if it was C++ compatible would simply smash your stack when multiplier is big enough
[22:19:41] <Malignant_Manor> I don't know much at all about coding. I just modify existing code and don't really mess with memory management.
[22:21:31] * Dominus goes in a very different direction now... It's great in SI we've probably been always able to access crates behind walls (if you stack them the second one is openable). It's been this way in 1.2 already...
[22:21:45] * Dominus is just ranting...
[22:22:34] <Marzo> It doesn't seem like the kind of thing that would be SI-specific
[22:22:39] <Malignant_Manor> I did some hacky stuff awhile back Dominus that seemed to fix some manipulation of objects behind walls.
[22:22:57] <Malignant_Manor> I don't think I really knew what I was doing though.
[22:23:00] <Dominus> marzo, can't reproduce in BG
[22:23:28] <Dominus> Malignant_Manor: whatever you did, it was the same in Exult v 1.2, so at least you didn't make it worse :)
[22:23:54] <Marzo> By any chance, does it also happen in the originals?
[22:24:03] <Dominus> no, I checked first :)
[22:24:45] <Malignant_Manor> Did you upload a save where it is reproducible and how to reproduce it?
[22:24:51] <Dominus> I'll make a nice test savegame now and will test whether it also happens with chests and other containers
[22:24:57] <Marzo> Is there a good place to test?
[22:25:25] <Dominus> but to reproduce just start a SI game, in monitor the store west of the blacksmaith
[22:25:51] <Dominus> enter it and on the other side of the west wall behind the glass desks are some crates
[22:32:03] <Malignant_Manor> Here is the manipulation bug from before. I don't see what svn version I supposedly fixed it in. https://sourceforge.net/tracker/index.php?func=detail&aid=3118478&group_id=2335&atid=102335
[22:32:44] <Malignant_Manor> The saves may very well be relevant.
[22:33:02] <Marzo> If they still work :-)
[22:34:14] <Malignant_Manor> Did the saves change much since the end of 2010?
[22:34:48] <Dominus> it's actually ridiculous... you can move chests from one store to the other as long as the place you put it is free
[22:35:49] <Malignant_Manor> I wonder if I ever commited anything and just thought I did. I know I had found something that worked.
[22:36:31] <Dominus> hmm, it might be something special in that store
[22:37:42] <Dominus> https://dl.dropbox.com/u/7737184/exult05si.sav
[22:41:27] <Dominus> I can move stuff over to the west room but when I'm in the west room I can't move stuff over to the east
[22:45:53] <Dominus> actually reminds me of some bug Malignant_Manor fixed with moonshade and conversation that autobegins
[22:46:37] <Dominus> I think you wrote something that you fixed except for some weird pathfind bug that you can still trip over
[22:50:18] <Dominus> Malignant_Manor: that one https://sourceforge.net/tracker/?func=detail&aid=2770629&group_id=2335&atid=102335
[22:52:07] <Malignant_Manor> Exult is ignoring the roof.
[22:52:38] <Malignant_Manor> Delete the bottom glass and you can't manipulate the crates.
[22:57:44] <Dominus> so, that is the real bug to report...
[22:58:58] <Malignant_Manor> I guess.
[23:00:59] <Malignant_Manor> The previous bug I linked to is confirmed fixed.
[23:01:14] <Dominus> yeah!
[23:02:15] <Malignant_Manor> That one was really bad.
[23:06:33] <Dominus> the bug wjp and me fixed on the 10th, fire field making clones, is interesting compared to the original. In the original victims of a fire field *do* fall asleep and the fire field seems to be much less aggressive
[23:10:19] <Malignant_Manor> Yeah, that npc talking bug seems to be the same issue.
[23:10:43] <Dominus> thanks for helping me point at the roof
[23:11:55] <Malignant_Manor> Well, I need to go.
[23:12:00] <-- Malignant_Manor has left IRC (Quit: ChatZilla 0.9.89 [Firefox 16.0.2/20121024073032])
[23:12:01] <Marzo> It is indeed something along these lines; the avatar is somehow finding a path on top of the glass which would allow getting close enough to the crate
[23:15:52] <Dominus> this weird, how should it pathfind ont the glass counter? In the other bug I can see a chair helping...
[23:16:08] <Dominus> but the roof should block it anyway, shouldn't it?
[23:16:29] <Marzo> It seems that the pathfinder in question treats the avatar's height as being 1
[23:17:18] <Marzo> And yes, in theory the roof should block it... but it is not happening, I am seeing a path being made with z increasing in steps of 2 then heading towards the crate
[23:20:45] <Dominus> so the avatar is making use of the tools available in the store and builts himself something to pass over... suuuuure :)
[23:23:15] <Dominus> grrr. it's getting late. got to go to bed. tomorrow morning I got the first shift to get up with the kid... that's in about... 5-6 hours... :(
[23:28:14] <Marzo> Well, I have a tentative fix
[23:28:34] <Marzo> But I have no clue if it breaks something else
[23:39:12] --> Kirben has joined #exult
[23:39:12] --- ChanServ gives channel operator status to Kirben
[23:44:36] <-- Marzo has left IRC (Ping timeout: 276 seconds)