What skillz do you need to help with programming the source code for glide3. I know how to programm in C/C++ have done a little bit of basic. And know glide2x.
I want to help to modify glide3(koolsmoky's) so that it will support all voodoo's and more features.
I don't know how I have to mail about this Koolsmoky, amigamerlin or
glide or dborca if I want to join.
QuoteOriginally posted by perer
What skillz do you need to help with programming the source code for glide3. I know how to programm in C/C++ have done a little bit of basic. And know glide2x.
I want to help to modify glide3(koolsmoky's) so that it will support all voodoo's and more features.
I don't know how I have to mail about this Koolsmoky, amigamerlin or
glide or dborca if I want to join.
Hehehe! Pure ANSI C will do! Which HW are you interested in? Drop us a line...
I don't know if you noticed but mainly Voodoo2 (SLI:D).
Because I don't have other Voodoo's yet[:(].
But working with programms concerning voodoo5 is fine with me to.
I hope that one day we can integrate support for all voodoo's, in one Glide and better support for opengl (not that it is bad I am already happy that Dborca made mesaFX compatible with Voodoo2, It was faster than wickedgl with my voodoo2)and finally make a directx to Glide wrapper compatible with all voodoo's. That is my vision.
QuoteOriginally posted by perer
I don't know if you noticed but mainly Voodoo2 (SLI:D).
Because I don't have other Voodoo's yet[:(].
But working with programms concerning voodoo5 is fine with me to.
I hope that one day we can integrate support for all voodoo's, in one Glide and better support for opengl (not that it is bad I am already happy that Dborca made mesaFX compatible with Voodoo2, It was faster than wickedgl with my voodoo2)and finally make a directx to Glide wrapper compatible with all voodoo's. That is my vision.
Voodoo2 is OK! I have one for testing (and hoping to enlarge my collection). Anyway, unifying Glide for all Voodoos might be a bad thing. CVG branch is specifically designed for non-3D core. H5 is already slower than H3 (in case of Voodoo3 / Banshee), because all decisions must be run-time: IS_NAPALM() or IS_VOODOO3(). We don't mean to make things even slower. The reason we endorse H5 for Voodoo3 is that H5 is more reliable (bugfree) and we don't have time to explore all possibilities -- not enough manpower.
Bottom line is: CVG will be for 3D core only and H5 will be for 2D/3D capable cards. Hum... I don't know about Rush...
again thx for clearing me up. I had to know that considering I read the Glide manual (2.43). Where you to first have to detect which voodoo system you are using. But okay than I will be focusing on cvg for know on. Where is the source or do I have to join the team first????
Well, hello, thats my first time in this forum, so if someone needs help for optimizing Voodoo2 SLI Memory management, just call me, I really want to improve the SLI memory managment system, as everbody has seem it´s very buggy, and the system does not recognize all the memory in the sli mode, and even adresses it well. Let´s join to improve it! :D
I think that needs to be coded in assembly, which I do not know YET.
But I am glad that someone stil wants to optimize the voodoo2.
Will it make a big difference in performance if we would optimize the memory adressing?? I was thinking if it is impossible to disable the GPU/Memory clock synchronisation, to only overclock the GPU. is that possible? I don't expect it to be but can someone explain me why that is so?