gsKit and PAL mode

[cosmito]

Finally on vacations and I've been exploring a bit of gsKit by running and experimenting with the examples.

It seems there is no support for low resolution modes for PAL (and NTSC). Am I wrong?

Regarding PAL there is a GS_MODE_PAL which is 640x512 interlaced and a GS_MODE_PAL_I which is basically a interlaced one (512 lines on PAL) but showing only 256.

I experimented a bit with gsInit.c and changed some settings for GS_MODE_PAL_I and GS_MODE_PAL, changing the GS_INTERLACED to GS_NONINTERLACED, 640 to 320 for screen width but it seems that the code is a bit tied to the 640x512 interlaced mode, since the result weren't very optimal (for getting a non interlaced picture, it was ok but for a low res 320x256 it seems the 320 width screen is drawn inside a 640 one.

I could create mode like the PAL with 320x256 dimensions but as I said, it seems the lib is expecting a 640x512 screen dimension.

Is there plans for implementing and interest in low res modes ?

Interlace in PAL systems is really ugly. In NTSC is very bearable.

[Neovanglist]

To be honest I never even thought about it... it should be possible but you will need to play with the MAGX/MAGY values to compensate for the smaller framebuffer.

You could try adding some new modes then expanding the big if{} else if{} set in gsInit.c to support them and plug in the appropriate startx/starty/width/height/magx/magy values to suit.

Otherwise you could just set it up as a normal halfbuffered or non-interlaced NTSC/PAL framebuffer then scale it up by using it as a texture and drawing a sprite which uses it.

If it's something people really care about I can add it... just hadn't considered the need for it before.

Thanks!

[cosmito]

To be honest I never even thought about it... it should be possible but you will need to play with the MAGX/MAGY values to compensate for the smaller framebuffer.

You could try adding some new modes then expanding the big if{} else if{} set in gsInit.c to support them and plug in the appropriate startx/starty/width/height/magx/magy values to suit.

Yes I tried it but I wasn't aware of the implications of creating a smaller screen to a lib that expects high res... Is this that simple or are you sure font rendering and other gsKit features will not have strange behaviour to low res screens ? I mean, are the other parts of the lib independent of the screen dimensions so that creating a low res screen will not result in crashes or flickering (unless by programmer fault) ?

I played with the starty a bit to center the screen but not magx and magy. Seems like zoom factors(?)

Thanks!

Well we should thank you of course (you're the author of the lib, right?) for it. Although I would like to see those low res options... Someone also interested ? :)

I think I will do some experimenting and *maybe* who knows I'll get these aditions to the lib although there are far better programmers like me :)

[kod]

I would be interested in seeing how low-res modes would be implemented.

[cosmito]

I would be interested in seeing how low-res modes would be implemented.

I've recently talked to Neovangelist and gsKit was made to be flexible not relying in any specific resolution. A low res mode should present no trouble. I'll try to implement in the near future, it's seems simple.

If it seems stable, I could go and send the addings to someone who has an account on svn. Even if not comitted (but stable) I could post the modifications instructions somewhere, i guess.

[cosmito]

A few days ago I started experimenting with the gskit code. I changed the gsGlobal->Width and gsGlobal->Height to 320 and 256 respectively at the PAL settings in the "else if(mode == GS_MODE_PAL)" block of the gsInit.c source. I also used GS_NONINTERLACED and set the MagX to 7.
Well, I draw some stuff but although the screen mode is in fact low resolution and not interlaced I've got strange things : only half width of the drawn textures were displayed (they were less than 320 pixels of course). I also changed the startx value but it seems only to affect the horizontal offsett display.

Another oddity I've found is easy to replicate : open the gsInit.c and look for if(mode == GS_MODE_NTSC). Change the gsGlobal->Width value to 512 and the gsGlobal->Height also to 512. Change the gsGlobal->MagX to 4. This should be the settings for a 512x512 screen mode (although the NTSC vertical is less than 512 there should not be a problem - the bottom lines will not be shown). Then go the the examples/linuz-texture and leave only the first texture by uncommenting the "gsKit_prim_sprite_texture(gsGlobal, &tex8, (...)" since it will not be needed for what I want to show here (in fact you could just remove all the texture draw calls).
Compile the gskit source and then the example and run it.

Now watch it closely : the gsKit_clear(gsGlobal, White) cleared what seems an 512x512 area but the display width itself is still 640, since there is a black border at the right.

I changed also the startx with the same results described above.
Is there something I'm missing ?

[Lukasz]

Try to take a look at the GS setup code in libito, it works in PAL (and NTSC) :-)

http://svn.ps2dev.org/filedetails.php?r ... rev=0&sc=0