Still about gsKit and interlaced mode – part 2

So I took the findings mentioned at my last post and did a simple gsKit screen setup. Additionally a BMP picture is load and shown at a non-interlaced screen.

I started by going into the main() of uLaunchELF and setupGS() and put all their gsKit screen init code into a unique example source file. Surprisely enough, I’ve found that the non-interlaced screen mode of gsKit is … well, not I was expecting :). In other words, it’s a 640×512 / 640×480 resolution screen mode for PAL or NTSC systems respectively, but only the odd (or even, I didn’t invertigated exactly) lines are displayed, resulting in a half vertical resolution non-interlaced screen.

So, in fact, the example loads a 640×480 image but shows only 240 lines of it :). What a waste of memory…

That’s the interlace handling on the gsKit side. Now I see how uLaunchELF interface code could be generic, having only one font for both screen modes. The only way to set up a lower resolution screen mode is in fact changing the gsKit sources, as I did for lsdlDoom PS2 port.

I leave you now the example sources and compiled binaries, for those who aren’t developers or still struggling to have the SDK set up.

show_bmp_ule-bin.rar
show_bmp_ule-source.rar

About the example : I also used the ROMFS system to have embedded the BMP image into the ELF. Consider this as an extra example 🙂 .
So, to compile it, you must have the romfs project on the ps2dev\ps2sdk-ports path. Point your SVN client to svn://svn.ps2dev.org/ps2/trunk/ps2sdk-ports/romfs and get it.

So, the example BMP is included at the romdisk directory and by doing a “make -f Makefile.romfs romdisk.o” you get the ROMFS object file. Finally, a “make” should bake the rest of this cooking.

As another extra, try putting a 640×480 BMP image named “picture.bmp” in the root of a USB drive and plug it into the PS2 before running show_bmp_ule.elf or show_bmp_ule_interlaced.elf.
Your image will be shown instead of the supplied example image 🙂 .

As you see, you have four examples in one go : how to setup gsKit like uLaunchELF does, how to display a picture, how to embed files into an ELF, and how to load the USB drivers and get files from it. Not bad, huh?
 

Still about gsKit and interlaced mode

GsKit is the latest  – and as I heard – the more optimized graphic library for the PS2. Other libs have neat things not present in gsKit but it’s the currently supported official lib.

I’ve been looking at the uLaunchELF4.12 sources and I saw pretty things 🙂
I’ve already noticed uLaunchELF could open a non-interlaced screen mode (but not pure low resolution!) and I looked in to see how it manage to do it with gsKit.

Function setupGS(gs_vmode) is pretty interesting : it allows to setup all the mambo-jambo to setup a screen in gsKit, where gs_vmode = GS_MODE_PAL ou GS_MODE_NTSC. There the lines :

 // Interlace Init
 if(setting->interlace){
  gsGlobal->Interlace = GS_INTERLACED;
  gsGlobal->Field     = GS_FIELD;
 }else{
  gsGlobal->Interlace = GS_NONINTERLACED;
  gsGlobal->Field     = GS_FRAME;
 }

where settings->interlace is uLaunchELF specific and acting like a boolean (in fact is a integer data type), this show the gsGlobal settings needed to enable or disable the interlace mode. I wasn’t aware of the gsGlobal ->Field thing…

Another useful function at uLaunchELF source is the updateScreenMode() which shows how to change on-the-fly the current screen mode. Basically, it calls the not-so-documented SetGsCrt() gsKit’s function:

SetGsCrt(gsGlobal->Interlace, gsGlobal->Mode, gsGlobal->Field);

I’m sure you can find the uLaunchELF sources out there, but if not, look here :
uLaunchELF4.12 binaries and sources

This includes pre-compiled binaries and sources.

 

My Adventures in Libito – part 2

It seems Libito suffers from performance issues – this is the impression I’ve got by running the sprite example. To moving sprite is simply too slow for what’s involved… This might be a specific issue not affecting the lib in a general way since the pad-pong example runs just fine, but it must be taken into account in the lib evaluation.

My Adventures in Libito

I also looked at another graphic library called Ito, better known as Libito. This one is done by Lukasz, which is a good thing.

So Libito is a pretty decent libray, also discontinued, but possible of displaying my beloved low resolution modes. It’s more complex than gsLib, less documented but have some nice extras :

• Support for FPU and VU magic. Only on the context of drawing operation as expected.
• Support for thead creation! I hope this is finished and working. It would be great.
• Simplified pad button reading, which is welcome.
• Have a nice example how to wrap the lib, so it can be used with C (Libito is C++).
• Have a cool texture managing system and loading (it supports BMP besides the IIF format).
• I bet some more feature than those listed here.

It also compiles out-of-the-box under the current ps2sdk at the moment I’m posting, unlike gsLib which is a very cool thing, since I hate fiddling with makefiles and usually have limited patiente to fix them.

Thanks Lukasz

My Adventures in gsLib

I’m starting to explore the old graphic library gsLib. But why, since gsKit is the standard nowadays, have a superiour performance and gsLib is no longer updated? Simply because gsLib, unlike gsKit, supports low resolution screen modes! Gosh, I hate interlaced modes in PAL CTR TV’s and that’s the only mode gsKit uses. In order to use a non interlaced, you have to modify to gsKit source to set, for example, a 640×256 or 640×224 screen mode. Personally I failed to add a pure low resolution screen mode like 320×256 to gsKit (I’ll try again someday) so then the interest in other graphic libs.

Another bonus feature the gsLib adds is mentioned at its documentation:

How cool is that?

This allows us to hook a function to the vsync video signal, so the function will run at the vertical refresh rate! This allows to compensate for the lack of easy to setup interrupt support/multitasking on the PS2 using the free ps2sdk.

The drawback of gsLib it that its written in C++, so the projects that uses it must be also in C++ … Oh well, nothing is perfect.

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.”

 

Free SVN repository

I’ve just tried the free SVN controlled hosting at http://www.assembla.com ! It works and it’s great !

Now my PS2 projects are kept in a safe place an have version control!

The assembla hosting allows you to keep your projects private or public, and to invite other assembla members to view/edit your sources. Very interesting. Thanks for the tip, Matteo.

This could be an excellent way to share my public sources.

Stay tuned!