Ronie
what would be good is to build milestones so that other people can play
with it and demo it.
So a solution even not working perfectly is better than a not working one.
Stef
On 31/5/14 01:06, Ronie Salgado wrote:
Hello,
I am also interested on this topic. For what I saw from NBOpenGL, Igor
was generating the bindings from older specifications of the OpenGL
API. Those older specifications are in a deprecated DSL.
The newer versions of the OpenGL APIs are available in some XML files
provided by Khronos Group. In this link
http://www.opengl.org/registry/#specfiles another link for a
subversion repository(
https://cvs.khronos.org/svn/repos/ogl/trunk/doc/registry/public/api/ )
with those XML files is available, along with the formal OpenGL specs.
Because they are now in those XML files, we need new generator for
OpenGL 3.3-4.0.
Another question, a core profile context is really needed? Why not
starting working with a compatibility profile?. OpenGL API deprecation
does not depend on us, it depends on what the Khronos Group and the
graphics card maker decide to do. In the x86 Desktop, the three big
companies cannot remove the compatibility profile, otherwise lot of
older video-games will stop working.
Also, there are lots of graphic cards, specially older integrated in
laptops that are only OpenGL 2.x. A better bet is to support at least
the subset available in OpenGL 2.x that is also available in the core
profile.
As for plans for OpenGL support, normal and accelerated GUIs, I am
working in OSWindow.
OSWindow provides support to manage native operating system windows
purely from image side. With Igor, we made a custom image and VM for
Linux in which we removed almost everything graphic related from the
VM. The only support needed in the VM is a small check for event
presence in the VM heartbeat.
For OSWindow, we made initially a XLib based back-end. To reduce
maintenance efforts for Windows and Mac OS, I made a new backend based
in SDL2. It is quite complete and I have tested mostly in Linux. For
Windows I could make it work, not perfect so it needs more testing and
a complete removal of the old Win32 drivers. I don't have a Mac for
testing, but Alex is going to help me there.
I have to tell the CMakeVMMaker to also build SDL2 before building,
instead of having to build/install it manually. After that I think
that we can start integrating into Pharo 4.
As for OpenGL, SDL2 gives me a multi-platform abstraction for creating
a window with an OpenGL context. I already made it work with NBOpenGL,
the only tricky part is dependency order when loading the stuff in the
image.
In fact, I already started making a new 3D graphics engine Pharo, to
rewrite Roassal 3D on top of this one in the near future. Soon I will
be posting some screen-shots of this engine.
With this graphics engine, I am also going to try to make an Athens
backend, for accelerated vector graphics. Vectorial graphics with
OpenGL are very hard to do fast, specially self intersecting bezier
curves. Stencil based testing is simple, fast, supported and efficient
for this job.
Greetings,
Ronie
2014-05-30 11:10 GMT-04:00 Sean P. DeNigris <s...@clipperadams.com
<mailto:s...@clipperadams.com>>:
darrinm wrote
> Oh, and NBMacGLConstants is lacking necessary constants. Is it
manually
> created or generated somehow?
>
> - darrinm
-----
Cheers,
Sean
--
View this message in context:
http://forum.world.st/OpenGL-3-0-tp4760914p4761009.html
Sent from the Pharo Smalltalk Developers mailing list archive at
Nabble.com.
