Archive for the ‘releases’ Category

Nicky Boum PS2

December 25, 2010

First of all, Merry Xmas for all who celebrate it and equally happy moments for all the others.


In short words:

Here you can find my PS2 port of Nicky Boum, a popular game among Amigans, from the NickyBoumPSP port by deniska, from of the original Nicky Boum engine rewrite by Gregory Montoir.

The controls are:

Left analog stick for movement, ‘X’ button for fire (hold it for ‘boum’), ‘O’ for jump, L1 for skip level, L2 for quit current live, R1 for adding all bonuses, ‘Select’ for pausing and ‘Start’ for quiting game. Any USB keyboard compatible with the PS2 is also supported.

The original game has some aparent bugs and it was not extensively tested, but it’s not my intention to fix any of the original engine bugs or missing features. Please expect not much future releases from me.

Download here:

NickyBoumPS2 v.0.2.0a binaries and sources


In long verbose words:

For the brave ones who decided to read this part, I’ll start explaining why Nicky Boum and how this port it came to reality, mentioning its ups and downs.

So it all happened when I tried Nicky Boum PSP from deniska from This is a port of the popular Amiga game called Nicky Boum which I never played to say the truth, although my long past as an Amiga user and gamer, but I know it to be very dear among Amigans.

When I first looked into its sources, the first thing that striked me was the relatively small number of small source files, the fact that’s a pure SDL game port and with almost 0% PSP specific code (as far I remember, it only sets the PSP CPU frequency). So, I saw in this port an excellent oportunity to get a PS2 port of the game for the hungry PS2 homebrew scene and also a fast way to test the current health of the ps2sdk SDL libs,  compatible with my limited free time.

I did the port itself in less than one hour. After this time time period, it was already compiling and a .ELF was born into this world. After fixing some issues with file IO specific to the PS2 and the host: device for debugging, I was not much surprised by the result: A blank screen and no sound what so ever.

So what was the problems, then?

First the blank display: The function SDL_UpdateRect is used to redraw the display but accordingly to the SDL documentation, “Makes sure the given area is updated on the given screen. In other words, it makes sure any changes to the given area of the screen are made visible. The rectangle must be confined within the screen boundaries because there’s no clipping“.

On the other hand, i’ve also read the description of the SDL_Flip() not used at the sources: “On hardware that supports double-buffering, this function sets up a flip and returns. The hardware will wait for vertical retrace, and then swap video buffers before the next video surface blit or lock will return. On hardware that doesn’t support double-buffering or if SDL_SWSURFACE was set, this is equivalent to calling SDL_UpdateRect(screen, 0, 0, 0, 0). A software screen surface is also updated automatically when parts of a SDL window are redrawn, caused by overlapping windows or by restoring from an iconified state. As a result there is no proper double buffer behavior in windowed mode for a software screen, in contrast to a full screen software mode.

So, it happens the ps2sdk SDL lib compiles using SDL_USE_HW_SURFACE=1 defined at the Makefile, so apparently SDL_UpdateRect(screen, 0, 0, 0, 0) makes no effect. I replaced it by a SDL_Flip call and wonder of the wonders, I’ve got a gameplay image. Apparently, SDL_UpdateRect is enough at the pspsdk.

And I’ve got literally a display image, not an animation, since the gameplay is completely freezed… What was wrong then? So, the program flow is stalled after a SDL_Delay call, which should take a specified limited amount of miniseconds, not an unlimited amount. Unlike the pspsdk SDL port, the PS2 SDL port requires explicit initialization of the timer used by SDL_Delay, how could I know this? Adding a SDL_INIT_TIMER tag to the SDL_Init unlocked the gameplay!

The sound is working but shitty. It seems to be an effect of broken task switching but yet there is sound, unlike my previous experiences with ps2doom. High frequency sounds like speech and high pitch sounds seems more affected than lower frequency samples, such as the explosions. What most suffered with this was the music play, and this would be intolerable, specially for those who have good memories of playing this game in the past on other platforms. I managed to avoid having to debug SDL sound routines (more than not fun, it would be very time consuming with the current primitive debugging tools for the ps2sdk) by using another approach: sdlmixer mod play works fine, so I commented the original music play routines and replaced by sdlmixer calls. I gave the player the option to select only sfx or music during gameplay and put sdlmixer pumping the original songs I’ve got from (the songs at the data folder doesn’t seems  .mod files compatible with sdlmixer).

To finish it I just needed to adapt the controller sources to cope with the PS2 specifics (a USB keyboard is also supported, thanks to ps2sdk SDL, by the way), tweak the sdlmixer lib to output slight more volume to the mod play, use romfs to embed all the data files into an .ELF and release to the public.

By the way, I decided to included some game files as in the Nicky PSP archive from the link above. If there is some request to remove them, I’m glad to comply.

The conclusion is that the PS2 SDL ports are not 100% healthy and even the simple standard example may show its problems. I’m glad for the folks that ported SDL to the PS2, don’t take me wrong. Unfortunably, it seems interest on the PS2 platform as homebrew is very low measuring from the number of the active coders and I don’t have the opportunity nowadays to fix all that is needed to fix.

Enjoy it.

Download here:

NickyBoumPS2 v.0.2.0a binaries and sources

(Project’s home :

PS2Doom v1.0.5.0

March 21, 2010

Time for a new release, featuring:

  • Simple but effective WAD selector: No more need to having only a WAD per ps2doom!
  • Controller almost fully configurable using the configuration file (ps2doom.config)
  • HDD support (at last). Thanks Adilson Pierog for his contribution and for figuring out which irx were needed and its correct sequence order. I Just needed to integrate it better into the source and make the hardcoded paths configurable.
  • Now uses freesd instead of LIBSD. Japanese users should be happy now. And PS3 compatible now?
  • For doom2 wads, sound is no longer half sampled. Sounds the same to me, anyway…

For me, the major update was the use of a configuration file to make the controls configurable. That also opened the door to HDD support which needed some special treatment of WAD paths. I was hoping to release also easy to use configurator for Windows PC written in C# which would set the configuraton file but I forgot the lib I’m using (libconfig) did not have a C# wrapper. With proper free time I would do it by myself, but as you all saw, I was hoping to have this ready for January…

Those who are interested at using the HDD must read the ‘Whatsthis.txt’ file released along with the distribution below. It explains exactly what settings you must change at the config file and where to put it. Please pay attention to that, before asking any questions, thanks.

For the future, well this might be the last update I do for PS2Doom due to lack of time and things doesn’t seem to get better any soon, since I need to solve some personal issues more important than homebrew development.

I still have my own wish list for PS2doom, including cheat support and MP3 decoding during playback (that way not only we’ll have Doom music but literally any music we wanted) and who knows one day I’ll accomplish this? But besides this, I don’t see much future for PS2doom… I guess the next step would be dropping this version of ps2doom and start adapting PrBoom+, maybe chopping off some more performance hungry features of it. PrBoom+ would allow PWAD support and networking with Doom running on other platforms such as the PC, for example. For those who would take the task, my improvements for the starting Lukasz version would be reusable into PrBoom+ port (mc support, audio alternative to the still broken SDLaudio).

If there is any developer who wants to continue the project of start PrBoom+ port, please go ahead. Fell free to use my code as reference. I’ll soon put the souce as a google code project but in the meanwhile, get it from the assembla repository >here<.

Have fun!

Get it from here :

PS2Doom v1.0.4.1

June 12, 2009

New features:

– Savegame handling for different WAD : Now savegames from doom1 and doom2 and other WADs can happy cohexist at the same memory card.

Important: This means that your previous saves needs to be renamed at the PS2DOOM memory card folder. Use uLaunchELF for that (copy the save files to a USB storage device for example, rename those at your computer – see below, delete those same files at the memory card and copy the renamed saves from the USB device back to the PS2DOOM memory card folder). Refer to uLaunchELF documentation for this operations (I won’t offer help at this subject).

Until now, the saves follows the scheme for all the WADs : doomsav0.dsg,  doomsav1.dsg, and so on. For now on, the saves reflect the WAD name:

For doom2.wad savegames, you should use the the naming scheme : doom2sav0.dsg,  doom2sav1.dsg, etc. Similarly for doom1.wad saves, this will be doom1sav0.dsg,  doom1sav1.dsg.

For doom.wad, the filenames should be doomsav0.dsg,  etc. You get the picture (sorry to explain this to detail, but I wanted to keep this clear).

Bug fixes:

– Should work with the doom2f.wad (I don’t own it). It should run with previous versions (memory requirements issue since sounds weren’t being downsampled)
– Previous/next weapon selection was buggy (some weapons weren’t selectable) – fixed
– Fixed a crash when a lump is not found (doom.wad at “menu slideshow”) – original sources bug?
– Save/load file handle fixed (no more trying to load/save from empty slots)

I also realised the the source files cosmitoFileIO.c and cosmitoFileIO.h weren’t being included at the distribution archives… Going to fix that.

Get it from here :

PS2Doom v1.0.4.0

May 31, 2009

Well, almost a entire month has passed since the last update and I can assure you it was been a hell of a 4 weeks at the job. No spare time to do anything than work. No cinema, no walkings, no friends, no life. And yes, no ps2doom.

It took me only about 2-3 hours of quality free time on this week end to understand how strafe was implemented at lsdldoom and how key/button events are handled in Doom. So, implementing strafe for the right analog stick was almost a linear task and for better, it wasn’t necessary to change the code dramatically.

Now ps2doom plays beautifully with strafing 🙂 If you never tried this feature on ps2 lsdldoom port, you don’t know what you’re missing now on ps2doom! It tooks the gameplay to another dimension completely. Actually, I feel the gameplay with a Dualshock PS2 controller surpasses by large keyboard gameplay at action time, not accounting for the extra functions you can quickly access though keyboard.

Have a try and lots of fun! Doom is incredibly addicting, even after you finished it over and over.

As usual, source is included with the pack:


PS2Doom v1.0.3.0

May 1, 2009

This time, good news for people who want to run PS2Doom from memory cards:

Now the .WAD file is loaded from the same directory ps2doom.elf resides, so this avoid the mess of having files at the root of USB storage devices. As a consequence, the files can be entirely placed at memory cards. USB storage devices are still supported, of course.

Currently, HDD is not yet supported. To detect the device name and full path of ps2doom.elf I just parse the main’s argv[0] string. It seems that when launching from HDD using uLaunchELF, the device name appears as “host:”… So I’m not sure on how to detect when ps2doom is executed from HDD. Any help?

I believe HDD support will be added along with a config file where would be listed all the .WAD paths to feed a WAD selector.

Another feature added :
– The Quit option menu now boots back to the OSD PS2 Browser

Get it: ps2doom_v1030

Next stop: Strafe support.

PS2Doom v1.0.2.1

March 12, 2009

Minor update:

No more hicups on sound during screen melt/wipe effect at the start of a new game or at level ending.

PS2Doom v1.0.2.0

March 1, 2009

Time for updates:

Version features USB keyboard support, so if you own a keyboard compatible with the PlayStation2 (not all USB keyboards are, unfortunably) it’s time to try it! It was as simple as enable it at the SDL makefile 😉 

Now it’s possible to change the weapon at will 🙂 Select previous/next weapon with the Square and Circle buttons, respectively.

Also,  gamma correction, run, and map view are accessible. L1 button now results in ‘n’ key instead of a ‘x’ key, which is good for confirmation input.

Saving and loading is still only possible via host: device.


Dualshock Joystick mappings:
Left Analog Stick :     Move

Cross:     Shift / Run

Square     : o / Previous weapon

Circle     : p / Next weapon

Triangle     : Escape

L1     : n

L2     : y

R1     : Fire

R2     : Space / Open doors

Start     : Enter

Analog Left click     : Map

Analog Right click     : Brightness (gamma)


Please note: Enter key action (required to menu operations like starting new game) is a bit clumsy for now. For bringing up the menu, use the Cross button but to select items, use the Start button. This will be fixed.

Enjoy it:

PS2Doom with proper sound, at last!

February 24, 2009

And today is the day!

Sound seems now reasonable, after adding some calls to swap between the mixer and game threads and even without any optimization over the mixer code, it seems to run well.

This is PS2Doom v. (let’s call the original Lukasz version and features sound. Basically is the same version presented at but I first replaced the sound routines by Jason’s hoping to get sound working. Since it didn’t worked, I removed the SDLmixer calls from Jason’s functions and injected my own mixer calls.

I developed a rather simple mixer I decided to call cosmitoMixer, or cosMix for short and I’ll present it properly soon. Currently the cosMix uses SJPCM lib (this means it will fail on some older Japanese consoles) but hopefully I’ll switch to isjpcm lib.

Binary and sources here :

Instructions for running and compiling included. WADs not included.

The plan is to drop the unstable lsdldoom port and apply all the features I’ve been adding to PS2Doom port.

Stay tuned for more updates.

Sources of “Natal 2007” available

January 18, 2009

Almost one year ago I did a small production (see here), a sort of “powerpoint” slideshow with music (but with good music!) were Christmas  was the theme and I sended to some of my friends as a (late) gift.

It evolved from the sources of a oggplayer released by a dude nicked CarelessWhisper which I then added synchronized image display. I really should released the source earlier but my intent was to comment on it, serving as a tutorial for what I did and for things that should be done better, but for me time is scarce as always and also since then, so I can only show you the sources…

I hope to comment on it briefly soon, but any question, leave at the comments zone.

Currently the sources won’t compile out of the box, due to recent gsKit changes but it’s really not complicated to fix it for yourself (but be assured that I’ll do it…)

You can get it from the Assembla public repo

until I find a better free hosting subversion service (does anyone knows alternatives to google code?) since I feel cheated by and I simply don’t want to keep using their public services in the near future. I even fear from the longevity of their services since they pissed off many people with their recent change of service rules… I guess google will be around for many years and I really hate broken links.

So enjoy and learn with it (at least learn how to do better 🙂 since today I would to it better)

Some updates

August 3, 2008

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 :

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 🙂