Auto detecting for the API

#1 TAP is designed so that you don't have to worry about any of this--you simply use the engine as it's designed and let the platform layers take care of the rest.

It will be -extremely- rare that you will even know from a development perspective even what OS they are running, much less which graphics layer or version they have.

#2 Disclaimer: I've not personally done much in the area that you are talking about, so your milage may vary slightly.

That being said, there is nothing anywhere in TAP where you even set a "preferred device". You simply code your game using the functions/methods (script and source) that are available to you from the platform layer on up, and then compile executables and .dso's for each OS and it takes care of the rest...

Now, if you start using very specific direct graphics layer calls in your game code itself, you are going to code yourself into corners obviously, but yes, TAP auto-detects the graphics capabilities available, and configures to use them as appropriate.

Check out your console.log in depth, you'll see where it does things like detecting your CPU type, your graphics card capability, etc.

Do be forwarned, TAP uses OpenGL by design, and defaults to it. If the player manually selects D3D (DirectX), then torque will use it if it can, but all it does in that case is re-implement D3D style functionality for the OpenAL calls. In other words, it still uses OpenGL as a "wrapper" around D3D.

EDIT: This design tactic also puts TAP at the mercy of the player's installed video card drivers, and sadly, some video card manufacturers don't do an exceptional job of implementing OpenGL capability. Even worse, Microsoft's generic drivers that come with many "beginner's computer" systems don't support OpenGL at all. I bring this up only because you will eventually run into it--it's not hugely common, but it does happen where a customer may have drivers that simply don't support OpenGL, and they have issues until they upgrade their drivers. I would guestimate that it will be a very smally population sample that runs into this issue--we see it brought up on the TGE forums in some form about every 2-3 months or so.

#3

Quote:That being said, there is nothing anywhere in TAP where you even set a "preferred device".

Quote:If the player manually selects D3D

Um, which one of these is true?

Quote:Even worse, Microsoft's generic drivers that come with many "beginner's computer" systems don't support OpenGL at all.

They support OpenGL. Just not in hardware ;)

#4 I may have mis-understood what he meant when he said "so if set DX8 as the preferred device ". It sounded like he meant the developer sets a preferred device (he doesn't). IF You allow it via an Options Dialog, you may allow the player to say "I want to use D3D instead" as a graphics option.

Regarding the "OpenGL" support, I'm just summarizing back posts over the last year+. Those that have had problems with OpenGL support have fixed those problems by selecting a different video driver, and almost exclusively by reverting from the "Microsoft Generic Drivers" to the manufacturer supplied drivers--although even in this case, the "latest drivers" are commonly some of the worst. The "best success ratio" has been (for those that even had trouble in the first place) by finding the 2nd, or in some cases 3rd most recent driver supplied by their video card manufacturer.

Again, it's a pretty small statistical sample that have trouble at all.

#5

Quote:I think it will be a good idea to set the preferrred device inside the prefs file so TAP at least looks at DX first. It may be slower, but it is ultimately more compatable?

In the windoze world? Possibly. But then you are cutting out 2/3 of the cross-platform options.

So it depends on who your target really is!

#6 On install you could have an option where people choose... though you'd probalby have to modify your own installer

#7

Quote:In the windoze world? Possibly. But then you are cutting out 2/3 of the cross-platform options.

So it depends on who your target really is!

That makes no sesne. What he's suggesting is that T2D look for DX first, and if it doesn't find anything, look for OpenGL. Since there is no DirectX on non-Windows platforms (and, btw, calling it "windoze" is a derogatory word that has no place in an intelligent discussion), it would "fall back" to OpenGL.

As you yourself point out, OpenGL drivers do not tend to be stable. Indeed, DX drivers tend to be far more stable. MacOS GL drivers are pretty decent, though Linux drivers aren't paragons of stability. So, it makes sense on Windows platforms to use the more stable alternative as the default. Why take the chance that someone who buys your game won't be able to play it because his GL drivers suck?

#8

Quote: /mi:'kroh-sloth" win"dohz/ (Or
"Windoze", /win'dohz/) A derogatory term for Microsoft
Windows which is so limited by bug-for-bug compatibility with
mess-dos that it is agonisingly slow on anything less than a
fast 486. Also called just "Windoze", with the implication
that you can fall asleep waiting for it to do anything; the
latter term is extremely common on Usenet.

Its on dictionary.com ;)

Quote:that has no place in an intelligent discussion

So no flaws derogatory comments should be mentioned, no flaws of an obvious flawed operating system? Seems your own posts in the past have defied this method you now proclaim... "intelligent discussion" ... actually I've seen him answer your responses very respectfull considering how 'derogatory' your tone was... He was insulting towards an operating system, you were insulting towards a person, I find that very disrespectful to all of us and the community in general.

and I think

Quote:So it depends on who your target really is!

is some very valid advice

#9 In T2D (and TGE) you can set the following preferences...

$pref::Video::preferOpenGL = "0";
$pref::Video::appliedPref = "0";

This will remove the preference for OpenGL (full cross-platform). D3D will then be preferred but if not available then OpenGL will be tested and selected.

I haven't checked if this works the other way around although it's wouldn't be difficult to make it do so.

Due to there being lots of "prefs.cs" files (something we will sort out soon), you need to modify the last one loaded which in the stock SDK will be the one in the particle-editor.

- Melv.

#10 Matt,
That was a damn good post.

I love windows but I got your point.

I honestly don't see why some people feel the need to post stuff when it serves no purpose other then to show off how smart they are or to push there own opinions down other peoples throats.

Then again, that's just my opinion

#11

Quote:He was insulting towards an operating system, you were insulting towards a person, I find that very disrespectful to all of us and the community in general.

Are you, perhaps, suggesting that we all go around promoting infantile names for various OS's that we don't like? Perhaps I should start refering to it as CrashOSX? Or Linsux?

The reason that I have an intense personal dislike for names like Windoze or Micro$oft or other such nonsense is because it oversimplifies a complex choice (ie: which OS do you use). It takes a substantive debate and turns it into one-liner MTV-style name calling. And that is not conducive to any intelligent discussion, no matter how you slice it.

Just because something has flaws doesn't mean it should be mocked. And just because someone thinks that something is worthy of redicule doesn't mean that it is.

Quote:is some very valid advice

Personally, I'm an advocate of the strengths of OpenGL as a graphics platform. However, as a reasonable person, I must admit to its weaknesses and the strengths of Direct3D, as well as the weaknesses of modern GL implementations. As others have mentioned, DirectX is a valid alterantive to the various "open" technologies on the Windows platform. OpenGL drivers, while can be faster than Direct3D, are not nearly as stable. Writing a D3D driver is an order-of-magnitude easier than writing a full-fledged implementation of OpenGL. Coupled with this is the fact that most graphics cards makers consider a decent GL implementation to be a nice bonus feature, not a first-class need. It needs to run Quake3-engine games, and maybe NWN, but that's about it for them. D3D drivers, by contrast, are tested more extensively and are given more (proportionately) resources. It's no surprise that D3D drivers are often more stable than GL drivers.

The "target audience" doesn't matter if, for some reason, your game doesn't work on their system. It could be as simple as not having a Linux port, or more complicated like a set of broken OpenGL drivers. However, in the former case, you can tell people up front that you have no Linux port. You can't do anything about bad GL drivers. Except offer an alternative with (likely functioning) D3D drivers.

Quote:In T2D (and TGE) you can set the following preferences...

Hmm... Where do we go to find more of these kinds of values?

BTW, is TGE/T2D (on Windows) willing to load GL drivers outside of the standard ICD driver model? Like, if you had an MCD (the old Voodoo method for using GL) or an install of Mesa, would it be willing to load those drivers manually? Just curious; I have no intension of doing any of these things.

#12 Robert,
I reorganized the directories into a one level deep layout.

T2D.exe
[common]
[images]
[effects]
[sounds]
main.cs
datablocks.cs
prefs.cs
<game name.cs>

and I believe it only took 2 or 3 changes to paths in the GUI code in [common]. It would have been zero changes, but there was some issue with ~ not always resolving to the location of the launching t2d.exe.

If it still makes any sense to do this after the new release comes out, I'll post a thread showing the changes. Melv mentioned cleaning up the structure a long time ago, so I'm hoping I won't need to post it :-)

#13 @Smaug: It was an attempt to inject some light hearted humor into what can sometimes become quite tedious forum discussions. You read the T2D forums probably once or twice a day (possibly more, this is for comparative purposes). I read approximately 4 times that more than 20 times a day, and after seeing questions for the 15th and 20th times (not this particular one), occasionally I inject a little humor.

As an aside, quite honestly your discussion techniques and style fall into one of the categories that tends to become ignored over time by many long time forum members, despite the valid and most of the time very accurate technical content. That's not an insult, nor is it a complaint, it's simply an observation.

@Robert: The reason for the /common folder (as I've explained before in this forum) is because when you are working with multiple projects in the script environment, many of these projects will use scripts that is completely unchanged between each project. The /common folder provides a single point of reference for these files, so that if you happen to change some of the functionality, you won't have to change it in each and every one of your projects as well--change it once in one place, and all of the projects will recognize and use the change.

You can certainly move the directory structure around however you like (as long as you make the appropriate script changes) so that it works more closely for your personal project management style, but keep in mind that as updates are released to script, it will require additional effort for you to apply the updates, since they will assume the original directory structure.

#14 Well, here's an example of why it's the "opposite of redundant", hehehe:

Let's say that 3 months from now, after releasing a total of 5 demos, Melv decides to make some changes to the particle editor (which AFAIK is stored in the /common dir).

Now, you've downloaded all the demo's, and have them all in their own directories under /example. You've also played around with modifications to 3 of those demos for your own projects, each in the demo directories.

With the current directory structure, all you would need to do is to update the files in the /common dir that contain Melv's changes. With a different directory structure that doesn't have the /common dir, you would have to make the changes for each of your directories manually.

Like I mentioned before, it doesn't always make sense from a development team's perspective to have a common dir (my project took it out ourselves, but we only work on a single project), but for the widest customer base, and the different types of teams and projects out there, it does make sense to have a common area that contains script shared by many (all) possible projects. It would be redundant to have the same exact code in each and every directory, when you can share it in a single /common dir.

#15

Quote:oversimplifies a complex choice (ie: which OS do you use).

Seems like some other argument is being carried over here... he made a simple (and now even stated joking comment)... plus feel free to bash whatever you want, I could care less... I use Windows, I despise it on many levels (I'm a PC tech / web hoster/developer turned Game Developer... my day job is web design/PC tech, lol beleive me I know how evil and how needed 'Windoze' is) but I think its a necesary evil... much like AOL...

Quote:The "target audience" doesn't matter if, for some reason, your game doesn't work on their system

I'd have to respectfully disagree... your target audience has to be one of the most important factors in everything... that is the point, you get your target audience and you ensure you have the best setup for their systems... that sentence of yours really is an oxymoron. You develop a "target audience" exactly for that reason.

On the other hand I'm no longer going to debate you just so you can debate lol... lighten up a bit and you'll have more fun and find that we are all a little more cooperative ;)

#16 Stephen explained it better than I could... :) If your working on multiple projects the common folder setup can be great... you can also compile it down for a release version

#17

Quote:Hmm... Where do we go to find more of these kinds of values?

That's a really good question without a good answer unfortunately. Prefs are one of the "inherited knowledge" things that as far as I am aware are not very well documented.

I'll underline it on my list of things that need better documentation, and do what I can to get some focus on it, because I agree, there is some very nice kernels of knowledge about them scattered across 5 years of forum posts.

#18 Lol, I know what you mean Stephen... thats the nice thing about T2D... a fresh start at documentation vs catching up... I have a bunch of old links to forums posts that I've dug out as well that I need to document... I'll look forward to what you dig up :)