|
Shannon V. OKeets -> RE: IMPORTANT: State of the Game and Future Plans as of June, 2015 (10/26/2017 7:13:14 PM)
|
quote:
ORIGINAL: Dabrion
702000 sloc hmm.. did you press the disassembler button? :§ My longest program was titled "Hello World (directors cut)" and had 702001 sloc in the same amount of modules, I win!
Seriously though, I would have to look up numbers. UOX and DoL are somewhere in the 500k - 1M sloc range by my estimates. Vassal has a little over 200k. Not that I wrote all those lines ..
The lab rotations and student projects I supervise reach ~100k sloc with a 2 month time investment. Not sure what a comparison on that level is going to accomplish though.
@Brook's Law: I think it is quite ridiculous to argue diminishing returns when contemplating a +1 for a solo project. Even in this special case the +1 could just do QA and continuous integration/testing for the project. That would enable Steve to focus on progressive coding, and consecutively eliminate all those regression bugs you seem to suffer from a lot. Moving from one "square forward, one square back" to "one square forward." is going to be an infinite increase in productivity..
MWIF is pure Delphi (basically Object Oriented Pascal). I replaced all the built in Assembler and other unusual code I inherited from CWIF because: (1) I didn't trust the updates to the operating system (i.e., Windows) to necessarily support all those calls in the future (specifically changes in the hardware), and (2) Delphi generates pretty efficient object code. Trying to improve performance with difficult to understand source code seemed self-defeating to me, given the potential for catastrophic changes by outside parties causing months of effort repairing existing code.
The ever improving speed of CPUs and disk access reduces the (old) requirement for extremely efficient code. Still, writing good/efficient source code is crucial for MWIF. It just doesn't have to be dealing with bits, shifts, and logic masks all the time.
[On the other hand, the map and unit data are stored as packed binary. Masking and shifting are used continuously in the program to extract individual values for hexes, units, etc. I left that as it was in CWIF - for the most part - and even added to it to include additional functionality in the game. But that was because there are 70,200 hexes and 7000+ units. To my eye it seemed foolish to allocated 50+ variables to each of those instead of just 4 for hexes and ~10 for units.]
As for line count - I take what Delphi tells me when I do a full compile. There are some third party libraries in there - and that code is very verbose [if that is the right word to use]. Also the compiler is dealing with 100+ forms, which can be edited visually by the programmer, but the compiler converts them all into source code. I have no sense of how much code is thereby generated for each form.
What I do know, is that if I add 100 lines of source code myself, then the line count generated by Delphi increases by 100.
|
|
|
|
