Horde3D

Hi,

I wonder how one can determine what OpenGL shading specification is used. This mainly because I've read about the release of the release of OpenGL shader spec Version 4.0 (see http://www.opengl.org/registry/doc/GLSLangSpec.4.00.8.clean.pdf), which should be the match to DirectX11 (according to humus http://www.humus.name/index.php?page=News&ID=304).

What is necessary to compile different OpenGL Shading spec versions? Capable hardware drivers? Or is it necessary to patch Horde3D?

cheers

_________________
philipppixel
8=:(=)D { Save the Giraffes )

Usually, you can specify for which GLSL version your shader is targeted using the #version directive at the beginning of the shader. However, many features like constant buffers need support code on C++ side which means that horde would need to be extended.

Hello,

For the long term its IMO not viable to stay at the current fixed function + extensions only, it will handicap performance and capabilities too much (if these aspects are of high priority that is).

For new game projects its often ok to target the current higher end of APIs due to the fact that when the product is ready in 3+ years its the norm anyhow.
Its crucial to know if the overall priorities and goals of an engine fits yours before investing too much time in it.

What are the plans regarding opengl API in Horde 3D ?.


regards
gustav

There is actually pretty much no fixed-function rendering left in Horde - the developers did a good job of stamping it out.

At this moment in time, there is also no performance or capability benefit to be had from using OpenGL 4.0 as opposed to OpenGL 2.x + extensions. All OpenGL 4 features are available as extensions to the 2.x series, and the 2.x drivers are still far more mature.

_________________
Tristam MacDonald - [swiftcoding]

Being "available as extensions" is _hardly_ the same thing as having an engine desgined to per default take full advantage of it, you (should) know that !.

Who cares about the shitty history of opengl driver quality ?. Hardly a man that plans for the future instead of being stuck in the past.

Its nothing wrong with being focused on legacy hardware support but thats hardly in line with a "next generation " theme.

There are other engines around where people have some sound technical reasoning involved in their design and hence realize that you cant have the cookie and eat it, so their current design is only opengl 3.2/3.3+ compatible.

You misunderstand my intention.

Fully half of our prospective userbase doesn't yet have the possibility of OpenGL 4.0 - we still need to wait for stable ATI drivers, and of course Mac will lag behind (though that is lower priority). In addition, NVidia has only made OpenGL 4.0 available on DirectX 11 cards, which restricts its usage to the handful of people who have managed to get their hands on a fermi card.

If we want to move Horde's baseline requirement, a sensible target for the near future would be OpenGL 3.3, which brings a large portion of the OpenGL 4.0 functionality, without eliminating all existing graphics cards from the support list.

--

Also worth mentioning that development of Horde is not as rapid as it used to be - both of the primary developers have additional concerns to occupy their time. I don't think that there is a concrete plan for a major API upgrade at this moment in time - various other goals are still at a higher priority (i.e. abstracting out the underlying rendering API, eliminating the scene graph, etc.)

_________________
Tristam MacDonald - [swiftcoding]

If you've got a 3-year dev-cycle, then that's plenty of time to replace any 2.x extensions with the equivalent 4.0 core functions
Should only take a month for a (full-time) graphics programmer to port a back-end...I haven't done any OGL programming for a while so forgive me if this is a stupid question -- Besides the ugliness of the code, is there much difference between calling a function via the extension mechanism or via the core? On windows you get access to the functionality by looking up a function pointer in both cases, and most of the new 3/4 stuff has equivalent extension on 2, right?
Don't get me wrong, I'm not anti-GL3/4... I'm just curious why you're being so aggressive about this switch?no need to be insulting; you haven't even gotten an 'official' response yet and you're getting personal...

OpenGL 3 has a few nice things which would make life a bit easier (e.g. d3d coord conventions which are useful for DDS or floating point depth buffers). Using those and some of the other new features is easy, it does not require a redesign of the engine. Other more fundamental things like instancing are mainly useful for specific cases like vegetation rendering. Our current strategy is to use a GL3/D3D10 "style" (e.g. no fixed function, very little deprecated functionality) but with the subset of GL 3 functionality that is still supported by GL 2.1.