L B

I agree with Rick. It seems counter-intuitive to me to have to call IncRefCount. After all, why would I? I have a texture object, I want to use it, why should I do anything to it first? Similarly, using Release() instead of delete seems just as counter intuitive. Normal C++ would do exactly as in your first example. I understand you're removing internal classes this way, but for the end user, it's not prettier, not more intuitive, and will actually be a bother in the long run if we have to type this for every object. In the "source purity" aspect, this has the adverse effect of making me think this wasn't designed for C++, but just patched to work with it.

D'oh, missed it. Guess I should have done more game development in the past year.

I think you may underestimate the amount of work in an undo system for an editor as complex as Leadwerks 3's. But hey, it's almost over, so cheers.

I think Mirror's Edge is baked, not real-time. Unreal Engine 4 seems to do it as well. ParaToxic, I sent you a PM with the video.

It sure is possible, Unreal Engine 4 has it. I would link to a video, but Mr. doesn't seem to like that (understandably). Perhaps you could lookup their implementation details? What algorithms have you found on the web? Some theses might cover it.

Do it well, but don't release it months after the release -- it's a critical feature. I also go by the philosophy of doing from scratch, yourself, but sometimes you have to admit that some libraries exist that already do it well. Weigh the possibilities. People will start coding crappy GUI alternatives from scratch and redo them later.

I like the "Add Component..." approach better.

Yay! And thus, Leadwerks died to profit.

Procedural content generation truly is the future of indie game development. Not having to worry about artists for your props, level or even characters would give developers a huge boost in base assets, and perhaps help unlock funds with the added credibility for future specific assets in their game or software. I have a tree generator side project that I develop when I get time off school and other work. Here's a screenshot for the curious:

Expected behaviour for a fade would obviously be RGB, not HSV. I can only see this being used for unicorns, gay pride, or nyan cat.

FatCow includes the 32x32 version, y'know.

Oh but Josh didn't you hear? DX11, tesselation and PhysX just make your game instantly sexy. You only have to press one button, and voilà!

The only thing I'll ever bother using for communities any more is Vanilla Forums. It's the most lightweight I found.

Confirming, tested in my C# implementation. I would also like this fixed somehow.

Bumpitybump?

Oh, right. Well in that case, let me rectify my statement: Your killer CPU versus my puny 2.3 GHz Dual-Core.

Not to mention your killer GPU, vs my puny 9600 GT.

Approved by LordHippo: Here are some comparison shots of with/without Crysis' SSAO (not his version (sadly)). I think it shows the difference quite well.

Get better soon! You can do it Can't wait.

Can I somehow disable culling or improve this specific case then?

I see, thanks for the reply. Can I somehow disable culling or improve its performance though?

There have been many discussions about culling performance. Notably: http://www.leadwerks.com/werkspace/topic/4449-showhide-heavy-trees/ http://www.leadwerks.com/werkspace/topic/3995-entity-cull-time-optimization/ http://www.leadwerks.com/werkspace/topic/3956-model-setviewrange-causes-crash/ Josh often says that he needs a scene file to test. Here is one, along with the 3D model "filler.gmf" used in it. http://localhostr.com/file/rg5ZGkP/Culling.sbx http://localhostr.com/file/xT1HJD0/Filler.gmf http://localhostr.com/file/QIcDJF8/FillerLOD1.gmf Here is a screenshot of the performance assessment: I want to stress the following points: The polygon count is 25k, which is nothing for Leadwerks. Draw time is 1ms. The world time is of 7ms, 5 of which are taken by entity cull time. This is enormous. I often get 6 or even 7ms taken by the cull time, out of the total 7ms. There seems to be 2376 entities drawn, whereas the square is 24x24=576 cubes. The other entities are the directional light. Perhaps the LOD counts as 2, but even then, it's not 2376. If you don't see performance drops yet, try multiplying that grid 4, 8, or 16 times. Then you'll notice cull time starts to rise in the 30-60ms. Another interesting point is that when you look down from the basic camera view, there seems to be a massive glitch in culling. Although no entities are in view (screenshot shows some only to indicate how I lowered the view, but you can lower further to show none), almost all the entities and polygons are still drawn. Also note that culling still takes the most of the render time. This seems to indicate frustrum culling is not only slow but bugged. This needs to be fixed, as it causes massive drops in performance for apparently no reason. Or, there needs to be a way for us to disable culling in that case. I'm interested in learning how.

Note that Newton supports obtaining joint force (applied?), but it doesn't seem to be implemented in Leadwerks. The documentation pages are off: they seem to have been copied from another function description, and not edited. But the functions and definitions are there: http://newtondynamic...llGetJointForce http://newtondynamic...ointGetRowForce http://newtondynamic...ewGetJointForce http://newtondynamic...erGetJointForce http://newtondynamic...geGetJointForce The ball joint seems to be properly documented. It should be really easy to implement.

I'd like to know a couple of things about joints: Can you (and if so how?) get the amount of stress (unit: Newtons) on a joint? Are stiff joints finally fixed? http://www.leadwerks...f-newton-joints The bug tracker is down. Without this, a lot of physics breakage simulation is hard. I could get the force on collision, I guess, but I can think of a case where I'd like the joint to break without any collision, out of the sheer mass suspended to it.