[SDL] Back on the input events thingy, and some ps2gl

[Eric Vidal]

Quoting Stephane Marchesin <stephane.marchesin at wanadoo.fr>:

> Maybe you could expose such fonctionality through suitable OpenGL
> extensions like :
>
http://oss.sgi.com/projects/ogl-sample/registry/EXT/pixel_buffer_object.txt
>
http://oss.sgi.com/projects/ogl-sample/registry/ARB/vertex_buffer_object.txt


Hmmm, that looks promising.  I can theoretically catch all queries for
OpenGL functions from SDL to see whether the app is requesting a vertex
buffer object, then redirect them to my own functions that allocate the
memory in the ps2stuff area.

Actually, should I do this?  Or should I just modify ps2gl so that the
extension is officially supported?


> For the textures, you have to allocate and copy the texture to this
> specially allocated memory (the OpenGL texture Object which got
> standardized in OpenGL 1.1 allows doing just that). That's really
> ...
> So what you describe falls very well into the current graphics
> hardware
> trend. Or maybe I'm missing something.

Oops... here's what's missing in my description -- ps2gl isn't a real
OpenGL library.  It does have texture objects, but getting them to work
requires that the texture itself be stored in ps2stuff-managed DMA
memory, just before passing the texture data to glTexImage2D.  (And
like I said in my previous post, there's still a weird thing going on
with all the GS slots and areas and whatnot.  My nose is bleeding.)

Another weird thing about this is that ps2gl's glTexImage2D (and
actually most of its other functions) won't copy the data -- it will
just update some internal pointers.  I don't know why it was designed
this way -- perhaps to conserve memory?  (I can't seem to think it's
performance-related because textures are usually preloaded anyway,
hence copying shouldn't be a big deal except when memory is scarce.)


Eric Vidal
Lecturer / Graduate Research Assistant, DISCS
Ateneo de Manila University
http://aegis.ateneo.net/evidal/