Mumbles

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...

Wait a minute, you followed him into this thread...

Never do that for games. No client wants to be kept hanging around waiting for physics updates, simply because "there's less overheads if we wait 100 milliseconds for a few more updates". Send them instantly or else your client side synchronisation will be horrible. If you're employing the same idea I am, "full" physics updates go via TCP, and they must arrive timely. They're sent only once a second, so any going missing would be a disaster - I might increase it to 2 per second. But delta updates for dead reckoning instead go via UDP, and it's not a serious showstopped if one arrives late (or never at all). For everything but games, yes, wait for data to reduce the overheads, but for games, ignore it and send instantly. It would be a good idea to place the networking in its own thread - possibly more than one thread even. For a server, I'd say a minimum of one thread per client As for sending data, the RTT is all that's really important. You don't need to know how quickly 100 MB transfers from the sender station to its receiver. But if it's taking 200 milliseconds for absolutely any packet to be received, in a game that ticks 25 times a second, the data is 5 ticks out of date by the time the client receives it. So if the server overrides any predicted physics, there could be 5 ticks worth to recalculate, which a player has a good chance of visibly seeing, and it negatively affecting their playability. On the other hand, someone who has a ping of 30 could completely catch up and be synchronised with the server, resulting in any server enforced correction being barely noticeable at all...

The return val of send() doesn't mean the data has been transmitted, it just means that the receiver is able to receive it. send() only returns an error if (for example) you try to send data, but the receiver station has hard closed on you. Check what recv() is receiving, it may be mixing several packets together. That's the sort of thing Nagle does...

That's the default for winsock TCP sockets... If you want to disable that, and send instantly: BOOL bOptVal = TRUE; int bOptLen = sizeof(BOOL); int iResult = setsockopt(/*Your socket handle*/,IPPROTO_TCP,TCP_NODELAY,(char *)&bOptVal,bOptLen); pinched straight out of the MSDN... I presume those silly capitalised BOOL and TRUE are defined in winsock2.h. However intellisense seems to be having one of those days for me where it doesn't want to tell me

Perhaps I was reading the documentation for the Linux version (although if that's the case, why haven't I found the doc for the Windows build? I mean, I use SDL for joystick handling!). I mean, SDL did start as a Linux library didn't it? SDL_net relying on SDL... I didn't know that, but it equally sounds plausible. The only part I had a hard time believing was the SDL and Direct X bit. Although thinking about it, I think I remember you in the past telling me how it uses DirectInput for its joystick handling on Windows, hence why it has the silly triggers thing when using 360 controllers in Windows, but doesn't in Linux. Such that (off topic) I eventually programmed my controller class to use both SDL and XInput for joystick support (although, only one at a time per controller), just on the off chance that if a 360 controller was used in Windows, both the triggers would work correctly.

Really, I can't find any mention of Direct X in SDL, but there's plenty to do with Open GL... I can't see SDL achieving its cross platform goals if it relies on Windows proprietary graphics APIs.