Non-interlaced NTSC in graph & draw?

[SSpeare]

I have been going along quite nicely using the standard NTSC mode in libgraph, but my code is now too slow to run in 60Hz so I need to stop using interlaced mode and switch to non-interlaced so I can run at 30Hz without flickering.

I am having a very difficult time doing this using these libraries. Has anyone successfully completed this? There are some oddities which I don't understand, such as the details of the horizontal line count in interlaced mode and what that should be in non-interlaced mode.

What I've done is merged the differences between the interlaced NTSC mode and the VGA_640 mode to try to create a mode that is NTSC and non-interlaced. What I'm seeing is my scene, but it is magnified, offset, and clipped. I've tried playing with the MAGH and MAGV settings without much luck. I also played around a little bit with the SCISSOR and XYOFFSET settings, again without much luck.

If anyone has any pointers or at least verification that you have gotten this to work, I would appreciate it.

Here is the new mode I added:

Code: Select all

  {  640,  224, 0x02, 0,  143360, GS_SET_DISPLAY(276, 34, 3, 0, 1279,  111) },

Thanks!

[ooPo]

There's a few ways you could go about doing this.

You could change the call to SetGsCrt() to use frame mode. This will give you a 640x224 frame stretched twice as high when displayed. You have to take care to make sure to draw stuff pre-squished so that it'll look fine onscreen.

Alternatively, you could try using gsKit instead of the graphics code in ps2sdk. It runs a lot faster and supports the mode you're looking for.

[SSpeare]

Thanks for the response! Yea, I noticed that libdraw only supports FIELD mode. But I think what I want is non-interlaced mode. I guess I'm not 100% clear on the difference.

Non-interlaced mode vs. interlaced FRAME mode?
Non-interlaced mode ignores the FIELD/FRAME flag because it isn't interlaced. I was under the impression that FRAME mode still expected a 60Hz swap rate. Unless I switch the actual MODE in libdraw to be non-interlaced, then it won't create two buffers for me, which is what I need to run at <60Hz.

Anyway, I knew I posted too early. I got it working last night finally. This is the entry I used:

Code: Select all

  {  640,  224, 0x02, 0,  143360, GS_SET_DISPLAY(632, 30, 3, 0, 2559,  223) }

What I don't understand is the 5th parameter to GS_SET_DISPLAY(). It is supposed to be the width - 1, but then why is it width*2 -1 for NTSC and PAL? I thought it had something to do with them being interlaced, so I switched it to width-1 like the other modes.

I also found a bug in draw.c that was annoying me. When I would initialize the GS it would flash horribly between the current contents of VRAM. The code currently looks like this:

Code: Select all

  // Wait and clear both buffers.
  draw_swap(); draw_clear(0.00f, 0.00f, 0.00f);
  draw_swap(); draw_clear(0.00f, 0.00f, 0.00f);

  // Initialize the packet.
  if &#40;packet_allocate&#40;&draw_packet, 1024&#41; < 0&#41; &#123; return -1; &#125;

But it should be:

Code: Select all

  // Initialize the packet.
  if &#40;packet_allocate&#40;&draw_packet, 1024&#41; < 0&#41; &#123; return -1; &#125;

  // Wait and clear both buffers.
  draw_swap&#40;&#41;; draw_clear&#40;0.00f, 0.00f, 0.00f&#41;;
  draw_swap&#40;&#41;; draw_clear&#40;0.00f, 0.00f, 0.00f&#41;;

Because draw_clear() uses the draw_packet.

I guess I should look at gsKit. Is it a better choice than gsLib?

[Neovanglist]

gsLib is a decent library, but it hasn't been updated/maintained in a long long time.

gsKit is C (whereas gsLib is C++) and a bit different API wise.

I obiviously think gsKit is better but I'm hardly unbiased :)

In any case, gsKit supports every mode the GS can perform, and if you want something strange/custom then you can always setup your own mode in gsInit.c.

(it's quite simple)

[ooPo]

SSpeare: I've updated the source in the repository to include your non-interlaced NTSC mode and the bug you've pointed out.

As for GS_SET_DISPLAY()... uhh, I forget. Let me take a peek at the documentation when I'm home later today. If I remember...

The graphics code in ps2sdk is intended more as an example which can be easily (I hope) understood by people wanting to learn about the PS2. If you're just interested in putting stuff on the screen then something like gsKit would be much better for you. It recently added speed! :)

I don't think it does 3D yet, though.

[Neovanglist]

gsKit can do 3D, but it will just push 3D prims (textued and non textured) for you, and won't do any kind of projection math, etc like you would need in proper 3D.

As for 2D... it should do just about anything you need :)