Mumbles

Would you not write p.a = a? since Projectile::a is a pointer to a pointer, and _tmain::a is already a pointer... That would allow a "straight passthrough" I could be wrong, but it looks like p.a isn't actually pointing to _tmain::a's object instance - it's pointing to where _tmain::a's pointer is located... p.a = &a would be correct if your actor object instance wasn't created by pointer... as in: Actor a(); rather than Actor* a = new Actor();

Sounds like a stray pointer issue to me... Are you using any pointers to your Actor class? Actor * Blah = new Actor(BlahBlah); Actor * ActorPtr = &Blah; //ActorPtr might be a void pointer in another class (like "UserData") but you get the idea ... delete Blah; Blah = 0; //ActorPtr still thinks the actor is valid - attempting to use it will crash

Graphics(800,600,32);

This one? I think this is like 2.0 time...

Hoodwink Aggror's Community Project Furious Frank Just a few of the playable Leadwerks games...

My reason for mentioning that was that I'd assumed you perhaps used the more common block size of 256-bit. I actually meant to write that, because otherwise, I say 128-bit is up to 128 times faster. 128 times faster than what? I used to wonder why transferring to and from my computer remotely, away from home, only averaged about 80K a second. I used to believe it was just our Internet provider throttling traffic as they all tend to do until it was pointed out to me: Everything you do on SFTP and SSH is encrypted, by default, your key will be 2048-bit. You can do in plain unencrypted FTP if speed is the most important goal, but there will be no security - so no point even bothering with passwords. Encryption with block sizes that high is typically far more CPU intensive than it is I/O intensive, and mainstream workstation CPUs just can't process such large blocks as quickly as we'd like.

Sophos is very sensitive. There's no official ranking, but it's one that's used by universities and large companies. I'd guess that the only reason banks don't use it is because they mostly run Unix, and there for can't run it, and indeed don't need it. As far as encryption and compression go, they weren't really a problem, and in fact something I would have like to add to my project although perhaps maybe a smaller block size for the encryption would be better. Unless there's a significant weakness in the algorithm (in which case key size won't matter), 128-bit AES keys are probably more than sufficient and anywhere up to 128 times faster to decrypt, and considering distrubited.net is expecting to take 200 years to brute force a 72-bit key, exhausting all possible combinations. It looks like you're decrypting and decompressing into RAM, and then loading your media straight from the RAM. How you'd do that I have no idea, but I'd guess you're setting a mount point in RAM somewhere. On Linux it's much easier, you just have to create a mount point in your directory structure, and mount that to a temporary ramfs and then it can be treated just like any other directory.

Except of course, write your game for you... ...and protected. When (or if) you start creating sub-classes, anything marked as private is not usable by the new subclass, whereas protected is usable by the subclass (and obviously public is usable by all)

"I hear that Leadwerks Engine 2 will be released in about 500 years." For some reason, she didn't jump for joy at that statement. Side strafing seems faster than forward running, and sideways runnings is insanely fast. With an FPS of only 30, my AppSpeed was almost constantly between 1.95 and 2.08 which may have something to do with it if you can't reproduce this straight away. It looks nice but I wasn't too happy to wait 4 minutes for it all to decrypt and unpack, then as soon as it tried to run, the Sophos on-access scanner quarantined it. It was declared as HIPS/ProcInj-001. Since it came from what I believe to be a trusted source, I simply authorised it and then after another 4 minute decrypt and unpack was on my way

That's the exact one I was talking about. Now how did I not find it?

I think there was something which could play Theora on a texture by Niosop. Can't remember now, and searching for the word Theora gets no results.

I believe we used to have another with a display name of DJDD, now known as Scott Richmond. As for Moose, I think he's from before Werkspace even...

I'm not even sure the collision results are totally accurate. I just don't think that entire panels would come as easily in reality as they do in that example video. Take the first crash at 0:25, at 0:28 a fairly large piece just crumbles away. What are the cars made out of? Cake? Aluminium might buckle, it might bend, I suspect it would buckle and bend, and then stick out of side such that it would chop off anyone's knees if it then drove past someone closely enough, but I doubt it would just come clean away like it did there. Also I was kept wondering "Where's the engine? You know, the bonnet (hood) just looks like it's an empty hollow box in that smash" Then the rear part of the truck (where you might hide an illegal immigrant under a canopy) doesn't seem to be welded to the cab at all, even though I would have thought it would be. Look at 0:08 where it just wobbles completely independently of the cab. It casts doubt in my mind as to whether to collisions and deformation are as realistic as they claim.

When I first started reading files through the ifstream interface, I used to copy in blocks of 256 bytes. Obviously for huge files, it took forever. Now I just seek to the end, get the overall length, make sure the pointer I'm reading it to is large enough, and then use that value as the number of bytes to read for the read command.

You can only read from one location on the disk at a time. It may be a little nicer if you are using an SSD, but really, you would do just as well reading the first bit of data, then seeking to the second half of the file (using the above snippet) and reading the other bit of data, all in the same thread. This also doesn't waste CPU cycles switching between the threads. A non-SSD drive would be a nightmare in that case if the chunks of data were at least 32 MB. Constantly jumping to different locations on the disk to serve the two threads at the same time, when disk I/O is the single slowest thing a computer can do... I/O is always better done in serial, rather than parallel.

Maybe he's teaching his students on computers powered by hamsters running around in their wheel, with the graphical capabilities of an etch-a-sketch. A put another way, old computers without OGL 3 capabilities...

I'm not a purist by any means. For starters I don't see the problem with Valve releasing software on Linux like a purist would. I use Debian yes, but I use XP too, and will do for some time yet - especially when it comes to development. The majority of gamers are still using Windows. Whilst Code blocks works for windows too, VS 2008 is what I'm familiar, and comfortable with. I have tried code blocks and I just wasn't as comfortable with it. What's popular amongst everyone else is irrelevant - forcing myself to be a lemming and use something I'm not comfortable with, just because everyone likes it, will adversely affect my productivity. That and I don't know too much about how code blocks works with the Platform SDK - if it can use it at all, since my project does use that. Ultimately, I'm a classic example of why Microsoft gives their professional range away to university students for free. That's what you learn to use at uni, and you get something of a vendor lock-in. Again, I'm not as comfortable with 2010 as I am with 2008, so until any IDE can match 2008's comfortability, that's what I'll stick with.

I use SDL with visual studio, but not for Open GL. I find creating graphics contexts so tricky, that I rely on the fact that a call to Graphics() in LE 2 creates a valid Open GL graphics context - from there your application can use any valid Open GL commands.

I consider my opinion vindicated. I didn't join this project, and sure enough it actually seems to be making very good progress...

Strictly speaking, wine isn't an emulator. (Despite the urban legend, wine does not stand for "Wine isn't an emulator". Since you'd get stuck in an infinite recursion if you attempted to resolve the letters to words) An interpreter would be a more accurate description, although I believe that's not technically accurate either.

Of all the people the spam bot could have impersonated...

Find a time when he isn't. It will make headline news Treason! Orrf with is head!

Wrap calls to malloc, that's easy As part of what I'm doing: // this is the call back for allocation newton memory void * NewtonMalloc (int sizeInBytes) { TotalNewtonAllocated += sizeInBytes; #ifdef DEBUG_NEWTON_MALLOC std::cout << "Newton malloc'd " << sizeInBytes << " bytes. (Total: " << TotalNewtonAllocated << ")n"; #endif return malloc (sizeInBytes); } // this is the callback for freeing Newton Memory void NewtonFree (void * ptr, int sizeInBytes) { TotalNewtonAllocated -= sizeInBytes; #ifdef DEBUG_NEWTON_MALLOC std::cout << "Newton freed " << sizeInBytes << " bytes. (Remaining: " << TotalNewtonAllocated << ")n"; #endif free (ptr); } realloc is more of the same, as is delete. new is a little more complicated though, as you would probably find yourself writing one function per object type, and on top of that, 1 per overloaded constructor. Unless I'm missing something

Cats aren't off topic...