-
Notifications
You must be signed in to change notification settings - Fork 5
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
track app-shadertoy API requirements #7
Comments
The functions used in Microidium and not directly from ::Modern are as follows. From Helpers:
Also used in shadertoy:
Only in Microidium:
Are in ::Modern, but have different prototypes, and thus can't accept arguments as
|
Forgot, for reference, here's the code where i'm using these functions: That should help in deciding which ones to implement, and which ones to give me guidance on how to replace them with other invocations. |
For reference, these macros and functions are used by Prima::OpenGL:
|
Migrated most old OpenGL functions to OpenGL::Modern, with the changes i made being as follows: In Microidium: wchristian/Microidium@7399ea8 Almost everything worked decently fine, though i'm unsure about the performance of so much data munging in Perl, especially when previously i could just hand C pointers to the XS code. Additionally, as noted in #15, i couldn't migrate two functions due to the inability to pass them null pointers. I also made slight adaptations to the "pass a pointer and the result will be written to it" functions, as some of them will write arrays of values to the given pointer. I added a "result count" argument to those, that defaults to 1 if not given, which is then used to set up the target buffer at the correct size. |
As recommended by @devel-chm i changed the typemap of wchristian/OpenGL-Modern@37fe97b |
I've consolidated the required OpenGL API bindings from Microidium, Prima::OpenGL, PDL, and app-shadertoy into the attached file required-api.txt. I'm assuming that the OpenGL constants implementation is good so all the GL_DEFINE_PARAMS are good in OpenGL::Modern. Regarding the function implementations, functions having only non-pointer/non-C-array argument types and return values should be correctly implemented with the standard default XS typemaps. I call those "good" and list them in the attached file required-api-good.txt. The problematic bindings are the ones where there is a pointer type involved (this can be either a pointer in the C type specification, like "void*" or a C array specification which can be considered equivalent to a pointer type specification, like "data[5]". Because meaning of a pointer type in the API bindings is not fully determined by the type specification, the default binding will use the pointer types explicitly and leave the correct handling from perl to the perl programmer. Because the number and type of arguments and returns will be identical with the C API, these perl bindings are indicated by a suffix of "_c" on the base OpenGL function name. I'm in the process of updating the generate-XS.pl program to apply the appropriate suffix to the function names in the bindings. Once that is complete and verified, work will continue with the more natural perl-ish bindings in 2 basic categories: enabling the use of perl @arrays where possible, and/or using a perl object or reference type to provide the data to be passed for the pointer arguments. The table below shows the current status of the bindings for the "bad" routines.
|
I've determined that all the set of "good" routines includes all of the original Perl OpenGL non-suffixed routines so any remaining work for OpenGL::Modern is in the support of _c, _s, and _p bindings for the "bad" routines. |
Implemented glShaderSource_p for the latest git and that routine works on SPP. Rather than spend time trying to hack perl to talk in C, I believe implementing real perl bindings that don't require finagling at the perl level to work at all is a better approach. To add manual implementations, just edit utils/generate-XS.pl and add the routine name to @Manual and then edit Modern.xs to place the new code near the bottom. |
I've attached the extracted signatures from the priority routines and attached them here. |
This is a list of OpenGL routines used by Slic3r. These appear to be done:
and these are either '_c' currently and need friendly versions:
|
These OpenGL routines are used in app-shadertoy but should be ok since they don't have any pointer arguments:
These are the problematic routines with pointer arguments or return values.
We should sort out the API issues as regards these functions first:
NOTE: arguments or return values with string pointers in them are probably ok since the binding for all pointers is to perl PV strings.
The text was updated successfully, but these errors were encountered: