Mumbles

Does WaitEvent() block whilst it's waiting for an event or does it just return null if nothing is waiting? If it blocks (either indefinitely or up to a maximum interval) then you'll really feel the advantage of multithreading. And in that case, you would have been better going for a quad core with lower clock speeds. Parallel computation always wins over raw speed. But it's a bit late to say that now anyway, you've already ordered the thing.

Oh, I thought you meant it compiled fine but crashed whilst running. Sounds like there might be a problem with your engine.h file because the missing identifiers are fine for me. The AutoUpdater might have an updated version. If need be, do a clean install to a new folder, then copy the new engine.h over the old one.

Well, that's the fastest solution. float a = 200, b = 800, ratio = a / b; would also work because by the time 'a' and 'b' are reached they are floats. In Rick's case it evaluates the constants (as ints) as 0 and then stores the result as ratio

If your project is a VS2008 console application, press CTRL F5 (starts the project in release mode without debugging). Now when the error occurs, the command prompt window will stay open so you can see which file is failing to load.

I don't get that in 2.27 but I also always run in release mode

Well Josh, don't feel too bad, You already knew more than me. I never even knew clock() existed! All this time I've been using GetTickCount() you know, the one that only updates once every 16 ms on win32...

Here's hoping. Hopefully he's trying to show the average gamer that Open GL is once again the king of 3D graphics. Once that bit has been done, they'll think "So why am I paying for this rip-off Windows (*'s)?" Then they'll think, "wow! Linux is free, and works with all my current hardware, so I can still use my Phenom II / i7, and it has a graphical interface too..." Then Linux will dominate, and it will all be down to Josh...

Don't forget though, that Mike is a programmer. Chances are, nice simple interfaces are actually more difficult than raw coding. I know that's true for me - C would be much easier than click and drag...

That model looks nothing like a citizen

The ProcessScene I have does not load terrains. That might be because I took it out though (I don't use terrains). In any case, I don't think it would be to hard to add in. The support from Josh for 2.0 is the same as the support for 2.3+ . The difference is that most users are used to the autonomous nature 2.3. I don't mean this in a nasty way but I think the majority of the 2.3 users were interested in more of a one-stop-shop engine, and writing your own scene processor would not have fitted that bill. That said, writing your own scene processor allows you to draw your own progress indicator with a fully accurate reading (Something a fair few users are still requesting).

3.1 sounds like a plug for LEO. Nothing really wrong with that, but I felt it was overkill. OOP is especially useful when you have several objects of each class. But take the engine itself. How many engines are going to be instanciated at a time? My feeling, "only one". it feels like rather a waste of time to set up all of access modifiers when there is only going to be one engine object. Now entities are a completely different story. Indeed I have made my own "Entity" class (original name, huh?) which basically does what LEO does anyway. But it's necessary for me because one of my entities will be made up of a Leadwerks TEntity and newton NewtonBody* sometimes even a NewtonUserJoint* . To do with structs in a procedural way would probably get messy after a while. That's the main reason I use the C interface. Things like the engine itself where I don't see the advantage of OO, stay as they are. But for entities, where OO feels to have a large benefit, I wrap the procedural bits up into my own classes... I don't think the engine can handle worlds that big...

I know this issue seems to be resolved now, but just for general programming practice, in your class declaration, you should move the TTexture texture; into the private or protected areas, because right now, the SetTexture function is not needed: TTexture TestTexture = LoadTexture( "abstract::testsprite.dds" ); Sprite TestSprite; TestSprite.texture = TestTexture; At the moment, that's valid. But in OOP, we don't like code like that. By moving the texture into the private or protected areas, you now must use the SetTexture function, which is a better way of doing it, because it's almost impossible to change the value by accident.

That works... until the commands require a graphics context. I'm not ready to do dedicated servers yet. But when I am, I don't want to have make loads of changes. I think it's better to try and get it right first time.

After a bit of reading, I can now invert a 3x3 matrix. Apparently inverting a 4x4 is jst a matter of breaking it down into four 3x3s? Or something like that... Maths just seems to be one of those things that if you don't learn in school/college, it becomes so much harder to learn it yourself later. If i'd learned it at college, it would probably be really easy for me to do...

I didn't have any issues with the A0 through D3 element numbering, I figured that bit out. My point was that a Vec16 didn't have an invert operation. At the time, I thought this was some proprietary code of Josh's that just didn't exist anywhere else. ...But it looks like DaDonik has solved that bit for me. The code on the highlighted site doesn't look very complicated... just long. I can live with long, so long as I know what it's trying to do. What I don't know about that code is why it works... But that's not important in maths. Maths isn't about explanations, it's about blindly following rules. Things only go wrong when you don't follow the rules correctly, or follow the wrong rules. In any case, when I get a bit of motivation back, I will try it out and hopefully carry on with the project.

I have two: A quake clone to learn from, and a sort of modern day mobster story, sort of like Mafia ... but without, the mafia bit. Not much to say about the quake clone, but the other one, is currently designed as an FPS with a cheesy story but attempting to make it otherwise quite realistic. Rather than simply using straight line raycasts for bullets, having bullets that are still insanely fast, that over time will: Lose speed Lose altitude Start to spin more erratically [*]An extension of location based damage Being shot in arms causing unstable aiming Being shot in legs causing stumbling movement Hand to hand combat that might knock weapons loose, or cause impaired vision if hit to the head [*]More realistic sprinting Instead of running for 4 seconds and taking 5 seconds to recover. Be able to sprint for about 1 minute, then constantly slowing down for another minute, Recovering taking about 3 minutes if standing still or 6 if constantly moving. [*]Removing unrealistic accuracy penalties Weapons maintain their accuracy whether you are moving, or not. Instead, you'll have less idea where your weapons are pointing. The test for most games is: fire a shotgun and observe the spread against a wall. Now fire the same shotgun whilst running, does the spread get any wider? In my game the spread will stay the same, but where the weapon is pointing will be modified instead. [*]Physics based projectiles In Modern Warfare 2, it was touted as something completely new... "Grenades will roll down hills". Due to using Newton, this will occur naturally, likewise, a grenade does not need to be thrown, you may opt to underarm roll it into a room if you prefer [*]Ammo types and armour Players will rarely be issued with body armour, but aggravating the police enough might cause them to protect themselves. Damage is not calculated as a raw figure, it is dependant on how much energy is in the bullet when it hits you, and the size of the bullet. A fast moving large pointed FMJ bullet will inflict far more damage than a small, slow moving, flat tip hollow point bullet. Different grades of body armour will provide different levels of protection. With "flak jackets" easily holding out handgun bullets but doing little to stop rifle rounds. Ceramic plated vests will provide superior protection, but hitting the same area repeatedly with enough energy might eventually cause the plate to break, where the armour can then be penetrated [*]Proper reloading Standard games have two ammo counters, how much is currently loaded in the weapon, and how many spares bullets you have. However, if you have 27 bullets loaded and 2 spare, doing a reload will give you 29... It's fine for shotguns, but not rifles Instead, for magazine based weapons, you will have a count for how many bullets are in each magazine, and how many are in the weapon's chamber (usually just 1 or zero). So now, suppose you reload from empty, you insert a 30 round magazine, and pull back the bolt, you will now have 1 in the weapon, and 29 in this magazine. You can now swap that magazine for one with a full 30 rounds. Because there is already a bullet in the chamber, you do not need to pull the bolt again, and you will now have 1 + 30 = 31 shots before needing to reload again. Because all of the magazines are counted separately, when you get round to using the 29 round mag, it will still have 29 rounds in it, not 30. Two types of reload "tactical" and "speed". might seem like an awful lot of effort for a mobster, but why throw a mag away if it's not empty? A so-called tactical reload, hang on to it and use it later if you need it - The drawback being that it is slower to put the mag back in your pocket, than to simply drop it on the floor. But why hold onto an empty mag? No reason at all. If you're in a tight spot you might wish to do a speed reload and get firing again sooner, and pick up the half-empty mag later. (It takes time to bend down and pick it up, so don't think you can just speed reload and instantly pick up your dropped mags. I thought of that one already) There's a lot of planning so far, when I get round to ..trying.. AI, there might be a lot more. But there's no work on this game yet. Must finish quake clone first... This game is also so brilliant, I haven't even come up with a working title yet

That might be a question going through some people's minds. The answer is "yes" I'm still working on it. Just much slower than before. At the start of the project everything was working brilliantly, I'd got as far as adding an external newton into the project. I'd even got it to correctly build the physics shapes from wavefront obj files on-the-fly, and force and torque was all working too. So where did progress suddenly freeze? The answer was the player controller. I would have to write my own so that it could be processed by a dedicated without the leadwerks graphics. Problems keep coming in when I find that I've built something that ends up needing entities. Because of course, if you have not called Graphics() and CreateWorld() you can't create entities... So far I've been able to work around, but anyone who's active on the boards will have noticed my most recent problem, posted as a status message last night. ...The problem now is that Newton always adds forces in global space. So when I want to move my player forward, I have to transform a Vec3 of (0.0f,0.0f,1.0f) into whatever the correct vector would be for the angle the entity is facing. There is the problem, TFormVector's second and third parameters are entities, so graphics needed. Josh came to the rescue with some source code in an email. I believe it's meant to be private, so I won't post it here. The problem is it's BlitzMax code, so it doesn't translate exactly. The code has a TMat4 data type, but my version of the engine does not. From reading the wiki, I have changed these to TVec16 but then there's another problem It does something like this: TVec16 TempMatrix; TempMatrix.inverse(); TVec16 in the C interface does not have an inverse function, and I can't seem to find command in the wiki that would do this. In fact, if you press the "dot" key after a declared matrix, visual studio will show you 16 fields: A0, A1, A2, A3, B0, B1, B2, B3, C0, C1, C2, C3, D0, D1, D2, D3 ... A TVec16 does not seem to have any other members that I can find. The other problem is that I can't build an inverse function myself because I have no idea what it is supposed to do. One thing about me is that I did not do A-level maths. My uni course covered matrices very briefly. We were taught, as an example "Here are two matrices -> this is how you multiply them together" . That much, I can do, but we were never shown what they might actually be used for. I have no idea what the inverse of a matrix is... Reverse the order? Flip the rows and the columns with each other? I just don't know. I would ask Josh, but he has already provided enough help, even when he didn't have to. I'm sure he's busy enough with the next version of the engine, that he doesn't really have time to spoon feed what is probably basic level stuff, and so it would be just plain wrong (and selfish) to ask ('nag' may be a more appropriate word). It's depressing stuff, which has brought the development speed of my project almost to a complete stop. But I've not totally given up on the project... Not yet.

It's still always a good idea to free old mallocs (and delete old news) that you no longer need... You just never know how much RAM another system will have available.

I can see the advantage of try-catch: As soon as the exception occurs, the code jumps straight to the first matching catch statement, (so the general "anything goes" catch should always be last). With if null checks, these checks are only done when you say so. The code could have gone wrong but carry on executing. If for some reason you forget the if null check, the error could go undetected until the whole programs comes crashing down. ...That said, so far I've only used if null checks in C, but in time, I probably should be moving to the try catch system I assume like Java (what I learned at uni .. my first taste of try-catches) that you can make it so that some functions must have exception checking. Either by try catch blocks, or by making the current function throw the exception up the call stack for something else to deal with.

If the margins are not set up for two sided printing, then there's nothing your printer can do about it. What will happen if you try is that the "inside left" pages will be too close to the gutter, and if you've spiral bound, or even stapled the pages together you will have some words that are not fully visible. This is because in single sided printing, the gutter is always on the left - But for left side pages, the gutter should be on the right. If your margins are set for two sided printing, then the "Top" "Bottom" "Left" "Right" changes into "Top" "Bottom" "Inside" "Outside". Now, "right" pages use the same margins as before, but "left" pages will flip the left and right margins, and the gutter will be on the right, not the left. When you've done that, you can then safely duplex print and bind the pages, and still have it fully readable. I think it's the margins that Lumooja's getting at, rather than the ability to duplex print. ...But with all that said, it is still a very useful and valuable thing to have around to read. When I get round to read it, I'm sure it will be quite useful, so thanks...

For the graphical part of the game, I believe Leadwerks should be much easier to write your game in, when compared against UDK. The built-in networking isn't brilliant but it will get you started. I would say, don't go straight for MMO, stick to 8-16 players at first. When you're happy that's all working smoothly with both client side prediction and server side correction working properly, then try increasing it to 64 or more. At that point, you will probably want to look at using a third party library. The code to send/receive your data will need to reflect the new library but that should be a relatively quick process. I'm no genius but I'm working on a smaller scale multiplayer project, and I'm still laying down the ground work, and not even ready to add-in the networking components yet. But when I am ready, it will first be limited to just 4 players, then 8, then 16, and finally 32 when I think it's handling the load decently. I'm not building an MMO, but that build-up process should still apply - it's a common mistake to try and support 64+ players right from the start, and then not being able to figure out why your server can't handle the load.

If the errors have gone away, then run it and see if you like it...

You mean none of the fancy shader stuff? With graphical quality as good (or bad...) as the first Unreal? Nah, don't waste time that. Any system needing the fallbacks because it has **** hardware, you should just ignore. Otherwise you'll put lots of effort into it, and people using systems that need those fallbacks when complain that it looks awful. I thought that was the policy for LE 2 because I think that one should stay. I also thought that in addition to its current user base, LE 3 was also to be expanded towards professional studios, rather than tramps using 10 year old hardware. Wasn't that the biggest reason to move to C++? There's only one way I can look at this: This engine is your business, which in turn constitutes a large portion of your life. Anything the professional studios want will almost certainly take priority because they will be willing to pay more, also they stand a much higher chance of the engine the publicity it desperately needs. However much it feels like a kick in the face to us, the faithful, current customers... Whilst I'm sure there is a large call for cross-platform ... between the three major computer operating systems. I didn't think there was much call for FFP fallbacks. Likewise, there are lots of calls for console support. Whilst it would be nice, would it be worth the time supporting the current generation of consoles when the graphical quality may not be as high?

For some reason. I find that using .c_str() doesn't seem to work even though it should. std::string LevelName = "BlahBlahBlah.sbx"; char *OldStyleString = (char*) malloc(LevelName.size() + 1); for(int x = 0; x < LevelName.size; x++) OldStyleString[x] = LevelName[x]; OldStyleString[LevelName.size()] = '\0'; TEntity MyScene = LoadScene(OldStyleString); free(OldStyleString); But since you say it seems to be trying to load, perhaps copy and paste this troublesome bit into a console project and run that. As you might know, for console projects, the log is printed to the console window in real time. So if you run that without debugging, the console window will stay open and you can read which object gave when trying to load

Chapter 6 now available (First post) Topic covers basic loading of a sandbox scene (models only). But once you know what it's doing, you should be able to adapt it to do lights, and any custom classes (triggers maybe?)... ...Next, integrating with an external newton, followed by camera controls, and applying forces / torque Edit: I forgot to mention, mlib changed between chapter 5 and chapter 6 so remember to replace your existing version because this chapter uses it quite a bit... Also Ive somehow overwritten the the first 2 lines of chapter 5, where it just tells you to create a new project using the project wizard. Those two issues are now fixed - didn't want to change the file whilst people were trying to download it.