Converted all cases of GLLINELOOP or GLLINESTRIP that had a large amount of verts (crash in D3D) to GLLINES Why the heck are they still using that darned D3D over GL translation layer? It didn't work right back then and will never work right since it is a widely known fact that OpenGL and D3D features don't map 1:1. If they didn't just slightly modify TGE core to make TGB, they had a major syndrome of cut and paste to copy the ugly mess that is dgl. Another one from the changelog that reminds me of old-school optimization which, yet again, points to TGE code in TGB. Resolved issue where writing fields with greater than 1000 length would crash the engine.
Now finally, after a very long time, a video again! This is my first Constructor tutorial, and i hope you like it. Download Blockland for windows and macintosh. For advanced users Milkshape, DTS exporters for Blender, download the map2dif program 3D Studio Max 6. Nov 23, 2005 - Additionally, version 1.4 features integrated Unicode font rendering, enhanced map2dif interiors, and better support for Mac OS X and Theora.
Ok, one might argue that std::string is not the most optimised part of the STL. In fact, it's the worst part of it and could do with a good shaking up (See 'Exceptional C Style' by Herb Sutter and 'A Policy-Based basicstring Implementation' by Andrei Alexandrescu implemented in on erdani.org for more on that). But, still, it isn't a reason to use fixed-length strings for user-data fields in production code (only cause possible for the kind of issue described). Because, as they discovered, they are mainly a source of bugs and can even be insecure if your application is networked (which, coincidentally, is one of GG selling arguments for the Torque line) Well, aside from that, as I already mentioned, my personal opinion on the Torque line is that they have good editors but that's all they currently have. If they fixed the map2dif and uprated the DTS format to support even some basic features like texture layers and multiple UV's I'd probably have been using it now.
Map2dif For Macbook Pro
We spent a good 8 months of the past year being depressed, Ogre had pretty poor art pipeline tools, Blitz3D was too old, and Torque had a horrendous art pipeline and felt clumsy in part because the tools we usualy use have an entity system of some sort and high level abstraction like Blitz3D and Ogre to a fair extent. When Ofusion came out I was over here like a shot. I agree, Evak I was running back and forth between Torque and Ogre: I needed good tool chain, and support for non- and shader cards in one product(I still do), and creating a product in TGE then porting it to TSE - too expensive, same amount of time to assemble an engine with ogre, create advanced exporter for XSI. The big turn around on Torque for me was when I found that DTS is not flexible et all, and I dont think it worth to invest time in it when I can invest time in my engine with Ogre. I was amazed with the price of XSI - it's affordable! I was thinking to use XSI as my primary tool, but OgreBlender is coming and I'm thinking to use that - it will be the best prototyping tool ever with their game engine and Ogre viewport. Noticeable, Ogre community has the same amount of features as Torque one, except it's not yet quite polished (takes time for part-time developers), but it seems like Torque developers take time as well to do the same.
Just had a crazy idea yesterday when I was turning over and over in my bed looking for sleep: let's redo it!!! I mean, we're all here bitching how Torque's renderer and physics sucks but how they've got a great content pipeline. And I was thinking, we have already developed all the parts here in the OGRE community so why not assemble them into a coherent whole. Furthermore, cloning the Torque level editor wouldn't be so hard a task.
So here is a sample parts list: Framework: GOOF or Yake Physics: OgreNewt (Newton is so beginner friendly; quite a requirement for a Torque clone). Or maybe NxOgre because PhysX is a real beast (but it's not portable and cannot be used for commercial purposes). Not considering ODE because of numerical stability problems (at least in the past and I've heard that even now it's still hard to work with). Rendering: OGRE what else? Now, Dagon or Eihort?
I'd choose the latter since it's gonna be niftier and the project may take a while. Gui: CEGUI of course as it's already integrated with OGRE. Sound: FMOD or OpenAL. I personally love FMOD since it has lots of nice features for 3d sound positioning like automatic sound occlusion by geometry but if there are more votes for OpenAL then we can always use OpenAL. Scripting: The goal of the project would be to make it easy to port Torque games to the new clone but, naturally, we can't use TorqueScript since it's copyrighted by GG. I'd suggest Lua but Lua's philosophy is too different from TorqueScript.
Python would be a nice replacement but binding Python code to C code is not exactly what I'd call a joy ride. Then, again, those who have worked with Torque might remember that TorqueScript binding had to be done with complex #defines to hide the inherent complexity. Exporters: We'd need exporters Torque-New clone. But what do we need to export?
Map2dif For Mac Os
Mission files don't need to be exported as they are plain XML. Terrain files. While they are in a weird binary format, I have already laid the bases for an exporter. I could probably finish it but it would have to be distributed as binary-only since it would use Torque code. Not a very flexible format but pretty well documented so it would be very easy to make a DIF-MESH exporter. Anybody's up for it?
Have I forgotten something? Miscellaneous notes: - We still need to figure out Torque's world scale matrices (as I previously mentioned). Fortunately, I figured out an easier way to do it than tracing through the code: just use an opengl tracer on Torque when it's in opengl mode. While GG are boasting that Torque is an inside/outside engine, it is not. It never switches scene managers ever. The fact that the character is able to move inside hollow meshes is what they call being an inside/outside engine. It would be both nearly impossible and virtually pointless to do anything remotely resembling Torque.
Everything about Torque is anathema to modern engines, GPUs and DCC methodology. It would be far better to stay the course with one or more of the current game engine frameworks.
In the end, as we all know and state repeatedly, good tools are what makes for an attractive game engine. If a few people put significant effort into basic tools for something like GOOF then the problem is solved. While ther might be some merit to developing TGE-GOOF converters, the problem is that the TGE content uses such an archaic foreign format that it would be much better in the long run simply to re-export the original assets. Of course, it doesn't correspond anymore to the reality of today GPUs. That's why I said: let's assemble modern components that correspond to the reality of today GPUs. The goal of the project would be to allow easy porting of games already developed with Torque to a more modern framework.
And there are some assets that can't reexport from a Torque game since they were made directly with the Torque editors. Those are: the heightmap, the alpha maps for splatting and the mission file (but no need to export that since it's XML).
Only thing you can do is hook into the terrain code and dump memory. Well the.mis file isn't XML, it's just plain text (TorqueScript) but I understand what you mean. It would almost be simpler to hook into memory and dump the heightmap, to be honest, than to try to write a converter for the.ter files. The problem I see is that it would still end up looking like Torque - the texture quality and resolution would not have changed. The art would still need another pass through the art pipeline to make it look worth a damn. Not saying that it shouldn't be done, but that it might not be worth it - a modern engine is so much more capable than TGE that the game would have to be rewritten and the art re-tech'ed anyway.
I think that a lot more community focus should be on creating a world editor and content pipeline, as well as a true engine for Ogre. Whether that be GOOF, Yake, OGE, WGE, or whatever. These projects need a clear driving force - a champion of the cause - one or two developers that are willing to go the mile and get the editor working, the content pipeline established, and the game engine up and running. They also typically need a solid base and examples, documentation and tutorials before they'll be adopted by the community.
Possibly even a full game implementation. Anyone that feels like joining GOOF, Yake, OGE, WGE, VisualOgre, Mage, etc. Should definitely do so and contribute to these tools/engines. I think it might be better to get someone like Brad who makes Ultimate Unwrap3D to support Ogre.mesh files with basic materials. It already loads and saves out Torque DTS files.
DIF and DTS are pretty limited formats that havent really changed in the past 5 years. I'd like to see more tools that support.scene and.osm to make misson building. Torque seems pretty clumsy to me and an entity system with a high level abstraction layer combined with simple programming can often achieve a lot more a lot quicker. I think the lack of actual finished games produced with torque and the quality of the games says quite a lot about torque. It's archaic, doesn't allow you to do things in your own way, and only the most experienced developers are able to dig out anything that resembles an actual finished game, and thats usualy with a couple of years of concentrated development time. Id like to see more collaboration on actual game development tools, and were going to be creating some tools in blitzmax with our ogre wrapper that we hope will be of use to the rest of the ogre community in time.
Currently we have Ofusion that were using for our in house projects, but were beginning to realise that for community members to use our wrapper we need some decent editors that can load meshes and save out to popular scene formats that are useful for game development. Rather than develop our own we would like to support OSM and.Scene and leave the editors open enough that your not restricted to our blitzmax wrapper and can use any general purpose ogre tool.