Author Topic: jPCT access to underlying OpenGL  (Read 2492 times)

Offline iagofg

  • byte
  • *
  • Posts: 12
    • View Profile
jPCT access to underlying OpenGL
« on: July 15, 2011, 02:03:32 am »
I really like jPCT. In fact seems to suit most of my needings, but...

Did you have think in adding functions to get/set OpenGL (or other) internal ids or handlers and access to the underlying OpenGL (or other) calls?

In that way we could call native OpenGL if it is really needed to make an effect. In that way if the engine lacks of a feature, while it is not embeded in the mainstream projects can still going on using workarounds.

Of course I've to say that I've seen that jpct interfaces can make a lot, but for sure are limited on some cases. On most cases using natives should be discouraged, but on some cases it can be a last chance until the engine is updated :D (use on your own risk xDDD).

Don't you think so?

In fact is possible on some casses that you could add the native calls as improvements directly to the engine chain later if we send you back :)

Offline EgonOlsen

  • Administrator
  • quad
  • *****
  • Posts: 12056
    • View Profile
Re: jPCT access to underlying OpenGL
« Reply #1 on: July 15, 2011, 08:04:07 am »
What you can do already, is to

  • write OpenGL code at any place you like as long as you do it in the render thread. You just have to make sure that your code doesn't interfere with the state that jPCT assumes to be set or at least save it before and restore it afterwards.
  • implement the IRenderHook-interface to execute some additional stuff directly in jPCT's render pipeline.
  • do your additional stuff in a shader.

Neither way gives you access to the internal ids, but i'm still waiting for a requirement where this is actually needed. Personally, i haven't come across anything like that until now. Shader support in the desktop version for example, is solely based on the IRenderHook interface.