There are lots of words strung together to make sentences, but i still have no idea what they are telling me!!
Its another language that i'm not getting at all. Hats off to all you guys and galls that understand it and make money from it!!
There are lots of words strung together to make sentences, but i still have no idea what they are telling me!!
Its another language that i'm not getting at all. Hats off to all you guys and galls that understand it and make money from it!!
Yes, i myself impressed with what you can do, but i wouldn't think that i could ever do even simple code myself - The Developers of LFS i regard as being way to smart for me.. Genius. Anyway, i'm not contributing any point to this conversation what so ever.. so i'll leave you all to it
After being part of a programing team for writing a 4D maze at school I can say I have alot of respect for programers. We worked on a maze that worked in 3 dimensions and also had multiple mazes interlinked. (hence 4D)
Everything was done in Turbo Pascal, which runs on computers with less processing power than modern cell phones.
I was in charge of the user interface, and it took me a week to write something that drew a very simple ASCII interface with arrows for direction, a compas, and lines for borders.
Something that seems simple when you see the finnished product, but requires some pretty complex code to work with the actual maze generator/display.
The generator and display portion was worked on completely by our lead programer, it took him 2 weeks and at least a thousand lines of code, probably alot more. It was mind blowing to see the source, and realize that someone actualy wrote it.
For a one man show LFS is one hell of an accomplishment, and if anyone says any different I challenge them to try coding a sim on their own.
Everything was done in Turbo Pascal, which runs on computers with less processing power than modern cell phones.
I was in charge of the user interface, and it took me a week to write something that drew a very simple ASCII interface with arrows for direction, a compas, and lines for borders.
Something that seems simple when you see the finnished product, but requires some pretty complex code to work with the actual maze generator/display.
The generator and display portion was worked on completely by our lead programer, it took him 2 weeks and at least a thousand lines of code, probably alot more. It was mind blowing to see the source, and realize that someone actualy wrote it.
For a one man show LFS is one hell of an accomplishment, and if anyone says any different I challenge them to try coding a sim on their own.
Its amazing how 6mb turns into a couple hundred mb give or take. But man I never knew...6 million characters? WOW!
Yep, know what you mean. I am lead dev on a project at the mo that I have put about 1.5 man years into and has probably a total of 2.5 man year at present. We currently have about 1200 classes split between program objects and their related unit test objects.
Some people see software as something that is simple to change without knockon effects.
I must admit though that since using Nunit it lets you feel safe making changes in core areas as you soon see all the fail points when you have near 100% test coverage on your project.
Even so, small changes can still cost a huge amount in time and manpower required.
...and I get confused when I'm going through my 100-line BASIC code!
6 MILLION characters is like... well, :hbomb: much!
6 MILLION characters is like... well, :hbomb: much!
The main problem with unit tests is how to use them with code giving graphical result.
It's pretty easy to make a unit test for parts of code doing precise things like numerical functions...but there is no easy way to do a unit test that will detect when your buttons are misaligned, or something is flickering, or something is hidden when you resize this or that, or combobox does not have the right behavior. Same problem with code using directx.
To write this 6 million characters source code, you can bet Scawen had to type at least 3 times more...because it is never a direct process. You write, correct mistakes, come back later and add something, remove, refactor...
I sit below that line. All my work is web services and below, saves having to deal with human interaction. I am more what you call a bottom programmer
The guy doing all the human bits is using WPF which as you say is a nightmare to unit test.
I have done testing in interfaces before using the View/Presenter model so you test the presenter and the view code becomes a dumb display that is only responsible for pumping data into the view and triggering requests that come from the interface via the presenter. That is about as close to the display you can test and makes sure all your "functionality" works without a care about what it looks like.
There are nunit extensions for displays but they are just not worth it.
View Presenter also allows you to change the view and no effect your "real" code. It does take some extra bootstrap but well worth it imho.
No, the couple of hundred MB is the data - that is not produced by the source code.
The source code is the humanly readable text that is compiled to create the LFS.exe program file (1.7 MB).
Unfortunately for me I have been doing everything on the other side of the line. For a long time my job has been to develop big GUIs for real-time trading client-server solution. The kind of stuff where dozens furiously clicking traders were connected through several stock exchanges through our poor GUI and generating all possible conflicting situations as they could interfere with each other in all possible asynchronous ways...woooohooooo
People from the server side looked soooo peaceful with their unit tests.
6MB of sources vs 500 files ... sound to me not quite right Scawen, looks like your .cpp files are either a bit large or your comments in headers are huge.
Also 6MB is A LOT, I prefer to refactor my code a lot to have in the end short sources doing the same thing. (although not obfuscated just in the name of shortness)
Than again all these comments are pointless, as I haven't seen the LFS source, maybe my version of LFS would had 9MB and 300 files. (if it would be ever finished, and I'm afraid it would not, hehe 
)
Also 6MB is A LOT, I prefer to refactor my code a lot to have in the end short sources doing the same thing. (although not obfuscated just in the name of shortness)
Than again all these comments are pointless, as I haven't seen the LFS source, maybe my version of LFS would had 9MB and 300 files.
(if it would be ever finished, and I'm afraid it would not, hehe )Hmm, I don't think they are that huge. That works out as ~12.5kb per file, on average. Doing the same division here at work gives me ~8.5kb per file.
For people unfamilar with the size of games though, a quick check here tells me LFS in about an order of magnitude smaller than our games.
Thats why I hate the stuff that deals with humans. Those strange beings are so unpredictable. I like my cold hard logic mind space lol
Feel sorry for you. Sounds line you are too far down the line for a refactor to Model-View-Controller. Its a huge investment but sounds like it would pay off as you could test closer to the human level.
I know what a hot bed trading spaces can be. Spent a year contracting at Reuters
As Bob says, the files are not that big. Depends on the logic in the code and what is common.
Also if you refactor your code so you have lots of code all doing the same thing you are doing it wrong
Write each "thing" once. The more times you repeat code the more places you have to fix the same bug. Or is that not what you meant.Yes some of the files are a bit large. Comments are not huge, but frequent in the source files so I can try to make sense of my code when revisiting years later and wonder what it's all about and why it's in the order it is.
Some of the source code files like "Car.cpp" and "TrackEd.cpp" grow and grow as things are added and finally they get broken down into pieces every now and then when I'm restructuring to get things tidier. I'm from the olden days when a program had one monster file.
First wrote a computer program on the Apple 2. But got serious in BASIC on the BBC micro. Did not use comments or variables with more than one letter in those days - and put as many statements as possible on one line as it was all about allowing the interpreter to zip through the code as fast as possible. Very different nowadays... but I'm not scared of a big file of code.My style is more C style but using many C++ features that benefit me, most functions are of course in classes though my classes are 'struct' rather than 'class' because I don't really need to protect everything from myself so don't need to bother with private and public members and functions. I don't use all these overridden operators and allowing the code to create temporary things on its own. It's more function calls with pointers so that's what I mean it's kind of C style. Semi object oriented you could say but keeping it very clear so I really know what the code is doing, not allowing it to do all its "clever stuff" behind the scenes.
Yes my code is very compact in fact and with very minimal duplication indeed, this I can achieve as there's only one programmer, I do all the re-using of code that is possible or efficient, unlike when working in a larger company when every programmer seems to create his own similar version of functions.
If you think it's big that is actually only because it really does a lot. Although on the other hand what Bob said, it's really very small compared with the 10 MB or far greater executables of many games.
my lfs folder is 4,7gb
I could play "Stairway to Heaven" when I was twelve. Jimmy Page didn't actually write it until he was twenty-two. I think that says quite a lot. (Vim from the band "Bad News".)
Yeah but my LFS.exe is 2 MB. I always admired Mr Scawen because we have a excellent simulation and it wastes minimal hd space. The instalation zip is only 100+ MB
What makes you think we were not using MVC ? Of course we used MVC we are not totally crazy
Sorry for OT
I have to admit I know little about programming. It never interested me so I took no interest in class - (you try staying awake trying to learn programming in Fortran77 !! :razz - but isn't C++ a language that requires manual memory management? Just makes me wonder how many of those 6 million characters are taken up dealing with allocating and freeing memory. I thought people were moving away from such languages to ones that do automatic memory managment, as they are more code "efficient". But like I said, I'm no programmer.
- but isn't C++ a language that requires manual memory management? Just makes me wonder how many of those 6 million characters are taken up dealing with allocating and freeing memory. I thought people were moving away from such languages to ones that do automatic memory managment, as they are more code "efficient". But like I said, I'm no programmer.It's not a very complicated concept. Basically it boils down to keeping track of changes made so that you have an audit trail to find what was changed, when it was changed, and by whom. It also covers keeping back up versions of any document, software created along the way so that changes can be (relatively) quickly and easily reverted back to the way they were if new versions turn out not to be any good for what ever reason. It's also used extensively in project and programme management, (as well as SLA and Contract management etc).
Yes. In C++ you have to take care of the memory yourself. So yes, you have to do a bit more code to take care of that. But C++ can be more efficent in terms of performance which why it's still used so much.
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.
Like you said gone a bit over my head. I've never got on with abstractions used in high level languages. Do these things essentially boil down to variable registers? As far as languages are concerned I'm far more comfortable at a lower level talking about registers, flags etc. But even then I don't really have the will to get in to it in any depth.
I see what you're saying though. Automatic memory management makes you pick up lazy programming habits, which then work against you when it comes to managing other resources, (eg graphics memory, i/o ports etc), right?
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.
Another question:
How do you structure the code?
Like this:
or this:
Or some other way? I myself use the first of the two as I find it easier to read the code at a later point.
How do you structure the code?
Like this:
function foo()
{
for(int i = 0; i < 25; i++)
{
do_something(i);
}
}
or this:
function foo() {
for(int i = 0; i < 25; i++) {
do_something(i);
}
}
Or some other way? I myself use the first of the two as I find it easier to read the code at a later point.
How Big Is Lfs?
(81 posts, started )
FGED GREDG RDFGDR GSFDG