Josh

It's easier to develop for all platforms I intend to support at once. It would be much harder to go back after the fact and find out I have to change things around in a product that is already in use. Past a certain point, I can just write code and not worry about which platform it's running on.

Chasing features is the worst thing I could do. It consumes an enormous amount of resources, increases the complexity of the system with each thing you add, attracts the most unrealistic dreamers, and you will never satisfy who you are trying to satisfy because their tastes change each week. With Leadwerks3D I am focusing completely on the user experience and the ability to create gameplay. The entire focus is on the core user experience and facilitating the production of games, since that is where most people have trouble, in every system I have ever seen. You get severely diminishing returns as you add more and more abstract features, and if the core experience isn't easy and simple, you can never go back and "fix" it without starting from scratch. I am betting that a good core experience with excellent documentation will win based on what I have seen over the years.

Unity is somewhere around $3000 for the real thing and Unreal has been free since the beginning of time. That's how Red Orchestra came about. (And Counterstrike, with the Half-Life engine.) They changed the terms a bit and rebranded it, but it's the same situation that's always been.

I haven't actually had the Leadwerks3D editor running on OSX Lion until a few days ago. There were some underlying GUI issues that had to be updated to handle a few new ways that OSX Lion does things. The first run was pretty frightening, with random crashes and all sorts of visual inconsistencies. However, careful testing resulted in these issues being resolved one by one. The most peculiar was a bug in which the editor would crash when a file request dialog was opened if, and only if, it occurred any time after a popup menu had been displayed. The error displayed read as follows: I initially assumed this was some weird Mac thing that got changed between Snow Leopard and Lion. Google didn't provide much help. Finally I came across this page which hinted that other applications may have a problem with this "SCFinderPlugin" thing. Following the instructions here to uninstall the plugin made the problem go away. Then I remembered that SCPlugin was a sort of TortoiseSVN for Mac I tried out, that I never got to work. Apparently, it causes EverNote to crash when viewing PDF files, and there happened to be a PDF in the folder the file requestor opened by default. So now the problem is eliminated and the Leadwerks3D editor is working pretty well on Mac. The interface is still ugly and unrefined, but important functionality is working the same across Windows and Mac. And now I am off to fix a few Leadwerks Engine bugs reported here...

I always found CamStudio to be very slow. I've always had the best results with FRAPS, it seems to be the only one made to capture at a fast rate.

If all you need is a forum, I recommend XenForo.

A lot of times complex systems will run okay with small amounts of data, but if performance scales in a linear manner as the amount of data increases, you will have much worse performance than if you do something clever to change the way it scales. This is true of both 3D graphics and database applications. In 3D graphics, we do things like clustering objects in an octree so that large numbers of objects can be discarded without iterating through them all. In database applications, they do stuff like caching and who knows what else to make applications scale in a non-linear manner. I can't say exactly how database applications are designed because it's not my area of expertise, but there's a lot of work that goes into it.

I believe you could set up a very rudimentary system in two days, but a fully-featured system that scales well would take a very long time to learn and develop.

I generally categorize every aspect of Leadwerks as either "absolutely required" or not necessary. If it's categorized as the latter, I don't bother with it, and if it's categorized as the first, I pursue it with a dogged determination until it is done. This has served us well in many ways, like our vegetation rendering system and character controller. However, this assumes I have full control and mastery over the product, or at least have someone working for me who does. This is almost always the case with software development. I do not have the same power over other aspects of Leadwerks like the website. Our bug reporting system, based on IP.Tracker, was an unsupported unofficial add-on offered by Invision Power Services. That means they offer it, but if anything goes wrong you are on your own. This should have steered me away from using it. I generally never use any third-party add-ons, especially free ones, but the features were nice and it was compelling. (The one exception in our system is our chat system, which has functioned wonderfully, but also came with a fairly high price tag. Correlation?) After installing IP.Board 3.2, I attempted to install the new Tracker that works with it, but the installation process would not work. I even got IPS to look at it, despite their policy of this being a non-supported product, but their "fix" was quickly done and didn't actually fix it. I could keep pestering them, but I've already spent a lot of time on it, and we're never going to get a real solution. Even if it could be installed successfully, a new problem could arise at any time, and we'd be back in the same position as before. The application hasn't been updated since August of last year even though there are outstanding bug reports. Despite all it's complexity, there's really no other forum/CMS that comes close to the features IPB offers. Anyways, the point of my long-windedness is that I'm giving up on upgrading IP.Tracker and created a bug report sub forum here: http://www.leadwerks.../59-bug-reports The data is all in the database still, and there's a possibility we might be able to migrate it into the forum, but I honestly wouldn't count on it. The value gained per unit effort is getting very bad if I keep going down this road. Additionally, the new IP.Gallery application is so badly designed I consider it unusable. Even before the upgrade, people frequently posted images in the Showcase forum rather than deal with the complexity of managing albums and uploading images into different categories. I have implemented a custom system here we have complete control over. I encourage you to re-post your images here where they will be safe, and I have complete control over the layout and design: http://www.leadwerks...ce/page/gallery I have posted a few images there to test with. If I posted one of your images and you would like to re-post it in your own name, I will gladly remove my upload. Additionally, the latest images will soon be added to the Portal page, mixed in with the latest videos thumbnails. A link to the old gallery will remain at the bottom of the Gallery page until April 1, 2012 so you can access your images. This is a complex site, and I am operating it with a minimal amount of IT support. Going forward, we are going to implement a few policies to minimize problems. 1. No third-party applications or features will be utilized, with the exception of our chat bar, which is a paid third-party product that has always functioned perfectly. 2. When a custom database can serve our purposes, that will be preferred over third-party applications and even some official IPS applications. For example, I implemented a custom database for the video section, articles, and replaced IP.Gallery with our own system. (I do not have any plans for any additional databases or website features in the near future.) The upgrade to the latest version of IP.Board was well worth it, in spite of those couple of problems. First, it would have been very difficult to find a designer capable of and willing to work with the old version. Second, the new system cleans up a lot of the functionality of the older version, which oould be quite chaotic in some places. Finally, it ensures we are up to date if any security issues should arise. There hasn't ever been any, and I have no reason to believe there will be, but it's best to be prepared. IPB 3.1+ was really an infant product compared to the more mature version 3.2. Further versions of the system are not expected to be such drastic changes, as the feature set and design has solidified quite a lot. Thank you for your patience and especially for generating all the great content that makes this site so fun to browse.

This says that card has 96 stream processors ("CUDA Cores") and a gig of VRAM which should be good, but your performance seems dismal for some reason, in everything you have posted. My frame rates with an old GEForce 9800 in the arctic scene are 60 FPS, I think. http://www.geforce.com/Hardware/GPUs/geforce-gt-530-oem/specifications You're sure it's not a GEForce 520?

The master speaks.

I know what's going on... Since your framerate is below 60, the physics are being updated multiple times per frame. After an update, the force is reset to zero. If your framerate is 15, the force gets carried out on the first physics update, but does not on the next three that occur before the world update function finishes. It's better to call any physical functions like this in an entity or world physics update function, so it always gets called before each physics update occurs.

I can't immediately.

I changed my response since I don't see anything wrong with your code.

That does seem strange.

Gravity is a constant force of 9.8 meters per second squared. Gravity causes objects to accelerate. If you want a constant speed use CalcBodyVelocity to figure out the required force.

There's no way your FPS should be that low unless you have some setting really massively off. Distance culling would be the most obvious issue.

At the point materials and shaders are enabled in the rendering pipeline, the code has no idea what entities are being drawn. All it has is a 4x4 matrix. Materials are not enabled per-entity. They are enabled once for each batch of surfaces drawn.

Yep, that's why everyone is just installing straight to the C drive nowadays.

Turn on SSDO, make your ambient light dark desaturated blue, make the sunlight slightly orange and crank the intensity up, enable HDR, and that will look fantastic.

There's not necessarily even an entity associated with every material. I would use the entity draw callback for anything that needs the entity.

Sorry, the docs were wrong. There is no second parameter in the callback: http://www.leadwerks.com/werkspace/page/Documentation/le2/_/command-reference/materials/materialdrawcallback-r295

You don't have to redo anything, just click the option and it will work.

It looks like your text resolution is really big, but I don't see how that would make a difference. Go to Help>About and it will show the version of the program.

It should look like this: