Jump to content

Timmy

Members
  • Posts

    378
  • Joined

  • Last visited

Posts posted by Timmy

  1. Hey guys been working on the mac port and got it all running now. Would be handy if anyone here with a mac could give it a run and just report any problems or anything so we can continue to move it along. There hasn't been any optimizations done yet for the GL side of things, that is an ongoing task as is the whole port,


    Source is here: https://github.com/rextimmy/Torque3D/tree/mac_port

    Binary here: https://drive.google.com/open?id=0B0tHSJ8eQYh6RzQ1LXpXLVNFdEk


    So if you don't want to bother compiling it just grab the dmg file. OSX 10.9 or later is required, it is 64bit binary too. The CMake files still need a bit of tinkering around with to better support debug/release builds, will get to this.


    If you do spot anything if you could provide screenshots and also console.log that would help, no retina display support yet, so it will look a bit wrong if you got one of those ;)


    Code is a bit of a mixture of some of the awesome work @Hutch has done on the mac plus i stole (borrowed :mrgreen: ) some code from our little brother T2D.

  2. Yeah @chriscalef it is the order of inlcudes. I have a physx3 cmake module here https://github.com/rextimmy/Torque3D/commit/1770ed01ce45affc76e6ae48278153d93fda58bc ... To use it just grab the physx source and compile it yourself and than make sure TORQUE_PHYSX3_PATH points to /somepath/PhysX-3.3/PhysXSDK and away you go. I do have a version of that cmake file floating around that adds linux support too.

  3. This is a problem introduced with deferred shading, the mac port suffers the same problem. I am looking into this tomorrow as i have an old PC with the same family Intel GPU. If anyone else having this issue, can you please post your console log so i can see driver versions with OpenGL.

  4. Also just beware when using custom shaders, with DX11 it is very, very fussy that the vertex format matches exactly the same as the shader.


    E.G


    Bad (AppData in the vertex shader doesn't match vertex format):

     

    //C++
    GFXVertexBufferHandle<GFXVertexPCT> verts;
    
    // Vertex Shader
    
    struct Appdata
    {
    float3 position   : POSITION;
    float4 color      : COLOR;
    };
    
    

     

    Bad(order is incorrect in the vert shader:

     

    //C++
    GFXVertexBufferHandle<GFXVertexPCT> verts;
    
    //Vertex Shader
    
    struct Appdata
    {
    float3 position   : POSITION;
    float2 texCoord   : TEXCOORD0;
    float4 color      : COLOR;
    };
    

     

    Good:

     

    //C++
    GFXVertexBufferHandle<GFXVertexPCT> verts;
    
    //Vertex Shader
    
    struct Appdata
    {
    float3 position   : POSITION;
    float4 color      : COLOR;
    float2 texCoord   : TEXCOORD0;
    };
    

  5. For the most part, changes in the hlsl shaders you need are (glsl remain the same)


    Texture Sampling:

    // Old Code
    uniform sampler2D textureMap : register(S0);
    float4 color = tex2D(textureMap,uv);
    //New code
    TORQUE_UNIFORM_SAMPLER2D(textureMap,0);
    float4 color = TORQUE_TEX2D( textureMap, uv);
    

     

    Pixel Shader targets:

    //Old code
    COLORn
    //New code
    TORQUE_TARGETn
    

     

    Semantics (vertex shader output and pixel shader input only. Vertex shader input remains the same as does all other semantic names)

    //Old code
    POSITION
    //New code
    TORQUE_POSITION
    

     

    There are a few other things so just ask if you have troubles with any shader conversions.

  6. The old project generator is pretty much dead now, try the build again with CMake @LukasPJ

    generateProjects.bat still works fine for me - though I haven't added a vs2013 or vs2015 target yet, the vs2012 target script still does what it's supposed to do. Not sure how it can really break, after all - all it does is walk the source folder recursively and add files to the project. This results in a project with your specified parameters from the buildfiles/config/project.config file for the project at hand. Nothing really fancy here, so I'd expect it to be pretty durable.

     

    Yeah i know how it works ;) . A lot of stuff has not been updated with it and 3.9 will not compile using it.

  7. Ok glad it worked. With the error above, this will most likely be coming from some of that custom code, i'm sure james would have given me a nudge by now if that one popped up. Check the code and make sure the primitive buffer that is causing this error is not created with GFXBufferTypeStatic and than you are trying to update it, if it requires data to be changed than you must use GFXBufferTypeDynamic or GFXBufferTypeVolatile (depending on what your usage is for this buffer). DX11 is very strict on this compared to DX9

  8. If you are going to do 64bit builds i highly recommend using cmake to generate the project files for you, the project manager doesn't "officially" support 64bit and you gotta manually do some things to make it work. Sounds like something is wrong with the paths in your case and is not finding the dx11 libs it needs to link against. Can you show what paths it has?

×
×
  • Create New...