RaVeN-05 wrote on 2022-09-05, 05:27:
But i hope SGL2 API is supported in some way or another in other cards than Neon250
for example Looking for somebody with Kyro/Kyro 2 or Neon 250 and willing to help in small test
Tuxality confirmed "Kyro still supports SGL2 API and is very close to Neon250"
First please quote my full sentence, it starts with "It seems", that ain't confirmation for my taste ... 😉
As for the SGL2 on Kyro, it exists, does somewhat work, yes it is true that it is mostly used for OpenGL ICD internal purposes as leileilol stated yet it does work for two of the SGL2 demos as well as it does comply with the SGL2 API header that I was using for my SGL compatibility layer attempt (sans one struct that I needed to RE).
The main difference between SGL2 support on Neon250 and Kyro/Kyro II is that some functions were no longer exposed in the later one such as sgl2_mt_tstrips while some new one were added such as sgl2_get_intermediate_map_info. Function was obsoleted in favor of SGL2 extensions, in this case SGLEX_PVR250_MULTI_TEXTURE (0x00010020) with same prototype it seems so.
On Kyro Fortune demo does not start due to the missing function which I believe can be hacked/wrapped to support missing functions with use of SGL2 extensions as mentioned above, Marble and Scanner demo crash at startup while Knot and Trilinear demos does start and run although it seems that geometry is wrong in case of the last demo. In the attachment you can find screenshots from the demos executed on Kyro II.
Regarding SGL compatibility layer, as explained in that particular thread I've encountered issue related to the rendering being suddenly aborted when working on a proof-of-concept. After REing and wasting time in general I've come up what was causing the issue, it was the DirectDraw surface Lock/Unlock pair during rendering. In a nutshell, SGL when initialized in address mode expects user to provide surface pointer as well as stride obtained from calling the IDirectDrawSurface::Lock and IDirectDrawSurface::Unlock methods, so before final render the PROC_2D_CALLBACK is called and in the user callback Lock/Unlock is used to retrieve surface information in order to let PowerVR know where to blit rendered scene. So what is the issue? Well, Kyro / Kyro II during such does abort rendering, even if sgl2_is_render_complete is performed or any sleep added. I've disassembled mentioned SGL2 demos and indeed, SGL2Shell implementation does only call Lock/Unlock once in the entire application lifespan as compared to the SGLShell implementation as well as to what the SGL games do, most likely this is a known driver bug and/or limitation that the ImgTec developers might be aware of or it can be an intended SGL2 behavior while having context created - not sure as I do not have any intel regarding that. So, in order to fix this I needed to hack DirectDraw to cache surface information and prevent calling Lock/Unlock more than once, this also applied to the GetDC / ReleaseDC from the surface if I remember correctly. Such hack allowed SGL-based Virtual On to work in its full glory on Kyro SGL2 implementation. However, this is too hacky for my taste especially that on Win9x you cannot do simple IAT patching which complicates this a little as replacement DDRAW.DLL needs to be renamed to other library as well as binary hexedited to accommodate chages - due to that project was abandoned (the SGL wrapper is in development, it is the poc that is no longer). It is not worth time, IMO.