Mumbles

facepalm moment. I hadn't noticed this was the second page the link is on the first page... It must be because Filax has the first post on the second page I just assumed it was the first post in the whole thread. I thought this thing sounded familiar, and now I've seen the screenshots on page 1, I remember it. The attachment is still there, but it took a while to respond, so, since it's still sat on my hard drive...

I use Sleep(1) instead of Sleep(10). About 2% CPU usage but far more physics updates can be done in that time than just with VSync alone... Since I run physics at 100 UPS that gives each step a total time of about 9 ms to run whilst still leaving time for networking (in future) and keyboard/mouse input.

Yeah, Direct X's dominance was short lived. Microsoft got too cocky by insisting that that you had to leave XP behind if you wanted DX 10 or newer. I believe the current Leadwerks engine uses Open GL 3.3 for its graphics. LE 3 should be coming with an Open GL 4 renderer on supported hardware which should easily match DX 11 ... whilst also being able to run on Linux and a Mac...

How much do you pay her to answer the phone?

Don't blame intel for the mac. Apple chose to switch to intel's new processors. No one held a gun to the figurative Apple's head. But hey, I've stuck with AMD since 2001. A processor that works and sold on its own merit rather than by corporate bullying, and now outright lies...

It doesn't - and you need JointLibrary.dll as well. Confusing when you use your own version of Newton 2.25, which has renamed it to dJointLibrary.dll It's so tempting to get rid of the other redundant one but you just can't...

I swear this topic wasn't here yesterday, I posted in the other one...

Maximum number varies by hardware. Perhaps let the user decide how many lights they want active at a time. Through playing, they will find out what the best number is for them. Closest 10? No, you could assign each light a "Zone ID" and each time you change zones change which lights are turned on and which are turned off. A zone could just be checking the bounds of a box. If you check the distance to each light every frame, speed will suffer.

Numbered them just to make it a bit easier 1: No 2: I'm not sure. There may be a Leadwerks GMF exporter available for blender, but you cannot lead .blend files... 3: Not sure, but why would you want to? Dynamic is one of the best points about LE 2... 4: Not really. You can place your assets in a password protected "pak" file (just a standard zip file, with the extension changed to .pak). But your password will have to be stored in the executable, so anyone who knows how to, can disassemble your code and get the password back. Without requiring an Internet connection to decrypt your files every time, it's almost impossible to ever fully protect your assets. 5: Difficult to say, there are several languages here used by the community. C (and C++), BlitzMax and C# are probably the most common. Most users will be using lua in addition to those listed, and some may be using lua only. Hopefully that has answered some of the things you want to know. But like I say, I'm not too sure of the answer to your second and third questions...

I had it working in VirtualBox... at like 3 fps for the rotating cube example mind you...

Amber?

If I get it to such a state that I would feel comfortable releasing it and if there are people that want to use it. I would most likely make a library of it and and release it. Oh believe me, there will be people interested in this. I am for starters. A more important question would be: is it going to be free? The only bit of a GUI I've managed to do is a progress bar... with blocks and rounded edges! (rather than a solid fill with sharp edges) Some achievement huh? This however, is exceptional stuff

It should be fine to leave out, but don't hold me to that though. Then I'm again, I'm a C nerd, and take care of my mallocs anyway so I've never found myself living by a garbage collector (Maybe we should call it a "bin man" because it's quicker)...

LE3 runs on Mac computers. Most LE2 executables will work in Linux, using wine, therefore the OSX port of wine should work too. But the executables themselves must be compiled as Windows executables, they cannot be compiled natively in Linux or OSX...

Easiest is guess the number. No fancy graphics required

It's not just an OSX thing... and shouldn't the slash be the other way?

And not a single mention of fortran... Welcome back...

You have a source license for LE3 too? Even though it's not finished yet?

Oh dear, Apple's tech isn't doing particularly well in any of the questions. Maybe new customers will change the opinions, but the current user base doesn't seem to share your desire for the Mac, Josh... I mean take the first question. Linux is doing better than both of the Apple options combined.

I was kind of thinking that same thing. You would assume anyone wanting to sell their game would vote basic graphics in order to hit the most machines. Tell that to id or Epic... I don't see them building Open GL 2.1 renderers anymore. Actually, I don't really see Epic using Open GL at all these days. Relying more in the console market to fill the void of PC users who aren't up to spec... Actually, is there any reason this poll is private? Would there be any significant problems with seeing who wants support for each platform? Right now, all it would really reveal is which two users are looking forward to OSX support...

Where's the option for "not interested in mobile platforms" for the second question? Of the two available, I'd go for Android, but really, I only picked that because 'none' wasn't available...

I don't know, but doesn't your first buffer need BUFFER_DEPTH as well as BUFFER_COLOR?

The problem is that some dishonest individuals reset their trials, meaning that they never have to buy the software, and it's almost impossible to prevent.

The LE3 deferred renderer will not work on SM3? Strange considering the LE2 one does, doesn't it? Mind you my experience with SM3 cards on LE2 was slow (big time), and at this point, only you would know if your FFP implementation works faster on SM3 cards than the deferred renderer does. Or is it because so much functionality of LE2 was unavailable on SM3 cards?

What is "o" in this example? Because if it's not an int, then why would you use the "pointer to an int" typecast? (Line 1) Also, by converting your pointer to an int, 'pointer' will not be a hex value, every digit will be 0-9. Print it out to the console if you want but I'm almost certain that by casting it out of a "pointer to a" type, that the A-F values will be lost. Essentially, what's happening is: o is a pointer to an object. The value is (for example) 0x20 (of course in reality, you would never get such a low number) pointer is declared as an int, but we are not ready to assign its value just yet because we have to do some casting first , in the order of right to left a temporary pointer is created, it has the same value as pointer (0x20) but this pointer instead declares that the target memory contains an int, not an object. a temporary int is created, it has the value value 0x20 which has a binary representation of 00100000, which is 32. pointer is initialised to this temporary int value: 32 because you are putting the int into the stringstream, and not the pointer, "32" will be added to the string stream, not "20" Object *ObjectPointer = &o; //If o is an object, do this one, otherwise do the one below Object *ObjectPointer = o; //If o is a pointer to an object, do this one, otherwise do the one above std::string hex; stringstream ss; ss << hex << ObjectPointer; should keep it in hex... Either that or I've gone a bit cuckoo...