Mumbles

I don't provide: engine.dll newton.dll jointlibrary.dll because simply running the project wizard puts all of those in your project as is. But hydro's stuff is not included by default, and there's nothing worse than trying to follow a tutorial if the files don't seem to match. Since the oildrums are not part of hydro's pak anyway. I'll probably include 2 oildrum paks, one for 2.0 and one for 2.3 each with their version as part of the filename - and just tell readers to rename their version to just oildrum.pak, where hydro's sbx will be told to look. I might also reduce what's in hydro's pak because it's nearly 26 MB. In any case, I pressed ahead with the chapter with no physics for the being. All I can say for anyone waiting for it is: it's a long chapter...

Yep, thanks, that's the right phy file - but out of curiosity will that not give 2.3 readers a problem, or was there a separate 2.3 zip for those tutorials.

From the first post, I should point out the defraggers are preying on insecure minds. NTFS doesn't dramatically slow down with heavy fragmentation, the same way FAT32 did. I don't know where your speed boost came from, most likely new drivers, but I can say, almost for certain that your defragging will have given you no speed increase whatsoever. Like ext2 file system, the slowdown in NTFS due to fragmentation is minimal at most. The best way to increase speed on your system in to turn off any on-access scanning part of your antivirus package, but I'm sure I don't need to say how dangerous that is...

When Josh said "undocumented" I presumed he just meant there was no wiki entry for it, and that otherwise, it was there from the start - so yes I was surprised when I couldn't call it directly. And then, when GetProcAddress couldn't find it, I was thinking it may have been a 2.3 thing. Oh well, never mind, eh?

"Working" does not mean "supported". Official support is almost always quite helpful. Now, on this site, unofficial support is helpful and friendly too, but on most other sites, people will bite your head off and make you feel like a retard, just because for whatever reason, you don't quite understand something that they think is simple. So I can understand why Josh might want official support for other platforms...

I use a winsock dll that was built for Dark GDK. It just gives you the basics with nothing fancy, and is a damn sight easier to use than proper winsock itself

When you say, selling 100 licenses of the Linux versions would be okay, do you mean that a Linux license separate from a Windows license? Or do you mean 100 unique licenses, where a linux application has been built (maybe on its own, maybe with versions for other platforms released concurrently)... I would have guessed that one initial price paid for Windows, Linux and Mac simultaneously. Because after all, you don't have to pay anyone else for a license to build self-executable applications on those platforms. Consoles need licenses from the company who builds the console, so I would understand, not including those versions as part of a sort of "base price"

I don't see what's wrong with manually parsing the sbx file, it is just a plain text file after all. That and I'm (the only one maybe?) using a version where I don't to worry about any of this silly lua anyway. I don't use terrains because I don't see the point of them. And the sbx has most of the info you'll ever need, position, rotation, etc. The only sort of thing it won't hold is stuff like mission objectives (if you're building a game that has such things), and yes, your own text file will cut the difference easily. All in all, it seems like a perfect file, I don't use the LoadScene command, which was intended to simplify loading such files. Indeed it does just that - but with larger scenes, you can be left waiting for ages, with no way of accurately knowing how much longer it will take. You could put a mac type spinner animation on, but that has the same problem. That, and with Mafia II, I didn't like their world streaming. It had something my brothers call the "Black horse syndrome" Apparently oblivion players will understand what that means. But for those who don't, basically, you move across the world so quickly, every 10 seconds or so a different portion of the world is loaded, causing a huge drop in fps whilst it happens (it lasts about 2 - 3 seconds). Indeed on the highways in Mafia II, it felt the same. It's not a good way to demonstrate a streaming world, and they are the pros who are supposed to be good at what they do, and showcasing their technology. I think it needed to load more at a time, so the stutters weren't so close together, even if each stutter lasted for 5 seconds instead.

...Apart from programmers, who else would use the Initialise command? Power to us, absolutely...

I'm a bit dim... But should I get the impression that the height is 1, and the radius is 0.6? (The last screenshot in the thread). Because that's a big help for now (so thanks for that)... But it doesn't solve the number of slices. I would guess at 12 for the highest LOD mesh and 6 for lowest. Would that sound about right? However, I don't actually need to know this becase: 1->It's several chapters away. 2->A close approximation should be good enough anyway, just so long as you can't overlap the surfaces on the oildrum. ...In any case, thanks, I can now get on with writing up about loading scenes manually.

Indeed, sod everyone else. In fact, let's extend that to everyone but the C programmers...

I just thought about it now, and it was suddenly all too clear. What has been the largest long term complaint to do with new upgrades to the engine (both small upgrades and major upgrades)? ...Re-serialisation of the .phy files. I took out the physics file and it worked, but obviously they were jammed in place. Can I ask, Josh: Do you have the measurements for the oildrum (height, radius), as well the number of "slices" (I'm pretty sure that's not the technical name, but I think of it as being like slices of cake). Just to make sure I get the same shape so that I can make one that is 2.2x compatible. Either that, or do you have the exact obj files that you used to make the physics shapes? That and in later chapters, small physics shapes will be generated from obj files on-the-fly since it seems to take a millisecond or so - and if it's part of a loading scene, how cares how long it takes? (unless it's like 10 seconds per object, and several objects - but with small objects, it's milliseconds sort of time.)

The game I'm building doesn't use vegetation layers, so I had not even thought about that (which means it won't be covered in the tutorial chapter). But if that's normally done during LoadScene, then it should be stored in the sbx file somewhere. If can you see how it's stored, you should be able to adapt it to include those as well

I've got a thread in the general programming board. A series of tutorials that I'm writing along side my first game, so that when it's finished. Any bits people like, they will know how to do them. Chapter 6 is the next next one to go up, and if it all works, it should show you how to load a scene with an accurate progress bar. The only problem is, it will be in C... The biggest clue is to avoid LoadScene. Really, all that does is load an entity scene "container", and then models in the scene are loaded as children. But you could just load the entities one at a time with a for-loop since the sbx file is just plain text, it's easy read it manually.

I believe so but I'll just check... It was in a registered abstract path. But copying it to the local path does not change the outcome.

After a spate of (rushed, and poor quality) C tutorials yesterday, I've now encountered a problem. Lesson 6 was going to start out with loading a scene (the hydro scene included with the loading a scene tutorial), by using the load scene. Then it would move on to parsing the sandbox text file manually, first with a caption that shows which objects are currently being loaded, then finally, some sort of accurate progress bar. But I noticed that all the oildrums it tried to load were missing. They indeed pointed to a directory in Josh's hard drive, which I don't have. "C:\documents and settings\joshua\desktop\projects\engine working directory\meshes\Oildrum\Oildrum.gmf". So I searched around my hard, looking for the correct folder for these oildrums. Turns out the only oildrum.gmf files I have are from an old program that Josh might remember called "chat17" and Lumooja's community project. I have added them both (but not at the same time) to hydro's pak file, and then watched it load... ...Or not. The last entry in the console window before it crashes is: "loading texture: ......oildrumdot3.dds" which makes it crash. However I don't uderstand the crash because the model viewer in the Leadwerks SDK folder can read the oildrum without any problems. The sandbox file also points to missing models like "industrial_cagelight" but I can do without those. For the tutorial simply loading the geometry and a few oildrums will do. From the source code included, can anyone see why it might fail to load the oildrum? (To make it smaller, so that it could be attached, the hydro scene, and replaced with a pak that contains the oildrum.) Edit: 2010/09/27: Because the issue has been solved and there is an 8 MB total attachment limit, the attachment from this post has now been removed...

Chapter 5 added, The first chapter that involves using Leadwerks, only basic level mind you. Minor editing of the Rotating cube app that Roland's Project wizard creates. Edit: Whoops, forgot to include the library you needed, it's there now... Edit 2: Oh, chapter 5 answers, second code snippet has redeclares the tickers, Obviously that's a typo. When chapter 6 goes up, that bit of chapter 5 answers will be fixed.

When I realised that about a year suddenly pointer made sense. I saw that everything in Blitz3D was just a number. Armed with that new knowledge But still when the server has a large number of entities to track it starts to fall over. I'm generally of the opinion that clients are always dishonest and the server should authoritatively do as much as it can, there are some things that you have to offload to clients, debris for example. Whilst we have a much higher data rate than we did 10 years ago, we also expect our games to handle a much larger load than they did at that time. One of my brothers' final year uni project was to build a small multiplayer game in Blitz 3D. Although he promised client side prediction, it wasn't there for the final submission. On a local subnet it was fine, and this was still so when played on the wider local network. As soon as it hit the Internet you could see occasional stutters. That told us that a relatively high end home connection (20 megabit cable) connecting to a server on the SuperJanet network still needed a little bit of prediction to make it as smooth as it was on lans. And If you're wondering, SuperJanet has a throughput rate of about 40 gigabits per second, it's certainly one of the fastest private networks in this country, if not one of the fastest world. I'm sure there are some that handle terabits per second, but no one here is going to get their game hosted on one. But that certainly make me wonder about no prediction coupled with the much lower throughput rate of most dedicated server providers. Oh come on Josh, you there was another option... I can see why you might be annoyed having paid so much for 7 Ultimate... ...But paying even more for a mac is not the way

I'm sort of used to that, but you can change the style part of the body tag a new hex colour and it should change the all the text in that. I have my terminals set up in that colour scheme so I keep forgetting that its bizarre to everyone else But I'll change it white text against black background. Unless people really want black text against white background... I just think a white background is awful to look at. (Will be re-uploaded in a few minutes - Done, original post has the new attachment) ...I just wish I knew how to make the colours user definable, but C seems to be the only language I really know...

For anyone who doesn't know by now, I'm currently using Leadwerks to write a clone if the old classic Quake (specifically, the multiplayer one, Quake 3). This is designed to act as simple game which I can then further expand, and build into an even better game. But also, I'll be documenting every step of the way so that others can hopefully learn from it. But I'm going to be writing it in C++ which isn't very helpful to those who don't understand C++ syntax. I therefore thought that I should dedicate the first few chapters to attempting to explain C++ for those who don't know. Whilst at the start of chapter 1 I had hoped it would be simple enough for anyone to understand (including non-programmers), I don't know if I introduce too much too quickly, and so possibly confusing people. The first four chapters that I've uploaded today don't include any coding with Leadwerks at all, so there's just a warning if you're expecting to see some game source code straight away. The later chapters, which I'll upload when they're done will involve using all of: Leadwerks, Newton and Winsock all within the same C++ project. The first four chapters can be run on any operating system, using any C++ compiler you feel like. I describe getting a simple Visual Studio console solution up and running in windows, and for a bit of patriotism if nothing else, building a C++ program on Linux using g++ (Yes, I know that any Linux user here probably already knows this, but still). After that it will be a windows only endeavour, not least because Leadwerks doesn't compile natively on Linux, but also because will be using the windows Newton SDK, and of course, winsock (of which the clue is in the name). So yeah, I'll be updating this thread with new chapters as and when I finish them, even if there appears to be no interest, starting today. The tutorials are all in html format but not with nice fancy pictures unfortunately, just boring plain text. If you don't like the colours, then just change the body tag, but I found a white background gharish to look at, not least because I spent so long looking at it. All the html files are all packed together in a rar file. As a side note, for those who will be using these first four chapters to learn C++. I found at school, college and even at uni, after a bit of reading, the best way to try and make it "stick" in your mind is to try and answer some questions about what you have just read. Because of this, there are some questions at the end of each chapter, with some answers too. Hopefully it is of some use to someone. Also would it too much to ask if some C++ gurus could look over it to make sure I'm not actually teaching any incorrect information? (There are a few cases where I teach something in a simplified way, and then reteach it properly in a later chapter, but there might be some things that are wrong, and left that way.) I should add that in the early chapters, I say that the string is a struct, when it's actually a class, this was something to be revealed in chapter 5...

I know certainly 2.0 that wait wait until it's finished load all child entities of the scene before continuing. So yes a static loading image would suffice. But when you have no idea how much longer it's going to take to load, and it already seems to have taken a while - as a player, I find that very irritating.

512 metres squared? as in 262,144 square metres? The first measurement sounds really small, but the second makes it sounds ridiculously large... Your system copes with that size without any slowdown? What's the density of your NavArea? 1 cell per 1 unit? Or a little less dense than that?

I just don't use LoadScene. I have a file containing a list of standard items that are found on every level, which I will cache up front (Like weapons, characters, etc). Then for each individual level, I just the read the sandbox (editor) scene files manually, and load every item in it, with my own version of ProcessScene, which loads entities acting as geometry and items unique to a specific level. I know it's not called sandbox in 2.3 onwards, but because of the sbx file extension I will still think of it as the sandbox. To do a progress bar, I cheat slightly. My custom level description file, holds key information: Like which sbx is the one associated for each level - it also says how many entities are stored in the sbx file. This means that I have to update that file every time I update the sandbox scene, and if I get the number wrong, two things can happen: 1, number too low, the final entities are not loaded. 2, number too high, the engine tries to load a null object - and crashes. But it also means I know up front how many entities there are to load, so I can use a for loop, with the last lines of the loop being used to render a progress bar, but only if its been at least 50 milliseconds since the last render. This way, I have an accurate progress bar, and one that doesn't refresh at 500 fps when 20 fps is smooth enough for a progress bar.

This undocumented command. Is it in the DLL or just a command that the source / BlitzMax users can use? I ask because, it's not in my engine.h file, so I tried: //Explicit DLL linking for the hidden command typedef int (_stdcall *TGraphicsModeExists) (int width, int height, int depth, int hertz); TGraphicsModeExists GraphicsModeExists; int main( int argn, char* argv[] ) { Initialize(); HINSTANCE hInstLibrary = LoadLibraryA((LPCSTR)"engine.dll"); if(hInstLibrary) { GraphicsModeExists = (TGraphicsModeExists)GetProcAddress(hInstLibrary, "GraphicsModeExists"); if(!GraphicsModeExists) { std::cout << "Function pointer is null\n"; Terminate(); return 0; } } else { std:cout << "Failed to load the DLL explicitly...\n"; Terminate(); return 0; } //Remainder of the code body Result: Function pointer is null.

Whilst the free software thing means there's practically a utility for everything (useful when Windows stuffs up your partition tables), there are some things you have to charge for. I know that personally I've never been against actually paying for something that sits on my system although a one in a million case isn't too good for business. That and look at it from Josh's perspective, there's one user who is prepared to pay for a Linux port, and have it closed source - but this same user hasn't yet paid for 2.3, so how can he be sure that his efforts to port to Linux will actually yield any income at all? The only way to keep this engine going is to charge for it. But then again, the price doesn't just include the software, it also includes free access to one of the most valuable help resources I've come across - this place. I wouldn't mind betting that quite a few Linux users who insist that everything should be free, will be secretly paying the subscription to experts-exchange. (yes, we all know about the old url...) The main reason Linux stuff is free is because it's also largely open source. How can you charge for something when the source code is already in the public domain. There's no reason to be concerned with supporting the developer because if you really want to, you just edit the code yourself. This however, I feel would be a software product that, when left down to the users would probably end up going wrong. It's one that needs the intital genius of the project to work through it from start to finish. But like I've said in the past, I switched to Linux because I wanted a reliable system, and was having real trouble getting XP to stay up and running, which given XP reputation for reliability, even I was surprised at the time. It is now running quite smoothly but so is Linux. So I use both systems, and I do know that Debian gets much better usage out of my quad core than XP does (Only supports two cores), and probably gets better CPU utilisation than Vista. Because most people will know that if Windows hits about 55 - 60 processes you get the feeling its trying to run on a zimmer frame. Debian meanwhile, certainly on my system has about 180 - 195 processes running at any one time. Granted, usually all but about 5 are sleeping at any one time, but on Windows as soon as I have about 3 processes not sleeping at the same time. It starts to die. Unix itself has always been better at multitasking, so of course any system built on top of it seems to multitask quite well. That's still an area that lets Windows down. I've digressed a bit there, but I'll end it by saying it would be nice if some more Linux users weren't totally free and open source crazy. It's a nice idea but its akin to communism, and whenever that's been tried in history, it's never worked...