AltME groups: search

What I would like to look into is the possibility of speed-up of 
GUI refresh. Not 3D based GUI, just a refresh/rendering/blitting 
- whatever is possible. Cyphre told me, he has general DLL, which 
allows to accelerate even R2 faces ...

IIRC there is a standard called miniGL which is a subset of OpenGL 
specificaly designed for smaller devices... it should be compilable 
on anything, even if you don't have hardware 3d AFAIK.

OpenGL really is on every serious OS in any case, and the standard 
is very well supported, so that if you target a minimal version of 
OpenGL, your app will be pretty much the same on every OS...

gfx will be a little different pixel wise, but not enough to really 
be an issue, especially if you take a few precautions.

I thought that it is a "standard", so that everything is supposed 
to look pixel precise on all gfx cards, whereas it seems the situation 
is like with browser - they differ in details ...

but my OpenGL extension is not to replace view.  Its for gaming, 
and a totally new GUI experience...

i'd like to target QNX as the kernel but their gfx hardware support 
isn't too good... so its probably going to a linux kernel... but 
without anything else than the HW driver and most basic kernel stuff.

I've got impression, that OGL is slowly dying, and feature lacking, 
in comparison to DirectX?


I don't see that. All *NIXs use OpenGL. OS X GUI is based on OpenGL. 
Playstation 3 use OpenGL (PS1 and PS2 used a proprietary Sony API).

From http://www.opengl.org/

The Khronos(TM) Group, today announced OpenGL(R) 3.2, the third major 
update in twelve months to the most widely adopted 2D and 3D graphics 
API (application programming interface) for personal computers and 
workstations.

It seems, OpenGL is growing.

yess which only a minority of HW in the world support...  since its 
blocked via VISTA.

Maxim wrote: "gfx will be a little different pixel wise"


Do you mean, 2D graphics will look at bit different, if using OpenGL?

AFAIK 2D on openGL is just the fact of using a flat camera (orthogonal 
perspective) with a camera looking straight down.

When using a Mac, you look at an OpenGL output. If you use the zoom 
function, there is a key combination to put anti-alias on/off. If 
it's off, you see the correct pixels, as there is in the drawing 
(bitmap). But you're right, if you put in anti-aliasing and other 
effects, it can look different on different hardware.

some details like the coordinate precision and various occlusion 
optimisations, being done differently can affect the output... like 
if you superimpose two polygons with the exact coordinates... some 
cards will remove one of the polys... others (most) will cause pixels 
to shift from one poly to the other everytime you refresh... causing 
a very annoying shimering.

It is? :-) I thought, AGG did a pretty good job.

I've never seen a single font which didn't have at least a single 
letter which was grossely mis-AAed.  often its the s, the o, or the 
e..... they stick out in every word and its annoying.

in any case, when you build a GUI with OGL, you build in such a way 
that everything scales, cause its sooo easy to do... its in fact 
free... like AGG.  so the fact that a GUI isn't exactly pixel perfect 
is secondary... since often you don't even have the same fonts on 
various OSes  ;-)

That's also the reason why I'm not a fun of scalable GUIs.

true type and the ttf lib are pretty much on all OS nowadays... its 
just a question of having the right to distribute a font with your 
apps... which in theory is the same issue with flash I would guess.

there is a big difference in how flash and AGG render their stuff.... 
it seems to me that AGG is actually more scalable in sheer quantity 
of strokes, whereas flash seems to be much better at handling textures 
and bigger screens... have you noticed the same reactions... having 
much more in depth knowledge of flash, I'm curious as to your observations....

I wish all those decisions where available to the programmers... 
often I have been bitten by these decisions in REBOL...  I plan to 
allow as much control to the Low-level stuff as possible with my 
OGL extension, even with the toolsets I'll build using it, I still 
want to allow the capacity to edit quality & quantity based-decisions, 
probably by providing a standard gfx setup requestor available to 
all applications of rogle.

this way developpers won't have to build their own, its going to 
be built-in and not require a "restart" of the application.

Pekr no sound yet, but can be written using extensions probalby. 
I was thinking more in twerms of creating the soundstream for later 
use than actually playing it from R3 (at least right now, as a first 
step)

in theory, you could replace the main loop if you want, if we have 
callbacks in extensions, the main loop can be handled from an extension. 
although its not like having it close to the core, where it can be 
smarter...


but if a callback can see if some events are waiting on a list of 
event ports (something like event: wait [ port 0] ), then we could 
use whatever timer/window events and fire from there....  the rogle 
extension includes GLut which already has its own (precise?) timer 
internally, but it can't trigger rebol code *yet*. so right now I 
have to handle all events in the C side :-(

Sounds like a good idea to me. I would get devices working asap...

knowing how smart you are this shouldn't take you more than a few 
hours the first time... and then a few minutes for following libs 
 :-)

the advantage is that you are able to use the dlls in their native 
and have access to ALL of their code (C++ isn't working as-is yet, 
but is theoretically possible, with a few tweaks to the extensions.h 
stuff)

is there any example creating a extension connecting to  a external 
system library? , e.g. using api calls with nested structures, pointers 
etc.?

you can simply do a block to struct conversion within the C layer.


the extensions docs show how to read and create new blocks, with 
working examples... you just need to continue from there on.


googling how to connect to a dll in real time will give you examples 
in C, but many dll's which are distributed as tools also come with 
their equivalent static .lib files so you might not need to do a 
run-time link to the dll.  OpenGL, for example came with both.

hmm, wouldn't REBOL's object better represent a struct? Do we have 
API to access object btw? The trouble is, that the object member 
might be for e.g. a function, but maybe it is not problem at all? 
:-)

no objects in extensions...  


I was just thinking yesterday that a struct type in R3 could be a 
good idea now that we have extensions.  Carl could wrap it up quickly 
since structs only store and align data, no rebol code.


but I think I'll build a struct <-> block set of tools in C and REBOL 
for extensions in the meantime... this will be handy for sure.

thx for the info pekr & maxim. 

I thought that extensions will easy unlock the power of ready to 
use C libs/sources. 

but building wrappers on wrappers is the same like layers on layers. 
annoying... 

well, I am using rebol exatcly for this reason to escape from this 
paradigm! 

on the other hand there is a good change that I did not understand 
the power 

of extensions right now. building my own libs in C to speed up things 
is fine 

but easy use and access of precompiled libs or open sources (and 
there are many fine pieces out there) 

are much, much more important in my opinion. A swiss knife like rebol 
should be able 

connecting easy to as many other tools and components as possible.

I would wait a bit - maybe someone builds some R2 kind wrapper as 
an extension, so that producing extensions is easier :-)

yes, I will be doing that first thing after my current project is 
done.   I will be looking into SWIG, maybe I could use all of its 
advanced C language parsing capabilities and just add a REBOL export 
module to it  :-)

tombon:  the thing is that rebol has to map its datatypes to the 
basic and static data representations of C and other compiled languages. 
 the R2 tried to do this within rebol, but it ended-up being useless 
for many libs which used types that rebol cannot translate natively... 
like unsigned integers or single precision floats, arrays... etc.


extensions do the rebol datatype conversion in the C side, so that 
it can directly map ANY C code to a form that rebol functions can 
understand directly  and vice versa... so for now we could use blocks 
as an interface for structs, even though R3 doesn't understand anything 
about structs.  :-)  


Its MUCH faster to map in C and makes the lib completely integrated 
into REBOL when used.


So for example, we can use tuples as colors within REBOL, and the 
DLL's functions will be called with a struct  or an array, to map 
the 3 channels.

I expect Extension to be a (cool) addition to REBOL, not a replacement 
for the /Library component. Even if limited, /Library is a very useful 
and working feature of R2. /Library allows to interface with most 
of OS API without having to code in C. This is a productivity advantage.

I always thought that it was easier to write REBOL code than C code. 
Extension would require a C compiler that will generate an additional 
DLL (times the number of OS to support...). I looks to me more like 
a regression compared to R2 if /Library get trashed in R3 (unless 
someone provides a similar interfacing system). 


SWIG is huge compared to /Library. Having to provide the C header 
files is not always convenient compared to just declaring a routine! 
from online API documentations (like e.g. MSDN). I would prefer to 
keep having /Library in R3 for fast and handy OS interfacing, and 
the ability to build my own Extensions for cases where it's not enough.

It is easier to use REBOL code once you've written it (due to compiilers 
and such), but whether it is easier to write it depends on various 
factors. In the case of /Library, the data model was a weird subset 
of a union between the C and REBOL data models, and simply couldn't 
easily handle many C-compatible APIs, and no APIs that weren't C 
compatible (C++, Delphi, Java, Objective C, ...). Extension wrappers 
are actually easier to write than /Library wrappers, and will eventually 
be able to do much more. Of course, once they are written, your criticisms 
apply.

I've used the R2 /library often and a part from mapping a few of 
the simple windows MAPI functions, I've never gotten it to do anything 
usefull and fantastic because there are simply so many discrepancies 
in types... callbacks crash notoriously and things like arrays and 
pointers are fudgy at best.


A part from the suggestions above, it is ALSO possible for us to 
build an extension which does dynamic library binding on the fly. 
 But that will require a bit more research to get working.  basically, 
we could build an extension which mimics and improves the /library 
system.

Max said "with callbacks (devices?), there is no need to keep bugging 
Carl about A LOT of things people keep complaining about.  :-)" - 
my question is - how callbacks/devices allow you to plug-in different 
scenarios into REBOL?


Let's take multimedia timers for e.g. AFAIK, events are part of Host 
code, not a device. So how can you e.g. create device, which allows 
you to replace inbuilt timers?


OK, maybe timers are not good example. We have networking being done 
as a device. Can you easily replace REBOL's built in networking device 
with your own one, to try some different networking aproach for e.g.?

yes... the DLL will trigger code based on how its hooked into the 
OS.... so if you used multimedia timers, they will trigger when you 
ask them to.  if we have callbacks, then Rebol code can be run as 
a consequence of that trigger.


tcp sockets use triggers to tell you when connection, data, etc occurs... 
you could very well use C sockets directly by opening a lib and calling 
its funcs... I don't know if the fact that the rebol task already 
opens up a tcp socket lib would cause some interference, its quite 
possible that it would work.


DB drivers often use callbacks for the "response" aspect of DB requests 
since most well designed DB interfaces should be async.


Events & callbacks simply allow applications to live in the wait... 
and be asynchronous in nature.  its the "better" model since it means 
the task is never busy waiting.  There is a large effort in the linux 
world to make every app behave "properly" in this regard, and its 
a good thing... if every app is silently waiting on triggers, the 
whole system has a significant boost in responsiveness.

the OpenGL,  GLut lib, for example, has its own windowing system. 
 so any application can VERY easily create OpenGL apps which respond 
to keyboard mouse and window events.  its ported on all OS, so your 
code runs just about the same everywhere.


If R3 had callbacks, my OGL GLass engine will be ported to all platforms 
without any extra effort.


GLut might not have all the fancy events (I haven't gone over it 
in detail) but its a good basis to develop, being so easy to use.

ComLib: Using it quite often to control XLS. I hope to find the time 
to bite-the-bullet and givetti a try with a R3 extension. The current 
ComLib is good but fragile.

Overall R3 should have a /Library interface. IMO adding a way to 
Rebol so that more c-ish datatype can be handled would make life 
a lot easier. And of course, provide a way to handle callbacks. Maybe 
via a proxy stub on the C side that transforms these callbacks to 
TCP socket requests.

I actually will give this engine a look, its ported to all 3 platforms, 
and can render over OGL OR Direct3D which is pretty nice.

Ogre3D is the probably the best open source 3d rendering engine there 
is .. I followed it's path a long time..  his simpler "follower" 
is irrlicht .. maybe there are some new ones now I am not sure , 
since I am not actively following this area any more

thanks, will look it to it too... although I have anidea for the 
ogre...  using "." for the member separations  :-)

ex: Ogre.FreeImageCodec.startup


all the extension has to do is wrap the call to its proper class 
path.   I would also have to build a struct/class lookup mechanism 
(which is the hard part)

I'm also thinking that I could build a flat C SDK for Ogre which 
would make its integration into R3 much simpler after... basically 
storing stucts and pointers to things internally and using a few 
simple and fast generic scene query calls.

yes, ogre is really "topnothch" .. maybe you could reuse, maybe the 
ones who made python/lua/... bindings already made a c overlay

ah good idea.. will see their approach as a reference for mine.

but also quite a task .. maybe you could geenrate rebol binding or 
part of it from some othe binding programatically .. I know some 
folks did something like that for GTK / WxWidgets from haskell to 
ocaml

and the actuall download isn't insane... it ~45MB.  for a full-featured 
cutting-edge 3D engine this is very small.  We have to remember that 
3D and image aren't just functions, they actually require data which, 
because of the array aspect of them, requires a lot of memory... 
so I am thinking that a large part of the 45MB is in fact source 
data which is needed, in order to populate the actual scene.

yep, programmatically binding the engine is what I plan to do... 
especially since it will allows us to rebuild the binding at any 
moment just by flicking a switch and update it without any user-intervention.

so far, my options are:

 -a direct wrapper generator coded in REBOL using C++ sources, with 
 an advanced  C++ declaration to R3 Extension converter, 
	-I try out SWIG build an R3 extension output module for it, 

 -I use another language binding as the one to base mine with, and 
 make a specific tool to convert it to an R3 extension.

 -do a manual (and painfull) convertion, using a few generic scene 
 interaction commands.


One thing I'd like, is to add some way for the OGRE extension to 
be able to call REBOL code directly via callbacks, using their Extensive 
hooks throughout the api.


Although this will be slower than if the callbacks where in C, obviously, 
some parts of REBOL are swift enough (like series management) that 
they just might make the cut for REAL time rendering hooks.  Well 
implemented, they would be fast enough for common GUI interaction 
events for sure.

very cool, as I said this is not a minor task but if you do it it 
will be very awesome!

GLASS is a general purpose GUI using advanced dataflow programming 
at its core.  I've got some prototypes of various pieces of GLASS 
using R2 and AGG which work really well, but I've been waiting to 
be able to do HW gfx before Investing time on the real GLASS, which 
integrates the prototypes and new stuff too.

(Oops).  Max, I experimented with OGRE in Purebasic a few years ago. 
 Frederic Laboureur built a very nice interface to it, which comes 
built in native to Purebasic.  He'd likely be a good person to chat 
with, and he's very active on the purebasic forums...

noted  :-)  I'm starting to really look into this right now... taking 
a break from my "serious" programming.

will start by playing around with the C++ stuff, basically building 
a simple scene.... when that is working, I'll try to build an extension, 
allowing me to do the same calls via R3

what is so special about the Ogre? Just a 3D engine, no? Is it used 
mostly for games? What would you use it for?

programming for a 3D rendering engine and for a scene engine is a 
totally different affaire... just like using DRAW vs using AGG directly.

its a complete hardware abstraction, so the exact same code will 
run under any hardware/OS implementation.

On the other hand, I've never met anyone who went back after giving 
a modern DVCS (which means mostly Git and Hg) a serious try.

So, to mark an official release, like A110, is it only necessary 
to commit with that message, or do we need to make a tag as well?

I would suggest adding a tag as well.

A tag is a minimal object in git, just pointing to a commit.

I'm running out of questions. (A good thing.)

Those in-between dashes have a tendency of getting dropped or replaced 
by spaces or worse. So it's basically an attempt to preempt this 
:)

Now someone should really write some short docs. This is so complex 
and surely was not created for normal mortal, who just wants to download 
few source files and build a distro? So I downloaded Tortoise Git, 
naively thinking this is all I need. No, so I installed Git preview 
version (not full msysGit). Now - what should I do? I created a directory 
called host-kit, right pressed mouse, and chose "create repository 
here" or something like that. Now once again I press right mosue 
button, and try either git-clone, or Git sync, but it does nothing 
... I think my problem might be (apart from being too dumb and not 
willing to spend tonnes of my free time with such complex stuff):

- I am required to have some kind of account at target site

- I don't have it somehow linked with SSH stuff (did not choose to 
use my putty installation during the installation phase)


How do I get the actual copy of R3 Host Kit? There might be plenty 
users as me, willing just to download recent sources, and build, 
not to commit anything ...

You shouldn't need to create and init a repository first.

From the explorer extension, choose a folder into which you want 
to place the hostkit folder. Right click, tortoisegit, clone, enter 
http://github.com/rebolsource/r3-hostkit.gitas url.

IMO Sync is just a shortcut - green icon shows from master to client. 
In main context menu, I can seee - Sync, Commit, TortoiseGit in the 
main context menu git section

Andreas, I'd like to assemble a doc for git github access. Just a 
rough draft, if I can get your comments.

http://www.rebol.com/r3/docs/git.html-- just a starting point to 
add to

I would add a note that getting a Git version >= 1.6 is strong recommended.

(The CLI has improved quite a bit in 1.6.)

The official site for Git is http://www.git-scm.com/(if you want 
to add a link).

Has a list of download links on http://www.git-scm.com/download

Sounds good.. each platform will branch/fork and make their changes, 
the merge will be controlled by REBOL.. just need a way to notify 
that a merge is pending.. I suppose a CureCode ticket would be OK?

Yeah, CC will certainly be a good start.

Is there a convention for user.name?

Andreas: sounds like a plan :)  we can test this out once the a110 
baseline has been established as Carl indicated

One step at a time :)

I don't know. I can try changing it to see if it cleans up. 


Was going to add config notes to rebol.com git page but can't remember 
docbase login procedure. I know I have a docbase account but I seem 
to recall two levels of login are required or something.

I am lost in a sea of logins and channels.

Carl, two resource links to add:
http://gitref.org/
(One of the best currently available tutorials.)
http://progit.org/book/
(Has the full content of a good, published book on Git.)

A: got it. updating.

Yes, when the server restore came in, once you got a PM, all your 
old PMs went away.

It's a button to the right of the repository name.

And add a link to http://www.git-scm.com/downloadinstead.

I thought about putting libraries for all platforms in a directory 
structure below lib/ .

This is a temporary test area for the release... until we get it 
how we want it.

Andeas: take a look at R3A100, and let me know your comments. There 
are some issues:
1. how best to handle the libs dir for multiple platforms?
2. should we merge the makefiles into a single dir?

Sounds like a good idea.

1. The easiest way for now will probably be a directory hierarchy 
under lib:
lib/1.3/libr3.so
lib/3.1/r3lib.{dll,exp,lib}
lib/4.2/libr3.so

It's not the final location. It's a test, to get feedback on the 
layout of the source files before we release to the final location.

You can pull from multiple remote repositories into a single local 
repository.

Pekr, there's no need to purge, but it is a good idea to do that. 
 There have been various changes, some of which will not merge properly.

Andreas, it is easy to move the TO-* to the command line.   It was 
originally put in a file to try to keep the gcc line shorter (easier 
to see compiler warnings.)

The goal of the current R3 build automation method is to save my 
time.


Currently, the platform table is only ~10 lines of REBOL, so it is 
difficult to beat using any other method.  And, even with the detection 
approach you mention, you need still tables.


However, that being said, if you want to create and test such a detection-based 
method and confirm it works over a range of OSes I would be happy 
to use it!  It must handle Linux, Syllable, BSD, OS X, Solaris, Windows, 
AmigaOS, Haiku, QNX, and various others, and also work for systems 
ten years old or more.

I'm open to any idea like this... as long as it saves *me* time.

I can't test it myself on most of those systems, but I'll keep the 
idea in mind when digging further into the host kit. There are a 
few well known configuration systems that are much too bloated to 
use, but that are good sources to collect the tests needed on systems 
that I don't have

It's currently not a big deal, but it would be nice to eliminate 
the manual configuration requirement