#exult@irc.freenode.net logs for 18 Dec 2013 (GMT)

Archive Today Yesterday Tomorrow
Exult homepage


[00:26:45] <-- ShamblerDK has left IRC (Remote host closed the connection)
[07:56:04] --> Eviltar has joined #exult
[08:02:02] <-- sh4rm4 has left IRC (Ping timeout: 264 seconds)
[08:12:15] --> Marzo has joined #exult
[08:14:02] <-- Marzo1 has left IRC (Ping timeout: 264 seconds)
[09:50:42] <Dominus> wjp, it needs a better function... isMT32 is not enough as is clear when I looked more closely.
[09:52:02] <Dominus> it needs ismt32, but also everything that has get_music_conversion() == XMIDIFILE_CONVERT_NOCONVERSION and get_music_conversion() == XMIDIFILE_CONVERT_GM_TO_MT32 set int he cfg file
[09:52:19] <Dominus> or we will not be able to use a real MT32 as one :)
[09:53:30] <Dominus> bust also needs !midi_driver->isFMSynth (to make sure the cfg file conversions are ignored when isFMSynth...)
[10:31:06] --> sh4rm4 has joined #exult
[11:37:52] <wjp> Dominus: yes, that's what I said yesterday :-)
[11:38:07] <wjp> 23:17 <@wjp> hrm, although I suppose that will entirely miss the case of a true mt32
[11:38:10] <wjp> 23:17 <@wjp> so never mind that :-)
[12:54:30] <Dominus> wjp, yeah, seems it took me a bit longer to get what you meant there :)
[13:07:54] <sh4rm4> is there a good reason mididriver is hidden, private, or whatever ?
[13:14:48] --> TheCycoONE has joined #exult
[13:47:32] <wjp> that's the default of course
[13:47:38] <wjp> never expose more than necessary
[14:01:12] <Dominus> so a mt32_background_sfx_music() function (just trying to find a good name (most important part)) :)
[14:03:07] <wjp> well
[14:03:26] <wjp> what exactly was the condition again?
[14:04:01] <wjp> if the condition is purely "is it an mt32", then it's better to just name it "is_mt32" (or whatever is consistent with regards to _ and uppercase)
[14:04:55] <Dominus> no, it's is it a mt32 *OR* is mt32 conversion set
[14:05:11] <Dominus> or fakemt32
[14:05:53] <Dominus> a fluidsynth soundfont stack could possibly be having the correct instruments but of course can't handle the sysex messages, so uses fakemt32
[14:06:16] <Dominus> should be fine to play the mt32 background sfx tracks
[14:06:28] <sh4rm4> fakemt32 with those bg tracks sounds pretty wrong
[14:06:44] <sh4rm4> it's not like fmopl where you get completely horribly tunes
[14:07:04] <sh4rm4> but it's not exactly like background noise
[14:07:10] <Dominus> sh4rm4: with a soundfont it all depends on the instruments
[14:07:20] <sh4rm4> well, with the default soundfonts
[14:07:30] <sh4rm4> for GM and GS
[14:07:47] <sh4rm4> i doubt there are many fluidsynth users that use better fonts
[14:08:03] <Dominus> well, that's why you read the documentation and only set fakemt32 if you have a MT32 compatible one
[14:08:05] <wjp> and how important are all these cases? This is starting to sound far too complicated
[14:09:24] <Dominus> wjp, the cases should just be as it is now in gamewin, jsut being able to exclude isFMSynth
[14:09:37] <wjp> "just"? :-)
[14:09:43] <wjp> so that's a 6-way test? :-)
[14:10:35] <sh4rm4> if (is_ogg() || is_real_mt32()) play_background_sfx();
[14:11:01] <wjp> please don't use "real" if an emu is also real
[14:12:08] <Dominus> midi && !isFMSynth && (ogg || mt32 conversion || fakemt32 || isMT32)
[14:12:27] <Dominus> in a nonfunctional nutshell
[14:12:32] <wjp> what's the difference between fakemt32 and mt32 conversion?
[14:12:51] <Dominus> mt32 sends the sysex messages, fakemt32 does not
[14:12:58] <wjp> what's the difference between fakemt32 and mt32 conversion?
[14:13:07] <wjp> um
[14:13:20] <wjp> let's try the right key this time
[14:13:58] <wjp> but then what's the difference between isMT32 and mt32 conversion?
[14:14:13] <wjp> this is all far too confusing
[14:14:22] <wjp> are there actual usecases for this?
[14:14:33] <Dominus> yes
[14:14:49] <Dominus> isMT32 right now is only the MT32Emu driver
[14:15:28] <Dominus> mt32 conversion is needed in Windows and OS X when you select the Midi device that a real MT32 has hooked up
[14:15:51] <wjp> (and linux)
[14:15:57] <wjp> (and every OS)
[14:16:16] <Dominus> fakemt32 conversion is needed when you have a midi driver that has the right MT32 instruments but doesn't handle sysex messages
[14:16:25] <wjp> do people have that?
[14:16:41] <wjp> if it's just one person, I'd suggest not caring
[14:16:52] <Dominus> yes, with Fluidsynth and the right soundfont
[14:17:14] <wjp> and does it improve the experience over regular GM?
[14:17:15] <Dominus> you could have that. I think Marzo achieved this with a soundfont stack
[14:17:46] <Dominus> yes, it sounds like a MT32 and *could* have the background sfx tracks :)
[14:22:41] <Dominus> timidity, too, btw.
[14:23:06] <Dominus> don't know if anyone uses that still, though...
[14:23:52] <wjp> anyway, I'd suggest wrapping all of those in a single is_mt32 check then
[14:24:10] <wjp> since for the world "outside of Midi.cc" all of them look like an MT32
[14:24:18] <Dominus> true
[14:24:20] <wjp> even if the handling internally is different
[14:24:39] <wjp> with proper comments saying what exactly this function is testing
[14:24:54] <Dominus> yes
[14:25:13] <wjp> so that's something like this in Midi.h: bool is_mt32(); // Check for true mt32, mt32emu or fakemt32
[14:25:19] <wjp> and this in Midi.cc:
[14:25:25] <wjp> bool Midi::is_mt32() {
[14:25:52] <wjp> return midi_driver && (midi_driver->-isMT32() || conversion blah);
[14:25:53] <wjp> }
[14:26:10] <wjp> and maybe a && !midi_driver->isFMSynth() or so
[14:34:52] <wjp> if at some point in the future it needs to become more complicated we can have it return an enum value that says _what kind_ of mt-32
[14:35:11] <wjp> but as long as the "world outside of Midi.cc" doesn't care, simpler is better
[14:39:54] <Dominus> k, looks like something i can apply. will do later, got to go now.
[14:40:17] <Dominus> thanks for bearing through this confusing topic...
[15:49:57] <sh4rm4> <Dominus> don't know if anyone uses that still, though...
[15:50:03] <sh4rm4> timidity is still widely used
[15:50:20] <sh4rm4> from my experience more often than fluidsynth
[15:50:56] <sh4rm4> actually exult is the only game i know that supports fluidsynth
[16:04:53] <Dominus> sh4rm4: scummvm has fluidsynth too ;)
[16:05:43] <Dominus> I thought fluidsynth is preferable since it actually has people occasionally working on it
[16:06:41] <sh4rm4> btw i just did a walk speed test
[16:07:13] <sh4rm4> in original, it takes 8 seconds to "run" straight down from the south moonshade wall to the swamp
[16:07:31] <sh4rm4> with exult (10 FPS, lowest resolution) it takes 12 sec
[16:27:03] <Dominus> on a real machine?
[16:27:17] <sh4rm4> no, dosbox
[16:27:46] <sh4rm4> my pc is fast enough to emulate a 486 at full speed
[16:29:14] <sh4rm4> cpu usage is far below 100% so it doesnt make the game faster than it's supposed to be
[16:30:13] <wjp> that doesn't follow
[16:31:06] <Dominus> in dosbox when cpu is at 100% it only means you've come to the highest cycles your pc can give dosbox
[16:31:37] <Dominus> not that it doesn't run faster than original
[16:32:06] <sh4rm4> if a game runs faster in emulation, that means it has hardcoded pc speed assumptions
[16:32:14] <sh4rm4> a good game doesn't do that
[16:32:31] <sh4rm4> it queries timers to find out when it has to redraw
[16:32:37] <Dominus> like Black Gate...
[16:32:58] <Dominus> run that in Dosbox at the same cycles...
[16:33:25] <sh4rm4> black gate ran equally fast on my friends 386dx40 and on my 486dx100
[16:34:03] <Dominus> it doesn't
[16:34:19] <Dominus> you might remember that but it doesn't
[16:34:42] <Dominus> you are already trying to use dosbox as a reference so use that
[16:35:15] <Dominus> but honestly almost all dos games benefit highly from higher cycles
[16:36:02] <sh4rm4> i only ever saw a single game that was much faster to play on a fast pentium, iirc it was california games
[16:36:13] <sh4rm4> it ran absurdely fast so you couldnt play it really
[16:36:15] <Dominus> my imac ranges in over Pentium 266 rank in a Dos benchmark
[16:36:22] <sh4rm4> all other games behaved as expected
[16:37:27] <Dominus> well they don't in Dosbox at higher cycles
[16:37:28] <sh4rm4> Dominus, it's true that the emulated machine is capable of doing more calculations
[16:38:02] <sh4rm4> but when the game is properly code, it only does whatever number of calculations needs to be done to get the next frame drawn in time
[16:38:26] <sh4rm4> if your pc is much faster than the lowest end machine it was designed for, the number of calculations doesnt change
[16:38:40] <sh4rm4> so the only difference is that your cpu is idling more often
[16:38:45] <Dominus> anyway try Black Gate at higher than 7000 cycles in Dosbox and you will see
[16:39:08] <Dominus> many dos games weren't properly coded
[16:39:10] <sh4rm4> i've removed the cycles cap in dosbox
[16:39:17] <sh4rm4> should always run at full speed
[16:39:21] <Dominus> in that regard
[16:39:38] <sh4rm4> anyway... my feeling is that walking is too slow in exult
[16:39:44] <TheCycoONE> ug... shouldn't have extended my highlight list to include .*cyc.*
[16:39:45] <sh4rm4> even with 10 fps
[16:40:03] <Dominus> yeah, then don't compare the original u7 in dosbox with exult
[16:40:20] <sh4rm4> so it would actually be nice to be able to increase the fps to more than 10
[16:40:31] <Dominus> anyway... my feeling is your research is flawed
[16:40:50] <Dominus> it's insanely fast on my machine
[16:40:51] <sh4rm4> 15 would probably give me the speed i want, so running is as fast as in real SI
[16:41:19] <Dominus> last time, try it on a real machine not dosbox
[16:41:33] <sh4rm4> is there a good reason the fps are capped at 10 ?
[16:41:46] <sh4rm4> i think the user should be free to adjust it to his needs
[16:43:37] <Dominus> yes it's capped because it is too fast otherwise
[16:44:04] <sh4rm4> not for me ... and probably also not for others
[16:45:04] <Dominus> well, the source is free...
[16:47:39] <Dominus> back to dosbox, the right cycles for u7 are around 7 and 12k, everything above is way too fast...
[16:53:16] <Dominus> also in Exult try point scaler at 2x
[16:53:31] <Dominus> you might tax your pc too much ;)
[16:57:33] <sh4rm4> yeah i use point scaler x 2 (640x400 window)
[17:48:38] <-- Matt_O1 has left IRC (Quit: Leaving)
[18:30:22] --> TheCycoTWO has joined #exult
[18:33:14] <-- TheCycoONE has left IRC (Ping timeout: 264 seconds)
[18:56:54] --> Matt_O has joined #exult
[19:03:55] <Dominus> ok, seems to work
[19:04:24] <Dominus> bool MyMidiPlayer::is_mt32()
[19:04:24] <Dominus> {
[19:04:24] <Dominus> return midi_driver && (midi_driver->isMT32() ||
[19:04:24] <Dominus> get_music_conversion() == XMIDIFILE_CONVERT_NOCONVERSION ||
[19:04:25] <Dominus> get_music_conversion() == XMIDIFILE_CONVERT_GM_TO_MT32) &&
[19:04:26] <Dominus> !midi_driver->isFMSynth();
[19:04:27] <Dominus> }
[19:04:31] <Dominus> in Midi.cc
[19:04:57] <Dominus> then in gamewin.cc:197 I have this: if (player && (player->get_ogg_enabled() || player->is_mt32())) {
[19:05:25] <Dominus> then in gamewin.cc:197 I have this: if (player && (player->get_ogg_enabled() || player->is_mt32())) {
[19:05:40] <Dominus> wjp, that seems to work but I'll test some more.
[19:06:37] <Dominus> I just wonder if the midi_driver is checked double there, by if (player... in gamewin.cc and return midi_driver && in Midi.cc
[19:06:45] <Dominus> or if that even matters
[19:06:57] <Dominus> be back in a bit
[19:10:57] <sh4rm4> i'd put the test !midi_driver->isFMSynth() into the first position
[19:10:58] <-- Matt_O has left IRC (Read error: Connection reset by peer)
[19:11:21] --> Matt_O has joined #exult
[19:11:22] <sh4rm4> it's much more likely that ppl dont have MT32 enabled than not
[19:11:33] <sh4rm4> so for them the function takes the shortest possible exit
[19:13:18] <sh4rm4> given that fmopl is the only music driver that works "out-of-the-box" without manual configuration changes in the xml or by installing some soundfonts and other things
[19:15:14] <Dominus> on windows and osx default midi works also out of the box
[19:18:33] <sh4rm4> an ultima lover would still use FMOpl because it sounds like the original
[19:22:49] <sh4rm4> btw shouldn midi_driver->isMT32() return false anyway when it is a FM synth ?
[19:24:47] <-- TheCycoTWO has left IRC (Ping timeout: 260 seconds)
[19:26:03] <-- Marzo has left IRC (Disconnected by services)
[19:26:03] --> Marzo1 has joined #exult
[19:30:59] --> TheCycoONE has joined #exult
[19:50:45] <-- TheCycoONE has left IRC (Ping timeout: 250 seconds)
[20:24:01] --> TheCycoONE has joined #exult
[21:00:05] <Dominus> sh4rm4: yes, isMT32 should be false when isFMSynth but it's one of three conditions, the conversions in the cfg could be true
[22:20:08] <-- TheCycoONE has left IRC (Quit: And then there were n-1)