forums.ps2dev.org

Posted: **Thu Jul 01, 2004 11:37 pm**

Hey there, figured it was time I put up a gsKit thread. This is where I'll announce releases, and where you can discuss bugs, suggestions, and anything else gsKit related. Keep in mind, it's still a early work in progress, so there are some broken things, and there are some things that will be improved.

I have a 0.1-Beta release ready for you. Read the STATUS and ChangeLog files for more information.

I have prepared two versions, one with just source, and one with source and compiled binaries.

Source Only:
http://neovanglist.thefrontnetworks.net ... ta.tar.bz2

Source and Binaries:
http://neovanglist.thefrontnetworks.net ... ed.tar.bz2

Let me know what you think!

MODIFIED - 5/10/2005

gsKit 0.2 Released!

You can grab it here:

Source Only:
http://ps2dev.org/files/gsKit-0.2.tar.bz2

Source and Binaries:
http://ps2dev.org/files/gsKit-0.2-Precompiled.tar.bz2

gsKit ChangeLog:

-> 05/08/05 - Chris Gilbert (Neovanglist)
* gsKit 0.2 release.

-> 03/12/04 <-> 05/08/05

* Added 3D primitive support.
* Fixed and tested texture support.
* Fixed and tested VGA support.
* Rewrote display initialization system.
* Added prelimianary doxygen documentation.
* Fixed subtle DMA bug regarding DMA timeouts.
* Added support to enable/disable the Z buffer and double buffering.
* Added the ability to enable/disable bilinear texture filtering.
* Lots of small Makefile fixes by Pixel.
* Tons of other small things I fixed and can't remember.

-> 03/12/04 - linuzappz
* Fixed FNT format support.
* FNT files can be loaded in raw format.
* font demo uses arial.fnt by default, compiled within the elf.

Regards,
Chris (Neovanglist) Gilbert

Posted: **Mon Jul 12, 2004 1:21 am**

It' very good, i like it and the example code is easy to understand. But I can't find the Z coordinate for the vertices... (Am'I missing some conceptual basics?). And what is that Q component of the color?

Posted: **Mon Jul 12, 2004 1:31 am**

Q is there for texture perspective correction.
if you are familiar with STQ you know what its for, otherwise google if you care :)

Posted: **Mon Jul 12, 2004 1:49 am**

So, to render true 3D model I have to project it in the 2D and set up correct Q coordinate? What about the z buffer? Do I have to compute it manually ? :)

Posted: **Mon Jul 12, 2004 4:03 am**

zbuffer is just an addr in vram, gs takes care of filling it, you just set it up and make sure you dont write anything there ( dirtying zbuffer when you know what you are doing is ok though :), you do need to clear the zbuffer each frame though, not sure if gsKit does that internally when doing framebuffer flip.

now I have not checked out gsKit, but all coordinates sent to gs are in the XYZ form so id be suprised if gsKit doesnt allow you to specify Z :)

Posted: **Mon Jul 12, 2004 7:27 am**

Unless it's been changed since the initial implentation of the various primitives I believe you can only specify one Z coordinate per primitive, so it essentially acts like a hardware zsorting (which isn't near as nice as zbuffer)

BTW.. is it just me, or is there a problem with color and point primitives? All points I draw show up as white instead of the specified color.

Posted: **Mon Jul 12, 2004 11:07 pm**

Well, firstly, the reason that you specify one Z coordinate is it was done in this manner in both my references. It would be an easy change to allow you to specify the Z coordinate per vertex. However, it would make the function parameters quite long. In gslib and the BreakPoint demo lib it is done the same way I have implimented it. Perhaps what I will do, is restructure the primitive handling a bit so that there is less code duplication. At that point, I can provide a separate function which allows you to specify independant Z coords. If you guys really want this, let me know and I'll make it happen.

Drak, the color in point prims should work fine... I have 2 black point prims in the "basic" example. I'll look into this further myself later on today.

And thanks a ton for the feedback :>

Regards,
Neovanglist

Posted: **Tue Jul 13, 2004 5:45 am**

Here are my opinons:
I' not 3D graphics expert, but the only function I use for 3d rendering on pc is calling vertexArrays on triangles. I have all vertex data prepared in the float arrays so it can be sent to gpu as quickly as possible. I can understand that if someone wants to programm cool demo effects then those other primitives can be handy. So If I can speek, I 'd appreciate some batch processing function of the vertices and eventualy vertex indices (I know it sounds easy but it surely is a lot of work to do...). As for the Z coordinate - from my point of view: I didn't see any 3d tutorial that is refering to other vertex position coorinate specification than X,Y,Z. If this lib is intended to be used (also) by beginners (like me) to learn 3D i vote for Z coordinate (I mean true Z coorinate not just some sort of ordering priority). I don't want to sound ungratefull I realy like what you did.

Posted: **Tue Jul 13, 2004 6:32 am**

Neovanglist wrote:Well, firstly, the reason that you specify one Z coordinate is it was done in this manner in both my references. It would be an easy change to allow you to specify the Z coordinate per vertex. However, it would make the function parameters quite long. In gslib and the BreakPoint demo lib it is done the same way I have implimented it. Perhaps what I will do, is restructure the primitive handling a bit so that there is less code duplication. At that point, I can provide a separate function which allows you to specify independant Z coords. If you guys really want this, let me know and I'll make it happen.

Drak, the color in point prims should work fine... I have 2 black point prims in the "basic" example. I'll look into this further myself later on today.

And thanks a ton for the feedback :>

Regards,
Neovanglist

If the function parameter length is the problem you could just create define's which remap to have all the 3d info for the lazy programmer who can't find copy/paste.

Code: Select all

int drawthedamnthing&#40;x1,y1,z1,x2,y2,z2,color&#41;

#define drawthedamething&#40;x1,y1,x2,y2,z,color&#41; drawthedamnthing&#40;x1,y1,z,x2,y2,z,color&#41;

I haven't fully woken up but that should work I think :P

BTW... try green points, and red points...

Posted: **Tue Jul 13, 2004 7:51 am**

Unless your vertices all just happen to fall on the same z coord (rendering through constant planes of z technique), you NEED a z coord for ALL vertices.

Posted: **Tue Jul 13, 2004 8:47 am**

J.F. wrote:Unless your vertices all just happen to fall on the same z coord (rendering through constant planes of z technique), you NEED a z coord for ALL vertices.

If you want zbuffer support yes, but if you just need a zsorting effect you don't. With 2D stuff having it act like a simple zsorting works fine, and I believe this is what Neo was originally thinking about.

Posted: **Tue Jul 13, 2004 6:44 pm**

I bet neov just looked at the simple line, tri, sprite examples that is out there, and essentially they where made for showcasing, not used irl.
having a vertex pusher is more sane.

as far as changing the current functions, just pass a "vertex" struct, and you wont have
those long function lines.

Posted: **Fri Jul 16, 2004 4:21 am**

I'm just starting with gsKit ans I would like to know if we can put textures (bmp, jpg , c files).

If it is possible how can we do it ?

Thanks

Posted: **Fri Jul 16, 2004 6:39 am**

!Read the STATUS and ChangeLog files for more information.!
You don't read included doc and not even the posts! :)

Posted: **Fri Jul 16, 2004 6:45 am**

sorry i just read license and readme files :(

Posted: **Wed Aug 25, 2004 12:20 pm**

I've been trying to get the zbuffer to work for a few days now.
You code shows, very nicly how to set it up.

I'm working on a small demo to hopeful get me a job,
but also to learn some more about PS2 codeing.

Once the demo is finished,
Where is a good place to put it up, some people can look at it?

Also, where did people find out the memory configs needed to get this stuff to work?

Posted: **Sun Nov 07, 2004 9:21 pm**

Where are the %$#^%@^%$ binaries in the "Source and Binary" download ("gsKit-0.1-beta-Precompiled.tar.bz2") ???

- jum

Posted: **Fri Jan 28, 2005 9:58 am**

There are object files. Presumably one is intended to link those into one's own final executible.

Posted: **Tue Feb 01, 2005 12:01 am**

I've been using gsKit in my latest project (Geotron) and it works great (for video setup, line and point prims, and double-buffering anyway). Thanks gsKit dudes, and release an updated version soon!

One feature I would like: a function to detect whether the PS2 is NTSC or PAL.

Another feature I would like: "accumulation buffer" for "blur" effects. Maybe this could be integrated into the vsync/swapbuffers code???

Respect

- Jum

Posted: **Tue Feb 01, 2005 2:30 am**

Pull the latest from CVS if you want updates. I just tried it today to get the texture stuff, and it's not blowing up in my face or anything.

Posted: **Wed Feb 09, 2005 3:38 pm**

Hey, I've been attempting to use the current CVS version for just a short amount of time now. Great work, it really makes life easier, and setting these registers much more readable (than say, doing it like funslower).

The only problem I've had is with textures. I've heard of some issues, but I'm not sure if anyone is having problems with the current CVS.

The problem is loading a bitmap. Heres the printf output:

open name host:bitmap.raw flag 1 data 41378
open fd = 2
open name host:bsdgirl.bmp flag 1 data 41378
open fd = 2
Get Reboot Request From EE

Hmm, why would it result in an EE reboot?
Great work though, like I said, makes things much easier.

edit: The problem seems to be with 24bit textures. Line 125 of gsTexture.c. at that fioRead, it crashes.

Posted: **Sun Feb 13, 2005 8:38 am**

Hey guys, I made a massive commit to gsKit CVS today, so check it out as it fixes a ton of things.

From the CVS message:

Code: Select all

THE UBER COMMIT!!

Finally, gsKit is one step closer to gsKit 0.2!

The entire mode/init system has been overhauled, VGA now works
as it is supposed to. I have tested every single VGA mode to 1024x768.
Anything above this is buggy and untested. Also, for 1024x768 it automaticly
forces single buffer rather than double buffer. This is due to VRAM constraints
on the GS.

New primitives!

gsKit now has full 3d primitive support. Add _3d to any primitive to
be able to pass z axis coordinates to each vertex.

The standard primitive calls are actually just macros which access the _3d functions.

Also, there have been several new textured primitives added&#58;

gsKit_prim_triangle_texture_
gsKit_prim_triangle_texture_3d
gsKit_prim_triangle_strip_texture
gsKit_prim_triangle_strip_texture_3d
gsKit_prim_triangle_fan_texture
gsKit_prim_triangle_fan_texture_3d
gsKit_prim_quad_texture_
gsKit_prim_quad_texture_3d

Check em out!

However, textures are still a bit buggy and we are lacking FONTM support.

Once these two things are added, gsKit 0.2 is gold.

About the Reboot from EE message, that seems to be a strange occurance. It's only happened to me once, and rebooting my PS2 seemed to resolve the issue.

As for NTSC/PAL autodetection, I will add that in the very near future, and defiantly before gsKit 0.2.

Posted: **Sat Feb 26, 2005 1:07 am**

My Geotron game uses gsKit (0.1?), and it hangs/freezes after playing for about 3 minutes.

I've checked my code for rogue mallocs etc, but can't find any reason for the hang.

Is there any chance that gsKit could have a memory leak or some other bug that's causing the hang/freeze?

- jum

The freeze I mention above turns out to be my fault, not gsKit's :)
As easy to use as gsKit is, I had to convert Geotron to use gfxpipe because there was too much slowdown with gsKit.

Posted: **Sat Feb 26, 2005 4:32 am**

Hi there Jun, are you using the 0.1 release from the ps2dev.org site, or are you using the latest gsKit from CVS?

I don't imagine that this is a gsKit bug, but it very well could be.

Posted: **Mon Mar 28, 2005 12:19 am**

HOLY CRAP!!

Okay with the help of nearly everyone, I have finally fixed the texture support in gsKit. It had a whole multitude of bugs, but the final ones were pointed out by sparky and tyranid this weekend at Breakpoint.

If you guys run into any other texture bugs let me know, but I'm pretty confident that they are sorted now.

This should include:

The "More than 2 textures bug" where you get textures inside other textures.

and also...

The "Really large textures make gsKit shit its pants" bug.

Thanks again everyone, and one step closer to a new gsKit release!

Posted: **Wed May 11, 2005 12:40 am**

gsKit 0.2 Released, top of thread updated to reflect this.

Posted: **Fri Jul 22, 2005 5:50 pm**

Hi all,

I have problems with textures.

1°)When i upload a texture (400*400) i get the following message : Not Enough VRAM for this allocation

I have only on texture to upload and when i try to upload a smaller, it works.

2°) After uploading a (small) texture, i display it with gsKit_prim_sprite_texture. I can guess my texture displayed at the right place, and the right size, but i see strange colors over the texture.

Anyone can help me ?

Posted: **Thu Jun 22, 2006 7:41 am**

Neov,

Concerning the persistent mode, I see in your examples the following thing :

Code: Select all

switch_mode &#40;persistent&#41;
upload_texture&#40;myTexture&#41;
set_prim_tex&#40;my texture&#41;

while &#40;1&#41;
  exec_queue&#40;&#41;;
  flip&#40;&#41;;
end_while

this sounds ok for me.

now can I do this ?

Code: Select all

switch_mode &#40;persistent&#41;
upload_texture&#40;myTexture&#41;
set_prim_tex&#40;my texture&#41;

while &#40;1&#41;
  upload_texture&#40;myTexture&#41;
  exec_queue&#40;&#41;;
  flip&#40;&#41;;
end_while

as in my case my texture is updated every frame. the reason behind is that i've implemented HW_Flipping in the SDL driver, and I'm having strange result with the texture displayed.

thanks beforehand,
evilo

Posted: **Thu Jun 22, 2006 8:37 am**

never mind, I got it working...

I just missed the first upload_texture before the set_prim_tex(my texture).

anyway, as a result, I have a 200% performance boost in OpenJazz (SDL) using HW_Flip instead of UpdateRects, from 25 to 50 Fps (PAL)

gsKit roooockkks !!! striped textures is a great addition too :)

Posted: **Fri Jun 30, 2006 4:10 am**

Is the svn version updated over the version in the first link?

forums.ps2dev.org

gsKit Development and Discussion Thread

gsKit Development and Discussion Thread

Thankyou

gskit binaries

PAL/NTSC detection

crash maybe caused by gsKit