Beta Testing?

#21 I'm patient too... That being said has there been any information (not that I've looked for it) about being able to get the version of code all of the guys coming out with add-ons and expansion packs are using? It would seem to me if I'm in the tool building market I'm way behind the curve.

Now, I'm not in the tool building market. Then again I would have to have the code to even consider it.

It's way too early to say that I want to create custom code to augment the engine, but I think I want to create custom code to augment the engine. Of course if the code isn't finished what am I augmenting?

This is how diametric my feelings are on this release. I want it now but I know it has to be close to a final form.

#22 @Joshua - The only ones that have early access to Torque3D are those people either working on Torque3D or those with existing products either finished or that were already well underdevelopment in older versions of Torque (and therefore agreements already in place with GG).

So you're not missing out, if you're after creating an add-on pack then you can start right now as the first steps are going to be figuring out what the pack will contain and some design work by the time you get that out the way the Beta should be with us

#23 @Andy

I have 8 million things I want to learn so there isn't a lack of something to do. A white paper or some kind of skeleton design document would help me design a reasonable interface to the engine, though.

I'm not sure how similar TGEA and Torque3d are as far as the design is concerned, so I don't want to spend my time designing something to plug into TGEA. For example, I'd like to implement some custom shading or particle effects. Mostly, I want to do this in SM 4.0 because I'm learning SM 4.0 at the moment.

I can wait for the beta to be released because I have several things in the queue, such as learning Torque Script and shader model 4. I may also have other responsibilities as far as a team project I may be joining as well.

I expect to spend a significant portion of my time learning how the engine works before actually creating something, even with a complete design.

This whole post could be boiled down to "I'd like a design document".

#24 SM 4.0 is DirectX 10, that might be a problem...

#25 That it is. Perhaps that's something to consider for a project; adding DX10 support for the engine? Is that possible with the Professional license source?

And I realize the potential for that to be a massive job. I'm just asking if it's possible.

Either way, it doesn't address the design document question. For example, Khronos has docs out for their APIs well in advance of anyone actually releasing a standard version.

#26 @Joshua - Yes it is perfectly posssible, the GFX layer is abstracted so you could support for any DirectX version but it would take a bit of work... have a look at TGEA you'll see how both DirectX 8 and 9 are supported.

If you learn TGEA then 90% of what is there will still apply to Torque 3D, it's not a brand new engine it's just TGEA 2.0 but they're renaming the product.

#27 @Andy - Thanks for the advice. I'll take a look at the TGEA abstraction of DirectX. That gives me something fun to do while I wait for the release.

#28 Not much point porting to DirectX 10 these days, DirectX 11 has feature levels from 9.1 to 11 (and stuff like multithreading which can be nice).
But still, the videos we've seen prove much can be done with "dumb old" shaders...

#29 I want my Tee Shirt!!!

#30 @michael I haven't been keeping up with the hardware requirements. Has anyone developed a card for 11 or can you run it with 10 hardware?

Edit - Did some research. It looks like new hardware is required for at least some of the features. I'm going to not try to early adopt everything at once and just look at shaders for 9 and 10 as I need them in that order. Although, compute shaders do look cool.

#31 There is no public card available for D3D 11, which would require hardware support for domain/hull (tesselation) and compute shaders (stuff like CUDA) as well as shader linkage (mostly interfaces to avoid having to write 3 billions different shaders, although that one can probably be done partially by the driver without hardware support I suppose).

But unlike D3D10, D3D11 is backward compatible all the way down to D3D9 class hardware, and even with that kind of hardware you get features like (working) multithreaded rendering.

Anyway you can try the samples from the SDK, the ones that require hardware support work fine via emulation. Also D3D11 comes with a software renderer called WARP which is quite fast and can emulate all the D3D 10.1 features...

#32 Yeah there is a good chance that GG and many other game engine providers will skip DX10 support and jump from DX9 straight to DX11, I know that's something I'd seriously consider

#33 Dx11 Compute Shaders have multiple profiles. 4.0 and 4.1 work on Dx10 and Dx10.1 hw parts, 5.0 is for Dx11 parts.

#34

Quote: Yeah there is a good chance that GG and many other game engine providers will skip DX10 support and jump from DX9 straight to DX11

Sounds like a good idea.

#35 OK I'm going to start learning DX12. I know it's not even on the drawing board yet but I think by the time I have a decent code base done it will be.

Don't ask...

Edit - OK since that's bound to confuse quite a few people, that was a joke.

Edit Edit - "With Shader Model 5, Microsoft applies certain concepts of object-oriented programming to its shader language, HLSL. Unlike preceding versions, which introduced new capabilities (Dynamic Branching, integer support, etc.), the purpose here is to facilitate programmers’ work by solving a common problem in current game engines: namely the upsurge in the number of shaders due to the large number of permutations. We’ll take a concrete example: Suppose that an engine manages two types of materials, plastic and metal, and two types of light: spot and omni. A programmer has to write four shaders in order to handle all cases:"


I take it from this shaders written in SM 4.0 will become obsolete as far as syntax is concerned? Why do I bother buying books? grrr

#36 Don't think that skipping DX10 is that a good idea for a non AAA big buck only technology (and even those need to fallback to DX9 and DX10 on weaker machines or they won't be licensed by too many companies)
Realistically seen it will take till 2011 / 2012 before the first performant DX11 cards are available, like it took over a year until the first DX10 cards appeared that worked on an acceptable scale.

Considering that normal machines also will need to be supportable, DX11 is even further off than 2011 for sure, as the technology for mid and low range cards commonly is 1 generation so 9 - 12 months behind the enthusiasts class GPU.
DX10 is just starting to get a somewhere usable (to non AAA funding driven devs) market penetration with new "normal and performant enough" machines thanks to the NVIDIAs 9400 heavy push and a few successfull low cost ATI cards.

With the things T3D got from what we've seen so far, I think that DX10 even would make sense to be on the forseable roadmap as it seems to use different things that are more performant / flexible in DX10 than in DX9


And no SM4 shaders will likely not become obsolete. They will just not be SM5s
Same as it is right now with SM2 / SM3 on SM4 hardware, where they can not benefit from the geometry shader units and unified shader units in general.

#37 @Marc
I'm not sure what you mean, considering D3D11 works on the same platforms and more hardware than D3D10 (since it supports D3D9.x, 10.x and 11 hardware, while D3D10 has a "frozen" feature set, mostly)?
Basically you'd need to support D3D9 for old operating systems (anything before Vista) and D3D11 would be for Vista and 7 (and still support D3D9 hardware)...

#38 Not sure if the extra work to compile the stuff to the appropriate target won't make the whole stuff significantly harder to be optimized and work correctly than clean single API GFX driver implementation.

Its not like DX11 has some godlike magic to just do what the platform supports, you still have to write 3 distinct drivers again to get target optimized shader output for example (<= SM3, SM4, SM5) as there are various things that don't exist pre SM4
And in addition you cut any OS pre Vista, as DX11 requires Vista+
As many didn't switch to Vista (either you go for Vista64 or better remain on XP if you care about RAM usage and performance) but are waiting for Windows 7 (SP1), cutting XP is not something I would tolerate actually for the DX9 path.
Good thing is it already present so that part is unlikely to happen. So the DX11 part would only have to handle DX10 and DX11

#39 "Its not like DX11 has some godlike magic to just do what the platform supports, you still have to write 3 distinct drivers again to get target optimized shader output for example (<= SM3, SM4, SM5) as there are various things that don't exist pre SM4"
Actually there is a 10Level9 which lets you run D3D10 stuff on D3D9 hardware...

"significantly harder to be optimized and work correctly than clean single API GFX driver implementation."
D3D10 is not a clean API, they made it all dirty with 10.1 ;)

"And in addition you cut any OS pre Vista, as DX11 requires Vista+"
Just like D3D10 ;)

There is really no good reason to write a D3D10 implementation when D3D11 is already available and provides better performance even for older hardware...

#40 Yeah to clarify Dx11 can be used as Dx10 with free bonuses, you never have to write a Dx11 hardware path if you don't want too, in which case its just Dx10 but with a number of nice new features (compute shaders, command buffers), all supported on the same hardware as Dx10.

Which is why Microsoft is trying to remove the whole Dx10/Dx11 hardware names, its meant to be keyed off shader version. I.e. Dx11 uses shader model 4.0 hardware providing you with some new features over Dx10 on SM4 hardware, Dx11 is also the first API to supports SM 5.0 hardware coming out soon.

Really no reason at all to go Dx10 at this point.