• Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search

AltME groups: search

Help · search scripts · search articles · search mailing list

results summary


results window for this page: [start: 1 end: 100]

world-name: r4wp

Group: #Red ... Red language group [web-public]
Behold, an OpenGL triangle rendered by a Red/System program:
(2/3 inline binding code and the rest is very plain OpenGL and, yuck, 
I ported a second demo to my OpenGL binding, using textures
Where one can download the OpenGL binding? Don't you want to put 
the bindings into the Red's github?
My bindings are in Fossil repositories. I haven't published my OpenGL 
binding yet
All the old bindings still work with the namespaces branch, except 
I'm getting an internal compiler error on my OpenGL binding, but 
I'm not sure it's my latest code
Nice! I've missed that. It will make parts of my OpenGL binding look 
much nicer
About the native GUI option (using only what the OS provides), I'm 
pretty confident that the minimum common should be enough to cover 
most needs for business apps, I will do a prototype for the Red IDE. 
Having a free drawing x-platform canvas, for games and non-native 
GUI would also be needed, SDL seems to be the best backend for that 
AFAIK (that gives us also OpenGL for free).
Right, adding basic float support to Red is not difficult, but as 
floats are not needed internally to build Red, they are low priority 
(but if someone wants to contribute it, it will be welcome). Moreover, 
the runtime lexer is disposable code, it will be soon replaced by 
a new one with Unicode support and more complete syntax support. 
So extending it now for additional literal forms is a bit of waste 
of time.

If someone is interested in implementing float support anyway, the 
decimal! name is reserved for a future BCD datatype, so possible 
names are: real! or float!. It will be a 64-bit float, so mapped 
underneath to Red/System float! type. A support for float32! at Red 
level is not planned, converting float! to float32! at Red/System 
level when needed (i.e. OpenGL API) should be enough.
PicoGL is a library that defines four or so functions in which an 
OpenGL program should be defined. Although PicoGL is a dynamic library 
loaded by the program, it expects the program to provide those functions
I can't get OpenGL to work on it if you don't :-)
Bindings not in there are SDL and OpenGL, for graphical 2D and 3D 
programs, ZeroMQ for network messaging, and some specific extra widgets 
for the GTK+ binding, such as a (real) web browser, two map browsers 
and a PDF and other document viewer
directories under red.esperconsultancy.nl are according to the script 

test common C-library cURL ZeroMQ-binding REBOL-3 Java SQLite SDL 
OpenGL GLib GTK GTK-WebKit OSM-GPS-Map GTK-Champlain 6502

I copied my list from my browser address field history. Should have 
noticed GLib (first I had tried GLIB and found nothing) was the one 
you asked for.
Group: Announce ... Announcements only - use Ann-reply to chat [web-public]
Normally I do not announce my upload to rebol.org but this time is 
different. I have uploaded an upgraded version of  my interface to 
opengl: http://www.rebol.org/view-script.r?script=opengl-glu-glut-h.r
and I am asking you to insert "GLX_DOUBLEBUFFER" in the block of 
the line: "attrList-def: reduce [GLX_USE_GL GLX_RGBA  GLX_DEPTH_SIZE 
16 GLX_RED_SIZE 4 GLX_GREEN_SIZE 4 GLX_BLUE_SIZE 4 0]"  to see if 
doublebuffer works since in my virtual machine it is not working 
(an empty window is opened and no gl rendering occurs)
Normally I do not announce my upload to rebol.org but this time is 
different. I have uploaded an upgraded version of  my interface to 
opengl: http://www.rebol.org/view-script.r?script=opengl-glu-glut-h.r
and I am asking you to insert "GLX_DOUBLEBUFFER" in the block of 
the line: "attrList-def: reduce [GLX_USE_GL GLX_RGBA  GLX_DEPTH_SIZE 
16 GLX_RED_SIZE 4 GLX_GREEN_SIZE 4 GLX_BLUE_SIZE 4 0]"  to see if 
doublebuffer works since in my virtual machine it is not working 
(an empty window is opened and no gl rendering occurs)
I finally got my OpenGL binding for Red/System in a form suitable 
for publishing:


Currently, the only available backend is for PicoGL, which does software 
rendering with the TinyGL library and shows it through SDL.
I made an SDL backend for my Red/System OpenGL binding:


SDL with OpenGL is available on most platforms, and depending on 
your system, it supports hardware acceleration. So you can now choose 
between software rendering with the TinyGL engine through PicoGL, 
and hardware acceleration or software rendering with the Mesa3D engine 
through SDL. The two example programs can be compiled with either 
I made an OS-Mesa backend on SDL for my Red/System OpenGL binding:


This does off-screen rendering in a memory buffer using the Mesa3D 
engine and then displays the result using SDL. Somehow I can't get 
it to work on Linux, but it's the first time I can use Red/System 
for OpenGL on Syllable. It circumvents two problems: the PicoGL library 
expects application functions that Red doesn't export, and Syllable's 
SDL port doesn't support the official OpenGL backend, so those routes 
both don't work. For most other targets than Syllable, the official 
SDL backend can be used.

It's also the first time that I have used my Mesa3D port to Syllable. 
I couldn't display the output before, because there is no display 
driver for the current Mesa3D versions for Syllable, just the standard 
off-screen rendering. It works great, even though it does only software 
rendering. PicoGL is a bit faster, but Mesa3D is a much more modern 
and complete OpenGL implementation.
I've added binary downloads for all Red platforms to the test repository 
of the two OpenGL examples for the Red/System binding: GL-spin and 


Test reports welcome. All platforms should work in theory, but so 
far I have tested Syllable and Linux x86. You need to have SDL and 
OpenGL installed (in 32 bit versions). SDL is included in the repository 
for Windows, and OpenGL should be included in Windows.
If you use the download.r from the repository (with Fossil), you 
will now get the source code for the OpenGL and Java JNI bindings, 
together with all my other bindings
I fixed the calling convention for the OpenGL library that's included 
in Windows, so the Red/System binding works there now:


I also fixed the binary downloads GL-spin and GL-textures:

Group: Ann-Reply ... Reply to Announce group [web-public]
Yes, not released. r3ogl.exe is our OpenGL based prototype. r3encap 
is our encapper.
No one here can test my new %opengl-glu-glut-h.r on X11?
Please, let me insist. Can someone test %opengl-glu-glut-h.r (on 
rebol.org) on a (real) X11 environment ?
Kaj, great work on OpenGL!  Question: Am I understanding correctly 
that the OpenGL backends currently available don't use the hardware 
rendering in the GPU?  If this is a correct understanding, do you 
have a roadmap for including hardware rendering capability?  Just 
Kja, nice progress on OpenGL support!
There's also the other way around: most GUI toolkits such as GTK 
have an OpenGL widget, so with my multi-backend design I can make 
OpenGL backends for the widgets of those toolkits. You'd have your 
regular widgets and then the option to use part of the window for 
Kaj, I ran into Carl today in Home Depot and we talked about your 
SDL binding for Red.  Do you think it would be difficult to make 
a binding for R3?  Carl was saying that he thought it wouldn't be 
too hard to convert R3-GUI to run off of OpenGL instead of the current 
foundation (was it AGG?) so it could be hardware accelerated.

Just curious.
C++ and OpenGL, GLUT I think. Bleurgh
Support for OpenGL overlay hardware on both X11 and WIN32. Emulation 
if none
FLTK (pronounced "fulltick") is a LGPL'd C++ graphical user interface 
toolkit for X (UNIX®), OpenGL®, Microsoft® Windows®, OS/X, and several 
other platforms.
I don't think you would gain anything by using SDL to get R3GUI faster. 
AFAIK SDL has no 2d graphics support...it's just low-level lib for 
handling the OpenGL or 2d framebuffer. There is no support for 2d 
vector graphics, font rendering etc. so you'll end with the same 
needs for the UI engine in the end.

As Pekr mentioned above, with the new R3 graphics code reorganization 
I'm working on it will be possible to even create a compositor based 
on SDL though if anyone is interested in doing that.
or use OpenGL directly ;-)
Group: Databases ... group to discuss various database issues and drivers [web-public]
Yes, it's in progress. Some like SQLite are one-to-one in Red like 
in Red/System. SDL is used more as a part in other low level bindings, 
such as OpenGL. OpenGL itself is waiting for floats in Red
Group: !Syllable ... Syllable free operating system family [web-public]
Out of the box, Boron has some bindings with Qt and OpenGL, that 
don't work on Syllable
Group: !REBOL3 ... General discussion about REBOL 3 [web-public]
Would it make sense to for a start, have a non-native GUI running 
on top of OpenGL? This is what you see from a bunch of different 
groups out there - e.g. using Lua (Corona, Gideros, Muai), Python 
(Kivy), Haxe, etc. This could maybe be done more quickly since I 
think there's already been some experimenting with OpenGL by Maxim, 
and others (Cyphre?). I guess taking this route would depend on how 
much work it would be to make Draw run over OpenGL, but it would 
open the door to a certain class of apps (games, graphics)..
AdrianS: re OpenGL. I see multiple ways here:

-try to HW accelerate the AGG graphics engine (currently used in 
R3) : I did some experiments which looks interesting. But the more 
you 'accelerate it' the more compatibility problems you get on different 
HW so it's about wighting the pros/cons.

-build completely OpenGL based engine (big task, brings lot of crossplatform/HW 

Otherwise it would be great if the current R3 graphics codebase is 
reviewed and some parts made more modular so different graphics engines/libraries 
are easier to plug-in. That should be not so hard work to do.
Cyphre wrote 2-Apr 2013 22:03:
For those interested in the 
alpha-channel change": ..."

It's a good change to get the alpha-channel 'right' or similar to 
most other standards. Have there been thoughts about including the 
alpha-channel with the RGB values, so it becomes RGBA, which we know 
from OpenGL and other places?

From my R3 console:

>> i: make image! [1x1 #{01020304}]
== make image! [1x1 #{

The alpha values seems to be left out. (It might have changed in 
newer versions.) Setting the pixel will include alpha values:

>> i/1:
>> i
== make image! [1x1 #{
} #{

But it seems, the alpha channel is separate from RGB values. Why 
not always have the alpha channel, and include it with the RGB values, 
so we have: [1x1 #{01020304}]
And related: have there been thoughts about setting origin of images 
in the lower left corner instead of upper left? When I use REBOL 
to draw graphs (of scientic values), I always find myself flipping 
the y-axis. Putting origin in lower left should make such code easier. 
Textures in OpenGL has origin in lower left.
Group: !R3 Building and Porting ... [web-public]
With HRD comes higher performant GPUs but I'm not sure how CPU scales. 
Look at Adobe, they are almost dropping support for classic display 
list (rendered on CPU) and forcing everybody to use their Stage3D 
which uses GPU. It's not easy move as there is almost no tooling 
yet, but it's a must. CPU is not able to process so many pixels with 
the new screens (with high frame rate). I don't say we should drop 
AGG support, just that there must come GPU support using OpenGL/DirectX 
and let the AGG to do high quality rendering of assets.
Actually, Oldes, that's a great idea!  R3's new GUI could be built 
to utilize OpenGL by default.  That way, the GPU would handle all 
the graphics calls, and R3 would have 3D capabilities built-in as 
a bonus!  This would probably even make porting to Android and other 
platforms a lot easier.  In fact, doesn't IOS (iPhone) use OpenGL?
It is. OpenGL ES2.0. As well as Android. Actually I don't think there 
is a chance to do GUI on these platforms without OpenGL.
We did a short test some time ago to use OpenGL, works but is quite 
some work to implement it completely.
The problem of OpenGL is it is great for rendering bitmaps etc. that 
can be used in 'crossplatform' way and I'd like to make such frontend 
for R3.... But if you want to implement something like DRAW  in OpenGLyou 
are getting into troubles. To do it properly you would need to use 
GL shader fragments.
Ofcourse if you want to create classical 3d game from textured polygons, 
shaders etc. that's the area where OpenGL excells (and the developement 
was mainly focused)
Couldn't DRAW work the same way as it does now, but render to a bitmap? 
 Then that bitmap could be rendered by OpenGL like it does any other 
Just think, though, if OpenGL was the default renderer for graphics 
in R3, you could create a flat surface for a 2D screen, but during 
the same session, you could create another flat surface for another 
2D screen at a 90% Z-axis orientation to the first, and then rotate 
from the first 2D screen to the next 2D screen in a fluid 3D way.
I did quite a few tests with OpenGL on R2, but the killer for me 
was the inherent delay with R2 calling the methods (functions) in 
the OpenGL dll.  I was still able to rotate an object created with 
over 1000 coordinate points 30 times per second on a quad-core computer, 
but that's probably 1000 times slower than you could do it with straight 
C on the same computer.
I don't say you should use OpenGL for DRAW. There is no drawing api 
in Stage3D as well. I was proposing to use AGG to draw to bitmap 
with the best possible quality and let the HW do what it's made for.. 
to move pixels around. Bo understands it. That's actually how are 
modern apps made to have 60fps. To make animations just in AGG will 
not work (and honestly never worked). But maybe I'm too involved 
in animations and for many people would be enough to have static 
content. But that is not for future.
Oldes, I don't argue with you and Bo about that. I think we all know 
the state of this technology. I've already did several prototypes 
of such "engine" so I have some ideas how this could be done for 
R3 it's just matter of prioritizing&time&resources.

I wrote about the drawing apis just so other people know OpenGL is 
not any Messiah if you want to do hi-quality 2d vector graphics in 

I'm not against HW acceleration at all. It's just not easy topic 
in this non-ideal programming world as you pointed out.

I see the solution with good high quality rasterizer + HW accelerated 
compositing engine. That should be flexible setup at least IMHO. 
Plus this way also we got the classic 3d api for free.
Bo, I even tried to HW accelerate the AGG renderer code so it is 
completely using OpenGL...works well and you can use draw directly 
inside the OpenGL context mixed with 2d surfaces or 3d objects...lot 
of fun. But still , lot of stuff is still computed on CPU that way. 
Nevertheless its still better that fully SW based renderer.
Bo, I think if we don't make drastic changes to the GOB mechanism 
we should be safe when building anything on top of the GOB datatype. 
The gob! is in fact abstraction layer between the "VIew engine" and 
any "GUI framework" written in REBOL.
So as take this example:

We have now R3GUI framework which runs quite well on the current 
View engine (although this engine was build in 2 weeks during the 
very early R3 alpha work so it's kind of Q&D prototype ;))
(BTW should I mention the R3GUI is much better than R2 VID?)

Anyway, the R3GUI works on current View engine. When I tried to change 
the engine so it uses OpenGL accelerated AGG the R3GUI still worked 
without any problem (except visual bugs caused by incomplete OpenGL 
code implementation of the new prototype).

SO from that example you can see the "View engine" and "GUI framework" 
are two independent things and can be developed or even exchanged 

world-name: r3wp

Group: Ann-Reply ... Reply to Announce group [web-public]
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 
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. 
Group: RAMBO ... The REBOL bug and enhancement database [web-public]
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++
Group: Core ... Discuss core issues [web-public]
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
Group: Syllable ... The free desktop and server operating system family [web-public]
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 
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
Group: Linux ... [web-public] group for linux REBOL users
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.
Group: AGG ... to discus new Rebol/View with AGG [web-public]
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 
Group: Announce ... Announcements only - use Ann-reply to chat [web-public]
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.   

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
Group: rebcode ... Rebcode discussion [web-public]
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)
Group: Windows/COM Support ... [web-public]
I was suspecting it could be working over TCP/IP like Geomol's OpenGL 
Group: Tech News ... Interesting technology [web-public]
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?
[unknown: 9]:
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/
Group: !Liquid ... any questions about liquid dataflow core. [web-public]
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.
Group: DevCon2007 ... DevCon 2007 [web-public]
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.
Group: Games ... talk about using REBOL for games [web-public]
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. :-)
Group: Printing ... [web-public]
or perhaps more appropriate, what OpenGL does for displaying 3D graphics 
on screen.
1 / 327[1] 234