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 http://deniska.dcemu.co.uk/nicky-boum-psp-111236.html. 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 modarchive.org (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 : http://code.google.com/p/cosmitops2ports/)

Visual Paradigm SDE is recommended for latest versions of NetBeans and the payed version not only supports generation of code and sync with the UML models for it but it also supports Visual Studio, even if programming C#. Wonderful.

You can try it for 10 days or 30 if request a free trial license. There are methods to extend this, of course, using a virtual machine with undo hard disk image

http://svn2.assembla.com/svn/pedroduarteps2dev_public/wip/testTaskSchedMyPS2

It uses the scheduler.c and scheduler.h files taken from the myPS2 sources and starts two threads. Some delay loops are done inside each thread to slow down processing for us to see what’s going on. The call to ‘Scheduler_YieldThread()’ is important so the thread can cooperate with the other threads.

Could be an alternative to the thread switching method I’m using at cosMix (actually, it’s quite similar).

I’m trying to find an alternative to the excellent Mozilla Firefox browser which becomes an elephant when the tab feature is abused. Let’s see how Opera manages it. But regarding to speed, I’m not impressed. Au contraire.

http://devfull.de/?page_id=6

It seems to only work at a fat PS2 probabily due to incompatible code when using the network adapter and even at the fat, it stopped at init with the error “Loading GUI String Table…”.

From the same site, I’ve got the sources and I was looking for what file or resource it failed to load, since I get no printf output from the PS2 at this moment.  The contains a lot of interesting stuff.

First, it has code for MP3 decoding (well, it uses MAD library calls), net MP3 streaming (it supports shoutcast radios) and best of all, a thread scheduler!

Looks very good stuff indeed and it will be handy for sure. I’m still digesting its details, still…

The binary still has the date of 2007 when I first did the toolchain build, so this doesn’t seems to be the result of any recent build I did… I posted for help on the homebrew section of the psxscene forums, so I might get a hint soon.

—–

Actually I’ve found out that the cause of the problem was a running ps2client process at a “zombie” state consuming the ps2link output, so a matter of restarting the PC cured the problem (I take a lot of use of the hibernate feature). No problem whatsoever with ps2client itself, then. Check here for the discussion: http://psx-scene.com/forums/f19/ps2client-does-not-echo-printf-ps2-anymore-65105

This offers a solution for running a server at my computer. Free for personal use so it seems:

http://www.visualsvn.com/server/

Must try it soon.

Worst: Makefiles are the enslavement of the programmer by the lazy machine.

• 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_v1050.zip