#exult@irc.freenode.net logs for 6 Feb 2011 (GMT)

Archive Today Yesterday Tomorrow
Exult homepage


[00:04:23] --> shazza has joined #exult
[00:06:30] <-- shazza has left IRC (Client Quit)
[00:37:48] --> shazza has joined #exult
[01:29:44] --> jvlee has joined #exult
[01:33:42] --> Colourless has joined #exult
[01:33:43] --- ChanServ gives channel operator status to Colourless
[02:16:39] <-- jvlee has left IRC (Quit: jvlee)
[02:59:01] --> jvlee has joined #exult
[03:14:52] <-- Maggie has left IRC (Read error: Connection reset by peer)
[03:40:45] <-- Kirben has left IRC ()
[03:40:53] --> Kirben has joined #exult
[03:40:53] --- ChanServ gives channel operator status to Kirben
[03:42:03] <-- Kirben has left IRC (Client Quit)
[03:44:18] --> Kirben has joined #exult
[03:44:19] --- ChanServ gives channel operator status to Kirben
[07:50:02] <-- eviltar1 has left IRC (Ping timeout: 240 seconds)
[08:27:06] --> eviltar has joined #exult
[08:49:11] <-- jvlee has left IRC (Quit: jvlee)
[09:48:50] <-- eviltar has left IRC (Ping timeout: 240 seconds)
[09:56:56] --> eviltar has joined #exult
[11:22:36] --> Dominus has joined #exult
[11:22:36] --- ChanServ gives channel operator status to Dominus
[11:57:55] --- Dominus is now known as Dominus|away
[13:09:55] <-- Kirben has left IRC (Ping timeout: 260 seconds)
[13:12:02] --> Morde has joined #exult
[13:20:26] --- Dominus|away is now known as Dominus
[14:37:32] <wjp> Dominus: did you ever notice any relation between those disappearing objects and that infinite loop?
[14:37:42] <wjp> (just idly wondering)
[14:38:22] <wjp> (since I think we deduced that the object list was corrupt for the infinite loop, and I can imagine that could cause missing objects too)
[14:53:47] <-- shazza has left IRC (Ping timeout: 255 seconds)
[14:57:18] <Dominus> hmm, the fix for the infinite loop malignant submitted did not fix the disappearing objects for one user in the bug tracker
[14:57:37] <Dominus> I was about to ask you whether you have time soonish to take a closer look
[15:00:53] <wjp> hm
[15:01:39] <Dominus> malignant thinks it is related to when we changed shape pointer handling
[15:01:54] <Dominus> https://sourceforge.net/mailarchive/forum.php?thread_name=127417248.663209.1292265459568.%40core-dbc002c.r1000.mail.aol.com&forum_name=exult-general
[15:02:08] <Dominus> also https://sourceforge.net/mailarchive/forum.php?thread_name=48909C19.7020400%40model.com&forum_name=exult-general
[15:02:20] <Dominus> and https://sourceforge.net/mailarchive/forum.php?thread_name=62151.XQYODQtBEwU%3D.1216976275.squirrel%40webmailer.hosteurope.de&forum_name=exult-general
[15:02:33] <wjp> peculiar that that change r6797 would fix the infinite loop
[15:04:09] <Dominus> maybe it fixed just one symptom of the big picture
[15:04:23] <Dominus> at least the crash was fixed there for me
[15:05:06] <wjp> I should try to put those asserts we tried a few months ago back
[15:15:02] <wjp> are there any reasonably sure ways of reproducing those disappearing objects?
[15:17:01] <Dominus> no not really
[15:17:14] <Dominus> I had it happen once but couldn't reproduce it
[15:17:41] <Dominus> it seems to be combat related
[15:17:52] <Dominus> the one time I saw it was during combat
[15:18:30] <Dominus> with that save that crashed with the infinite loop, going into the cellar and being attacked by the rats
[15:19:02] <Dominus> but couldn't reproduce it instead found the infinite loop crash there :)
[15:27:49] <wjp> hm, valgrind is showing too many errors
[15:27:56] <wjp> ==27329== More than 100 errors detected. Subsequent errors
[15:27:56] <wjp> ==27329== will still be recorded, but in less detail than before.
[15:27:57] <wjp> :-)
[15:28:45] <Dominus> oh oh :)
[15:29:01] <wjp> most of them in the scaler
[15:29:55] <wjp> ooh, this one is interesting
[15:30:43] <wjp> but probably harmless
[15:30:45] <wjp> :/
[15:33:24] <Dominus> seems exult needs some valgrind love :)
[15:33:53] <Dominus> is it possible to have it running in valgrind and not have it slow down that much?
[15:34:43] <wjp> it's not so bad here
[15:35:32] <wjp> but turning off audio and scaling may help
[15:36:23] <Dominus> hmm, really unbearable slow on my system, last time I ran it I needed to use the command line shortcuts to start the game directly and not take hours to move the cursor in the menus...
[15:39:23] <wjp> I wonder if it's slower on OS X than linux
[15:40:06] <Dominus> if we really wanted to we could make a screen recording and compare that :)
[15:40:34] <Dominus> (wish #13432442234: port Dosbox capture stuff to Exult... )
[15:58:27] <-- Sevalecpp has left IRC (Quit: Leaving)
[16:00:23] <-- Colourless has left IRC (Ping timeout: 255 seconds)
[16:02:28] --> Sevalecpp has joined #exult
[16:05:27] <wjp> Dominus: how reproducable was that infinite loop for you?
[16:05:44] <wjp> (in that bat savegame)
[16:06:13] <Dominus> the savegame for SI fixes always, the normal exult savegame almost always
[16:06:32] <wjp> I've got it to trigger a few times (after undoing the fix to see if there was any valgrind activity), but now that I've added some assert it doesn't seem to trigger at all anymore
[16:06:36] <wjp> which confuses me a lot
[16:06:38] <Dominus> But I remember that under valgrind I couldn't reproduce it mainly because it was so slow
[16:06:56] <wjp> I'm not running in valgrind currently
[16:07:05] <Dominus> strange
[16:07:34] <Dominus> want me to test as well with the asserts?
[16:08:22] <wjp> if you would. I can't guarantee it'll be at all useful though since I'm mainly just satisfying my own curiosity :-)
[16:08:31] <Dominus> :)
[16:09:00] <wjp> undo the infinite loop fix by removing line 1239 ("if (state == strike || state == fire)
[16:09:08] <wjp> ") of combat.cc
[16:09:48] <wjp> and then add a line "assert(action);" right before line 5232 ("delay = action->handle_event(this);") of actors.cc
[16:10:52] <Dominus> k. any more?
[16:11:16] <wjp> no
[16:12:35] <Dominus> ok, building... time for a cofee break...
[16:20:24] <Dominus> couldn't get it to trigger for normal si but with the si fixes savegame I could
[16:20:50] <Dominus> but still hangs in the loop
[16:21:59] <Dominus> back then we were able to have it "cleanly" crash with asserts in objs/chunks.cc
[16:22:42] <Dominus> 837
[16:22:42] <Dominus>     assert(newobj->chunk != this);
[16:22:42] <Dominus> 838    assert(!first_nonflat || first_nonflat->chunk == this);
[16:23:55] <Dominus> and/or asserts in objs/objlist.h 85
[16:23:55] <Dominus>             assert(nobj != first);
[16:23:55] <Dominus> 86            assert(first->prev != nobj);
[16:24:06] <Dominus> (and in line 99/100 as well)
[16:29:52] * Dominus is gone for a bit
[16:47:11] * Dominus is back for a bit
[16:51:59] <Dominus> I have problems triggering the infinite loop with current trunk (and undone fix) and the SI savegame. I think recent combat changes may slow combat begin down
[16:52:47] <Dominus> the bug triggers with certain placement of npcs monsters and right now the one bat is already gone too far away when the party begins combat
[16:53:00] <Dominus> with the SI fixes savegame the bug triggers
[16:53:48] <Dominus> *almost* every time
[17:17:29] <eviltar> whats up guys
[17:17:46] <eviltar> i was doing some profiling
[17:18:27] <eviltar> and picked up a bucketlaod of performance, idk if itll help with the android build or anything
[17:18:42] <eviltar> but in exult.cc
[17:19:22] <Dominus> won't help with the native android port but perhaps with the sdl android port :)
[17:19:33] <eviltar> i changed the while(!quitting_time && SDL_PollEvent(&event)){
[17:19:47] <eviltar> to if(!quitting_time
[17:20:20] <eviltar> derp, i guess I asumed it was using sdl too
[17:20:42] <wjp> you changed what to what?
[17:20:49] <eviltar> while , to if
[17:21:49] <wjp> and that doesn't cause input to lag behind?
[17:21:56] <eviltar> nope
[17:22:12] <eviltar> i might have had to add a sdl_delay(1)
[17:22:46] <eviltar> it actually helped the input
[17:22:46] <wjp> because what your change does is handle only a single input event per frame
[17:23:05] <eviltar> well
[17:23:07] <wjp> which will cause interesting effects when moving the mouse rapidly or typing a lot
[17:23:16] <eviltar> as it was, if i moved the analog stick
[17:23:24] <eviltar> the frames shot up to 60 fps
[17:23:35] <eviltar> and nothing would do aything untill i let it go
[17:24:07] <eviltar> ^ probably another xbox sdl issue
[17:24:19] <eviltar> but anyway, just sharing info
[17:25:20] <wjp> I just tried it just in case, and it completely breaks input here, exactly like I described
[17:25:48] <eviltar> i imagine it wouldnt be good for a mouse
[17:27:10] <eviltar> the xbox is so bizare :S its just an oddball case
[17:27:24] <eviltar> I finally got oggs working
[17:27:27] <wjp> I wonder if they do ugly things like change mousemotion events already in the queue
[17:27:58] <eviltar> they dont have the suport for mice in their release libraries
[17:28:28] <eviltar> you can use it in debug only
[17:29:18] <wjp> or whatever events are generated by the analog stick
[17:29:29] <eviltar> JOYAXISMOTION
[17:29:32] <eviltar> via sdl
[17:29:42] <eviltar> and that was another problem
[17:29:55] <eviltar> it generated FLOODS of axismotion events
[17:30:01] <eviltar> if you touched the stick t all
[17:30:09] <eviltar> i had to limit them too
[17:30:20] <wjp> which is why it surprises me that reading only a single event per frame doesn't cause huge lag...
[17:30:34] <eviltar> a tiny bit
[17:30:42] <wjp> how do you limit them?
[17:30:49] <eviltar> if i hold the stick for 10 seconds
[17:30:56] <eviltar> it will eventually lag
[17:31:33] <eviltar> i put a sdl_delay in before it pushes the joystick axis events
[17:32:01] <wjp> in sdl itself?
[17:32:04] <eviltar> yes
[17:32:30] <eviltar> the sdl lib we use also wasnt using threading
[17:32:36] <eviltar> i changed that too
[17:35:34] <wjp> I can't imagine using actual delays is the best way to reduce the number of joyaxis events
[17:38:06] <eviltar> i'd love a perfect solution
[17:38:13] <eviltar> I just dont have one :P
[17:40:13] <eviltar> besides trying to learn how an ogg stream works, the 'mouse' via joystick has been the biggest challenge
[17:40:17] <wjp> if it's actually _too_ high, I'd just reduce the polling rate
[17:41:22] <eviltar> you dont happened to know where I'd find where the polling rate is defined?
[17:42:02] <wjp> looking through the SDL sources it's kind of implicit, but SDL_JoystickUpdate is called once per iteration in SDL_GobbleEvents
[17:42:28] <wjp> (but this is with stock sdl)
[17:42:43] <eviltar> i'll look in there thanks
[17:50:32] <Darrenor64> is this sdl lib for a specific platform?
[17:52:17] <wjp> some xbox port as I understand it
[17:52:53] <eviltar> yes for teh 360
[17:53:45] <eviltar> its an update of the xbox1 sdl library
[17:56:29] <Dominus> wjp: did you get any further? probably best if you install si fixes as well to check the crash
[17:57:20] <Dominus> eviltar: congrats for making the oggs work
[17:57:41] <Dominus> eviltar: so your port is working mostly fine now?
[18:00:03] <eviltar> its working great
[18:00:31] <eviltar> i dont know what else to fix now except work on the mouse more
[18:00:43] <Dominus> really congratulations now :)
[18:01:08] <eviltar> the game still has slowdowns when it 'enters usecode'
[18:01:39] <Dominus> if you make a nice patch for your changes you can easily always grab the newest svn and just apply the patch for building your port
[18:01:42] <eviltar> but tbh thats part of Exult I'm nto going to pretend to know anything about
[18:02:04] <eviltar> i updated to 1.5 a few weeks ago
[18:02:11] <eviltar> so it shouldnt be too far off
[18:02:17] <eviltar> from trunk
[18:02:46] <Dominus> I know but we fix things all the time, especially gameplay stuff and this way you can speedily be up to date :)
[18:03:15] <eviltar> i'll ask tortoise to make a patch
[18:04:22] <eviltar> i need to submit some of my fixes back to the guy that did our sdl port
[18:04:38] <eviltar> he'll be happy to know SDL can thread on the 360
[18:04:44] <Dominus> :)
[18:05:42] <eviltar> I should've been doing profile builds from the start
[18:05:47] <Dominus> and again, just maybe we can add your changes to the trunk (if your changes are clean enough), this way you'd really have an up to date trunk all the time :)
[18:05:57] <eviltar> that woudl be cool
[18:06:12] <eviltar> & future people could improve on my changes
[18:06:47] <Dominus> yes, great enough that you are doing it on a public svn though
[18:07:57] <eviltar> yanno, its kind of silly people get so worked up over other ppls programming hobbies, but I just don't want to offend anyone or make enemies just by doing a project like this
[18:08:43] <eviltar> I didnt do it for fame or credit all that shoudl go to Exult and SDL
[18:09:22] <eviltar> but I can understand when people don't share source, or take credit for other peoples work then it is pretty offensive
[18:10:38] <eviltar> idk, i did my best to respect you guys, I admire your work
[18:10:56] <Dominus> :)
[18:11:18] <Dominus> you are doing fine IMO
[18:11:48] <eviltar> 'not running around in an avatar costume soliciting gifts
[18:11:52] <eviltar> :P
[18:14:25] <eviltar> ^^ some people take donations for their homebrew ports
[18:15:04] <eviltar> maybe if I write something myself, ground up, but not for ports of open source projects, thats kind of lame IMO
[18:19:14] <Dominus> donations are fine IMO
[18:19:27] <Dominus> take a look at the work you've done
[18:19:37] <eviltar> haha, well
[18:19:49] <eviltar> the 1.49 no_mixer was work
[18:19:57] <eviltar> but after updating to 1.5
[18:20:02] <eviltar> and starting over
[18:20:09] <eviltar> it wasn't much work at all
[18:20:28] <eviltar> u7listfiles had to change a little
[18:20:39] <eviltar> the joystick stuff
[18:21:08] <-- ettin has left IRC (Ping timeout: 246 seconds)
[18:21:41] <Dominus> but it's also the bundeling and giving support
[18:21:53] <eviltar> yeah
[18:22:17] <eviltar> idk, it was for love of Ultima
[18:22:34] <Dominus> charging for it would be a sin as well as keeping the changes all to one self (as some ports of popular stuff seem to do)
[18:22:41] <eviltar> out of the 3000 people with modded 360's
[18:22:55] <eviltar> and the 100 of them over 30 years old
[18:23:12] <eviltar> so far 3 people have been happy abotu the exult port
[18:23:16] <eviltar> lol
[18:23:35] <wjp> :-)
[18:24:01] <Dominus> he he
[18:24:37] <eviltar> so if they want to buy me a beer i guess that's ok
[18:26:44] <Dominus> look at my OS X bundle baby... marzo invested much work in it, Colourless was prompted to rip out SDL_mixer partly because of that, I tried endless stuff to have a good clean build environment, and so on...
[18:27:04] <Dominus> version 1.4.9 rc1 for OSX was downloaded 736 times
[18:27:31] <eviltar> its still a good feeling to share a good memory with at least one person +)
[18:27:38] <Dominus> the windows version was downloaded over 7600 times, even the source code was downloaded 800something times...
[18:28:03] <Dominus> so all that work was done for very few people, 736 all in all :)
[18:28:22] <wjp> that's not so few though :-)
[18:28:24] <eviltar> I think you have to do it for yourself mostly
[18:28:29] <Dominus> :)
[18:28:49] <eviltar> and then sharing is just the icing on the cake
[18:35:58] --- Dominus is now known as Dominus|away
[20:02:55] --> Fingolfin has joined #exult
[20:02:56] --- ChanServ gives channel operator status to Fingolfin
[20:25:52] --> ParuNexus has joined #exult
[21:24:30] --- Dominus|away is now known as Dominus
[21:24:35] <-- Darrenor64 has left IRC (Ping timeout: 260 seconds)
[21:28:33] <-- Fingolfin has left IRC (Read error: Connection reset by peer)
[21:28:51] --> Fingolfin has joined #exult
[21:28:51] --- ChanServ gives channel operator status to Fingolfin
[21:30:36] --> Fing has joined #exult
[21:30:36] <-- Fingolfin has left IRC (Read error: Connection reset by peer)
[21:30:36] --- Fing is now known as Fingolfin
[21:30:36] --- ChanServ gives channel operator status to Fingolfin
[21:39:59] --> Darrenor64 has joined #exult
[21:49:10] <eviltar> derp, thanks wjp for the tip about not delaying inside sdl_joystick
[21:49:24] <eviltar> i made a static int to toggle every other shot
[21:49:40] <eviltar> and got rid of the sdl_delay in there
[21:49:49] <eviltar> so i get half the axis events
[21:49:55] <eviltar> and no lag
[21:51:39] <Dominus> another one bites the dust :)
[21:52:45] <wjp> great
[21:53:03] <eviltar> muchas gracias
[21:59:28] <-- Sevalecpp has left IRC (Quit: Leaving)
[22:03:14] --> Sevalecpp has joined #exult
[22:03:14] <-- Sevalecpp has left IRC (Changing host)
[22:03:14] --> Sevalecpp has joined #exult
[22:06:52] <-- Rottingbeef has left IRC ()
[22:20:50] <-- Morde has left IRC (Ping timeout: 240 seconds)
[22:20:55] --> Demorde has joined #exult
[22:34:45] --> Malignant_Manor has joined #exult
[22:37:17] <Malignant_Manor> wjp: I think there is still an issue with the loop in Combat. It may be in the approach part. My "fix" just reverted going there in a few cases. Endless loops still happen in combat but cannot be reproduced repeatedly like in the save.
[22:38:52] <Malignant_Manor> I haven't read through the log yet about what you have discussed in detail.
[22:39:38] <-- Demorde has left IRC (Ping timeout: 240 seconds)
[22:39:47] --> Morde has joined #exult
[22:40:34] <wjp> nothing worth reading the logs for I think
[22:41:28] <Malignant_Manor> I'm really not sure if it is pointer changes but I know some disappearing was not likely through combat.
[22:44:25] <-- Fingolfin has left IRC (Quit: Fingolfin)
[22:46:58] <Dominus> this bug sucks! non-reproduceable bugs that you know exist are baaaaaad
[22:47:59] --> Rottingbeef has joined #exult
[22:47:59] <Malignant_Manor> Well, the loop is reproducible. The few tries I did to change approach, didn't work nice.
[22:48:28] <Malignant_Manor> I need to finish some more work on the New game stuff.
[22:48:30] <Dominus> I mean the disappearing objects bug
[22:48:49] <Malignant_Manor> Yeah, that one is really bad.
[22:52:33] <Dominus> Malignant_Manor: will you add your new game pack to the source?
[22:53:13] <Malignant_Manor> I'm not sure. A lot are placeholders.
[22:54:25] <Dominus> from the stuff I saw in that forum post, your stuff looks way better than the stick figure that jeff added years ago
[22:54:49] <Malignant_Manor> It actually has all frames.
[22:57:12] <Malignant_Manor> There's also some issue where shape 160 is also expected to be a body since I had it there earlier. The game will crash if it is not a body shape.
[22:57:30] <Malignant_Manor> The last one really isn't a big deal.
[22:58:32] <Malignant_Manor> I will probably wait until I have at least some decent documentation.
[22:58:42] <Malignant_Manor> That won't be in my next release.
[22:59:17] <Dominus> :)
[22:59:50] <Malignant_Manor> I lost some data a long time ago and I think I have to change most or all of the paperdol.vga offsets.
[23:00:32] <Malignant_Manor> I think the only other thing to do is finish going through the messages and getting them described and not using the original sayings.
[23:02:08] <Malignant_Manor> The txt msg file so far: http://pastebin.com/UF6QQ5DC
[23:02:46] <Malignant_Manor> Oh, I probably need to update my SVN patches.
[23:03:05] <Dominus> neat
[23:04:18] <Malignant_Manor> The doors do not use the same frames as BG and SI, through the usecode I added anyway.
[23:04:46] <Malignant_Manor> I need to right another version that does.
[23:05:17] <Malignant_Manor> The door options in the default games is rather limited.
[23:05:24] --> Demorde has joined #exult
[23:06:02] <-- Morde has left IRC (Ping timeout: 240 seconds)
[23:06:27] <Malignant_Manor> I think mine requires 32 frames for each door though. (16 for lengthwise and 16 for heightwise)
[23:27:05] --> Kirben has joined #exult
[23:27:05] --- ChanServ gives channel operator status to Kirben