Quote from Shotglass :

yeah but from what i can see its the only error that really makes the code uncompileable instead of just not conform to standards

Not conforming to standards means it won't compile on anything newer than Visual C++ 6. The istream.h header has been removed (it's now just iostream), and cin/cout are inside the std namespace. "void main()" won't compile either.

This is the same example in proper C++:

Quote from Shotglass :

no compiler will ever compile code that uses undeclared variables... well no c compiler will

Obviously, but that's just one of a host of errors in that code snippet which I assume came from the DVD. He wouldn't have thought up iostream.h and void main() on his own. Those two are dead giveaways that the DVD is old and useless. I've seen enough old learning material to know that much.

Quote from Shotglass :

since you apparently dont know anything about coding may i suggest starting by actually learning to code first?

I'm sorry? Was that directed at me? (No, the link doesn't work)

Well if the examples on the DVD indeed include <iostream.h> and void main(), I'd just argue that it teaches you non-standard C++, and as such is useless as a learning aid. The code they provide won't even compile in any recent compiler (which you've discovered with Visual Studio Express 2008).

EDIT: To elaborate a bit. The language the DVD is teaching you is most likely a version of C++ from way back before it and its standard library were even standardised (in 1998). What it's teaching you just isn't C++ any more.

Last edited by wien, Sat 5 Jul 2008, 22:09.

Ouch. That's a hefty price tag for something that outdated and even plain wrong (void main() has never been legal C++. main() returns an int.)

As for more advanced books, there's always Effective C++ and friends (anything my Scott Meyers really). They'll teach you a lot of neat tricks on how to write correct and efficient C++ code. You need to have the basics down before moving on to those though.

Other good books include C++ Coding Standards by Sutter and Alexandrescu and The C++ Programming Language, Third Edition by Bjarne Stroustrup (the creator of C++). These also require a some previous knowledge though.

IMHO if the DVD references <iostream.h> and void main(), throw it away and never look back. It's guaranteed to be old as dirt and it will most likely teach you to write C++ code in ways that no-one really should anymore. So much has happened to C++ and its standard library since then.

Personally I'd recommend getting a good book like for example Accelerated C++. That will teach you more "modern" C++ which may save you a lot of trouble later.

EDIT: Oh, and if you plan on doing this as a career eventually, do yourself a favour and get used to learning this stuff on your own. University will never give you anything beyond the basics (Mine certainly didn't). A few of my class mates graduated lacking even the most basic of programming skills, so don't rely on university teaching you everything you'll need.

Last edited by wien, Sat 5 Jul 2008, 21:33.

Shadows aren't sharp. The blurry ones in game are much more accurate than the viewer ones. Either way you can't "move them over". Shadow rendering is part of the graphics engine code. Only Scawen can change that.

Quote from deggis :

I don't know how DaveWS created those,

IIRC he started with a sample of a gun shot and went from there. Makes sense really.

Quote from Stefani24 :

What Graphaics card do you have now?

And even more importantly, what processor is it paired with? LFS can be very processor intensive, so a new graphics card may not help if your processor is very slow.

Quote from Juls :

Do a test. Show LFS and rFactor to many many persons, and each time, ask them what sound is the most realistic.

Yeah, but you see; I don't give a hoot about those people. I care about me. Their ignorance is their problem. To me there's no comparison.

Quote from gezmoor :

Thinking about it that way I suppose it's true, even relatively low level languages are actually abstractions of what is really going on in the hardware as far as bits of data etc are concerned.

Exactly. Even programmable processors are just an abstraction made because soldering all those ORs, ANDs and NANDs together got tiresome when trying to perform complex tasks.

Quote from gezmoor :

Though I guess if you open/write/close a file for every bit of data and you know you're going to be writing more data to that file it's maybe a bit of an overhead to have to keep opening and closing it, (from the file system access speeds on the hard drive point of view i mean).

Yep. Speed is a huge part of it. An important aspect of any good abstraction is to enable the computer to work as efficiently as possible underneath it. It's also simply more efficient and less error prone to specify what file (filename) you want to work on once instead of specifying it at every write call. You have to weigh these things against one another really. Usability vs. efficiency.

I wouldn't say Ruby is too far away from your example though. Take for instance this snippet which copies text from one file to another:

It's not English, but it's pretty understandable if you read the code out loud.

Quote from gezmoor :

btw - do people still use subroutines any more, or are they a thing of the past?

Most certainly. Though they're usually called "functions", or if they're organized inside classes; "methods"/"member-functions". Depends on who you talk to though. They're the core building blocks of any program really. Without them programming would be a messy task.

Quote from gezmoor :

One thing I've never really understood about a lot of languages is why they need to be so "abstract". I've often thought that they're purposely designed to be obtuse just to keep programming "elite".

I'd say they are that way to make programming more accessible. Higher level languages, just like assembly and FORTRAN try to abstract away the details of how a computer works so you can write code quickly and easily without having to worry about the down and dirty details.

You use file abstractions to access the disk instead of keeping track of file systems, platters, cylinders, sectors etc. and writing the data manually. You use graphics APIs instead of writing a command buffer native to the GPU and send that across the PCIe bus. You write machine assembly instead of having to write binary opcodes using 1s and 0s. It's just easier, and the more complex applications get (because of user expectations), the more layers of abstraction are needed to keep thing at a manageable complexity level. We usually only have to worry about the top level though, Meaning it's easier for out pathetic human brains to cope. These languages simply let you describe what you want done, not how you want the computer to do it (which, let's face it, you don't really care about).

I know what you mean about the "write code in English" bit though, and there are languages that will let you do something close to that. BASIC has been around forever but some popular incarnations are getting quite long in the tooth these days. Ruby is one of the newer languages that try to stay fairly intuitive, so there's alternatives that are FAR better than C++ in this respect.

They're still not anything like real English though, and that's simply because English is a spectacularly bad language for instructing a computer. It's just too vague and ambiguous and requires extraordinary amounts of logic and intelligence to make head and tails of. It's better/easier to teach a human how to communicate in a way a computer can understand (we're good at that sort of stuff) than it is to teach a computer how to understand a human.

EDIT: Just wanted to add one of my favourite quotes on the subject which pretty much sum up high level languages to me: "Being abstract is something profoundly different from being vague... The purpose of abstraction is not to be vague, but to create a new semantic level in which one can be absolutely precise." - E. Dijkstra

Last edited by wien, Fri 4 Jul 2008, 19:10.

Quote from gezmoor :

Do these things essentially boil down to variable registers?

Well, not quite. But to take the file handle example, let's say you want to write into a file. To do that you need to ask the OS to please open *that* file for writing for me. The OS will then lock that file so no other program can access it while you're changing it, and return a handle to the file you can use for any operations you want to do on that file (reading, writing etc.). In C this is done through a call like "FILE *handle = fopen(<filename>, "w+");".

Now, when you're done with this file you need to tell the OS so it can release the lock on the file, once again allowing other programs (or your own program at a later time) to open the file again. In C this is done through a call like "fclose(handle);". This is of course when things can go wrong. If for some reason you don't call fclose you've leaked that file handle and the file lock won't be released. Exact same concept as a memory leak.

In GC languages like C# and Java the GC will take care of this for you, but if can't guarantee when the handle will be released unless you explicitly tell it to release the handle yourself (much like in C). For memory that's usually not a problem since you have lots and lots of it and a few tenths of delay on deallocation here and there won't matter in the long run.

With file handles though (and a lot of other resources), it's extremely important. You could very well end up in a situation where your own program tries to fetch a handle to a file that the GC has not yet gotten around to releasing (from some previous access). That could mean you won't be able to fetch a handle at all, or worse your program will lock up until the GC has released the handle.

So you need to explicitly tell the OS "I'm done with the file now", and you're back to square one (C) even though you have a fancy GC to help you.

C++ and RAII does not have that problem as the mere action of fetching a resource (memory, handles) also dictates the lifetime of that resource. You can't fetch a resource without also stating when the resource should be released. The two actions are one and the same. Once the resource handle goes out of scope (at the end of a function call for instance), the handle's destructor will automatically tell the OS "I'm done with it". There's no need to do this explicitly.

Last edited by wien, Fri 4 Jul 2008, 16:58.

Quote from gezmoor :

I thought people were moving away from such languages to ones that do automatic memory managment, as they are more code "efficient".

I may be talking over your head in the following, but it's so difficult to explain without rambling on for pages. Hopefully you'll get the gist of it.

A lot of people think garbage collection (automatic memory management) is the future, but personally I don't agree at all. While it does take care of memory leaks (in most cases, there are some pitfalls depending on the language) memory isn't the only resource a program will allocate and deallocate during it's lifetime. There's loads of stuff; file handles, window handles, mutex locks, graphics contexts etc. etc. Garbage collection doesn't really do anything to help you manage these. Sure, it will destroy these resources eventually when the GC gets around to it, but if you care about when that happens you need to do it explicitly. In the case of file handles and mutex locks the when is everything, because a hanging lock can prevent allocation of the same resource at a later point in the same program.

A GC lets you get lazy about memory which in many cases can leave you unprepared when you have to deal with resources that are much more scarce and important. If you don't know how to deal with these properly, you can end up with a lot of nasty bugs that are hard to debug.

That's why I love C++ so much. Instead of a garbage collector that cleans memory allocations for you at some point, it has a (IMHO) much more powerful system that can help you with all the others as well; destructors and a design pattern called RAII. This pattern says that if your program needs to allocate some resource (whichever type, memory included), you wrap that allocation in an object that automatically releases the resource when the it goes out of scope. If you do this correctly and consistently it means that your program will never leak a resource of any kind. No matter what happens the destructors will clean up the mess, and they'll do it as soon as your program is done using the resource.

This article probably explains the problems with the GC approach better than I could hope to do.

Last edited by wien, Fri 4 Jul 2008, 16:22.

Quote from flymike91 :

...

Yep. That's the most condescending thing I've heard come out of anyone's mouth in a good long while. I hope the weather is good up there on your pedestal.

Quote from mrfell :

As a non programmer, I have absolutely NO idea what you've just said!!

Feel free to educate yourself.

Quote from Whiskey :

I have this file modified: d3d8.dll, I have the ENB Series with comes whit the bloom mod. Could this cause the bug?

That could absolutely cause the problem. If I remember correctly LFS is using some capture function from inside D3D to do the sreenshots, so a modded DLL could very well break that functionality. Why don't you try without the mod to see for yourself?

Quote from Scawen :

No I just do frequent zips of the code

Huh. Now that is really surprising. I couldn't imagine writing code without source control anymore, even if I'm the only programmer on the project. I just love the control it gives you over the changes you make. (branching, merging, diffing etc)

You can get Subversion for free as well (sweet, sweet open source). You don't even need a server to use it (though it's perhaps a bit neater that way). It won't integrate with Visual Studio without an extra plugin though, but I find TortoiseSVN does the job nicely from the explorer shell.

That's really something that sucks about being a programmer. Most people really have no idea how much work goes into the stuff you do. Something that seems easy and trivial to them (because the visible impact is minimal) may be days/weeks/months of work behind the scenes.

<programmer-blues>I deal with this all the time when customers are shocked by the price I give them on what they see as minor changes. Graphics artists on the other hand can easily charge more since their work is immediately visible.</programmer-blues>

Aw shucks. Now who's going to beat multicoloured shite out of Massa? He'll be missed for sure.

Quote from Woz :

Probably one of the many reasons for Intels COMPLETE rejection of Vista.

Oh come on now. You're among friends. Cut back on the hyperbole. Intel did a normal cost/benefit analysis and found there were no benefits from upgrading at this time. Typical business desicion. (How long did Win2k stay around in the business world?) Parts of Intel are still using it if it makes sense for them. You make it sound like Intel completely rejected it on its techical merits, not allowing it on the premises, which is pushing the truth quite a bit.

That said, Vista certainly has its issues. The most annoying one I've encountered is the indexer hogging the disk even though it's set to a low IO priority. This means that if I've landed a lot of new files in my user directory (something I often do when updating some codebase from a Subversion repository for instance), I can't play a video off the same disk until the indexer is done indexing the new files. Hugely annoying, and something I can't fathom how got past QA; much like the network/media playback issue.

Quote from Hyperactive :

Aren't you making it sound a bit too cumbersome?

Of course I am. I think it's a stupid idea, so I will do my best to make it sound like one. Seriously though, all I'm saying is that I just don't see the benefit. "It won't be too cumbersome" isn't really reason enough for me to accept a change. Show me a common use-case that is made considerably easier for either me or Kunos by using the browser and I'll happily concede the point. Until then I'll remain grumpy and negative if you don't mind.

Quote from axus :

I was wondering if we could have a few words on the road ahead though? Pretty please?

http://www.lfsforum.net/showthread.php?p=842674#post842674 I doubt things have changed considerably since then.

Quote from volvopetter :

Yeah, but the wheel looks fake as shit, looks like an grey circle that are made in "Paint"

Do you talk to people like that in real life? They do a lot of work for you to enjoy and then you simply spit back in their faces? It's fine you don't like it (though I really don't see why), but jeez, some courtesy wouldn't go amiss.

Quote from baSh0r :

Do it, lets get beta \o/

:slap:

Thanks Scawen. It's when you see all the improvements in a list like that you actually appreciate how much has changed. Great work as usual.

Multiplayer lobbies don't spawn from nothing just because you develop inside a browser. You still have to write the code to do everything.

In fact, none of this is really any harder in a normal program (Using .NET like Netkar already is). I'd actually say incompatibilities between browsers (well, browser) makes the web approach a pain in the neck in comparison. Why anyone would expose themselves to that when they actually don't need to boggles my mind.

I can kinda see the unification angle, but the bother of having to open a browser window, navigating to the correct page, logging in, finding the launch button, just to run a program that's already on my computer by far outweighs any benefit in my view. This is just an unnecessary layer of complexity, and if there's anything Netkar doesn't need at this point, that's it.