Good news regarding the mixer

I’ve been working on a sound mixer done from scratch although taking advantage of existent libs for sound playing, like SjPCM and I was able to mix and play two samples perfectly using threads. This means “play and forget” for the main program, since all the mixing and playing work is done by the mixer thread.

So, the basics of the mixer are done and now it’s a matter of finishing it. The primary goal is to use with the PS2 Doom ports in order to replace SDLMixer which seems to not be fully working along with the current ps2sdk.

BTW: I’m wondering if you, the reader, could suggest a nice name for the mixer. The current candidate name is “cosmitoMixer” but I would like to name it with something better… Fell free to post your suggestions please.

PS2Doom – Time for updates

Both Lukasz and Janson’s ports of Doom uses SDL for graphics and sound. And I realised that the PS2 port of SDL (at least the SDL_mixer) is buggy. An example of this is clear if you look at the sources of PS2Pang: Before any call to SDL_mixer’s Mix_PlayChannel() function which actuallys pumps the samples to the mixer there is a misterious ‘printf(“”)’ which seems to do a lot more than nothing – without it, there is only silence, so no sound is ever played… (I suspect it could be a thread issue).

So, actually, it’s quite normal to have silence in this PS2 ports of Doom instead of any sound.

So, lets all go home and live happy with a silent Doom and I’m going to start working over another project.

 

Just kidding.

 

So, I could take two paths:

  1 – debug SDL_mixer
  2 – forget about SDL_mixer and use an alternative for sound

Sincerely, option 1 is not appealing to me, without any decent debugging tools. I’ll take path 2 instead.

Currently I’m exploring the well known and tested sjPCM library. It’s a low-level lib (well, it’s more a middle-level actually) so I’ve been looking at other projects that uses it like PGEN emulator to see how it works. I should also need to make a sound mixer by myself, since sjPCM only pumps sound samples to the PS2 dual SPU cores. I never did any sound mixer before, but it seems quite easy (i’ll probabily post a sketch of it later).
The question is: Where to do the mixing? At the IOP or at the EE? Doing in the IOP would be optimal since it would be synchronized with the sound pumping (I would only need to do the mixing just before the pumping to the SPU core) but I wonder if that’s too much work for the 36Mhz IOP… Doing the mixer on the EE may not be much simple since I would need to call it periodically and as you may know, the PS2 only have cooperative multitasking. Anyway, this all should be doable.
 
I’ve also chatting with jbit (helpful dude, he is) since his ps2snd library is able to send sound samples to the PS2 hardware as long as those are previously ADPCM encoded. This makes a lot of sense, since the PS2 already does sound mixing as long the audio streams are ADPCM encoded (the Doom sounds are the usual PCM signed words but there are examples on the ps2sdk for ADPCM encoding). He gave me some snippets of his yet unrealised ps2kit library regarding audio and I’m still messing with it (sucessful compiling but yet unsucessful playing).

I might also try to see why the heck the implanted Jason’s audio functions doesn’t work over Lukasz port… Those should work (I wonder how Jason’s was able to use sucessfully SDL_mixer considering the odd behaviour of it…) just because the time Jason must had over these.

PS2Doom – The Quest for Sound

If you’ve been paying attention to the source repository

http://svn2.assembla.com/svn/pedroduarteps2dev_public/ps2doom-src

then you’ll now that I proceed with the quest for giving Lukasz‘s PS2Doom port sound capabilities, imported from latest prboom+ sources (read my previous post here).

Well, after replacing the original sound routines from prboom+ I have still some bugs to hunt. I managed to get some chopping sound but it’s rather strange since it’s the result of messing with the sample rate and doing a printf to the console! It doesn’t make sense 🙂 I guess it needs more debugging work.

Some updates

Well, progress has being slow as usual. Allways busy at work, as you know.

In the meantime, I’ve been developing a sort of sprite displaying system (fancy name goes here), that is, a system that allows to load and display bitmaps from filesystem, supporting for basic animation and transparency, as required for sprite display.

There is still some technical difficulties, but you can get a preview here :
lowrestransparent7 romfs.rar

(no I’m not coding a web browser ;))

Regarding previous projects, yesterday I finally decided what to do to overcome the sdldoom sound crash problem. I no longer suspect of inherent bugs in audio driver and USB file loading in parallel, since similar issues I was experiencing in another project was just bad usage from my side :S

So, it looks like somewhere in the current port of sdldoom, some function is behaving badly, probabily corrupting memory that is shared by the audio driver and/or doom audio routines… The bug could also be intself in the audio routines of the port. But these are only guesses and unfortunably will remain as they are, since due to lack of decent free time and debugging support for the ps2sdk finding the offending function would be a nightmare…

So, the future? Replacing the audio routines in this port doesn’t seem to wisest thing to do, although this could be the solution if the bug lives there – If the bug is somewhere in the rest of the port, then replacing the audio would be wasted hours. The right thing to do is to start porting a more mature doom port, like proboom+ 🙂 But since it’s a somewhat large project, I’ll only port its audio routines and put them in the initial Lukasz doom port.

And this almost right thing started to happen yesterday 🙂

I’m keeping the sources in the assembla free svn repository :
http://svn2.assembla.com/svn/pedroduarteps2dev_public/ps2doom-src

so, keep an eye on the progress by looking at the WIP-sound.txt file on the trunk.

————————————————————————————-

I also start looking for some existent ports of ZX Spectrum emulators. Yes, I pretend to bring one to the PS2!

I tried the Windows and Linux version of zx4all but the sound is crappy, so it’s out of question. Fuse seems very nice, and there is also a nice PSP port, which could be a starting point.

Keep tuned 🙂

And now, for something you were all expecting…

I proudly present you :

lsdldoom for the PS2 v.0.0.5 without any sound !

🙂

It has been complicated these days… Very little free time to try to overcome the bug in the sources when loading an external WAD. It’s kind of odd, since this only manisfests in this favour – it seens not to happen on the “embedded WAD” version. It could be related to memory corruption, and by pure luck the embedded loads the ELF and the resources into a different memory area, safe from the possible trashing.

Anyway, I realised that if I disable the sound functions, the bug does not manifests. So, if you’re really eager to play the doom.wad or doom2.wad and don’t want to wait for the solution, try this :

lsdldoom-ps2_v005nosound.rar

(remember that the WAD files must be in lower case (doom.wad and doom2.wad, for example)

The good thing is that Doom is so great that even without sound it’s addictive!

I hope the next time I’ll post about this port of Doom i’ll bring good news and the bug fix. But it could take a very long time, I warn you.

Take care.

 

LSDLDOOM-PS2 : Update 5

Time for an update.

I fixed some issues preventing the configuration loading at startup and saving at exit, so at last you can permanently backup your Doom configuration. The config file is saved at memory card 1 (mc0:DOOM/boom.cfg) when exiting using the Quit option from de menu.

I also added the option to force a specific display mode (PAL or NTSC) for whom needs it – So just rename the DOOM.ELF to something ending with PAL or NTSC at the name (for example : DOOM_PAL.ELF or DOOM_NTSC.ELF).

Get here the shareware WAD embedded ELF (recommended) :
sdldoom-ps2_v005ROMFS.rar

or the you-supply-the-wad version (more unstable) :
sdldoom-ps2_v005.rar

Now source is included in all releases.
Hope you like it.

LSDLDOOM-PS2 : Building instructions

I updated the sources in the SVN include to include the building instructions and also to describe my gsKit and SDL modifications/hacks.
http://svn2.assembla.com/svn/pedroduarteps2dev_public/lsdldoom_PS2

“Instructions to build the PS2 version :

You must already have a working ps2sdk building environment prior to build this PS2 port of lsdldoom. You also need the SDL and SDL_mixer port to the PS2.

My modifications include a patch to gsKit so we can get a non-interlaced screen which is not available when I’m typing this. Since SDL depends on gsKit, we going also to make a minor change to it also to impose a 0.625 aspect ratio like seen on a PC version of Doom. Note that these changes are optional.

gsKit and SDL changes :
———————–
Apply patches or copy the supplied modified sources.

PS2lsdldoom :
————-

Embedded version (containing the sharewad WAD) :
————————————————

You need to have the ROMFS package. Get it from svn://svn.ps2dev.org/ps2/trunk/ps2sdk-ports/romfs. Add the line “include Makefile.romfs” at the end of the Makefile, uncomment the “#include ” and “rioInit();” at l_main.c.

Create a folder called romdisk and place there the doom1.wad (use lower case for the filename!) along with the boomlump.wad (look at the data folder for this wad). Optionally, create a dummy file named strafeonrightjoy.dat if you want to strafe with the right analog joystick – clumsy hack). Build the image with “make -f Makefile.romfs romdisk.img” followed by a “make -f Makefile.romfs romdisk.o”. Finally do a “make” and the DOOM.ELF should buid.

You supply the wad version :
—————————-

Remove the line “include Makefile.romfs” at the end of the Makefile, comment the “#include ” and “rioInit();” at l_main.c. Type make. You should now have your DOOM.ELF. Please note this flavour is more prone to crash than the embedded version.”

 

LSDLDOOM-PS2 : Update 4

The (I believe) long waited game saving/loading ability is now working.

So now you can save and load your games at any moment to memory card. The typical save sizes is as small as 30KBytes so I see no reason to save to other devices, like USB media storage (besides, accordingly to the USB driver author, USB saving is not enough tested).

Just go the the save/load menu, hit cross button to start entering a filename. At this point, the only possible character that can be typed in is the “Y” letter by hiting the L2 button. I might add some more characters latter, but remember that you’re only typing a description for the save file, not the filename itself, so it really itsn’t that important.

In the source, only minor changes were needed to fix the saving and loading functions. I had to use the IO fio* functions instead of the f* which are overwritten by the ROMFS, so the MC0 wasn’t accessible earlier. I also needed to code the equivalente of the offending expression “*(long*)save_p” where save_p is a pointer to a char buffer. It simply results in an exception, maybe because of the PS2 memory architecture (you tell me in the comments section, please)

I must also investigate if the LONG and SHORT macros are bad or not for the PS2’s sanity… Could this be the origin of the freezings?

Get it here :

(with shareware WAD inside)
lsdldoom-ps2_v004ROMFS.rar

(you supply the WAD version)
lsdldoom-ps2_v004.rar

As usual, the source is available here :
http://svn2.assembla.com/svn/pedroduarteps2dev_public/lsdldoom_PS2

(look for the 0.0.4 tag)

LSDLDOOM-PS2 : Update 3

So time to new features :

I added support for picking the previous/next weapon. You can use “circle” to select the next weapon and “square” to select the previous. This time, I did it properly 🙂 so you can use another bindings to these features going to the options/setup/key bindings/weapons section and define whatever you want for the “next” and “previous”.

Get it here for the shareware embedded ELF :
lsdldoom-ps2_v003ROMFS.rar

or for the “you-supply-the-WAD” version :
lsdldoom-ps2_v003.rar

Please note the freezing bug still plagues specially the non-embedded version…

 

LSDLDOOM-PS2 : Update 2

It seems the hang ups doesn’t happens in the ROMFS self-contained version, like Lukasz’s compiled here. I suspect from USB and sound RPC issues but I must admit I’m a newbie concerning these drivers (nope, it’s something else. I’ll keep trying to spot the bug ASAP) I’ve done some debugging. Until I have more clues, I also added ROMFS support like Lukasz did. So get it here. If it crashes (hangs, or something weird) drop a comment please.

lsdldoom-ps2_v002ROMFS.rar

So, this version have the shareware doom1.wad included (no loading of other WADs – this is the disadvantage of the ROMFS thing) and all the feature I presented in the previous versions, although the option “Now left analog stick does rotation and right does straffing” cannot be disabled.

The recipe to ROMFS support : Like Lukasz said, I was a matter of adding the line “include Makefile.romfs”at the end of the Makefile, uncomment the “#include <romfs_io.h>” and “rioInit();” at l_main.c, creating a directory called “romdisk” and putting there the extra files (the “boomlump.wad”, “strafeonrightjoy.dat” (optional)  and “doom1.wad” or other any WAD you have instead goes here – use lower case for the filename!), doing a “make -f Makefile.romfs romdisk.img” followed by a “make -f Makefile.romfs romdisk.o” and finally a “make”.