World: r3wp

Geomol - I jus hope rebcode is there, with refinements guys outlined 
... it should help too ...

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

I'm all for porting, but not if wating for key features means delaying 
work for "normal" folk.  I'm at a point where some of the bosses 
are actually getting pretty good at R2 data types.  :)

And I'm just starting to get people here involved with GNU/Linux...so 
I'm banking on that R3 release not being too far behind.  :)

Pekr;  Re r1 to r2.  I was a dropout from the computer biz from 1999 
till about January this year, so I was watching from a purely curiosity 
perspective, no vested interest.  Now the interest is much higher 
and far more vested.  :)  In that regard I'm still new.

Henrik, it's good, that R3 is open in a way, that it's possible to 
interface all kinds of systems. But I wouldn't recommend interface 
too deep into anything, that is tied to a certain platform, like 
DirectX is. We should find good cross-platform standards and interface 
with those from REBOL, so all REBOL software can run on anything.

Geomol - each coin has its two sides. Maybe there are some Windows 
only developers. From their POV, there is simply DirectX available 
on each PC, so no special need to install one. In the case of GLUT, 
they will have to either install it separately (I don't know anything 
about it, so maybe it is just few libraries), or simply pack with 
their app ...

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

My point is, it's good that REBOL is open for interfaces. I just 
wouldn't recommend interfacing with DirectX. That's it.

Like I wouldn't recommend interfacing with e.g. the Velocity Engine 
on Macs, because it's tied to Mac OS and the Altivec technology found 
in G4 and G5 processors.
REBOL is about cross-platform also. Write-once-run-everywhere.

OTOH - why not to optimise to what is native on all platforms? Under 
the hood, so that the programmer does not need to care? Well, app 
performance would probably vary between the platforms, but ....

Geomol, I think you mean that _RT_ should not focus on DirectX. :-) 
I don't see anything wrong with a 3rd party developer doing work 
on interfacing DirectX.

I would like to first see new View with rich-text, VID, ability to 
embed externall windows (e.g. video player, etc.), decent sound, 
really good VID, tools like screen painter, debugger, cross platform 
rebgui to give initial boost to apps, and then further fine-tuning 
using DirectX or View plug-ins (access to buffers etc.)

Yeah, something like that. If you interface to something special 
found only on one certain platform, your software will only run there. 
If you support many such technologies on many different platforms, 
you end up having huge problems supporting new versions. Trick is 
to find the right things to interface with. Carefull selection! But 
of cource some specialized developer can interface with such things 
for some special software only to be run on that single platform.

cross platform rebcode
 in my above text ...

Yes, rebcode everywhere solve many performance issues! I agree!

I think that we need few tweaks to it. BrianH and one other guy had 
some nice suggestions. Adding few instructions would allow emulation 
of some old machines :-) Porting some nice simple games could be 
easier :-)

Galaga already looked promissing :-)

And we are waiting for RPaint as well :-)

Look a our situation with truetype fonts in DRAW. It's one single 
little issue in one corver of REBOL, yet we don't have it on all 
platforms, even if there is truetype fonts on all platforms. Imagine 
the situation, if we had many such things with all different areas 
of REBOL. So not only RT should choose carefully, also us developers 
who would like our software to run everywhere.

corver = corner

that might be valid point ....

I am curious if r3 will be usable on smaller devices :-)

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

It might be necessary to install GLUT on Windows. See http://www.xmission.com/~nate/glut.html

and that is something I refuse to use, if it needs isntall, and can't 
be automated with my app install, or just by running some script 
...

if I can copy that somewhere and register it to registry (if needed) 
via some script, then I am ok ....

I think, you just have to include the glut dll with your app install. 
It's only a file to be copied.

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

what is glut? Some kind of wrapper?

Rebolek - maybe because it is available for most platforms?

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

GLUT have many things, we lack currently in REBOL, like key-up events. 
Also some window-handling, mouse-handling, etc. I just suggest GLUT 
as a shortcut to have these things. In the final version, when all 
that C code is found for all platforms, GLUT can be droppen again.

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.

A list of all the functions is found here: http://pyopengl.sourceforge.net/documentation/manual/index.xml
Scroll down to see the GLUT functions.

GLUT also add joystick support to some degree across platforms, so 
for e.g. game writers, GLUT is a good library to use.

OK, thanks for info

You're welcome!

It seems to me, that many things, like keyboard, mouse, etc., will 
simply overlap with current implementation. IMO the question is, 
how well internall View si built already, if things in there are 
"chaotic", or layered/abstracted/isolated.

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

In other words, GLUT provides some of the same functions as SDL, 
but with SDL, 3D is optional

we can link to SDL with Core, no? As others do. We can link to VxWidgets, 
if we wish to, no? View is simply yet another gui engine ....

I am not sure we can easily mix those things? But maybe we could 
use some of SDL code? It all depends upon its license ...

SDL is LGPL, so the R3 object files being available as planned is 
sufficient

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).

Cyphre - will there be access to buffer? Or is the OGL the thing, 
which will speed-up blitting, because it uses HW to draw?

IIRC there were planned so called View plug-ins, which would allow 
access to View buffer and plug-in HW accelerated display rather than 
current SW only renderer ...

... I am not strong on gfx, so I might actually confuse things :-)

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.