#xu4@irc.freenode.net logs for 26 Feb 2015 (GMT)

Archive Today Yesterday Tomorrow
xu4 homepage


[02:32:43] --> DominusExult has joined #xu4
[02:32:47] <-- Dominus has left IRC (Ping timeout: 246 seconds)
[02:33:13] --- DominusExult is now known as Dominus
[06:47:30] <-- Lightkey has left IRC (Ping timeout: 256 seconds)
[07:00:24] --> Lightkey has joined #xu4
[08:27:08] --> DominusExult has joined #xu4
[08:29:26] <-- Dominus has left IRC (Ping timeout: 246 seconds)
[08:29:27] --- DominusExult is now known as Dominus
[09:14:12] --> DominusExult has joined #xu4
[09:16:20] <-- Dominus has left IRC (Ping timeout: 246 seconds)
[09:16:21] --- DominusExult is now known as Dominus
[10:06:46] --> DominusExult has joined #xu4
[10:08:50] <-- Dominus has left IRC (Ping timeout: 246 seconds)
[10:08:51] --- DominusExult is now known as Dominus
[10:20:47] --> DominusExult has joined #xu4
[10:23:11] <-- Dominus has left IRC (Ping timeout: 246 seconds)
[10:23:12] --- DominusExult is now known as Dominus
[18:34:23] --> Jupp3 has joined #xu4
[18:34:33] <Jupp3> Hey
[18:35:00] <Jupp3> Having a bit of problem with the latest xu4 (latest, as in "svn checkout 30 minutes ago or so")
[18:35:31] <Jupp3> My end plan is to bring this version to MorphOS, BUT as it sems, I'm already having issues on X86/64
[18:37:33] <Jupp3> And I remember having the same issue (segfault) some months ago, thought it might be just temporarily broken, and check it later again, and I finally remembered about it now :D
[18:37:56] <Jupp3> This time, though, I did the install of data files manually (instead of using what I had for earlier version)
[18:39:07] <Jupp3> I wrote specific readme for older version, which I followed now: http://jupp3.binaryriot.org/readme.morphos.txt
[18:39:35] <Jupp3> And it seems that it worked (although didn't try beyond intro sequence) until I installed the graphics upgrade.
[18:41:48] <Jupp3> (and this far it's all on ubuntu X86/64, readme is for MorphOS version though, but I successfully used the same steps on earlier version on linux too)
[21:41:58] <Dominus> hey Jupp3
[21:42:09] <Dominus> so it only breaks with the graphics update?
[21:42:19] <Dominus> that's odd
[21:56:55] <Jupp3> Dominus: Well, haven't tried much yet
[21:57:07] <Jupp3> But it worked with only game extracted in ultima4/
[21:57:17] <Jupp3> Then still working after the ogg musics
[21:58:26] <Jupp3> Then I unarchived the gfx update over ultima4/ and bang!
[21:58:51] <Dominus> that's the problem
[21:59:10] <Dominus> you don't need to unarchive it, if I remember correctly
[21:59:21] <Jupp3> Yeah, I read that from the documentation
[21:59:24] <Dominus> just point at it and xu4 will use it
[21:59:44] <Jupp3> But being such small amount of data (compared to f.ex. musics), I figured out "why not"
[21:59:48] <Jupp3> And this worked in the past
[22:00:12] <Dominus> thing is, this way you can keep a clean u4
[22:00:17] <Jupp3> Anyway, can't figure out why this would be a reason for game engine to go boom :)
[22:00:37] <Dominus> and are you sure it worked in the past and you hadn't installed the update correctly instead of just copying it over?
[22:02:20] <Jupp3> Dominus: I'm pretty sure I used the same data files after upgrade to latest source
[22:02:23] <Jupp3> Earlier time I tried
[22:02:41] <Jupp3> But I guess at least some "engine-provided" data files changed
[22:03:10] <Dominus> so how huge was the step from last time it worked to recent svn?
[22:03:53] <Jupp3> Dominus: Last release :)
[22:04:36] <Dominus> yeah, well... :)
[22:04:56] <Jupp3> So I guess in software terms "an eternity ago"
[22:05:12] <Dominus> so, do a clean u4, don't extract the upgrade over it and try again... :)
[22:05:21] <Dominus> and yes, that's an eternity
[22:15:25] <Jupp3> Dominus: Seems to work this far, trying a bit further...
[22:15:40] <Jupp3> But even if this works, I can't see why they unarchived shouldn't
[22:17:27] <Dominus> they do work unarchived, I think, just not mixed up anymore :)
[22:18:39] <Dominus> and with different graphics styles available now, I guess it is an important change, so you can switch between styles and not have the graphics upgrade stick its nose in every style
[22:28:27] <Jupp3> Dominus: In any case, if you're interested in fixing bugs, that's how to trigger some :)
[22:28:55] <Dominus> as I wrote, it's most likely not a bug but a feature
[22:32:28] <Jupp3> Dominus: Well, that's one way to call illegal memory accesses
[22:33:02] * Dominus shrugs - not going to hunt down something like this :)
[22:33:28] <Dominus> gdb would probably tell you more of the source of evil
[22:37:37] <Jupp3> Dominus: Actually I was using valgrind. It's related to xml element validation btw
[22:39:19] <Dominus> so, mot likely: passes test for available u4, then crashes when a file does not fit what is expected to be (probably something written down in an xml file)
[22:41:06] <Dominus> probably filetype in graphics.xml
[23:00:29] <Jupp3> Dominus: Seems to get stuck in external loop looking for ega.drv (although I guess valgrind lets it run longer)
[23:03:48] <Dominus> hmm, maybe the detection logic of u4isUpgradeInstalled in u4file.cpp is flawed or broken
[23:06:02] <Jupp3> Dominus: I'm not saying this should necessarily work, but I think it should at least fail in some clean "how to fix this" way, rather than just crash
[23:06:27] <Jupp3> Investigating a bit further if I can find anything
[23:09:22] <Dominus> can you report the bug and your findings at https://sourceforge.net/p/xu4/bugs/?source=navbar
[23:09:22] <Dominus> ?
[23:10:03] <Jupp3> Dominus: Nah, upgrade checking seems to be done long after illegal memory accesses
[23:10:16] <Jupp3> Or I guess I can write something about it
[23:10:23] <Jupp3> It's just that that part might not be the issue
[23:10:32] <Jupp3> There's definitely something wrong before that
[23:13:28] <Dominus> it's just I have to go to bed now and things only written on irc tend to be forgotten... :)
[23:14:31] <Jupp3> Dominus: Yeah, I'll just try to find out more first
[23:14:41] <Dominus> maybe try with gdb, could be it points you quicker to the culprit. I found valgrind to be almost useless but that's with another project which had too much noise in valgrind and was making it too slow
[23:21:21] <Jupp3> Dominus: Well, I've used both, and I have more experience with valgrind
[23:21:28] <Jupp3> And it shows this particular issue
[23:21:51] <Jupp3> Dominus: I guess adding more if (verbose) debug where it might be useful won't hurt?
[23:22:40] <Jupp3> And I got a fast computer anyway
[23:22:48] <Jupp3> (Just kidding, dual core Intel Atom :P)
[23:46:08] <Jupp3> Dominus: Anyway, there are probably few different issues... The illegal memory accesses happen even when the game "works"