dsdoom source

elhobbs
Posts: 358
Joined: Thu Jul 02, 2009 1:19 pm

Re: dsdoom source

Post by elhobbs » Sat May 28, 2011 7:31 pm

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.

WinterMute
Site Admin
Posts: 1989
Joined: Tue Aug 09, 2005 3:21 am
Location: UK
Contact:

Re: dsdoom source

Post by WinterMute » Sat May 28, 2011 9:48 pm

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.
Help keep devkitPro toolchains free, Donate today

Personal Blog

elhobbs
Posts: 358
Joined: Thu Jul 02, 2009 1:19 pm

Re: dsdoom source

Post by elhobbs » Sat May 28, 2011 11:39 pm

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.

happy_bunny
Posts: 28
Joined: Mon May 02, 2011 10:13 pm

Re: dsdoom source

Post by happy_bunny » Tue May 31, 2011 11:00 pm

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.

elhobbs
Posts: 358
Joined: Thu Jul 02, 2009 1:19 pm

Re: dsdoom source

Post by elhobbs » Wed Jun 01, 2011 12:19 am

I cannot get the link to work - always temporarily unavailable. is it binary only or source too?

happy_bunny
Posts: 28
Joined: Mon May 02, 2011 10:13 pm

Re: dsdoom source

Post by happy_bunny » Wed Jun 01, 2011 8:41 am

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.

elhobbs
Posts: 358
Joined: Thu Jul 02, 2009 1:19 pm

Re: dsdoom source

Post by elhobbs » Wed Jun 01, 2011 4:38 pm

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?

happy_bunny
Posts: 28
Joined: Mon May 02, 2011 10:13 pm

Re: dsdoom source

Post by happy_bunny » Thu Jun 02, 2011 2:53 pm

chocolate doom and prboom both convert to midi before playing so I stuck with that for two reasons

1) it was easy root :D
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

elhobbs
Posts: 358
Joined: Thu Jul 02, 2009 1:19 pm

Re: dsdoom source

Post by elhobbs » Fri Jun 03, 2011 1:36 pm

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.

happy_bunny
Posts: 28
Joined: Mon May 02, 2011 10:13 pm

Re: dsdoom source

Post by happy_bunny » Fri Jun 03, 2011 10:14 pm

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

Post Reply

Who is online

Users browsing this forum: Ahrefs [Bot], Semrush [Bot] and 3 guests