gsKit Development and Discussion Thread
-
- Site Admin
- Posts: 72
- Joined: Sat May 22, 2004 9:29 pm
- Location: Copenhagen, Denmark
- Contact:
gsKit Development and Discussion Thread
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
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
Last edited by Neovanglist on Wed May 11, 2005 12:38 am, edited 1 time in total.
-
- Posts: 564
- Joined: Sat Jan 17, 2004 10:22 am
- Location: Sweden
- Contact:
-
- Posts: 564
- Joined: Sat Jan 17, 2004 10:22 am
- Location: Sweden
- Contact:
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 :)
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 :)
Kung VU
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.
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.
Shoot Pixels Not People!
Makeshift Development
Makeshift Development
-
- Site Admin
- Posts: 72
- Joined: Sat May 22, 2004 9:29 pm
- Location: Copenhagen, Denmark
- Contact:
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
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
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.
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.
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.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
Code: Select all
int drawthedamnthing(x1,y1,z1,x2,y2,z2,color)
#define drawthedamething(x1,y1,x2,y2,z,color) drawthedamnthing(x1,y1,z,x2,y2,z,color)
BTW... try green points, and red points...
Shoot Pixels Not People!
Makeshift Development
Makeshift Development
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.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.
Shoot Pixels Not People!
Makeshift Development
Makeshift Development
-
- Posts: 564
- Joined: Sat Jan 17, 2004 10:22 am
- Location: Sweden
- Contact:
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.
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.
Kung VU
Thankyou
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?
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?
gskit binaries
Where are the %$#^%@^%$ binaries in the "Source and Binary" download ("gsKit-0.1-beta-Precompiled.tar.bz2") ???
- jum
- jum
8 bits is all you'll ever need...
- Neil Stevens
- Posts: 79
- Joined: Thu Jan 27, 2005 2:22 pm
- Location: California
- Contact:
PAL/NTSC detection
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
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
8 bits is all you'll ever need...
- Neil Stevens
- Posts: 79
- Joined: Thu Jan 27, 2005 2:22 pm
- Location: California
- Contact:
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.
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.
-
- Site Admin
- Posts: 72
- Joined: Sat May 22, 2004 9:29 pm
- Location: Copenhagen, Denmark
- Contact:
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:
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.
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:
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.
As for NTSC/PAL autodetection, I will add that in the very near future, and defiantly before gsKit 0.2.
Regards,
Neovanglist
Neovanglist
crash maybe caused by gsKit
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.
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.
Last edited by jum on Thu May 05, 2005 12:28 am, edited 1 time in total.
8 bits is all you'll ever need...
-
- Site Admin
- Posts: 72
- Joined: Sat May 22, 2004 9:29 pm
- Location: Copenhagen, Denmark
- Contact:
-
- Site Admin
- Posts: 72
- Joined: Sat May 22, 2004 9:29 pm
- Location: Copenhagen, Denmark
- Contact:
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!
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!
Regards,
Neovanglist
Neovanglist
-
- Site Admin
- Posts: 72
- Joined: Sat May 22, 2004 9:29 pm
- Location: Copenhagen, Denmark
- Contact:
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 ?
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 ?
Neov,
Concerning the persistent mode, I see in your examples the following thing :
this sounds ok for me.
now can I do this ?
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
Concerning the persistent mode, I see in your examples the following thing :
Code: Select all
switch_mode (persistent)
upload_texture(myTexture)
set_prim_tex(my texture)
while (1)
exec_queue();
flip();
end_while
now can I do this ?
Code: Select all
switch_mode (persistent)
upload_texture(myTexture)
set_prim_tex(my texture)
while (1)
upload_texture(myTexture)
exec_queue();
flip();
end_while
thanks beforehand,
evilo
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 :)
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 :)