OpenGL Status?

#1 Oh but from what I've heard no features in TGEA were "promised" they were simply "announced as part of an ongoing development process" or some such.

Sorry just a little frustration coming through.
[/bitter]

#2 Aye, I can understand the frustration. I was more than upset when I saw TGEA being released to the masses without OpenGL. Originally (and when we bought in to it) it was slated to have OpenGL added prior to the last phase (which I think was phase 4) and before the final release. (I've kept all the printed material and keep even the employee comments I run across *after the fact* when they mention OpenGL's continued inclusion.)

Sadly most of the people I work with are pushing hard to move to another engine but in all honesty the support and resources available via the forums and such on GarageGames does make a huge difference from a programmer's perspective. But my artists, story editors and other business partners are pushing hard and I've had so much fun working on this engine simply because someone has tried or is trying something we are wanting to do.

#3 Well, in my opinion, TGEA is still in Beta (or EA). Yes, they "released" it but the feature set is so vastly cut down I think it hardly resembles what GG originally had in mind for its full release.

#4 Yes I think we'll see OpenGL - personally I don't know why bother with DirectX.

But hey, OpenGL will come :-).

#5 GG had no option but to left OpenGL out for the time being.

It would be pointless trying to add OpenGL support to TGEA right now because it would need to be completely rewritten once the new OpenGL releases are out, since it's well know they'll change the API this time around.

As it is, render to texture in openGL is still a pain the the ass, and TGEA relies on it for a bunch of effects. DirectX implements it a lot better with render targets, which are widely supported by nearly all DX7+ GPUs, without the need to implement two or three different methods and swap around depending on the compatibility like you need to do in OGL.

#6 Reasons why GL support isn't here:

1) GL just wasn't there at the time, and it was remarkably difficult to keep tabs on what vendor supported what (it still is difficult actually). As such, there was no easy way to say "Oh, hey, this will work a month down the line".

2) OpenGL did not have a crossplatform solution for render to texture until December 2005. Personally, I greatly prefer FBOs to D3Ds render targets. However, the IHVs decided that there were not enough GPUs from the fixed function era to bother adding FBOs to those drivers, so FBOs are only supported on the FX 5200/Radeon 9500 or better. Incidentally, the difficulty in getting a render to texture extension done (it took four years) was one of the main catalysts behind Longs Peak, the next version of OpenGL.

3) OpenGL just isn't as nice and crossplatform as we would all like. The IHVs either don't know about bugs or don't care (believe me, there is a lot of not caring going on), thus every driver has its own set of quirks which must be worked around. There are a fair number of hacks in my Modernization Kit which I had to put in to work around driver issues between nVidia/ATI and OS X. I don't even want to think about what hoops I'll have to jump through for a Linux version.

4) GL is not going to fit too nicely into how GFX does things. It'll be possible, sure, you'll just see some interesting workarounds here and there due to the smaller differences, like tracking texture filtering in the sampler state(GFX) instead of in the texture object(GL).

5) Things like render to texture and shaders are only crossvendor/crossplatform on the FX 5200/Radeon 9500 and better.

Reasons not to wait to do a GL port:

1) OpenGL had a high level shading language for a full year before TSE was announced. OpenGL 2.0 was released less than three months after TSE was announced. At this point in time GLSL has been put through its paces and is a reasonably mature shading language.

2) You can use Longs Peak side by side with OpenGL 1.0 - 2.1

3) If you write the GL layer with Longs Peak in mind, then 90% of the code could be copied and pasted. The remainder of the port could probably be done by a perl script.


There are other reasons, of course, but this should provide a nice general overview of why GL support isn't in TGEA.

#7 Nice post Alex. (btw, after the modernization kit, you should be considered the highest OpenGL authority on these forums by now).

Well, the way I see it the situation is becoming more favorable for TGEA OpenGL support as Long Peaks approaches.

But something keeps telling me that we'll not see OpenGL side by side with Direct3D as a renderer pref. I suspect OpenGL will be used in the OSX and Linux ports only, making each port use a single API and saving themselves of the hassles of supporting multiple APIs in a single package (#defines FTW?).

I may be wrong, but IMO the nastiest things to port to OpenGL would be the whole shader generation and parameter code. They are radically different and modifying GFX to be API agnostic in that regard would require lots of work, unless GG used Cg, which isn't ideal.

#8 Oh, making the shader stuff API agnostic is rather easy. The MK's shader interface is API agnostic, and it would be rather simple to implement a D3D shader class in the MK. The trick is the shader interface must be built around GLSL, as it has the most demanding API. Then all you need is a bit of parsing and some padding on the parameters and you're good to go. This is how the MK deals with ARB_*_program shaders, whose API is very similar to D3D's.

Shader gen would be a bit more challenging. The main issue with shader gen is not getting a GLSL version running, it's keeping the GLSL version concurrent with the HLSL one. Not many programmers are going to be willing to port their changes to one shader generator to the other.

Having a separate GL version of TGEA would make things rather difficult on users and on GG, and I doubt they'll go down that path.

Oh, and I'd rather see no GL version than a TGEA that uses Cg. I have rather strong negative opinions of Cg. nVidia appears to share them, if the fact that FX Composer 2 and NVShaderPerf 2 don't support Cg is any indication.

#9 So, is your work on the MK for TGE an "equivalent" to what GG wanted to do with TGEA? Could the MK conceivably be used as a basis for implemented OpenGL in TGEA?

#10 No, my work on the MK is exactly what GG did not want to do with TGEA. The MK is a quick hacked addon to TGE to quickly give it shaders and other such shiny things. TGEA has a completely rewritten renderer designed to work well on modern GPUs, along with the other shiny (including, but certainly not limited to, 3D textures, cubemaps, vertex buffers, autogenerated shaders, you get the idea). There is no comparison between TGEA and the MK.

#11 Ok, so the MK for TGE should be considered a "quick fix" for anyone wanted shader functionality without moving to TGEA?

#12 I can completely understand that GarageGames wanted to wait on adding OpenGL to TGEA. Alex has done a great job of summing up the reasons as to why it wasn't included. I'm not anywhere near good enough from a graphics programmers perspective to say I fully understand but from a generalist programmers standpoint it's obvious that OpenGL was delayed while certain features developed more fully with the OpenGL community. GarageGames took the opportunity to release a decent program without it, adding in the caveat that OpenGL (among other things) would be included at some point.

What I have yet to see is GarageGames make any public statement besides a few "angry" comments in reply to others inquiries on the current progress (if any) to implement OpenGL. Nor any type of time table ... as OpenGL was included when many of us bought in to the "Early Adopter" program.

Actually all I have ever been able to determine was one reply to a post found in someone's plan (or was it a product review) where one employee stated that they believed OpenGL would be included long before a version upgrade to TGEA (requiring people to pay) was made available. This person had hoped that this would be something we saw sooner rather than later.

http://www.garagegames.com/news/12259 - Matt Fairfax:

"With TGEA's development cycle already being as extended as it has been, we were forced to decide if we wanted to ship TGEA sooner or if we were willing to wait even longer for the OpenGL support to be fleshed out and finalized"

"(which could take many months longer)"

"get OpenGL support for your game for free later with a minimal amount of fuss"

"In the future we will charge for updates but we will make most bugfixes available for free."

It seems only fair to ask the question as it was planned per phase 4 to be included and then was post-pond (most likely for the reasons Alex and others have stated above). I'm curious to know about the progress so far and instead of writing a formal letter inquiring on a product I have already purchased, I opened this thread to have GarageGames reply and answer many questions, that (as we can see above) is not the only one curious.

--Carl

#13 I can't speak for anyone else, but I would feel a lot better if someone from GG would issue some sort of "formal" statement concerning the current condition of TGEA, and what their plans are for further updates.

In my mind, what is bothering me more than the state TGEA was released in is the infrequently and often confrontation (in tone) statements from GG staff that we should be happy with what we got. Anyone who has worked on a decent sized, professional, software development project knows that sometimes features get cut or pushed to later releases. That's a fact of life in the industry and should be nothing to be ashamed of. All I would like to see (especially for us EA purchasers) is a statement of what was cut, and a "rough" timetable for which features will be included. I'm not looking for hard release dates, they can list the planned updates in year "Quarters" if they want. I would just like to know there is a plan for future updates. TGEA is kind of a scary development platform right now because it appears that GG's stance on it is: "You've got what you've got, and you'll get more when we decide it's ready. No promises."

I don't think I'm being unreasonable here.

#14 To be completely open and honest: You won't get updates about expected features, or features moved from one release to the next, or planned upgrades or new functionality for any GG product any longer until such time as the community as a whole respects that even when things are posted, plans occasionally change, and sometimes features or functionality sometimes slip.

We have gotten so much anger and frustration from the community that we speak about nothing that is coming down the pike any longer--it's not something we enjoy, trust me, but given the nature of feedback from the community, it's a decision the company has made.

We're working on a ton of stuff that we feel people will be very happy about, but you won't hear about it unless you are in a private beta (and therefore under NDA), or the features are released.

#15 Hmmm all very interesting conversation. I can sympathise with the fellow who has his team pressuring him to change engines. I get that sentiment from my team on a regular basis. There is this constant hope that there must be something that's already finished that will work better. Periodically one of my team members will send me an email or an IM with a link to some other engine asking if we had considered that. Most times, we have in fact looked at their new discovery at some point in the past and rejected it for one reason or another. But I do understand, and likewise experience, the frustration that TSE is not ready yet. We very much NEED the terrain editor that was supposed to be part of Atlas, and it's not there. And the voice from GG seems to be "We're done with TSE now, we've got bigger and better fish to fry". Some of us are worried that we will NEVER get that terrain editor, that we're going to have to just deal with imperfect terrain or just use TSE as a demo tool until we can get funding for a more expensive commecial engine, or some other impossible solution. It is hard to know what to say to my team members when we've been pushing so hard to build the game in TSE thinking that when it was released it was going to have all the core componentes that we needed. Only to find that it's been released unfinished. People have this tendency to get discouraged and quit. So as the team leader I have to make decisions about workarounds and interim solutions, most of which have been holding to the promise that eventually we will get that editor. If we don't get that editor then we need to find someone with more talent editing .RAW files to create precisoin terrains than anyone we currently have on the team. Our map was created from an actual DEM of the real world terrain, and we have actual place locations we have to work with, but it was a low resolution DEM (from the modern time - whereas we're working with history in our game timeline) so there are a few errors and imperfections that need to be corrected. The terrain editor is just one example (the one my team complains about the most), but I know there are other features missing that need to be implemented as well. I'm sorry to hear that the community has discouraged GG from keeping us informed. I'm not so much worried about release date, just... hope. Is there any hope on the horizon?

Thanks for listening.
Blessings to you,
-Sparkling
http://www.visionsgame.com

#16 Thanks for the honest reply Stephen. I must say I'm extremely disappointed that you were forced to make your release schedules private. Torque has always been advertised as a professional game development platform, so I'm disappointed that the GG user community was unable to be mature about the release schedules of a professional development project.

Conversely, I hope you can understand how difficult it is for those of us who are trying to run our projects as professional, managed, development projects, to have to plan based on a completely unknown timeline for our technology platform. When questions rise among our team about issues such as the Atlas terrain editor, the only way we can respond is to say "We think they're working on it, and we hope it will be done soon."

I suppose if you're counting you could count me as the first "voice" in the community stating that I would like to see a development timetable; and I am prepared to be realistic about features slipping, or being moved. In my project, it is simply more important that we know.

#17 Just a question...

If a particular feature is so important to the design of your game, why aren't you just implementing it?

If you need an editor for Atlas terrain, write one...

I guess I just don't understand the mind set some of you are coming from. The point of an early adopter release is to allow you early access to the code at a reduced price. This benefits both GG and you, because you get to see the code early and get started on your game, and GG gets a large number of people looking at and using the code, fixing and finding bugs, etc.

GG provides a game engine, not an engine for your game. The game engine provides you with high detail fast terrain at the expense of low level editing. It also provides you a highly editable terrain, at the expense of detail and speed. If you cannot make either of those compromises, and I would seriously question why you couldn't, then you are going to have to get your hands dirty.

If you don't have the knowledge or skill to do what your game "has to have", then you are going to have to face the sometimes difficult realization that you can't implement your grand vision, and you need to change the design.

A bullet point on the feature list of an unreleased project is NOT a promise. Focus on the game play first... It doesn't matter how "real" your world is, if no one wants to be in it...

No offense meant to anyone, just my two cents...

#18 Well why didn't I think of that?

We know that TGEA is not a "finished game", and we understand the what we are getting. We have a very long list of features that we are implementing ourselves, that we never expected to be in TGEA. Make no mistake, the lack of a terrain editor has not halted our development process. However, a completely unfunded development project (like ours) has extremely limited resources. Pulling our programming resources off of other tasks in an attempt to create a terrain editor, only to have GG release a completed (and probably better) one, thus wiping out our efforts, would be extremely detrimental to our development process.

I understand that features get cut. I understand project schedules, milestones, priorities, and the economics of software development. I get it. I just want one question answered:
"Is an Atlas terrain editor currently being development by Garage Games?"

If the simple answer is "Yes" then great. We'll continue developing other things with the plan to integrate it later. If the answer to that question ever becomes, "No" then I would like to know as well. Not so we can whine and complain and act childish about it. I would like to know so we can adjust our resources, our project timetable, and our decision to use TGEA and Atlas at all.

Let me be absolutely clear about I am saying:
I am not so much concerned about the lack of features as the lack of information.

#19 Valid point Eric and I think you'd find that most in this thread fully understand that. However, many of us are probably depending on specific nuts and bolts to be included at some point, I for one, plan around those nuts and bolts as designing a game (of any magnitude) is reliant upon a time line.

I have artists, animators, story line editors and others working away on pieces of our game. Each is dependent on the other to do their part. For me, yes, I could eventually get OpenGL put in to my game either by myself or find another programmer to do it. However, when I first looked at TGEA it was part of the deal to have that built in. So, on my priority list, myself (or someone else eventually) did not have to worry about that single feature. The time line/production line was altered to work around it for the time being. I can continue working on the other items that I "know" aren't going to be part of the final product, which I have been doing and have never once complained about.

However, at some point, the project will come back to the items we had put off till later and in some cases, requiring us to go back to that point. As project managers (even as loosely as the term is based in an indie production) we have to stay true to our own deadlines.

As Stephen eluded to in his post, there are many things going on in any production schedule. One has to set those priorities to get things done. As Sparkling and Mark pointed out in there comments, we each have depended on specific features to be in place, our team expects us to keep on top of the project so they can do their job.

Stephen and perhaps the entirety of GarageGames has missed the point, "we" are as reliant upon them if we want to continue to use their products to provide quality information so we can stay on deadline. And that is not a bash on GarageGames in anyway, it's simply stating that they are not the only ones being hounded by people to finish things. Developers using their products to produce a product are being hounded by our own so called clients and staff.

I am sure many of us will either bite the bullet and stop production on crucial parts of our projects, hold up all other areas of work and then causing others to hold up their work to implement something ... we had every right to assume would be included. Now we are looking the bad person but we do it for the love of what we do as an indie designer. But others will give up and move to another engine, starting over from scratch in most cases and throwing in the towel. It will get done, one way or the other and probably as you [Eric] indicated in your comments.

In my humble opinion, simply getting upset over people complaining about deadlines in a programming environment is rubbish. It happens to anyone who has ever programmed for a living, we develop thick skins and move on. But if I walked in to my bosses office (my real life job) and told him I can't provide him anymore updates on what I am doing because my fellow co-workers are beating me up, I'd be handed my pink slip, told to clean out my desk and shown the door.

I am responsible to others and I'd like the same respect from those I purchase products from especially when these products naturally require us each to have teams helping us in the background. In an odd way, I feel like I am dealing with Sony Entertainment again. Speak nothing of what is going on, elude to big promises, and when it doesn't pan out, to late, money taken, they'll live.

--Carl

#20 I agree with most of what Eric says, although I would guess that one of the reasons that there are two reasons that people would rather sit and wait... The first would be that they might not have the ability or the resources to do those features. An in-game editor for example is behind the scope of many indie programmers. The second would be that you don't want to spend a lot of time on something only to find out that by the time you finished it an official solution was already available and better than the one you spent time on.

It would be nice to be in the know about some of the upcoming features for that reason. And in the past there were many valid complaints about he usability to TSE. Prior to MS4, I didn't think it was very viable for production of most games. At this point though I think it's stable and has most of what you need to develop a commercial game. There are some things I'd love to see still. In-game editing, a method to use different detail maps based on the terrain type, texture painting, opengl support are some examples of those things. But for the most part those are things that make life easier, or that add polish and not things that are required. OpenGL support would be an exception to that. It would expand the available platforms and benefit just about everybody. But the vast majority of the gaming computers out there are PCs, and run DirectX, so if OpenGL never comes to fruition, so be it. Some basic dedicated server support on linux would be great though.