[02:37:34] <-- Dominus has left IRC (Ping timeout: 260 seconds)
[02:37:53] --> Dominus has joined #exult
[02:37:53] <-- Dominus has left IRC (Changing host)
[02:37:53] --> Dominus has joined #exult
[02:37:53] --- ChanServ gives channel operator status to Dominus
[03:05:50] <-- frob has left IRC (Remote host closed the connection)
[06:00:03] --> frob has joined #exult
[06:04:46] <-- frob has left IRC (Ping timeout: 260 seconds)
[06:11:58] <-- crb has left IRC (Ping timeout: 258 seconds)
[06:37:40] --> crb has joined #exult
[07:30:39] --> i30817 has joined #exult
[07:35:13] <i30817> Hello. What's the situation with mt32emu on the master git repo? Launchpad finally managed to make imports to git repositories work (their bzr conversion choked on the gpgsig signing of some commits on the git repo on github so it couldn't import), so i naturally decided to update my packaging recipe.
[07:35:14] <i30817> The mt32emu library linking patch i made failed right away (i use it to link the latest version of libmt32emu since i'm already building it for dosbox).
[07:35:15] <i30817> I'm unsure if i should just delete the patch if you're updating the code mt32 code regularly yourselves or have some custom patches applied, or if i should bite the bullet and take a afternoon to update the (very simple) patch.
[07:43:56] <i30817> And i see that the ucparse.cc bison autotools compile bug was worked around upstream. Quilt didn't warn me, ffs.
[08:01:02] --> frob has joined #exult
[08:05:24] <-- frob has left IRC (Ping timeout: 245 seconds)
[08:10:31] <i30817> I also notice (but don't overly care) that the upstream code to find the roms path on exult seems to assume that the PCM rom is somehow always on the current dir unlike the hops it goes through to find the CONTROL rom. Very strange, is it not actually needed? I just need to hardcode the paths to look for them in the 'default' read only system path i created so i don't really care but still,...
[08:10:33] <i30817> ...i'd assume that you'd want to look for PCM in the same dir you found the CONTROL
[08:14:13] <i30817> Ahhh, no i looked again. It does assume that
[08:14:49] <i30817> The hops go for both, got slightly turned around by function composition
[08:36:29] <-- Lightkey has left IRC (Ping timeout: 258 seconds)
[08:47:32] <Dominus> hi i30817
[08:47:46] <i30817> Hi
[08:48:31] <Dominus> as the new mt32emu code is streamlined with MUNt now and easy to keep up to date, I'd say the external munt lib patch is no longer needed
[08:48:47] <i30817> patch is updated now though
[08:49:28] <i30817> i'm at the more complex slightly borken feature to disable the combat music one
[08:49:34] --> Lightkey has joined #exult
[08:50:47] <i30817> eh, i find the feature of having always the latest mt32emu code interesting
[08:51:03] <i30817> not that there is any difference much now
[08:51:42] <Dominus> yes, your munt lib patch and our integrated munt should be the same now
[08:51:49] <Dominus> except we have
[08:52:12] <Dominus> the current git of munt while your patch might be at v2.0?
[08:52:38] <i30817> nah, launchpad recipes pull direct from repositories
[08:53:12] <i30817> the patch is just glue to point to the system library, that is built with another recipe. So always latest, as long as it compiles
[08:53:34] <i30817> it's a buildbot basically (for apt)
[08:54:06] <i30817> with the opportunity to stack custom diff patches on top
[08:54:08] <Dominus> so, same same, only you don't need to patch Exult (unless it went way off the main munt)
[08:55:05] <i30817> yes as long as exult doesn't diverge and fork its internal code, it should be the same or slightly more updated, if you get lazy updating
[08:55:44] <i30817> that's why i asked if there were internal forks, then there would be no point to the patch
[08:55:55] <i30817> harmful even
[08:56:55] <Dominus> as Marzo said the other day, "Just have to be careful with the #ifdef HAVE_CONFIG_H" that got added on our side
[08:57:42] <i30817> where?
[08:58:10] <Dominus> mt32emu/globals.h
[08:58:45] <Dominus> https://github.com/exult/exult/commit/ff577f97274fc4812f77253d849c61404e436e15
[08:58:57] <Dominus> and mt32emu.h
[09:00:49] <i30817> Oh, that's unimportant. Not only because it's a system library compile, but because it's never going to be compiled with mingw on the ubuntu launchpad repos.
[09:01:28] <i30817> the buildbot is not for windows after all.
[09:01:51] <Dominus> yes, for your goal it is unimportant, it was more a general warning if you update the code and want it patched on our side
[09:03:50] <Dominus> i30817: with your lib patch, does Exult fail to use the mt32 driver when you set audio to mono? (as it does with the built in driver and did so before the update)
[09:04:19] <i30817> it's not compiling again yet
[09:21:42] <i30817> ugh maintaining non-upstreamed patches is so lame. This hack just to disable those nasty combat music transitions is not worth it.
[09:24:05] <i30817> it's so annoying to have that bombastic song interrupt everytime a goblin attacks thou. Maybe i should open a request for a different alternative combat songs for exult with fadeout for SI fixes instead.
[09:30:43] <Dominus> you can easily replace a song in a mod with a different ogg file
[09:40:55] <Dominus> current mt32emu driver is much less CPU taxing than the old one.
[09:42:04] <i30817> i'm using the same library for dosbox on a very bad computer, so i'm not too much worried about the cpu honestly.
[09:42:50] <Dominus> it's when you use the high quality scalers AND the mt32emu it is god that current munt is using less CPU
[09:42:56] <Dominus> especially on iOS :)
[09:43:13] <Dominus> (which has other problems with munt it seems)
[09:44:38] <i30817> iOS supposedly has a hard anti-jit kernel security barrier that they only disable for authorized software
[09:44:54] <i30817> disable self executing code basically
[09:45:47] <i30817> pretty anti-emulator policy. Just for that i'll never buy a apple device to run their OS .. not to mention the walled garden stuff
[09:46:15] <i30817> ppsspp has to use a interpreter
[09:46:31] <i30817> i dunno about dosbox
[09:51:37] <Dominus> phew I wonder if it were worthwhile to grab Dospad and add the munt patch and load that up to see whether that has similar distortions like the Exult port
[09:52:01] <Dominus> iOS has a strong reason for me to use it: EXULT!!! :)
[10:08:05] <Dominus> Marzo, have you ever noticed how Iolo's chaotic hut wreaks havoc on Exult's object sorting?
[10:19:53] <Dominus> https://www.dropbox.com/s/4ruu8wekiitny0i/Exultsawdust.png?dl=1
[10:20:06] <Dominus> https://www.dropbox.com/s/p53grcyn2uc4fb7/U7sawdust.png?dl=1
[10:20:29] <Dominus> the sawdust and the door are screwed up.
[10:20:41] <Dominus> sawdust is sorted too high
[10:48:03] <i30817> laaame, this bug again https://github.com/rofl0r/exult/issues/1
[10:48:03] <i30817> I'm just going to put in libogg-dev into the prerequisites to build and see if that fixes it
[11:03:18] <i30817> it didn't. Trying libogg.
[11:18:29] <i30817> Why does exult need libjack. Does it actually have a jack audio output
[11:18:58] <Dominus> exult doesn't need libjack AFAIK
[11:20:06] <Dominus> that must be pulled in by something else, not exult
[11:22:14] <i30817> stupid old debian control files
[11:40:44] <i30817> say Dominus, the configure.ac file says:
[11:40:46] <i30817> PKG_CHECK_MODULES(OGG, ogg >= 1.0 vorbis >= 1.0.1 vorbisfile, , AC_MSG_ERROR([*** must have Ogg/Vorbis installed!]))
[11:40:48] <i30817> This means it needs *all* of them or just *any* of them?
[11:41:46] <Dominus> it needs both
[11:42:23] <Dominus> ogg and vorbis
[11:44:30] <i30817> so libogg-dev, libvorbis-dev?
[11:46:08] <i30817> there is a libvorbisfile3 on the repos too.
[11:48:23] <Dominus> probably just the first two. libvorbisfile3 is likely another split up from libvorbis
[11:57:19] <i30817> hey, any way to order configure to use SDL2? If you have both 1.2 and 2 installed that is
[11:57:39] <i30817> i've noticed it fails building locally because i have a workaround mouse patch using a SDL2 function (it built on the buildbot because it only installed the needed sdl2.0) but it tries 1.2 locally and fails
[12:02:11] <Dominus> he he, configure --help to the rescue :)
[12:02:23] <Dominus> --with-sdl=sdl2
[12:02:34] --> frob has joined #exult
[12:02:42] <i30817> cool
[12:07:22] <-- frob has left IRC (Ping timeout: 260 seconds)
[12:22:49] <Dominus> Marzo, the sawdust in Iolo's hust is at lift 2 for some inexplicable reason. No idea if that is caused by Exult or the original had this problem and worked around it somehow
[12:23:07] <i30817> mmm, should i built in exult studio support on the package? If i'm already building exult studio anyway
[12:23:12] <Dominus> I made a map_patch to fix it but it is rather lengthy http://pastebin.com/00F1KZjV
[12:25:25] <Dominus> i30817: as you see fit :)
[12:26:13] <i30817> there is no danger of people screwing their game over by enabling the editor by accident right?
[12:26:41] <i30817> at least i'm certain that game files are in a read only location due to the way the install works
[12:27:08] <Dominus> Exult Studio never touches the original game files
[12:27:45] <Dominus> *but* it could mess up your current game if people do stuff with the editor - but just by starting the map editor, nothing will happen
[12:28:42] <i30817> I'll try it then
[12:28:59] <i30817> as soon as i figure out how it's enabled
[12:29:29] <i30817> --enable-exult-studio-support
[12:30:06] <Dominus> --enable-exult-studio
[12:30:40] <i30817> what's this btw: gnome-shp-thumbnailer
[12:30:41] <Dominus> and the glade file from /mapedit needs to go into the data folder
[12:30:56] <Dominus> it's a shp thumbnailer for Gnome :)
[12:31:09] <Dominus> for Nautilus I think
[12:31:44] <Dominus> (if the gnome file manager is called that)
[12:32:46] <i30817> does the glade file need to be writable?
[12:33:06] <Dominus> no
[12:34:38] <i30817> exult_studio.glade right? I was already installing it on the read only game data dir funny enough. Or rather, the smart guy i originally stole the packaging from
[12:35:12] <Dominus> yes that one :)
[12:35:16] <i30817> they must have not enabled exult studio completely besides building it for a reason thou... i guess i'll see
[12:36:39] <Dominus> and the exult_studio binary needs to be installed by your packaging (it will be in /mapedit, too). To test start an Exult game and press ctrl-alt-m
[13:12:23] <Dominus> hmm, my sawdust map_patch could be improved by using superchunck it seems (by looking at mappatch.cc
[13:13:52] <Dominus> or not
[13:44:44] <i30817> doesn't seem to do anything, even if the configure says it's enabled.
[13:45:36] <i30817> and running exult_studio directly and clicking 'play' has this msg:
[13:45:38] <i30817> Trying to connect to server at '/home/i30817/.exult/blackgate/gamedat/exultserver'
[13:45:39] <i30817> Socket connect: Connection refused
[13:45:41] <i30817> Error sending to server
[13:45:42] <i30817> ^C
[13:48:31] <i30817> also ugh, mididriver=mt32emu is not working
[13:49:35] <i30817> Trying config specified Midi driver: `MT32Emu'
[13:49:36] <i30817> Failed to initialize midi player (code: 1)
[13:56:18] <i30817> oh it makes sense, openROMFile is not ready to accept all kinds of files, only those in their narrow <SAVEHOME>, <DATA> or <BUNDLE> pidgeonhole.
[13:56:49] <i30817> needs a fallback to try to open a file as a file without prepending a path
[14:16:48] <-- i30817 has left IRC (Quit: ChatZilla 0.9.93 [Firefox 49.0.2/20161025170400])
[14:18:52] <Dominus> Studio requires x11. So SDL needs to be built with x support
[17:22:41] --> frob has joined #exult
[17:25:41] <-- Rottingbeef has left IRC ()
[17:26:30] <-- frob has left IRC (Remote host closed the connection)
[17:26:38] --> frob has joined #exult
[17:38:22] --> Rottingbeef has joined #exult
[18:27:07] --> ShamblerDK has joined #exult
[18:52:07] <-- frob has left IRC (Ping timeout: 240 seconds)
[18:52:38] --> frob has joined #exult
[19:16:37] <-- ShamblerDK has left IRC (Remote host closed the connection)
[20:10:31] <Marzo> <Dominus> Marzo, the sawdust in Iolo's hust is at lift 2 for some inexplicable reason. No idea if that is caused by Exult or the original had this problem and worked around it somehow < I *think* this may be due to the originals making stuff fall to the ground, which Exult does not. Have you tried looking at the sawdust in Iolo's hut on U7 Wizard and see what it reports?
[20:16:42] <Dominus> That makes sense. I haven't used U7Wizard in years ;)
[20:20:29] <Marzo> To be fair, I would not be surprised if the originals draw stuff in a vastly different way than we do
[20:21:19] <Marzo> Maybe they use something like a z-buffer to determine what should be drawn on each pixel, and draw the first thing found
[20:31:59] --> GitHub has joined #exult
[20:31:59] <GitHub> [exult] marzojr pushed 1 new commit to master: https://git.io/vXSA7
[20:31:59] <GitHub> exult/master fff311b Marzo Sette Torres Junior: Adding experimental support for link-time optimization; detection method...
[20:32:00] <-- GitHub has left #exult
[20:37:03] <Dominus> So, do you think adding this lengthy map_patch is the way to go? I guess it is hacky but the safest thing unless we add a highly critical "fall to the floor" which will likely break Exult in a thousand ways...
[20:37:41] <Dominus> I'm looking into other cases for map_patches in BG and SI
[20:39:02] <Marzo> Falling to the floor would need a way to prevent floors and roofs from doing so
[20:39:16] <Marzo> Imagine the second story of a house falling down
[20:39:30] <Marzo> (and that assumes that this is the cause of the problem)
[20:43:35] <Marzo> Dominus: for this card: https://trello.com/c/mM7KVzmR
[20:44:28] <Marzo> Oh, wait, I see you already tried what I was about to ask
[21:05:19] <Dominus> The ranlib/ar issue was driving me up the wall. Totally unneeded since it's just a stupid nonsense warning. But still ;)
[21:43:19] <-- crb has left IRC (Ping timeout: 245 seconds)
[21:46:10] --> crb has joined #exult