AltME groups: search

switching the search to "opengl" brought this up near the top: http://www.rebol.org/cgi-bin/cgiwrap/rebol/ml-display-thread.r?m=rmlDHPC

Anything that requires traditional I/O (not OpenGL or DirectX) will 
have a lot of variation on Windows. Video games use timers and delays 
to get consistent behavior.

I am unable to get the external dll working when doing a Release 
level build.  it compiles without any errors... 


but when running the same script which is working in debug mode, 
I get this  error in the console:


** access error: cannot open: %opengl-cgr.dll reason: "not found 
or not valid"

very strange

closer to 2-5 fps here, but probably due to software OpenGL

(strange that it runs now, when I was warned before that OpenGL wouldn't 
work)

wrt resize, yes that is on purpose.  it allows me to test events 
within and without the opengl.

and yes it is strange that it works now and didn't work before!  
I didn't change any of OpenGL code, though I had a serious memory 
corruption issue, so its possible that on your system, that translated 
to some bogus system call.

it has been behaving strangely just yesterday (openGL issues) and 
today (network flakey), so I'm not even sure it will keep working. 
:-)

the point is that making bridge  betwen rebol script and librari 
in the way it is actually done is good for tiny simple library but 
very a tremendous work when it touch to heavy complicated library 
that intent to abstract from the os consept and give the same way 
to code on any OS/material. Mostly Opengl and GTK for example. Both 
libraries are heavy (lot of libs lot of struct lot of types lot of 
dependencies that needs a bridge too). For OPENGL you have two way 
to work or you make a OS based I/O and windowing system example gdi32.dll 
user32.dll for windows or xlib.so for Linux and  then exploite gl* 
function that are stored in the openGL.so/dll  or you use the related 
to opengl portable set of libraries to handle window drawing and 
Mouse/Keyboard events glut.dll/so. The fact that a librarie portable 
must be a library the abstract from the OS dependencies make them 
very complicated to handle. AS we don't have the same coding effort 
on library bridge coding than other language because many reasons 
in witch the fact that library loading is a Pro functionnality and 
maybe too because the system is not enought developped. It's easier 
to make a library bridge for a language when this language allows 
type creation and have based type in this language that feets with 
the one in C/C++

If I take Cal Dixon's libopengl.r software for example we clearly 
notice that it only use the multi float functions in opengl and not 
the vectorial float functions that leads me to think  glColor3fv( 
my_colors[ 0.3, 0.5, 0.0 ]) kind of function are un explotable as 
is in rebol and many are the external libray that deal with array 
of data for arguments instead of fractionnal multi datas

I'm using this feature in the OpenGL API, I'm working at. Maybe I 
could do a late reduce, when accessing the inner blocks.

I already have some OpenGL examples from the red book of OpenGL running 
in REBOL syntax. It's funny to see those examples in REBOL with the 
minor syntax. :-) I have no real idea of performance yet, I need 
heavier examples for that.

james, no C syntax. I'm making a REBOL version of the OpenGL API 
with REBOL syntax. Users will be able to use normal REBOL and call 
OpenGL functions (with REBOL syntax).

John, Is your opengl api rendering in a rebol window or face?

The commands are sent to a C program (task), that'll execute the 
OpenGL code. So the C program owns the window, not REBOL.

james, no. It's from 2 different programs. The datastructure is just 
used in one example. Some OpenGL commands take pointers to datastructures 
as a parameter.

You can see the full example here: http://home.tiscali.dk/john.niclasen/OpenGL/GLClient.html

First you have the C source, and below that the REBOL source, that'll 
do the same thing. I first thought about putting a REDUCE in, where 
vdata is defined, but I've changed my mind. The glVertex3fv function 
has to reduce it's argument.

Yes, it should be possible to call my OpenGL functions from an engine 
like that. That's the sort of things, I'm going to use this for. 
Only thing is, that the OpenGL window is inside a C execute, so you 
can't put REBOL controls (view stuff) in there. But you can then 
just have 2 windows.

One window with OpenGL output and another window with REBOL buttons 
etc. to control the thing.

my goal is to get the host code and OpenGL headers past the parsing 
phase.  once that is done, I'll start work on adding the production 
phase.


I still have to write the pre-processor, but that in fact is pretty 
straight forward.  there are little rules and they are much more 
static and well defined on the MS web site.

Another thing is that Arno considered using OpenGL for this, but 
according to him, the OpenGL API is not suitable for multithreading, 
at least not to the extent that we need it at this low level in Syllable

If you're interested in the video driver framework, we're now having 
an excellent discussion on the mailing list about how to integrate 
OpenGL:

Probably comparable to the first stages of REBOL/Core years ago. 
On the other hand, it also has some much newer functionality already 
implemented. It has a simple interface to QT on Linux and the beginnings 
of an interface to OpenGL

Maxim, the OpenGL situation in DirectFB is still quite unclear

DirectFB 2, with OpenGL support, still seems to be just a plan

There's an old OpenGL extension that was revived a year ago and then 
again not updated. If it works, it probably only supports hardware 
acceleration on one old video chip

So it looks like for some time to come, you will still need X11 for 
hardware accelerated OpenGL

Software OpenGL should be possible on SDL, though, for testing or 
low speed requirements

Conclusion from all those tests is that right now Qt is leaps ahead 
of any other vector graphics framework in terms of raw performance. 
Nothing comes even close. Qt's OpenGL engine is so fast it's basically 
unfair to compare anything else to it.

hardware rendering --- it has OpenGL, FrameBuffer and some other 
no-X ways... i don't know

I mean no-X OpenGL and no-X Framebuffer. Maybe that diagram is misleading 
but maybe it is not misleading

One of the details I left out in the above overview is how clients 
actually render under wayland. By removing the X server from the 
picture we also removed the mechanism by which X clients typically 
render. But there's another mechanism that we're already using with 
DRI2 under X: direct rendering. With direct rendering, the client 
and the server share a video memory buffer. The client links to a 
rendering library such as OpenGL that knows how to program the hardware 
and renders directly into the buffer. The compositor in turn can 
take the buffer and use it as a texture when it composites the desktop. 
After the initial setup, the client only needs to tell the compositor 
which buffer to use and when and where it has rendered new content 
into it.


This leaves an application with two ways to update its window contents:


   1. Render the new content into a new buffer and tell the compositor 
   to use that instead of the old buffer. The application can allocate 
   a new buffer every time it needs to update the window contents or 
   it can keep two (or more) buffers around and cycle between them. 
   The buffer management is entirely under application control.

   2. Render the new content into the buffer that it previously told 
   the compositor to to use. While it's possible to just render directly 
   into the buffer shared with the compositor, this might race with 
   the compositor. What can happen is that repainting the window contents 
   could be interrupted by the compositor repainting the desktop. If 
   the application gets interrupted just after clearing the window but 
   before rendering the contents, the compositor will texture from a 
   blank buffer. The result is that the application window will flicker 
   between a blank window or half-rendered content. The traditional 
   way to avoid this is to render the new content into a back buffer 
   and then copy from there into the compositor surface. The back buffer 
   can be allocated on the fly and just big enough to hold the new content, 
   or the application can keep a buffer around. Again, this is under 
   application control.


In either case, the application must tell the compositor which area 
of the surface holds new contents. When the application renders directly 
the to shared buffer, the compositor needs to be noticed that there 
is new content. But also when exchanging buffers, the compositor 
doesn't assume anything changed, and needs a request from the application 
before it will repaint the desktop. The idea that even if an application 
passes a new buffer to the compositor, only a small part of the buffer 
may be different, like a blinking cursor or a spinner.

In computing, the Direct Rendering Infrastructure (DRI) is an interface 
and a free software implementation used in the X Window System to 
securely allow user applications to access the video hardware without 
requiring data to be passed through the X server. Its primary application 
is to provide hardware acceleration of the Mesa implementation of 
OpenGL. It has also been adapted to provide OpenGL acceleration on 
a framebuffer console without an X Server running.

 http://en.wikipedia.org/wiki/Direct_Rendering_Infrastructure_(DRI)

As far as I know, DRI requires 3D support. DirectFB supports 2D hardware 
and drivers. It can be combined with OpenGL

It's quite possible that the OpenGL combination requires DRI

The transformation handling is more simmilar to OpenGL in that way. 
See some OGL docs to get the idea and you will see the benefits.

at present I am re-writing all controls in draw only mode so that 
when we eventually get access to OpenGL surfaces I have less pain 
:)

although OpenGL plugin would simplify that a thousandfold

yeah .... events applyed directly on draw elements or draw able to 
"map" and show directly other graphical organised video layers who 
be so awsome that way from example what is rendered on sub engine 
external like opengl one could then be applyed to a regular vid area 

In one hand you will have an easy way to interface events and on 
the other hand you can map rendering any kind of sub rendering

maxim already said that  about linking external grphical library 
result using image! data type

Maxim
20-Aug
[10...12]	

when Carl adds a few little image! enhancements to the extension 

API, I should be able to use a rebol image! as the interface to get 

the OpenGL render into rebol, using R3 view.  If memcopy works, then 
it should be VERY fast ( a few hundred images/second AFAICT)


yes Geomol did, but the limitations of R2 can't make it native... 

meaning, you don't have access to the binary part of the data and 
use it directly within normal datatypes.

the goal is to have an OpenGL gob :-)

yes as you say... an 3D gob using external render should be doable, 
either OpenGL or other engine.

yeah or drawing non image based texts ... most of the time in game 
text are all fuzzy small et because of the distance with using AGG 
to draw the text on top of your opengl embeded to VID layer you could 
at no cost  get a stable way to display them

don't know really.  but in any case, you don't have to use the library 
to do the rendering...  We can always render them using AGG or OpenGL. 
 as long as we have the coordinates.

GLServer for Win32 is released. There also is a Mac version, Linux 
is still missing.
See group OpenGL.
It makes it possible to do 3D graphics from REBOL using OpenGL.

REBOL natively Generated OpenGL hardware accelerated graphics.   
  :-D

http://www.pointillistic.com/open-REBOL/moa/steel/R3-OGL.png

I did a few tests loading up OpenGL/GLut and it worked without a 
hitch... waiting for Carl to add a few features before I can continue.


screen shot of a rotating cube http://www.pointillistic.com/open-REBOL/moa/steel/R3-OGL.png

We'll have some decent openGl implementation... right? :)

Champlain is much more complete and generic, except maybe the GPS 
track functionality. However, it uses Clutter, so OpenGL, so that 
must be available on your target platform

I don't know where to post this request, so I put it here:

I am translating some .h files of useful shared library to rebol 
( fmod,sdl,opengl) so if you know of a useful-multiplatform-publi-shared 
library

please give me lonks to binaries, .h files and test programs, thanks.

btw - don't you expect any possible rebol 3D engine, even if we have 
rebcode, as simply slow? Isn't the only chance linking rebol to external 
engine/library (e.g. OpenGL)?

that's probably the only way... also you shouldn't expect to do any 
serious 3D without access to 3D hardware acceleration. it would be 
nice to do this through openGL somehow, but it would take up too 
much footprint to build this into rebol directly

As I'm interested only in pure vectors, REBOL speed is succifient 
for me :)) But yes, REBOL can probably be linked to some external 
library (as Cyphre did with OpenGL) or SDL maybe? But I don't think 
it should be high on priority list, other things are more important.

I'd also like a way to copy to/from an external image source... to 
allow easier access to DLL rendered gfx.  (opengl and others)

I was suspecting it could be working over TCP/IP like Geomol's OpenGL 
library

Regarding multitasking and REBOL, how far is it possible to go using 
communication between tasks over the TCP protocol? I've implemented 
multi-user locking this way with a relational database in REBOL, 
and it works quite well. I haven't done stress-test, so I have no 
real measurement, how effective it is, and what the performance is 
compared to other inter-task communication methods. I'm working on 
an OpenGL implementation, where OpenGL commands are sent from a REBOL 
task to an OpenGL server task (written in C), which will execute 
the OpenGL commands, so I'm about to get more experience in this. 
Both tasks will run on the same computer, but can easily be on different 
computers, of course.


Anyone with more experience in task communication using TCP? Where 
is the limit?

John...cool.  Build an X-Windows like layer between Rebol and OpenGL.

rebol->tcp-<opengl: could work. bottleneck is lots of request. In 
your case you would only do one request/frame. Copying the bytes 
on the same machine should be fast.

I'm developing a byte-code style for OpenGL commands, so little communication 
is needed. Only 1 byte for the command (gl, glu and glut commands 
are fewer than 256), and 4 bytes for most parameters. So many commands 
are fewer than 10 bytes of communication. It may not be fast enough 
for games, but I hope, it's fast enough to make tools and fast OpenGL 
prototyping (trying out ideas).

https://jogl-demos.dev.java.net/- another java-opengl lib. with 
webstart and applet-demos.  Needs a little bit polishing, but i am 
not sure the flash-runtime has thatmch advantages.  Tested with firefox/linux.

runs ok here. At least it iis opengl

OpenGL 3 announced - recent news on OSNews.com

Pyglet has sound, opengl link, there is nice asteroid game in 27kb 
of source!

OpenGL 3.0 specs released - http://www.khronos.org/news/press/releases/khronos_releases_opengl_30_specifications_to_support_latest_generations_of/

a tool which scans entire repositories of C/C++ code and builds bindings 
for various interpreted language... its one of the reasons python 
gets everything first... its totally integrated into SWIG... for 
example, SWIG was used to build the python OpenGL binding.  its just 
a question of getting the .h or the sources.  and then saying... 
I want to use it in [select language].

I guess you would build extensions per DLL. one for openGL, one for 
SQLite, one for audio, etc. no crisscrossing?

exactly... in fact, OpenGL provides the .lib files directly, so you 
in fact compile your own OpenGL DLL directly... no need to double 
reference the DLL  :-)

Taken from OS News (credit: Kroc Camen):


Google's Native Client (NaCl) is a browser technology to deliver 
native x86 binaries to users on Windows, Mac and Linux. Whilst this 
bridges the gap between modern JavaScript speeds and native binaries, 
portability is limited and that's especially important on the web 
where there's greater device diversity than on the desktop. Google 
are announcing that NaCl now also supports x86-64 and ARM. In addition 
to this Google are also announcing the ANGLE project, an open source 
compatibility layer to map WebGL (OpenGL ES for the web) to DirectX 
calls for Windows systems without an OpenGL library.


http://www.osnews.com/story/23021/Native_Client_Portability_Almost_Native_Graphics_Layer_Engine

Finally - http://developer.nvidia.com/content/accelerated-path-rendering-opengl-nvidia-path-rendering-sdk

so for elixir, I am thinking of building an OpenGL interface AND 
an AGG view based one using the same software. in fact, we could 
even have two simultaneous symmetric windows running and 0% code 
to add in the software :-)

(one in AGG and one in OpenGL, to compare them)

It would be nice if RT communicated to us in here, we who are very 
interested in working as closely as possible with RT, but cannot 
do work directly on the core, on what it would be a very good idea 
for us to consider building.


Like: "RT thinks you should look at building a GUI system" or "RT 
would like you to build a test case suite for R3" or "RT would like 
you to work on making OpenGL work well with REBOL as a dialect like 
VID" or "RT would love to see you building protocols for this and 
that kind of communication" or "RT needs a very good multithreaded 
webserver, that can handle X users" and have those efforts officially 
endorsed by RT, similarly to how MUI eventually became the GUI of 
choice on the Amiga to build your applications on. Perhaps put out 
hard specs and see if anyone will pick it up.


Right now, many efforts feel like they are there, not because RT 
felt they were a good idea, but because some individuals thought 
they were good ideas. Most of us here speak highly of our own ideas, 
but without much dialog with RT. AltME feels like it's the only non-RT 
effort that is endorsed by RT and perhaps also Cheyenne. Such directions 
would also mean that perhaps a lot of people would flock to the same 
official project, rather than starting 2-3 separate projects.

allowing me to use a gui and open it up in OpenGL, activeX, if I 
have the need/resources/time to provide it.  I mean to be able to 
extend the whole engine so I can skin it without needing to rebuild 
100% of the gadgets, etc... many of the things we spoke at the devcon, 
but more too.

Geomol, OpenGL, DirectX.... maybe? :-)

Skip DirectX, use OpenGL and implement it using GLUT. It works the 
same on all platforms.

Geomol, but I agree for the first round, OpenGL is more important.

Afaik, OpenGL is on Windows. I'm not sure, if GLUT is or it is linked 
with app.

About OpenGL: On this Windows 2000 machine, I have access to, I see 
"OPENGL32.DLL" and "glu32.dll" under /c/winnt/system32/

Geomol why do you think that opengl access should be done with GLUT?

so is OpenGL, I just do not understand why we should need some wrapper

GLUT is just some extra functions, that have same kind of interface 
as OpenGL OpenGL is just only basic graphics, where GLU and GLUT 
add things, that is used in e.g. games ... or in REBOL.

not very nice description of GLUT's internal state - http://en.wikipedia.org/wiki/OpenGL_Utility_Toolkit

SDL is more generally available than GLUT, and you can put OpenGL 
on top of it

AFAIK GLUT is simple wrapper which has been used mainly just to show 
some basic OpenGL demos. I'm not sure if this is a good  for usage 
in some 'real' crossplatform apps.

Regarding the OpenGL version of Rebol: this version is not yet worked 
on but I plan to work on it once the AGG based version is complete 
(as it this will give us much better big picture where the OpenGL 
advantages could be really useful in the visual system).

AFAIK the plug-in interface is not yet finalized so it is too early 
to discuss ho this will be exactly exposed.


But there are more things to consider than the blitting. If you do 
SW redered graphics you need to render into the  backbuffer in the 
main memory then you transfer block(s) sing a blit to the gfx card. 
If you do HW accelerated graphics you need to transfer all bitmaps 
into the gfx card memory first..also you are limited by the OpenGL 
2D functionality (which is not so flexible and pixel perfect as for 
example AGG implemntation). Also setting pixels directly in gfx card 
memory is possible but this is surprisingly the slowest way to dorendering! 
Why? Because fur current PC HW bus architecture is such transfer 
very expensive operation comparing to moving one big block of data.

So as you can see all this (and lot of other issues) needs to be 
considered not to mention that the solution should be as much as 
compatible on most of platforms.

Once the beta is released it will give us good picture how to make 
the gfx system even more optimized and extensible.

so if its done Like I think, using R3 elixir should be VERY interactive. 
 and if that doesn't work, well, I can just use OpenGL later on.

If I decided to go ahead with OpenGL and Elixir, using GLASS as the 
design... what is left of REBOL but the syntax and the interpreter 
anyways?  I'd rather have the tool running on steroids without being 
tied to a chain.

also will be porting to OpenGL, but the high level coding won't change.

using this technique, I was able to do skining which is independent 
of the gui engine underneith.  one only has to support the aspects 
in his skin and the skins (and gui using them) remain valid, even 
though you are running on opengl or vid.

The engine will use liquid's flexible interpreted messaging overlayed 
on the other graph engine which I will use for scalability in sheer 
volume of connections and nodes I can allocate.  just a portion of 
the tree usually needs to be in RAM at any given time, and in fact, 
parts of processing tree can now reside on different computers since 
the graph engine is refered to... it should be quite fun to use.


this will be tied in to the OpenGL and scream core scene-description 
engine as one cohesive toolset.


in this system, the binary nodes will actually be optional and should 
be invisible when used from the rebol application's point of view.

for my part, when R3 goes open, I'll be integrating liquid-paint 
with OpenGL asap... which will completely alleviate my need for /view. 
 we will have a 3D native GUI  :-)

if Cyphre can show that OpenGL can be compiled within (with a proof 
of concept demo, just to show that its actually possible),  for example.

I see no reason, why you can't make 3d games using OpenGL together 
with REBOL.  Eve Online is made with Python: http://www.eve-online.com/

humm. well how much of REBOL would we really be using in an OGL game 
with proper key support... none of view... so basically core with 
a huge stub over OpenGL and native event handling.

Any plans for an OpenGL version with perspective 3D tiles?

when R3 is released and someone writes the OpenGl plugin :P

but ive got a MMORPG to do in openGL before that :)

There are 2 OpenGL implementations for REBOL already. One by Cyphre, 
that require REBOL/Command (I think), and mine requiring GLServer 
(compiled C program, only for OS X so far).

Why not use OpenGL?  It seems your game primitives are just that...primitive. 
 A little physics, collision, sound, etc.   Nothing difficult.  IF 
you make it OpenGL, it can work on Mac, and even many Cell phones.


You might be able to write an abstraction layer so you can keep a 
lot of your Flash code in place.

I'm waiting for Maxim to design us all a nice game engine via openGL 
extensions. :-)

or perhaps more appropriate, what OpenGL does for displaying 3D graphics 
on screen.