Is there no other way to work on tgea like tge??
by Mquaker · in Torque Game Engine Advanced · 03/13/2007 (11:22 pm) · 14 replies
Soon or later we will service mmofps game.
We want to accept lots of users that have various graphic cards.
TGEA doesn't support mx440 series and ati 7000 series, including onboard series.
Which is basically does not supports shader.
To make them run on the TGEA like TGE,
Is there any other way to make such graphic cards work on the TGEA?
Did anyone try to work this method??
We want to accept lots of users that have various graphic cards.
TGEA doesn't support mx440 series and ati 7000 series, including onboard series.
Which is basically does not supports shader.
To make them run on the TGEA like TGE,
Is there any other way to make such graphic cards work on the TGEA?
Did anyone try to work this method??
About the author
#2
Fixed function predates even pixel shader 1.1. It's the way things were done before shader based cards even came along, so you're talking like three generations ago.
If TGEA didn't support 1.1 shaders, then there would be no reason you couldn't build it using the latest Direct X which removes support for anything older than 2.0. IT's Microsoft that is trying to push 1.1 shaders off the face of the earth. GG still supports them.
03/14/2007 (5:32 am)
TGEA has no support for a fixed pipeline, but it looks like they went to an awful lot of effort to put fallback code in there to support Pixel Shader 1.1Fixed function predates even pixel shader 1.1. It's the way things were done before shader based cards even came along, so you're talking like three generations ago.
If TGEA didn't support 1.1 shaders, then there would be no reason you couldn't build it using the latest Direct X which removes support for anything older than 2.0. IT's Microsoft that is trying to push 1.1 shaders off the face of the earth. GG still supports them.
#3
Right now our company major focus is budget games targeted at ages E-10, so we can afford sacrificing Mac and Linux portability for the time being in exchange of a much more optimized graphics pipeline. We also need our games to run properly on those goddamn Intel onboard cards to get more sales. (Yeah, *some* of them support shaders, but I wouldn't dare turning it on).
right now our plans to approach it is adding a fixed function fallback on the Material class, which uses the fields as the Materials do (but ignore bump mapping and other stuff), and create a CustomFixedFunctionMaterial class to be set as fallback for CustomMaterials.
The CustomFixedFunctionMaterial will have lots of fields for setting the render and sampling states so custom materials have at least something to display instead of gibberish when shaders are turned off.
We'll also need to do some changes to the legacy terrain render code, since it depends on shaders. Even in shader mode, using render targets to blend terrain blocks is very inefficient and I'm sure it'll run much better if we just brute force it using multitexturing + multipasses.
03/14/2007 (6:58 am)
It is very possible to add fixed function support to TGEA. Actually, we're starting to do it ourselves, since we're very unsatisfied with TGE's performance. Right now our company major focus is budget games targeted at ages E-10, so we can afford sacrificing Mac and Linux portability for the time being in exchange of a much more optimized graphics pipeline. We also need our games to run properly on those goddamn Intel onboard cards to get more sales. (Yeah, *some* of them support shaders, but I wouldn't dare turning it on).
right now our plans to approach it is adding a fixed function fallback on the Material class, which uses the fields as the Materials do (but ignore bump mapping and other stuff), and create a CustomFixedFunctionMaterial class to be set as fallback for CustomMaterials.
The CustomFixedFunctionMaterial will have lots of fields for setting the render and sampling states so custom materials have at least something to display instead of gibberish when shaders are turned off.
We'll also need to do some changes to the legacy terrain render code, since it depends on shaders. Even in shader mode, using render targets to blend terrain blocks is very inefficient and I'm sure it'll run much better if we just brute force it using multitexturing + multipasses.
#4
Could you give me more details about the creating class??
Now we're trying to get TGEA mixed with TGE, too.
Of course it needs a tremendous efforts.
I'm thinking about that why didn't they develop (build) the TGEA mixed with TGE in GarageGames, Inc.
Really, I want GG, lnc. to build the mixed engine to accept lots users.
04/05/2007 (7:58 pm)
@ ManoelCould you give me more details about the creating class??
Now we're trying to get TGEA mixed with TGE, too.
Of course it needs a tremendous efforts.
I'm thinking about that why didn't they develop (build) the TGEA mixed with TGE in GarageGames, Inc.
Really, I want GG, lnc. to build the mixed engine to accept lots users.
#5
Spock Logic... simple and effective.
Anything else is a waste of time. Let old hardware die the death it deserves...
We keep falling (pc game industry) behind the consoles and because modern computers don't blow up,
besides power supplies we have a problem of old stuff hanging around.
Destroy all old hardware.. don't support it.. let it die.. time for shaders to rule the earth and crush all
console games.
(lol)
04/06/2007 (10:29 pm)
Use TGE if your priority is compatibility.Spock Logic... simple and effective.
Anything else is a waste of time. Let old hardware die the death it deserves...
We keep falling (pc game industry) behind the consoles and because modern computers don't blow up,
besides power supplies we have a problem of old stuff hanging around.
Destroy all old hardware.. don't support it.. let it die.. time for shaders to rule the earth and crush all
console games.
(lol)
#6
1) Make the game run barebones without most effects (even standard TGE stuff like dynamic lighting and even fog.)
2) Go through the trouble of re-implementing the missing stuff in fixed function.
The harderst things to re-implement in TGEA FF are the terrains (both legacy and atlas) and the dynamic lighting.
I did a quick experiment and god DIFs and DTS rendering without shaders. First, you can force TGEA to not use shaders even if your card supports them by opening your prefs.cs file and adding this to it:
In RenderInteriorMgr::render(), find
And change this:
Now do the same in RenderMeshMgr::render() and RenderTranslucentMgr::render().
In GFXD3DDevice::getNumSamplers(), find this:
Done, you should be able to see your players, vehicles (both without any lighting nor shadows, but textured) and DIFs (with lightmaps). The skybox, particles and GUIs already renders normally in fixed function. I personally tested this on an integrated Geforce2, and it works.
But going beyond that point is up to you - I have no intention of implementing anything beyond the basic features (beyond the sun light and -maybe- projected shadows) in fixed function in the near time since our upcoming games won't use them (we don't even use terrains). FF will be the lowest graphics detail mode in the games anyway, so anything beyond "glitchy-looking" does.
Remember that making your game compatible with GF4 MX cards is more than not using shaders: you'll need low versions of your models and textures, otherwise the performance will be unacceptable.
04/06/2007 (10:55 pm)
Adole, I can't give you full advice on it, because I haven't done much myself yet. If you want TGEA to run on non-shader hardware, you have two choices:1) Make the game run barebones without most effects (even standard TGE stuff like dynamic lighting and even fog.)
2) Go through the trouble of re-implementing the missing stuff in fixed function.
The harderst things to re-implement in TGEA FF are the terrains (both legacy and atlas) and the dynamic lighting.
I did a quick experiment and god DIFs and DTS rendering without shaders. First, you can force TGEA to not use shaders even if your card supports them by opening your prefs.cs file and adding this to it:
$pref::Video::forcedPixVersion = 0; $pref::Video::forcePixVersion = 0;
In RenderInteriorMgr::render(), find
GFX->pushWorldMatrix();Change to:
GFX->pushWorldMatrix(); MatrixF proj = GFX->getProjectionMatrix(); GFX->setProjectionMatrix(MatrixF(true));
And change this:
GFX->setVertexShaderConstF( 0, (float*)passRI->worldXform, 4 );To this:
GFX->setVertexShaderConstF( 0, (float*)passRI->worldXform, 4 ); MatrixF worldProj = *passRI->worldXform; worldProj.transpose(); GFX->setWorldMatrix(worldProj);
Now do the same in RenderMeshMgr::render() and RenderTranslucentMgr::render().
In GFXD3DDevice::getNumSamplers(), find this:
return caps.MaxTextureBlendStages / caps.MaxSimultaneousTextures;And replace by:
return getMin((U32)caps.MaxTextureBlendStages, (U32)caps.MaxSimultaneousTextures);
Done, you should be able to see your players, vehicles (both without any lighting nor shadows, but textured) and DIFs (with lightmaps). The skybox, particles and GUIs already renders normally in fixed function. I personally tested this on an integrated Geforce2, and it works.
But going beyond that point is up to you - I have no intention of implementing anything beyond the basic features (beyond the sun light and -maybe- projected shadows) in fixed function in the near time since our upcoming games won't use them (we don't even use terrains). FF will be the lowest graphics detail mode in the games anyway, so anything beyond "glitchy-looking" does.
Remember that making your game compatible with GF4 MX cards is more than not using shaders: you'll need low versions of your models and textures, otherwise the performance will be unacceptable.
#7
sorry.. but what we want is to service to all users with our commercial game.
@ Manoel
Thanks a lot for your concerning !!
soon or later we'll service the game to all users(everyone).
because we're developing the commercial game of mmofps.
As said before in the first post,
by checking the graphic card automatically in downloading,
What we are trying is to make all graphic cards work by doing tge add up to tgea.
But as a result of the pressure of time....agonizing for days..
Anyway.. I really appreciate your generosity.
04/10/2007 (12:07 am)
@ Vashnersorry.. but what we want is to service to all users with our commercial game.
@ Manoel
Thanks a lot for your concerning !!
soon or later we'll service the game to all users(everyone).
because we're developing the commercial game of mmofps.
As said before in the first post,
by checking the graphic card automatically in downloading,
What we are trying is to make all graphic cards work by doing tge add up to tgea.
But as a result of the pressure of time....agonizing for days..
Anyway.. I really appreciate your generosity.
#8
I agree, legacy hardware support has been a plague to the Garage game community. I wish the community would start marching towards the furture rather than maintaining the Oh we have to make sure jo-bob and his windows 98 machine with a GF4.
I remember a year or so before the TSE was even anounced getting into huge arguments with GG staffers about adding shaders and them saying that they were unimportant.
if building a game you need to aim for the bleeding edge of what is current. because by the time you finish you development cycle that will be the norm.
If you are starting you game project today:
You should should target a minimum of a GF7 and XP. And your ideal system being a GF8800 window a core duo and Vista.
now if you work on you game for a year to 18 months by the time you are ready to release a GF8 will be old intels will have 4-8 cores and they will not be selling XP past jan 08 so by then, except in corp envioments. XP will start to be a minority.
I would rather sell my game to the real gamers that buy games than make a game that they will snub just so I can sell it to a few people that are to cheap to keep their computers up to date. I mean supporting a GF4??? come on that card is over 5 years old now. there are what10 of these people playing games on the planet. Not worth ruining my game and putting in a buch of extra work to make them happy . sorry.
let the TGE die.
06/07/2007 (10:53 am)
@Vashner,I agree, legacy hardware support has been a plague to the Garage game community. I wish the community would start marching towards the furture rather than maintaining the Oh we have to make sure jo-bob and his windows 98 machine with a GF4.
I remember a year or so before the TSE was even anounced getting into huge arguments with GG staffers about adding shaders and them saying that they were unimportant.
if building a game you need to aim for the bleeding edge of what is current. because by the time you finish you development cycle that will be the norm.
If you are starting you game project today:
You should should target a minimum of a GF7 and XP. And your ideal system being a GF8800 window a core duo and Vista.
now if you work on you game for a year to 18 months by the time you are ready to release a GF8 will be old intels will have 4-8 cores and they will not be selling XP past jan 08 so by then, except in corp envioments. XP will start to be a minority.
I would rather sell my game to the real gamers that buy games than make a game that they will snub just so I can sell it to a few people that are to cheap to keep their computers up to date. I mean supporting a GF4??? come on that card is over 5 years old now. there are what10 of these people playing games on the planet. Not worth ruining my game and putting in a buch of extra work to make them happy . sorry.
let the TGE die.
#9
You don't want to deal in the casual games market, which is definitely a valid business decision. But for people who like those millions of users and their money, older hardware compatibility is a must. You are targeting the hardcore gamers who are going to be comparing your tech (or even more so, your artists' ability) to Unreal 3. And that requires the bleeding edge.
But it is not needed for everything. Both markets are extremely valid. It's just difficult to combine the two.
06/07/2007 (11:39 am)
@James Brad BarnetteYou don't want to deal in the casual games market, which is definitely a valid business decision. But for people who like those millions of users and their money, older hardware compatibility is a must. You are targeting the hardcore gamers who are going to be comparing your tech (or even more so, your artists' ability) to Unreal 3. And that requires the bleeding edge.
But it is not needed for everything. Both markets are extremely valid. It's just difficult to combine the two.
#10
Your reasoning only applies to the top most AAA blockbuster games. Not every company has the resources to do one of those games, because they require massive marketing investments to push enough sales to recoup the massive development costs. And if your company can afford creating such huge games, it can probably afford "huge" engines like Unreal 3.
For indies and small devs, legacy hardware support is vital. Adding extra layers of parallax mapping at the cost of your game not running on Geforce FX series will not make their games sell more copies.
But since GG has TGE and TGB, I don't think it would be healthy for them to bother adding fixed function support to TGEA officially.
06/07/2007 (11:41 am)
@James:Your reasoning only applies to the top most AAA blockbuster games. Not every company has the resources to do one of those games, because they require massive marketing investments to push enough sales to recoup the massive development costs. And if your company can afford creating such huge games, it can probably afford "huge" engines like Unreal 3.
For indies and small devs, legacy hardware support is vital. Adding extra layers of parallax mapping at the cost of your game not running on Geforce FX series will not make their games sell more copies.
But since GG has TGE and TGB, I don't think it would be healthy for them to bother adding fixed function support to TGEA officially.
#11
and I think that great games are more about the artistry than the tech.
Second I don't think that the casual game is going to be using a GF4mx at least not many and definalty not millions!
I would think that most of them are prolly going to have intel or a very low level ATI chip. Either of which is play like crap. on anything higher than TGE anyway so there is no point is using TGEA.
My point is there needs to be more removing of old code from TGEA rather than adding it to it. the last thing TGEA needs is to become bloated with legacy code.
TGEA with the exception of a few things like shadows on atlas2 terrain is as good if not better than unreal. unreal shines becasue they hire some of the best artist in the industry and they have a artpipeline and a set of tools that is second to none.
with and equivilant set of tools and artist you can make levels in TGEA that are so big that is you tried them with unreal it would die.
luckily tools seem to becomming more important to GG and with the release of constructor things are a whole lot better. As soon as atlas terrain2 matures TGEA will be a serious contender.
06/07/2007 (1:33 pm)
First off for what the unreal license cost I can hire and army of both artist and coders.and I think that great games are more about the artistry than the tech.
Second I don't think that the casual game is going to be using a GF4mx at least not many and definalty not millions!
I would think that most of them are prolly going to have intel or a very low level ATI chip. Either of which is play like crap. on anything higher than TGE anyway so there is no point is using TGEA.
My point is there needs to be more removing of old code from TGEA rather than adding it to it. the last thing TGEA needs is to become bloated with legacy code.
TGEA with the exception of a few things like shadows on atlas2 terrain is as good if not better than unreal. unreal shines becasue they hire some of the best artist in the industry and they have a artpipeline and a set of tools that is second to none.
with and equivilant set of tools and artist you can make levels in TGEA that are so big that is you tried them with unreal it would die.
luckily tools seem to becomming more important to GG and with the release of constructor things are a whole lot better. As soon as atlas terrain2 matures TGEA will be a serious contender.
#12
I'm right there with you on most of it, though artist's realize their vision through advancements in tech allowing them to do so more fully, but this you obviously already know.
06/09/2007 (10:28 am)
@ JamesI'm right there with you on most of it, though artist's realize their vision through advancements in tech allowing them to do so more fully, but this you obviously already know.
#13
The company I work for currently spent a lot of money and time gathering accurate numbers on what's out there video card wise. So, depending on what your target audience is, it can be effort well spent.
Like many things in game development, it's another gray area where you have to decide what's right for your project; which more than likely isn't right for the next person's.
06/09/2007 (10:59 am)
James, just to be the devil's advocate, the number of GF4's out there is *most definitely* in the millions. The company I work for currently spent a lot of money and time gathering accurate numbers on what's out there video card wise. So, depending on what your target audience is, it can be effort well spent.
Like many things in game development, it's another gray area where you have to decide what's right for your project; which more than likely isn't right for the next person's.
#14
06/09/2007 (4:21 pm)
The only reason I would condone it would be if the TGE Development stopped that way all of GGs focus was on TGEA. If that was the situation I would say yeah add the functionality to the TGEA. But give Developers and easy way to strip it out if they don't want or need it.
Torque 3D Owner Marc 'Dreamora' Schaerer
Gayasoft
TGEA has no fixed pipeline anymore. Systems without at least Shader 2 won't run it.
What you would need to do is implementing the fallback yourself.
Someone mentioned that he / his team was able to do that, so it is definitely doable. But you will need to have experience in DirectX programming to do so or try to get TGEA mixed with TGE.
In both cases, you will have to keep your fixes up to date manually when you want to use the current TGEA versions.