gslib patch

[ragnarok2040]

I've been away learning about the GS using gslib but ran into a problem getting 8-bit textures with cluts working so I'm releasing what I've already done so far, :D. I made a class that keeps track of vram usage among the various gsPipe objects. It can allocate vram for textures, as well as be reinitialized, in case of a display mode change, scene change, etc. It could probably be merged with the gsDriver class but it might be helpful to have a separate object for handling that.

I've removed the auto resolution detection from the gsDriver class, since it no longer works on newer PS2s. That also means the gsDriver constructor needed to be changed to accept an input parameter for the display mode. I put a method of determining the mode automatically inside of the simple example, though. I've also added the ability to set all the modes the PS2 can handle, from 256x256 non-interlaced to 1920x1080i using an enumerated list, but I haven't tested them all. I changed the way gslib sets up the display framebuffer by using the correct values in the display register. I also setup a list of default offsets which change depending on mode and the interlacing option used which simplified the setDisplayMode() method by removing a couple of parameters.

I think that's about it. The patch is at here. If hotlinking is still disabled you'll need to go here and click on gslib.patch.tar.gz.

[ooPo]

Code: Select all

ps2/gslib$ cat ../gslib.patch | patch -p0 --dry-run
patching file source/gsDefs.h
patching file source/gsDriver.cpp
patch: **** malformed patch at line 499: @@ -371,4 +578,5 @@

The patch is a little munchy, can you regenerate it?

[ragnarok2040]

Weird, all my "svn diff" created patches are giving me that error when I try to patch the original gslib source. Looking at the patches, I can't see what's wrong. I thought it might be a line-ending issue and converted all the files back to <cr><lf> line endings, but that didn't work and actually errored out sooner. In the end, I generated a new one using diff, ignoring changes in white space, that applied cleanly for me. I wonder if gedit has a bug :?.

The new patch has been uploaded, :D.

[ooPo]

Code: Select all

ps2/gslib$ svn update
At revision 1477.

The patch applied fine this time, and I've committed it to the repository. I haven't tested it so if someone needs help, I'm pointing them towards you. :)

[ragnarok2040]

:D, Ok.

Since the only project I've found via google that uses gslib seems to be Altimit, I'll just post some information for getting it to compile with the new changes.

For users trying to compile Altimit using the latest revision of gslib, since the GS_SET_DISPLAY macro was corrected, in altimit.cpp:
GS_DISPLAY1 = GS_SET_DISPLAY(altGS.WIDTH, altGS.HEIGHT, altGS.OFFSETX, altGS.OFFSETY);
should really be (if it's for centering the screen):
setDisplayPosition(altGS.OFFSETX, altGS.OFFSETY);

and since the gsDriver.setDisplayMode() method was changed, in altimitGS.cpp:
altGsDriver.setDisplayMode(altGS.WIDTH, altGS.HEIGHT, altGS.OFFSETX, altGS.OFFSETY, GS_PSMCT32, 2, altGS.PALORNTSC, altGS.INTERLACING, GS_ENABLE, GS_PSMZ32);
needs to be:
altGsDriver.setDisplayMode(altGS.WIDTH, altGS.HEIGHT, altGS.PALORNTSC, altGS.INTERLACING, GS_PSMCT32, GS_ENABLE, GS_PSMZ32, 2);

The OFFSETX and OFFSETY values in the altGS structure are probably off by a lot now, so they need correcting. You can replace them in altimit.cpp using altGsDriver.getDisplayXPosition() and altGsDriver.getDisplayYPosition() which will retrieve the correct values depending on the mode. Also change GS_TV_AUTO to a real mode or add the method used in the simple example to choose a mode.

I think that's about it based on my cursory look over the altimit code... Any other compiling problems not related to gslib aren't in my realm of expertise.

[cosmito]

I made a class that keeps track of vram usage among the various gsPipe objects. It can allocate vram for textures, as well as be reinitialized, in case of a display mode change, scene change, etc. It could probably be merged with the gsDriver class but it might be helpful to have a separate object for handling that.

Does it have support only for 8 bit CLUT modes or for all modes?

[ragnarok2040]

My gsVram class supports allocating vram for both the clut and 8-bit/4-bit textures, based on gsKit's method of determining how much vram to allocate. Unfortunately, gslib's gsPipe class doesn't support uploading clut textures. I tried uploading the clut first then texture, reversing that, modifying the TEX0 tag when it's uploaded to change the clut lookup mode, etc, the closest I ever got was seeing the raw texture on screen, and turning the screen white at one point. I'm guessing something extra has to be done between the uploading of a clut and the texture. I've recently been fixing up gsKit, though, and it supports 8 bit clut modes.