With all that said, it's a 10 year old project that's still in alpha that's been ported over several times. You don't think any sort of SE: refactoring, design patterns, readability, proper use (ie. method/class does what it states) of methods and classes is not directly involved in this? Asking "how can I make this faster" or saying "this is for the community" is pointless when eyes are bleeding. But eh. Maybe my POV is wrong.

[quote name='Alpha_ProgDes' timestamp='1314732199' post='4855584']
With all that said, it's a 10 year old project that's still in alpha that's been ported over several times.

Is there a deadline?[/quote]
Well, I figure that he wouldn't want his incomplete engine to be older than his child or outlive him. But then again the Duke Nukem School of Project Management does work for some people.

You don't think any sort of SE: refactoring, design patterns, readability, proper use (ie. method/class does what it states) of methods and classes is not directly involved in this?[/quote]
Nope.

The best thing is that project finally saw light of day. It is one step closer towards being used.[/quote]
There have been plenty of game engine (indie) that were completed and never saw the light of day pre-release. So I don't know if being seen is actually a step in any direction.

"A boxer that wants to become a champion needs to win at least one match".[/quote]
Yeah, but his boxer can't even spar yet. **Correction: it can render. So it can at least do footwork and look pretty.

Asking "how can I make this faster" or saying "this is for the community" is pointless when eyes are bleeding. But eh. Maybe my POV is wrong.[/quote]

There is actually very good feedback on the first page, regarding lack of animations, lack of logic and the ability to load more complex geometry. Those are important questions regarding engine.

Endless rants about code are not, unless the current state of code prevents those features being added.
[/quote]
Point taken, but I don't think the comments about his code are not rants. I think it's productive. At the worst, constructive criticism. At the end, he's building an engine not a game. there has to be some architecture concerns, rewrite and some SE. Especially if he's gonna build upon it. Let me add this is my opinion which obviously different than his goals.

With all that said, it's a 10 year old project that's still in alpha that's been ported over several times. You don't think any sort of SE: refactoring, design patterns, readability, proper use (ie. method/class does what it states) of methods and classes is not directly involved in this? Asking "how can I make this faster" or saying "this is for the community" is pointless when eyes are bleeding. But eh. Maybe my POV is wrong.

It's 10 years because I was 12 and using Visual Basic when I started the project... Only over the last 5 years did I start learning C++ and only over the last 2 or so I actually knew how to use C++. There are fragments of code that I ported over from Visual Basic but they probably make up less than 5% of the code base. The structure of the engine has been more or less evolving. 98% of the ideas that I'm using now I had no concept of 10 years ago.

[quote name='Alpha_ProgDes' timestamp='1314732199' post='4855584']
With all that said, it's a 10 year old project that's still in alpha that's been ported over several times. You don't think any sort of SE: refactoring, design patterns, readability, proper use (ie. method/class does what it states) of methods and classes is not directly involved in this? Asking "how can I make this faster" or saying "this is for the community" is pointless when eyes are bleeding. But eh. Maybe my POV is wrong.

It's 10 years because I was 12 and using Visual Basic when I started the project... Only over the last 5 years did I start learning C++ and only over the last 2 or so I actually knew how to use C++. There are fragments of code that I ported over from Visual Basic but they probably make up less than 5% of the code base. The structure of the engine has been more or less evolving. 98% of the ideas that I'm using now I had no concept of 10 years ago.
[/quote]

Which is all fine and dandy except for the fact that in ten years still even more will be learned - and here's a golden chance to learn some of that 'more'. Look, you came here for criticism and advice - you've gotten both a plenty; what more is there? Have a nod and a pat on the shoulder for making it this far; but that still doesn't change that the code is a mess (quite natural, IMO, as it's been developed under such changing conditions during 10 or so years...) and that it's nothing new.

ApochPiQ gave you an enormously good starting point for fixing things, but it seems that is not what you came here for. So, uhm, what was the point now again? Congratulations on getting this far - now realize that you've got many many more miles to go.

[snip]

Why do people always need to go to the extremes? We're not claiming that "good coding practices will make your engine." And I doubt you are claiming "terrible coding practices won't have any influence on your engine." There is a lot of room in-between those two, and there is a big difference between "over engineer / premature optimization" and actually using consistent naming and using constructors.

Any engineering field has its commonly accepted practices. Even something as simple as which way you screw a screw has a logic behind. There is a reason for that. CS is no different.

I agree with Antheus. There were some good criticisms earlier in the thread, but I feel it's degenerated into nitpicking of the code, and then misrepresenting these issues as if there was a One True Way to do things, or as if this was proof his product is useless. Code review is always a good thing, but it's incorrect to assume this is a sign that a project is doomed, or someone is experienced - even if one downloaded the code of an established successful project, you could nitpick problems here and there in the code.

A few particular points:

* I don't think source-only releases for Linux is unreasonable (given the way that platform works). Binaries are great, but I wouldn't say the lack of them implies it's not cross-platform, so long as the source compiles without changes. (I don't know if he claims to support OS X - saying cross-platform certainly doesn't imply it, unless you're going to insist anything cross-platform must work on _every_ platform. There's not an AmigaOS version either...) I refer to my games as cross-platform, meaning Windows and Linux, even though Linux is source only so far. A better more relevant question (especially if it's meant as an engine for others to use) is whether the source would compile on Linux.

* Although I personally don't include licence info in every source file, I thought doing so is pretty common practice. And not just in OSS, so I don't get that comment either. (And even if it *was* the OSS way, that's a viewpoint you hold on OSS in general, and shouldn't be a problem of this one project, which is after all Open Source too.)

* "but it does strike me as the kind of "follow the crowd" stuff that indicates you're not doing enough free thinking." - so we've all these problems where he's not doing it the standard way, but when he does do it the standard way, that's not "free thinking"? Sorry, it's a fallacy to suggest that somehow it's a sign of poor thinking. Why is following what the FSF say on their licence not free thinking, but you are expecting him to do what you say? Should he not do some free thinking and do differently to what you say, by this reasoning?

* Disagree that being overly verbose is necessarily a problem, more a matter of preference.

* "Also, no need to zero out the data if you are just about to overwrite it anyway, it's just wasted CPU cycles." - I would recommend generally it's good practice to be initialising variables to some value on declaration. Unless your testing actually shows it to be a performance issue. (Agree about the point on constructors though; but this kind of premature optimisation, as well as the risk of missing initialisations, is generally bad practice.)

Comments like "just sloppy" for things that are common practice, without explaining why this is bad, isn't constructive. Might I suggest focus on the actual problems (or at least give nitpick comments as constructive comments rather than claiming it as evidence that someone's thinking is poor or the project is doomed; and avoid presenting opinion as fact)?

ETA: I guess someone had better tell the FSF are being "just sloppy" too ( http://www.gnu.org/l.../gpl-howto.html ). If I'm reading source code with a view to using it, I most certainly *do* care about the licence it's under.