Jump to content


  • Posts

  • Joined

  • Last visited

About lowlevelsoul

  • Birthday 10/28/1976

lowlevelsoul's Achievements

  1. https://github.com/rextimmy/Torque3D/tree/mac_port Cool - although I can't check it out - I think rextimmy has to allow me to have access. I'l download the zip for now and take a look at what's going on.
  2. So I have a Mac and I'm willing to do some work. I checked out the repository from Jeff's repository, but CMake has a bit of a fit when generating a project for me to use. What's the state of the 3.9 development branch? Is it worth checking that out to test?
  3. I think this is a terrible idea. The main strength of TS is that it's a scripting language aimed at making games, and even more, it's aimed at making games using Torque. Shoe-horning another general purpose language just because it's "flavour of the month" is going to be problematic, and a real turn-off. It'll have to be hacked all to hell to fit Torque and rather than elegant ways of working with scripting within the engine. There will be workarounds, hacks, and things that never work quite the way that they need to. TS isn't broken. There's no need to fix that.
  4. In which case, put a condition on the part that adds the lateral forces from the tires. When you're trying to add torque to rotate the body. Of course, this means that you could end up with very large lateral slip values and you may end up with weird results.
  5. I think you may have already hit on the cause of your issue - the tire code is most likely preventing the body from rotating. Any changes in angular rotation will cause lateral slip on the tires, causing them to generate an opposing force. Have you tried commenting out the part of the code that applies torque and force from the wheels themselves?
  6. Have you thought about using stream out? I have a real issue with vertex shaders doing skinning in that they just tend to be inefficient (for a number of reasons). Using a stream out system would mean that; The vertex shader pipe-line is the same for all mesh types, reducing overall code complexity The vertex shaders and vertex formats tend to be simplified, reducing the number of render state and shader changes during rendering No need for multiple draw calls for single mesh due to constant/constant buffer limitations (there's also a caching cost on constant buffers) Anyhow...even if you hadn't though if it; excellent work. I've been looking through the render pipe-line and my first thought was "aye caramba!". It's a clever person who can look into the eye of that beast and do something productive!
  7. I think object pooling, while a memory issue, is something that's done to the implementation of that particular system. It's not just allocating objects that tends to be problematic, but also, the lists that these objects manage internally. And since they tend to use templated contains such as Vector, it makes it problematic to ensure that objects are allocating from a single pool of memory. In short; it's really down to the overall design of the system, such as particles, rather than relying on a catch-all technique. This however, is where a memory manager can come in handy (as well as good profiling tools). If you can track where allocations happens (Vectors, Console Object types etc), you can get an idea of which systems are doing lots of allocations and and prioritise a re-design of how they use resources. I'm leaning towards a platform hook to create a mutex for the memory manager itself. Which brings me to the next subject. I downloaded an old version of TGE 1.4 from my account at GG to use as a testbed for a new memory manager. I wrote a small memory manager that implemented some of my requirements using tlsf that hooked into dMalloc, dRealloc and dFree. It worked pretty well as it turned out, and gave me some interesting stats on the Stronghold FPS demo bundled with the engine. The most interesting thing, was that I used lazy initialisation in the memory manager because I didn't want to mess round with figuring out where to put it. This was a good thing, as there are lots of global static objects such as Mutex that call new or dMalloc in their constructors. This meant that the allocator was being called before main was called! I also got some other interesting stats from the Stronghold demo; In-game mem usage ~19MB Peak mem usage: ~21MB Number of allocations: ~48k Number of frees: ~21K Number of realloc calls: ~4K (alloc and free were also bumped up by this) I meant to track the number of allocations below 16, 32 and 64 bytes as I have a feeling there's a lot of those going on but I haven't had the time. Once it's up and running, I'll transplant it to 3.6 or 3.7 and see what interesting stuff I can find.
  8. I'm willing to help. I'm not sure how much time I can give right now as I have other commitments but once those are out of the way; I'm willing to devote some time to the Mac build. A little bit about me; I've worked as a programmer in the games industry for the last 16+ years on a variety of platforms. I've worked on platform base code, rendering, physics, animation, collision detection, content tool-chains and a whole load of other bits and bobs. Currently, I'm employed by one of the big three console manufacturers as part of their development support team. Right now, my main issue is that I've been contracted to write a book which I'm trying to finish. Once that's out of the way, I can spare the time.
  9. I think the basic problem is that you don't have much (if any) experience in vector and matrix mathematics. In order to do any programming in 3D-space (or even 2D) you really need to learn about this stuff. In fact, I'd say you need to be able to do 3d math as naturally as you would count to 10 (without using your finger). Unfortunately, teaching this subject is a wee bit beyond what I think the members of the forum can do. In principal, you seem to have a good understanding of what vectors can be used for. Which is great; an intuitive understanding can help a lot here. I'd recommend looking up some vector tutorials online and reading a bit more about the fundamentals. Don't be put off by having to learn. I completely failed at school - you could't find somebody who was a worse student that me. But I was able to learn this stuff on my own in the evenings, while working on constructions sites during the day when I was 17/18. I'm pretty sure you can manage this without any problems.
  10. [mention]Gibby[/mention] - yeah, I found this out last night. I had to pop into the IRC chan to get some help on why I was getting an error with cmake. It looks as if the Mac version needs some significant work to be done to get to being close to usable - stuff doesn't compile and even if I could get the 3.7 rc candidate to build; running might be another issue all together. I'm sorely tempted to just use TGE 1.4 and write new render pipeline for it - I used it this evening to implement a simple version of the memory manager that I had proposed in the C++ forum and ran some tests. The Stronghold starter.fps demo was interesting to see in action again. I got some really useful metrics and some interesting results.
  11. I never tried to add 3rd party libs with the old memory manager, but I don't think new is overridden globally. I haven't grep'd this too much though, but all I saw with the memory manager define was new being overridden per class. Overriding new globally can cause some issues though. A good example is anything that uses stl and uses a container which is either declared as static/global. So the container tries to call new during startup, before main is called, and everything explodes. I've also read the opposite - that this used to be true but isn't any more. Are there any sources for this? It could be that os memory calls have gotten better. I know that on Android (as of a couple of years ago) they were slow-ish and the same goes for iOS. Under Windows/Linux/OSX this may have gotten much better, but there is still the following issues; Having lots of allocs from os allocators could cause virtual paging to be slow or even erratic.Instances where lots of small allocations below a certain size tend to be slow in comparison to a specialized unit heap allocation system. Then there's console, where memory interfaces can be massively different. The calls to malloc/new et al tend to be wrapped around system specific libs. Not to mention manipulation of the CPU VAT in lieu of a buddy-allocation scheme to get rid of fragmentation (typically, I see this on engines primarily aimed at PC and ported to console). And even if os calls and paging isn't an issue, having an underlying allocator that will deal with specializing in small allocations and helping to reduce fragmentation on systems with very primitive allocators (Playstation, Nintendo) is very helpful. And if a platform specific allocator needs to be written to make use of CPU VAT, then it's an "easy" task because all the memory allocation stuff goes through a single interface. Good question. In order to avoid namespace pollution in the rest of the engine, the classes are defined in platform with a forward declared struct that holds the platform specific stuff for the implementation.For example for the Mutex class this is called PlatformMutexData, and the Mutex class internally holds a pointer to that struct called mData. The actual implementation of the Mutex class is done on a per platform basis. In PlatformWin32 for example, there is a mutex.cpp file that does this and also defines PlatformMutexData. In the constructor of Mutex, mData is initialized by allocating the PlatformMutexData struct using new. It looks a little like this; struct PlatformMutexdata { CRITICAL_SECTION mCriticialSection; }; Mutex::Mutex() { mData = new PlatformMutexData; InitializeCriticalSection(&mData->mCriticalSection); } On the surface this looks ok (if a little shoddy). But if we're to use a Mutex inside of the memory manager to make it thread safe, we end up allocating memory for the Mutex BEFORE the memory manage is initialized. There are some possible solutions to this, which are :- Re-write the thread/sync classes exposing platform specific details to the rest of the engine to avoid calling new (easy, but bad)Re-write the thread/sync classes to use a custom allocator system (less easy, but prone to bugs and other issues) Re-write the thread/sync classes to do interface hiding in some other easy way that I can't think of Implement an interface for mutex's in the platform layer of the memory manager (easy, but more a little more work per-platform) I hope so. As long as it's implemented properly, and can be turned on and off it should make general development and porting a lot easier.
  12. Hey guys. One of my pet peeves is memory management. It's something that bugs the hell out of me. Not because I dislike it, but because from experience, managing memory can be super critical in making sure that your game runs smoothly and depending on the platform, is stable. The principal idea is to avoid calling the system memory allocation libs as much as possible. This helps would give the following benefits; Performance - system memory calls are typically very costly so they are avoided as much as possible.Helps to reduce overhead caused by OS memory paging/virtual mapping and re-mapping. Helps with stability as free'd memory blocks can be coalesced with surrounding free blocks. Memory fragmentation should not occur or only happen in very rare circumstances Helps track down issues w.r.t. memory bugs Helps for future platforms with limited memory (mobile, console etc) compared to desktop I tried enabling the memory manager in RC 3.7 and got a whole load of compiler issues. I'm not all that bothered. by that because the existing manager is messy and relies on overriding new within classes to get it to work properly. I'm thinking of implementing a new memory manager with the following requirements; TLSF based - an open source, reliable memory allocation scheme. I know that Unity uses it for it's underlying memory alloc stuff on console.Globally overrides new and delete. Now, I KNOW that this is a massive issue for some folks. But in my view it saves a lot of pain and effort. Memory allocation/free tracking. This comes at the cost of of extra memory usage, but is extremely handy in helping track down unused memory, multiple free bugs etc. Allocate memory in large "pages" which are managed by tlsf. Provide specialized heaps such as a block heap to reduce the cost of frequent small allocations (64-bytes or less) Thread safety - there's an issue here with the way that the thread/mutex stuff is implemented in Torque right now - these would have to be re-jigged. Labeling of where memory is allocated from and why - slightly different than tracking by source file. Able to identify things such as resource/sim usage. I intend to implement most, if not all of these features in my own build and test them out. Now what I want to know from you guys is; Is this something you feel would be useful to you?What other features would you like to see? Is it something that you would like to see in T3D main branch (really one for the steering committee I guess) ?
  13. Thanks for the tips, Gibby. Depending on if I have time tonight or not (I have book to finish and my publisher is nipping at my heels) I'll install CMake give it a go. I did download CMake last night, but saw posts about using the generate commands else where - so I figured I'd see if it was the path of least resistance.
  14. So at what stage is the Mac port currently at? What sort of help is required to get it running? I've been a Torque user on and off for the last decade or so and would really like to start using it once again, especially on my main computer which is a nice little MBP. I'm willing to put some time into helping, as the other alternative is to write my own engine/editing suite to make my game idea(s). I'm more than capable of that, but I think less time would be spent helping out with T3D in the long run. I'm not a big fan of Unity and having worked on an Unreal Engine project on console a while back - that was enough to swear me off it for life. I have a couple of decent windows machines that I can use, but as I said, my MBP is my main machine here at home and would like to stick with working on OS X. ** edit ** I've cloned the latest repository for GitHub and run the generate projects command. However, Xcode refuses to open any of the Full projects.
  • Create New...