I need advice from someone with more experience with openGL and/or
Racket.
I am still working on updating the Racket openGL binding to the current
openGL spec.
I'm doing this as in the old binding, machine-translating the formal
part of the openGl standard, which now uses a competely new formalism.
I'm debugging it (for now) by comparing the old Racket include file with
the new one on the theory that functions that were there a few years ago and
are still there should have teh same Racket definitions now as then.
Running into a big snag.
There are a *lot* of glGet functions that grab data from the video
processor and bring it to the CPU.
They give openGL a pointer to a storage area where it should return
data.
For example, there's glGetCompressedTexImageARB. It receivees a
pointer to an image area and fills it in with a compressed image.
According the the Racket C interface, the way to write this
would be:
(define-gl glGetCompressedTexImageARB 2
( (target : _int32)
(level : _int32)
(img : _pointer/intptr)
-> _void -> img)
(->> exact-integer? exact-integer? gl-pointer?)
check-gl-error)
(here define-gl is a macro interal to the opengl binding that contains a
number of input arguments and a contract for the manual as well as the
actual c interface description, which of course is
( (target : _int32)
(level : _int32)
(img : _pointer/intptr)
-> _void -> img)
Here the '-> _void' specifies the value returned as function value from
C, and ->img indicates what the Racket openGL bindig s to return as to
the Racket calling program.
But the old binding instead used
( (target : _int32)
(level : _int32)
(img : _pointer/intptr)
-> _void)
In other words, it ignored the fact that img is used as an output
parameter.
Now what should I do with this? As I said there are very many such
functions. It's not an isolated case.
Are all these glGet functions simply something that never happened to
get used in Racket code so no one noticed the discrepancy?
Is there some idiom in Racket programming where all this just works
anyway?
Is there some efficency reason for not recognising output parameters?
Do they parhaps cause new storage allocation every time they are called?
I would prefer that other Racket code that uses the old binding not have
to be rewritten for the new. I'd like the new binding to be both
correct and compatible insofar as compatibility matters.
And I would very much prefer my binding to follow spec on both the
openGL front and the Racket front.
Or maybe I should call the new binding something else, like opengl3,
so that old code can use old bindings and new code the new.
That would be touble for those using old libraries who also want to use
ew features.
And I've encountered a few cases where I think the old binding is just
wrong.
I would appreciate advice on these matters from those with more Racket
or more openGL experience.
-- hendrik
--
You received this message because you are subscribed to the Google Groups
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to racket-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/racket-users/20200731210527.lrbk4sajudjuivck%40topoi.pooq.com.
