All of the advice you guys are giving does not add new features or speed up anything. If I worried about every little random thing that adds nothing to the project then I would never make any progress... Some of the advice ApachPiQ gave was very useful but a super majority of it served no practical function other than aesthetics.

• If you aren't going to put effort into your website, take it offline now. Your web presence is your public face, and if you do not wish to maintain a good public image, don't have one at all. By refusing to put time into your web site, even to make it look nice and simple and clean, all you're telling me is that you don't care enough to do quality work. That right there is enough to guarantee I never use your library.

• Every open source project I know of keeps live binaries of their latest stable release, and often several older releases. This is standard practice. Nobody says you need to have every single revision posted as a binary. Either way, that's totally not my point: my point is that you hype up your project as "cross platform" and then don't even offer downloads for more than one platform. False advertisement makes people hate you.

• Again, refusing to update your public presence is just petulant and foolish. You have a lot to learn about programming, but even more to learn about how to present a good image and market yourself and your work. If you won't put in the token five minute effort to update your web site and remove these "outdated" links, you should stop having a website altogether. A poorly run site is far more damaging than having no site at all.

• Why are you willing to work on your Google code page but not your "official" site? Seems utterly random to me.

• Don't put code in your "Examples" path in your repository if you refuse to treat them as usage examples. Call it something appropriate instead. If you call them examples, I'm going to treat them like examples, and I am not the one who is wrong if you disagree.

• I know what @brief is for. My point is that you are not using it for its intended purpose, which is describing the source file. Why the hell would you go to the trouble of running Doxygen against your codebase if you refuse to even use it correctly?

• Also, spamming your license is always going to look silly to me (and yes, I think Apache's license is silly for doing this; I've felt that way for years). It is perfectly legitimate to have your source file point to a URL with the full license text, or just include the license in an obvious place and leave it out of the code header entirely. Every open source project I run does this. It's a personal preference and I certainly won't try to suggest that your code is worse off for it, but it does strike me as the kind of "follow the crowd" stuff that indicates you're not doing enough free thinking. OSS is full of this herd-mentality crap and it drives me nuts.

• I have a hard time believing you've fixed all of your inconsistent formatting and naming issues across your entire code base in a matter of three and a half hours... although, to be fair, you've got a tiny code base, so maybe you did. But I remain skeptical.

• Your "self explanatory" code is still ridiculously obscure. If I see "simplify(100, 0);" in code, I should not have to go look up what the 100 and 0 mean, nor should I have to spend time scratching my head wondering as to what orifice you pulled the number 100 out of. Name things properly, comment them, and for the love of bacon stop using magic numbers all over the damn place. Also, why does 0 as max_vertices not remove all vertices? That isn't clear either. You have a long way to go before you don't need any "further explanation".

• If it's a pain to use your repository, get better tools, or learn to use the tools you already have. I have integrated version control history in my IDE and I need two or three clicks tops to see a complete revision history for a file. Laziness is not an excuse.

• The fact that "the version of the engine [you] have on [your] hard drive right now" looks different from your version control master suggests that you have some terrible habits about how often you commit. If you modify and (successfully) compile code more than once without a commit, you're doing version control wrong. Learn how to use branches.

• Anywhere you have foo* bar = new foo(...) you are doing it wrong. This is terrible C++ practice. Further, anything of the form foo* bar = new foo[...] is bad. Your lack of RAII usage means that if any of the functions you call throw exceptions, you will leak resources like crazy. Look up "exception safety" if you need more details on this. As for C-style casts, never use (foo*)(bar) or anything of that nature. Use static_cast, reinterpret_cast, dynamic_cast, and const_cast - in order of decreasing frequency, i.e. you should use static_cast most often and virtually never touch const_cast. Look up C++ cast operators if you don't already know the details of each of these.

• The extern "C"/namespace/DLL export thing is really a long list of problems. First of all, declaring something inside a namespace as extern "C" is silly, because C has no namespace notion, and name mangling rules inside namespaces are ill-defined when trying to blend C and C++ name mangling conventions. This can bite you very hard as soon as you actually start using more than one compiler. Second, using declspec for DLL exports at all indicates you don't know anything about cross-platform or even cross-compiler programming. Third, you export classes which have non-POD members, which indicates that you know nothing whatsoever about how DLLs even work on Windows, let alone how dynamic linking works in the rest of the world, and you have no business writing DLLs at all. Do some research on this - and keep reading until you are shocked to learn how broken your current code is.

Finally, you seem to have missed my underlying point (which, I admit, I never explicitly said, so my apologies). My critique of your code was not meant to say you have some small cosmetic problems and everything will be fine and dandy if you rearrange the deck chairs. My point is that your ship is not just sinking, it's on fire, carrying a zombie plague, about to be struck by a comet, and populated by Justin Bieber clones. If I can find that many flaws in ten minutes of skimming one small file out of your code base, I don't even want to think about the problems I would likely find if I did a proper architectural review of your design, or the real issues that would crop up if anyone actually tried to use your "engine" as it stands.

Let me be perfectly clear: I'm not saying you should just give up and never touch a computer again. I'm saying that you need to understand that, despite the significance of what you've finished, you have sooo much to learn and improve upon if you want to be touting your project as something others should be interested in.


[edit]
[font=arial, verdana, tahoma, sans-serif][size=2]

All of the advice you guys are giving does not add new features or speed up anything. If I worried about every little random thing that adds nothing to the project then I would never make any progress... Some of the advice ApachPiQ gave was very useful but a super majority of it served no practical function other than aesthetics.

[/font][font=arial, verdana, tahoma, sans-serif][size=2]
[/font][font=arial, verdana, tahoma, sans-serif][size=2]...[/font][font=arial, verdana, tahoma, sans-serif][size=2]
[/font][font=arial, verdana, tahoma, sans-serif][size=2]Seriously?[/font][font=arial, verdana, tahoma, sans-serif][size=2]
[/font][font=arial, verdana, tahoma, sans-serif][size=2]I think I'm done here. No sense wasting my time if you don't want to listen.[/font]

Some of the advice ApachPiQ gave was very useful but a super majority of it served no practical function other than aesthetics.

This is the huge difference between building a game, and building an *engine*.

If you are building a game, you take the shortcuts you have to, to get everything done on time, because the goal is defined by feature-completeness on the ship date. But in building an engine, your goal is shifted: you need to provide a clear and simple interface to the developers who will be *using* your engine. All those little aesthetic changes represent the difference between a piece of software another programmer would consider using, and something they won't even look twice at.

This will confuse every single person that uses your code, they will expect a cross product or a dot product (which is why, in my code, I never overload the * or / operator for vectors because it's just so ambiguous).

No way -- the symbol for dot product is a dot, and cross is a cross, neither are a star. If the multiply (*) operator is provided, then the only thing you should be expecting is a component-wise multiplication.
Mathematicians be damned, no graphics/games programmer should be confused by this

[font="arial, verdana, tahoma, sans-serif"]

[font="arial, verdana, tahoma, sans-serif"][quote name='SteveDeFacto' timestamp='1314229312' post='4853451']Some of the advice ApachPiQ gave was very useful but a super majority of it served no practical function other than aesthetics.

[/font][font="arial, verdana, tahoma, sans-serif"]Seriously? [/font][font="arial, verdana, tahoma, sans-serif"]I think I'm done here. No sense wasting my time if you don't want to listen.[/font][/quote]Most of your advice had the smug tone of a back-seat driver pointing out the flaws of an expert, while your real subject is actually a complete amateur. You could've been a little nicer... but seeing as it's "I'm done here" time; go cry emo kid.[/font]

[quote name='SteveDeFacto' timestamp='1314229312' post='4853451']
Some of the advice ApachPiQ gave was very useful but a super majority of it served no practical function other than aesthetics.

This is the huge difference between building a game, and building an *engine*.

If you are building a game, you take the shortcuts you have to, to get everything done on time, because the goal is defined by feature-completeness on the ship date. But in building an engine, your goal is shifted: you need to provide a clear and simple interface to the developers who will be *using* your engine. All those little aesthetic changes represent the difference between a piece of software another programmer would consider using, and something they won't even look twice at.
[/quote]

I agree but at the moment I'm trying to just get it working. I'll polish it after everything is actually somewhat functional. If I worry about every little detail it will take me far longer to actually get a usable product out.

[font="arial, verdana, tahoma, sans-serif"]Most of your advice had the smug tone of a back-seat driver pointing out the flaws of an expert, while your real subject is actually a complete amateur. You could've been a little nicer... but seeing as it's "I'm done here" time; go cry emo kid.[/font]

Was that really necessary?


Look, I've gone out of my way to be clear about my opinion on this situation: what Steve has done is impressive in its own right. But it's got a lot of room for improvement, and it shows a lot of fundamental flaws that IMHO need to be addressed in order to improve the chances of the project's overall success.


I'm bowing out because apparently he's not interested in fixing the flaws at the moment, so why annoy him by continuing to be negative? Why consume more of my own time on something that he hasn't decided is a priority? I'm not all "oh noes someone isn't revering my sage advice" here - I'm leaving well enough alone because neither party is interested in continuing to focus on the problems in the project.

I'm not going to do anything in a moderative capacity here because I have been involved in the thread too much, but seriously... that was utterly uncalled for and I'm rather disappointed in you that you're doing such childish junk here. I've come to expect better from you.

Aw come on, don't be like that! Hugs?

[quote name='Hodgman' timestamp='1314232283' post='4853461']
[font="arial, verdana, tahoma, sans-serif"]Most of your advice had the smug tone of a back-seat driver pointing out the flaws of an expert, while your real subject is actually a complete amateur. You could've been a little nicer... but seeing as it's "I'm done here" time; go cry emo kid.[/font]

Was that really necessary?


Look, I've gone out of my way to be clear about my opinion on this situation: what Steve has done is impressive in its own right. But it's got a lot of room for improvement, and it shows a lot of fundamental flaws that IMHO need to be addressed in order to improve the chances of the project's overall success.


I'm bowing out because apparently he's not interested in fixing the flaws at the moment, so why annoy him by continuing to be negative? Why consume more of my own time on something that he hasn't decided is a priority? I'm not all "oh noes someone isn't revering my sage advice" here - I'm leaving well enough alone because neither party is interested in continuing to focus on the problems in the project.

I'm not going to do anything in a moderative capacity here because I have been involved in the thread too much, but seriously... that was utterly uncalled for and I'm rather disappointed in you that you're doing such childish junk here. I've come to expect better from you.
[/quote]

Actually, instead of chiming out. I could add you as a project committer and instead of telling me what I did wrong you could just change and commit your modifications. I won't expect you to contribute and you can make modifications only if you feel like it. Would you be interested?

I appreciate the offer, but I'll have to decline, for two reasons.

First, I don't have time. I already have a full time job programming and a second hobby project which is basically another full time job. I'm more than happy to point out areas where you could improve, but that represents a minimal investment of effort on my end, and is certainly far more practical for me to do than to go and start doing heavy lifting on yet another project.

Secondly, I don't think it's as effective. You can learn a little bit by looking at someone else's rework of your code, but you can learn a lot more by rewriting it yourself with tips on what needs changing. You'll benefit far more in the long run by internalizing the reasons for doing things one way versus another way; simply following someone else's rules by rote is not going to do you any favors.