Page 4 of 6
Re: dsdoom source
Posted: Sat May 28, 2011 7:31 pm
by elhobbs
The code I provided works with pate's adlib emulator. It decodes the mus stream and sends commands to the adlib emulator via FIFO. Not sure why happy_bunny used opl_ for a prefix on that function name.
Re: dsdoom source
Posted: Sat May 28, 2011 9:48 pm
by WinterMute
Ah, ok, cool. Didn't see that mentioned in the posts and assumed it was a C OPL emulator - I have one around somewhere that was optimised rather a lot and I couldn't get it usable above 8KHz standalone, never mind in ds doom.
Re: dsdoom source
Posted: Sat May 28, 2011 11:39 pm
by elhobbs
I did say that my code used pate's adlib emulator - though not in the same message where I provided a link to my code. the ommision was not intentional. I also mentioned that my code if heavily ripped from MUS Library. I tried to get the original dosbox c code to work (which pate's code is based on) with little success. it did not even come close to decoding in real time - let alone leaving time for something else to run. pate's code is pretty amazing. my main goal in trying was to see if my MUS decoding was working correctly. the mus files sound a little off on the DS. it is hard to tell though as I do not have adlib hardware to test against. pate did say that he took some shortcuts to make it fast so that may be the difference.
Re: dsdoom source
Posted: Tue May 31, 2011 11:00 pm
by happy_bunny
ok so got some music playing, heres the code for my port of doom based on chocolate doom
http://www.megaupload.com/?d=3LM094SX
its at version 0.4.0 so there are some bugs at the moment
1) chainsaw dont sound right
2) music files with big event lists dont load so dont play ie E1M2
at present it looks for wad files in
/Data/ChocDoom/Doom1
and stores midi's files in
/Data/ChocDoom/tmp
so both these directorys need to be present for the port to run / work.
Re: dsdoom source
Posted: Wed Jun 01, 2011 12:19 am
by elhobbs
I cannot get the link to work - always temporarily unavailable. is it binary only or source too?
Re: dsdoom source
Posted: Wed Jun 01, 2011 8:41 am
by happy_bunny
strange seem's to be working for me, its a zip of the source as its under the gpl license, let me know if you still cant get a copy and I will set something up on google code.
premature optimization == trouble, this worked in the end
void OPL_SetCallback(unsigned int ms, VoidFn callback)
{
if(ms == 0){
timerStart( 2, ClockDivider_1024, TIMER_FREQ_1024((10000)), callback );
} else {
u16 NewTickValue = 0x10000 - ((ms * (BUS_CLOCK / 1024)) / 1000);
timerStart( 2, ClockDivider_1024, NewTickValue, callback );
}
}
chocolate doom has opl code to drive sound blasters chips I editted that code to get music playing with pate's adlib emulator on the ds, thats where the OPL_ comes from. Currently this is how it works
the mus file gets converted to a midi file and saved in /data/chocdoom/tmp and then the midi file is opened and then loaded into memory one track at a time. This works for small midi tracks (6000 events and under) for larger midi tracks the realloc call in function ReadTrack within midifile.c fails.
Re: dsdoom source
Posted: Wed Jun 01, 2011 4:38 pm
by elhobbs
It looks like the link is working now - at least at work - where I cannot do anything with it
I will try it home tonight. I am curious to see if there is any benefit to converting to midi vs playing the mus file directly. Any reason that you chose to convert to midi, or is this just the way chocolate doom does it so you stuck with it?
Re: dsdoom source
Posted: Thu Jun 02, 2011 2:53 pm
by happy_bunny
chocolate doom and prboom both convert to midi before playing so I stuck with that for two reasons
1) it was easy root
2) midifile.c seems to setup opl channels before playing the midi files
the first point is me just being lazy, the second point is why I left it that way. I wanted to hear the midi file with its default setup before I want and changed anything.
I dont really like the setup at the moment as it
1) dont like to play large midi files (ie e1m2, e1m8, inter)
2) access the sd card is slow
if I get time I will like to change it so that after the mus file get converted to midi it dont save it to sd card (to speed thinks up), and secondly decode the midi file on the fly like musplay.c does to avoid having to load all track events into memory (this should allow e1m2 to play).
would be interesting to see what you think of the difference between direct mus play vs converted midi play
Re: dsdoom source
Posted: Fri Jun 03, 2011 1:36 pm
by elhobbs
I finanlly got a chance to compare the output. I must be doing something wrong in the musplay code. The midi code sounds much better than the code I cobbled together. I will take another look and see if I can spot the issues.
Re: dsdoom source
Posted: Fri Jun 03, 2011 10:14 pm
by happy_bunny
chocdoom version 0.5.0 , fixed double saw sound and added auto naming of save game slots (from dsdoom)
http://www.megaupload.com/?d=POK6VLPY