Convert MiniB3D to OpenGL 2.0? Thoughts?

BlitzMax Forums/MiniB3D Module/Convert MiniB3D to OpenGL 2.0? Thoughts?

ima747(Posted 2011) [#1]
I'm interested in what it might take to convert MiniB3D to run on OpenGL 2.0 instead of 1.x. The reasons are this:
- OpenGL 2.0 is the new standard. It's going to get more love from hardware and software vendors in future, to the potential detriment of 1.x since it's not backwards compatible.
- It can run in threaded environments much better to my knowledge, this opens lots of fun doors.
- Should make shader support easier I would assume...
- If ported into iMiniB3D it can leverage some of the higher end hardware in newer devices, add shader support etc.
- Ported into aMiniB3D it would make testing MUCH easier since the emulator actually supports OpenGL ES 2.0... also lots of new bells and whistles. Android is thread crazy so it could make life much easier as well.
- WebGL is OpenGL ES 2.0 based so it could be ported to WebGL which is rapidly gaining traction (won't be a serious tech for a while still IMO, but it would be great to be ahead of the curve...)
- If it works on all the above platforms it could be ported to Monkey for some cross compiling hotness including web... Personally I think that would be about the most awesome thing ever.

So. Does anyone have any thoughts on where some of the pitfalls might be? I know a few of the OpenGL functions would have to be replaced, likely more stuff along with them. Probably the whole rendering que would have to be re-structured since it wouldn't be the linear render trigger like OpenGL 1... I've learned what little I know about OpenGL by tearing down and re-building MiniB3D so I'm obviously not well versed in just how 2.0 works besides "differently"...

Any thoughts, comments, suggestions, resources etc.?


AdamRedwoods(Posted 2011) [#2]
Naturally, I'll chime in here:

I have ported openGL to monkey, and have begun to tackle miniB3D->monkeyGL. A big task, will take a lot of time.


OpenGL 2.0 is mostly shaders, seeing how commands get deprecated. So if there would be ANY compatibility with lesser opengl, you would to create those functions (for future drivers) that don't support anything less than opengl 2.0.

That said, it's pretty easy, but requires a lot of external shader programs for different things you want to do. And if you want the basic functionality of the fixed-function pipeline, you have to write that shader (or find one lying around).

That said, I've been progressing on the TShader extension and I like where I'm headed. It is a great beginning to get miniB3D into the 21st century, and *theoretically* could be used to completely bypass the fixed-function pipeline, but still retain backward compatibility.


ima747(Posted 2011) [#3]
That sounds excellent, and if I follow correctly the largest part of the transition would be recreating depreciated functions from 1 to shaders under 2. If that's right it seems like a fairly straightforward process to evaluate what's need to build up the current function set of minib3d. Doing so would probably make sense to build in a shader extending aspect above the current feature set like you're doing in the other thread...

Hoping I can find some time to dig into this a little in code at some point...


Difference(Posted 2011) [#4]
AdamRedwoods wrote:
.. and have begun to tackle miniB3D->monkeyGL. A big task, will take a lot of time.


It is a big job and much appreciated.

Maybe you should check out the excellent Warner engine too, because it is:

-Quaternion-based
-Uses Ints instead of Short for triangle indices
-Abstracted GL functions, makes it easier to port.
-ROAM Terrain
-Loads B3D files with up to 8 bones.
-You can manually add bones
-Manual animation functions (SetAnimKey/AddAnimSeq)


http://blitzmax.com/Community/posts.php?topic=94606

http://code.google.com/p/warner-engine/downloads/list


Yasha(Posted 2011) [#5]
recreating depreciated functions from 1 to shaders under 2


Just make sure you do a thorough check to see if someone's already done this! (Frankly I'd be surprised if they hadn't.)

If that's right it seems like a fairly straightforward process to evaluate what's need to build up the current function set of minib3d.


Aren't there only about two classes that even use OpenGL? As I recall, most of miniB3D uses its own secondary abstraction for everything. It strikes me as a good thing to have inherited a largely API-agnostic design, and something worth preserving.


ima747(Posted 2011) [#6]
There's OpenGL spread around but yes it is largely agnostic. The data is generally stored in generic constructs and then pushed to OpenGL during the rendering pass, but because of this the rendering path is structured around the way OpenGL data gets pushed to be rendered...

The math of object manipulation is all outside of OpenGL. As a result loading meshes etc. is largely independent on OpenGL, etc. Textures are a bit muddied in that regard since they are loaded into OpenGL, but there is a MiniB3D layer kept to reference them and control other aspects related to the actual texture data...

This is why I think it should be possible. without *too* much work to make an update/port to OpenGL 2 possible. A lot of the heavy lifting doesn't involve OpenGL so shouldn't have to change, just things related to the rendering process, and as stated above, if it's largely just shaders replacing existing OpenGL 1 methods then it should be (conceptually anyway) a simple process of finding/writing replacements and slotting them in...


FBEpyon(Posted 2011) [#7]
ima747:

I'm working on this as well, but I'm going to convert it to OpenGL 3.3 as that was when they started to standardize the Shader versions (#3.3 and #4.0) and I would think it would be better to try and go higher then sticking with the older platforms..

Also OpenGL got rid of the built-in matrix functions and I'm working on adding that into the system as well (minib3d should have its own math3d), and I was looking at AndrewT Martix Functions in the Code archive, and see if there better than what we have now (if you know of any hit me up)..

William Mc (FBEpyon)


ima747(Posted 2011) [#8]
Glad someone else is interested :0)

The reason specifically I'm interested in targeting 2.0 rather than later versions is that *almost* every device, and new tech (such as WebGL) is based on OpenGL ES 2.0 which is based directly on OpenGL 2.0. So targeting 2.0 means it's easy to port to basically anything, desktop, mobile, embedded systems, web, etc. Newer versions of OpenGL have poor or no support on older systems, and to my knowledge no mobile platform support at all making them really only suitable (from a distribution standpoint) to top tier PC games which are really easier to target with a more specific engine that would include more features out of the box.

My goal is ultimately to get MiniB3D supported universally so that a project developed on any platform with MiniB3D becomes comparatively easy to port to any other while still running natively and taking more advantage of the available hardware (i.e. building in shader support would be a bonus that would be essentially mandated by 2.0 support).

I don't see MiniB3D as a competitor system to say Unreal Engine. It's just never going to be optimized enough to compete on a performance level with a top shelf commercial product. But it's strength is in the fact that it's INCREDIBLY easy to get off the ground with, and that you can cross compile with it to multiple platforms. Going an extra step you can then rebuild a project for iOS (and Android to a lesser extent). I don't want to wrestle with unreal. I don't want to have to have 30 people in an art department to make meshes and textures. I want to make compelling games quickly and distribute them with ease. That means sacrificing some performance for massive gains in simplicity and portability. I suspect that switching to a 2.0 base, and modern hardware's support for shaders would probably result in performance gains over the current 1.x core, which would be a nice bonus...