Can we compile TSE without shaders?

#1 I forgot to say the chipsets we are targeting are the Intel 915 on a Samsung Q1 and the VIA/S3 UniChrome on a TableKiosk EO.

#2 Atlas uses a vertex shader for some simple vertex interpolation and coordinate mapping (fog & textures). It also uses a pixel shader for some basic stuff. To get Atlas rendering on TGE, you'd need to emulate the vertex & pixel programs on the CPU.

This would be a lot slower than using the GPU. I can't really tell you if it is doable or not, because I don't know how much slower it would be (I guess that depends on how to did it), nor do I know what those processors are capable of. But it would be slower.

#3 After taking a look at the Samsung Q1 specs, I highly recommended using TGE, not TSE, for your project. Since TSE is centered around a completely new rendering system, ripping out the shader capability is not feasible. I think you will experience a lot of performance issues down the road going down the TSE path. EXACTLY why is the TGE terrain not sufficient?

John K.

#4 DirectX reports that the Q1 supports Shader 2.0, the EO doesn't support any. So evening though the Q1 should support the shaders, TSE says it doesn't. Does TSE only work with ATI and nVidia currently?

The reason I don't think the terrain system under TGE is sufficient for our project is because we want to have large, explorable areas without having to do a lot of code. We have a very short deadline (a swarm of teachers will be coming to check out a workinng demo in less than a month!!) TGE would work for our first run, but unless we can be sure TSE will work later, we'll have to go with another engine within a year, which means we should just lokk elsewhere now. I have to submit my final recommendation Monday morning. I would prefer to use TSE, as it is what I plan to use for my own purposes on modern gaming systems, but I have to recommend what is best for this project.

Initially we'll only have about 5 students on a small island, but within a year we might see 30-40 users in a single space and they'll need room to move around. Since this is an educational venture, we can't have them just trying to kill each other to gain resources. They're supposed to work together.

We will only be running at 800x480 (or 640x480 stretched up) x16-bit and our models and textures will remain modest. ... If there is a work-around for the start-up code so it will recognize the shader support that the i915 has, I would be thrilled to death. We looked into profiles, and I stared at several of the source files for most of the day Friday, but we didn't come up with anything that made it work. I hate to just put it to others for a solution or dump the engine, but I'm out of time.

We're now looking at GameStudio A6pro. I've heard good and bad about it, but I think it might be the way to go to get this game bumped out in the short time we have.

#5 If DirectX is reporting that the support is there (which it should be as the Intel 915 chipset is DX9 Compatible, but not Compliant), then TSE should be picking it up, as TSE uses CAPS returned from the DirectX 9 Device.

In your log from the Q1, when it reports Direct3D Device Found, does it give any other pertinent information, as thats really the root of it. I suppose you could probably do some hardcoding, but it doesn't necessarily mean it'll run..

As for engine choices, Its hard to say.. if TSE doesn't pick up the shader support, then it might be something else that needs to be changed or looked at. With the source, then you obviously can make changes to whatever is needed...

#6 Here is what DX sees... I am not so experienced with DirectX, so I am uncertain where I can force things and where I must be careful. I normally develop under Linux.

Caps
DeviceType 1
AdapterOrdinal 0
MaxTextureWidth 2,048
MaxTextureHeight 2,048
MaxVolumeExtent 256
MaxTextureRepeat 0
MaxTextureAspectRatio 2,048
MaxAnisotropy 4
MaxVertexW 0
GuardBandLeft -1536
GuardBandTop -1664
GuardBandRight 2559
GuardBandBottom 2431
ExtentsAdjust 0
MaxTextureBlendStages 8
MaxSimultaneousTextures 8
MaxActiveLights 0
MaxUserClipPlanes 0
MaxVertexBlendMatrices 0
MaxVertexBlendMatrixIndex 0
MaxPointSize 256
MaxPrimitiveCount 65,535
MaxVertexIndex 65,534
MaxStreams 16
MaxStreamStride 255
VertexShaderVersion 0.0
MaxVertexShaderConst 0
PixelShaderVersion 2.0
PixelShader1xMaxValue 3.40282E+038
MaxNpatchTessellationLevel 0
MasterAdapterOrdinal 0
AdapterOrdinalInGroup 0
NumberOfAdaptersInGroup 1
NumSimultaneousRTs 1
MaxVShaderInstructionsExecuted 0
MaxPShaderInstructionsExecuted 96
MaxVertexShader30InstructionSlots 0
MaxPixelShader30InstructionSlots 0

#7 Support pixel shader, but not vertex shader.

#8 That sounds right, as the Q1 isn't DX Compliant (the Vertex shaders are emulated/ran on the CPU).. So when the engine goes to detect Shader support, it comes back negative.

I don't know if hardcoding Torque to still run 1.1 or whatever would still make it work, as it would depend if DX works properly via software

#9 Without knowing too much about your project, I would suggest you strongly consider using TGE instead of TSE. Your project doesn't seem to require the materials and shader support that TSE offers and the questionable compatibility issues could become worse over time. I suggest that you build upon TGE to get the initial prototype out, refine your requirements and design, and then later upgrade to TSE if truly needed.

We have had much more success moving TGE game code and assets to TSE than from TSE to TGE. In the meantime, you can look into porting Atlas code over to TGE or even re-structure your game to not require such an expansive terrain. Also, the TGE legacy terrain tiles very well for a seemingly endless terrain - you might be able to fake something.

In any case, good luck with the proposal.

John K.

#10 OK, I hadn't really spotted the Vertex bit until posting that. TSE is definitely out for now. Thanks for the insight, folks.