AltME: R3 Building and Porting

Messages

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

MaxV
Bo
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
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
We did a short test some time ago to use OpenGL, works but is quite some work to implement it completely.
Cyphre
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.
When it comes to shaders, that means my 8 years old notebook won't be able to render it :-)
Also note that on Android for example the Canvas class (which is comparable to DRAW) is still not HW accelerated AFAIK.
I guess same is on iOS....the "draw' api is also not using GPU
The HW acceleration is still currently mostly used only for moving textured bitmaps...kind of fast blitter in the 2d graphics area.
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)
But good news is some people are experimenting with shaders to created 2d oriented engines but until the main players on the market won't set some standard it can still take lot of time.
NickA
MaxV, I made a couple tiny edits to clarify https://github.com/hostilefork/r3-hf/wiki/Building-from-source-on-windows-with-mingw .  I hope that's ok.
Bo
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.
Cyphre
Yes, that's actually the method I'd like to upgrade the View engine...but not only for DRAW. The code would be modular so you can render to textures using any other library if you want.
I believe the Android porting effort will show us what is the optimal solution. It is good to find a balance between highly optimized but not much compatible HW engine and smoething that is fast enough and can be ported without big pain.
Bo
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.
Bo
I toyed with the idea of writing a C-based dll that could take all the information for rendering an entire data structure from R2 so R2 would only have to make one method call to a dll per frame instead of thousands, but couldn't get enough higher priority items off my list to get started on it.
Oldes
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.
But of course, it's not an easy task. One must be careful to make it right.. all the draw command batching, texture packing etc.

Last message posted 272 weeks ago.