AltME groups: search
Help · search scripts · search articles · search mailing listresults summary
world | hits |
r4wp | 53 |
r3wp | 274 |
total: | 327 |
results window for this page: [start: 1 end: 100]
world-name: r4wp
Group: #Red ... Red language group [web-public] | ||
Kaj: 25-Feb-2012 | OpenGL | |
Andreas: 27-Feb-2012 | Behold, an OpenGL triangle rendered by a Red/System program: http://earl.strain.at/share/reds-opengl-triangle-20120227.png | |
Andreas: 27-Feb-2012 | (2/3 inline binding code and the rest is very plain OpenGL and, yuck, GLUT.) | |
Kaj: 7-Mar-2012 | I ported a second demo to my OpenGL binding, using textures | |
Oldes: 7-Mar-2012 | Where one can download the OpenGL binding? Don't you want to put the bindings into the Red's github? | |
Kaj: 7-Mar-2012 | My bindings are in Fossil repositories. I haven't published my OpenGL binding yet | |
Kaj: 14-Aug-2012 | 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 | |
Kaj: 22-Aug-2012 | Nice! I've missed that. It will make parts of my OpenGL binding look much nicer | |
DocKimbel: 27-Aug-2012 | 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). | |
DocKimbel: 28-Mar-2013 | 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. | |
Kaj: 15-May-2013 | 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 | |
Kaj: 24-May-2013 | I can't get OpenGL to work on it if you don't :-) | |
Kaj: 28-May-2013 | 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 | |
Arnold: 21-Jul-2013 | directories under red.esperconsultancy.nl are according to the script download.r: 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] | ||
Marco: 18-Sep-2012 | 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) | |
Maxim: 18-Sep-2012 | 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) | |
Kaj: 15-May-2013 | I finally got my OpenGL binding for Red/System in a form suitable for publishing: http://red.esperconsultancy.nl/Red-OpenGL/dir?ci=tip Currently, the only available backend is for PicoGL, which does software rendering with the TinyGL library and shows it through SDL. | |
Kaj: 20-May-2013 | I made an SDL backend for my Red/System OpenGL binding: http://red.esperconsultancy.nl/Red-OpenGL/dir?ci=tip 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 backend. | |
Kaj: 21-May-2013 | I made an OS-Mesa backend on SDL for my Red/System OpenGL binding: http://red.esperconsultancy.nl/Red-OpenGL/dir?ci=tip 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. | |
Kaj: 22-May-2013 | 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 GL-textures. http://red.esperconsultancy.nl/Red-test/dir?ci=tip 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. | |
Kaj: 22-May-2013 | 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 | |
Kaj: 24-May-2013 | I fixed the calling convention for the OpenGL library that's included in Windows, so the Red/System binding works there now: http://red.esperconsultancy.nl/Red-OpenGL/dir?ci=tip I also fixed the binary downloads GL-spin and GL-textures: http://red.esperconsultancy.nl/Red-test/dir?ci=tip | |
Group: Ann-Reply ... Reply to Announce group [web-public] | ||
Robert: 25-Mar-2012 | Yes, not released. r3ogl.exe is our OpenGL based prototype. r3encap is our encapper. | |
Marco: 20-Sep-2012 | No one here can test my new %opengl-glu-glut-h.r on X11? | |
Marco: 22-Sep-2012 | Please, let me insist. Can someone test %opengl-glu-glut-h.r (on rebol.org) on a (real) X11 environment ? | |
Bo: 15-May-2013 | 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 curious. | |
DocKimbel: 21-May-2013 | Kja, nice progress on OpenGL support! | |
Kaj: 21-May-2013 | 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 3D | |
Bo: 22-May-2013 | 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. | |
Kaj: 22-May-2013 | C++ and OpenGL, GLUT I think. Bleurgh | |
GrahamC: 22-May-2013 | Support for OpenGL overlay hardware on both X11 and WIN32. Emulation if none | |
GrahamC: 22-May-2013 | FLTK (pronounced "fulltick") is a LGPL'd C++ graphical user interface toolkit for X (UNIX®), OpenGL®, Microsoft® Windows®, OS/X, and several other platforms. | |
Cyphre: 23-May-2013 | 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. | |
Robert: 23-May-2013 | or use OpenGL directly ;-) | |
Group: Databases ... group to discuss various database issues and drivers [web-public] | ||
Kaj: 4-Jul-2013 | 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] | ||
Kaj: 19-Jul-2012 | 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] | ||
AdrianS: 17-Dec-2012 | 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).. | |
Cyphre: 18-Dec-2012 | 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 issues) 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. | |
Geomol: 22-Jul-2013 | 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 #{ 010203 }] The alpha values seems to be left out. (It might have changed in newer versions.) Setting the pixel will include alpha values: >> i/1: 1.2.3.4 == 1.2.3.4 >> i == make image! [1x1 #{ 010203 } #{ 04 }] 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}] | |
Geomol: 22-Jul-2013 | 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] | ||
Oldes: 19-Dec-2012 | 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. | |
Bo: 21-Dec-2012 | 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? | |
Oldes: 21-Dec-2012 | 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. | |
Robert: 21-Dec-2012 | We did a short test some time ago to use OpenGL, works but is quite some work to implement it completely. | |
Cyphre: 21-Dec-2012 | 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. | |
Cyphre: 21-Dec-2012 | 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) | |
Bo: 21-Dec-2012 | 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 bitmaps. | |
Bo: 21-Dec-2012 | 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. | |
Bo: 21-Dec-2012 | 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. | |
Oldes: 21-Dec-2012 | 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. | |
Cyphre: 21-Dec-2012 | 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 realtime. 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. | |
Cyphre: 21-Dec-2012 | 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. | |
Cyphre: 21-Dec-2012 | 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 separately. |
world-name: r3wp
Group: Ann-Reply ... Reply to Announce group [web-public] | ||
BrianH: 24-Aug-2010 | 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. | |
Maxim: 25-Oct-2010 | 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 | |
Henrik: 27-Oct-2010 | closer to 2-5 fps here, but probably due to software OpenGL | |
Henrik: 27-Oct-2010 | (strange that it runs now, when I was warned before that OpenGL wouldn't work) | |
Maxim: 27-Oct-2010 | wrt resize, yes that is on purpose. it allows me to test events within and without the opengl. | |
Maxim: 27-Oct-2010 | 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. | |
Henrik: 27-Oct-2010 | 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] | ||
shadwolf: 3-Jun-2005 | 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] | ||
shadwolf: 14-Jan-2005 | 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] | ||
Kaj: 31-Aug-2005 | 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 | |
Kaj: 3-Sep-2005 | 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: | |
Kaj: 7-Nov-2005 | 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 | ||
Pekr: 14-Nov-2006 | 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] | ||
Cyphre: 5-Jun-2006 | 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. | |
ICarii: 4-Jun-2007 | 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] | ||
Geomol: 25-Apr-2008 | 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. | |
Maxim: 20-Aug-2009 | REBOL natively Generated OpenGL hardware accelerated graphics. :-D http://www.pointillistic.com/open-REBOL/moa/steel/R3-OGL.png | |
Maxim: 1-Nov-2009 | 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] | ||
Pekr: 1-Dec-2005 | 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)? | |
Henrik: 1-Dec-2005 | 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 | |
Rebolek: 1-Dec-2005 | 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. | |
Maxim: 9-Dec-2006 | 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] | ||
Henrik: 28-Jun-2006 | I was suspecting it could be working over TCP/IP like Geomol's OpenGL library | |
Group: Tech News ... Interesting technology [web-public] | ||
Geomol: 17-May-2006 | 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]: 17-May-2006 | John...cool. Build an X-Windows like layer between Rebol and OpenGL. | |
Volker: 17-May-2006 | 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. | |
Geomol: 17-May-2006 | 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). | |
Volker: 6-Feb-2007 | 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. | |
Volker: 6-Feb-2007 | runs ok here. At least it iis opengl | |
Pekr: 13-Aug-2007 | OpenGL 3 announced - recent news on OSNews.com | |
Pekr: 8-Nov-2007 | Pyglet has sound, opengl link, there is nice asteroid game in 27kb of source! | |
Pekr: 13-Aug-2008 | 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] | ||
Maxim: 7-May-2007 | 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. | |
Maxim: 7-May-2007 | 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. | |
Maxim: 8-Dec-2008 | also will be porting to OpenGL, but the high level coding won't change. | |
Maxim: 27-Feb-2009 | 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. | |
Maxim: 24-Jan-2010 | 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] | ||
Maxim: 2-Feb-2007 | 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] | ||
Geomol: 16-Jan-2007 | 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/ | |
Maxim: 16-Jan-2007 | 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. | |
Geomol: 5-Jun-2007 | Any plans for an OpenGL version with perspective 3D tiles? | |
ICarii: 5-Jun-2007 | when R3 is released and someone writes the OpenGl plugin :P | |
ICarii: 5-Jun-2007 | but ive got a MMORPG to do in openGL before that :) | |
Geomol: 5-Jun-2007 | 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). | |
Reichart: 6-Nov-2008 | 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. | |
Henrik: 23-Jan-2010 | I'm waiting for Maxim to design us all a nice game engine via openGL extensions. :-) | |
Group: Printing ... [web-public] | ||
Henrik: 4-Sep-2008 | or perhaps more appropriate, what OpenGL does for displaying 3D graphics on screen. |
1 / 327 | [1] | 2 | 3 | 4 |