forums.ps2dev.org

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.

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!

Neovanglist wrote: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(?)

Neovanglist wrote: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 :)

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

kod wrote: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.

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 ?

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