• Create Account

# What does GDNet think about my game engine?

Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

118 replies to this topic

### #21 SteveDeFacto   Banned   -  Reputation: 103

Posted 24 August 2011 - 06:41 AM

There are many many features not demonstrated in this test. Also it's loading an FBX file not a BSP file.

Yes, but that doesn't answer my question; what makes it 'next generation'?

It's not... Yet...

I see... *looks at 'about' box on website*
I see...

OK, so what planned features do you have which make it 'next generation'?

http://ovgl.org/view_topic.php?topic=91JL96IHFS

### #22phantom  Moderators   -  Reputation: 5016

Posted 24 August 2011 - 08:06 AM

A terrain system, no matter how 'clever' does not a next generation engine make...

(btw, a 3D volume texture is a massively inefficient way of doing this; you'll want to use some kind of sparse structure or you'll just be wasting vast amounts of ram and processing time)

### #23ApochPiQ  Moderators   -  Reputation: 10412

Posted 24 August 2011 - 12:40 PM

On the one hand, it is certainly commendable that you are putting forth such consistent effort on such a large scale project. Most people don't have it in them to stick with things like this long enough to get results.

On the flip side, though, I kind of agree with Phantom, although I'm a little more understanding about your own opinion of your work. When I was a much younger and less experienced programmer, I also over-described my projects and over-inflated the complexity, richness, and polish of what I worked on. So I totally know what it feels like; you've done something significant, which by all means you should be proud of - but not too proud.

Realism is important, and humility is nothing short of vital, especially when you start opening your work to external criticism. Remember that you are in a position where you need feedback, not sales; overselling your work is going to harm you far more than it will help. What does it gain if people think your project is really cool at first, but never use it because it can't deliver on your promises? Conversely, what do you have to lose if people try your project with low expectations and are pleasantly surprised by what they find?

It is always better to underpromise and overdeliver than vice versa.

You cannot possibly compete with the large teams of people who are making actual next-generation game engines. And even if you could, you wouldn't have to post about it on GDNet - your work would speak so loudly for itself that we'd almost certainly be talking about it already. So by projecting this image like your lone-wolf operation is going to beat out id or Crytek, you're really just inviting a lot of skepticism and dismissal from the people you should be courting.

I haven't had a chance to look at the code itself, so my opinion may change for the better, but judging from your posting history around here I wouldn't exactly jump at the chance to commit my next title to your code base. Again, I don't want to minimize your accomplishment, or sound too critical; you've got a lot of good stuff done. But my gut is that there's still a huge amount of room for improvement.
Maker of Machinery

### #24phantom  Moderators   -  Reputation: 5016

Posted 24 August 2011 - 12:48 PM

Yes, don't get me wrong; it's good that you are doing something HOWEVER the term 'next generation' has been thrown around so much as to have become even more meaningless than when it was first used.

Most features people see as 'next generation' are in fact CURRENT generation and have been for some time. The term "next generation" implies you are pushing features and tech beyond what we currently have... most people aren't doing that.

Your terrain rendering tech idea have some promise, but as far as I can tell it's nothing more than an idea right now; run with it by all means, I'll be intrested to see the outcome as that sort of tech is something I'm intrested in but that doesn't mean you have a 'next gen' engine.

### #25ApochPiQ  Moderators   -  Reputation: 10412

Posted 24 August 2011 - 01:17 PM

Here's some accumulated thoughts after looking at your project:

• I hope to God your code is better than your web design. Seriously, find someone with some actual graphic design experience and at least get some pointers on how to improve your site. Remember, your site is going to be your first impression for a lot of people, and if that first impression is less than stellar, you're going to lose a lot of potential interest right then and there.
• Your downloads page is depressing. For claiming to be cross-platform, not even having Linux or Mac downloads is an instant loser in my book. If you can't actually support multiple platforms right now and prove it, then don't advertise as such.
• Your Google Code page... uh... leaves a lot to be desired. Seriously, put some effort into this - it's what determines how many people will care about your project. Your code could be the best thing ever, but I'll never know as the average Joe stumbling across your site, because you look like you don't even care enough to properly describe your project on its own home page.
• Your examples exhibit a typical failure of example code. You put too much focus on brief, simple-looking demos and not enough focus on showing how a real project would use your library. Unless of course your "real" usages are full of poorly-factored functions, magic numbers, global variables, and other bad engineering practices - which I hope not, for your sake.
• I cherry-picked OvglMesh.cpp to look at, just because it seemed decently-sized and mesh handling is fairly core to any rendering engine. Following are a few shotgun observations from that file.
• Your operator== and operator!= implementations look a bit bush-league. This is not a nice thing for me to see as the very first bit of your code that I review. Why not just return (memcmp(...) == 0); instead of the totally unnecessary if and else? This sort of verbose over-implementation of a very trivial code concept doesn't give me much hope for the rest of your code's quality. Now, I'm doing my best not to make snap judgments and just prematurely conclude that all of your code is this questionable, but the average reviewer may not be so gracious.
• Why do you explicitly qualify all of your namespaces instead of dropping in judicious using-declarations or explicitly wrapping the implementations in a namespace {} block? This is another newbie-level mistake in code organization and reflects poorly on your code quality once again.
• Your code formatting is inconsistent, particularly when it comes to spacing and indentation and brace styles. Pick a format and stick with it. This is probably the single biggest smell I detect in new programmers' work - if you aren't disciplined and consistent enough to format things the same way even in the same 20KB file, what else are you cutting corners on?
• Magic numbers are evil, and your code is littered with them. What does mesh->Simplify(100, 0) mean? That's just terrible style and, yet again, makes me question if I should even bother looking at the large-picture architectural design of your code. If the implementation is this sloppy, I'm probably not going to like what I find at a ten-thousand-foot perspective.
• Checking in code with commented-out lines to your version-control repository is the height of sloppy. If you don't need code, remove it. If you need it again in the future, pull it out of revision history. There is no excuse for commenting out large swaths of code and then committing that.
• You use std::vector<std::vector<Ovgl::Face>> (note the >> with no separating space) which is not strictly legal prior to C++11, and will make many compilers barf in odd situations.
• Your (lack of) naming conventions makes it extremely hard to tell what is a local variable versus a class member versus a global, just by glancing; I don't advocate Hungarian notation, but at least format names in a way that makes it easier to tell where they belong, e.g. lowercasenames for locals, CamelCaseNames for members, and UPPERCASENAMES for constants/macros/etc.
• Your code lacks even rudimentary exception safety, and the use of raw pointers and arrays is a sign of very poor C++ style, at best. At worst, it's a guarantee that your code is riddled with nasty and subtle bugs.
• Anyone who writes a C-style cast in a C++ program should be lashed repeatedly with a USB cable.
• Lots more magic numbers and no documentation. What the hell is the point of all that index shuffling going on in Mesh::Update()? Documentation is your friend!
• You use an awful lot of platform-dependent type definitions (e.g. DWORD) for claiming to be cross-platform code. Not good.
• For some reason I popped open OvglMesh.h to see something in there, and I'll switch to remarking on that next. I didn't finish the .cpp file because I figure you've got enough negativity to deal with already ;-)
• Your Clean enum has terribly named entries. Better hope you never need a different enum with similarly-named entries! Common convention on every team I've worked with is to prefix enum entries with the enum name itself, e.g. CLEAN_BROKEN_FACES.
• extern "C". Inside a namespace. Exporting classes with std::vector members. At this point, I give up; this is hopelessly broken code and it's a bloody miracle it works on Windows, and will certainly never work anywhere else.
I have reached the conclusion I was afraid of from the beginning: you're not nearly experienced enough as a programmer to be billing this as a next-generation game engine. Or a last-gen game engine. Or even a game engine, because it's barely a renderer wrapper for OpenGL. Your code is full of mistakes and poor practices and outright sins; you have a dearth of actual features; and nothing - from your demos, to your library implementations, to your website(s), to the design of the library itself - strikes me as anywhere close to production quality.

I don't want to be discouraging here. Think of it as tough love. Like I said before, you've done a lot of work and your results are certainly something to be proud of - to an extent. I believe that and stand by it.

But you have a really long way to go.
Maker of Machinery

### #26Codarki  Members   -  Reputation: 462

Posted 24 August 2011 - 01:20 PM

At first I was amused by the "next generation" as well, and trying to do so alone will take more time than it's possible (it will be current gen at finish). Also going for cross platform can be a wrong decision. But this is going a bit off topic. I'm happy to see the progress, and you should continue it even if you sometimes lack the motivation. In the end you have something on your hands or you have learned a ton. Just realize when it's time to drop the project and start new one. I've had over year long hobby projects which I was wise to drop.

### #27Koobazaur  Members   -  Reputation: 649

Posted 24 August 2011 - 04:34 PM

After reading Apoch's post I got curious and looked at the code. wow, he didn't exaggarate. Why in the world do you have "class Mesh" AND "class CMesh" ? That's just downright confusing. A few other hints:


Ovgl::Vector2 Ovgl::Vector2Set( float x, float y )
{
Ovgl::Vector2 out = {0};
out.x = x;
out.y = y;
return out;
}

This function (as well as all the similar ones for ever data type) are entirely superflous and inefficient. Look up "constructors." Also, no need to zero out the data if you are just about to overwrite it anyway, it's just wasted CPU cycles.

Ovgl::Vector3 Ovgl::Vector3::operator * ( const Ovgl::Vector3& in ) const
{
Ovgl::Vector3 out = {0};
out.x = x * in.x;
out.y = y * in.y;
out.z = z * in.z;
return out;
}


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)....and basically everything else Apoch said about inconsistencies and inefficiencies. You may want to read a good book or two on C++ since you seem to be missing out on some very basic concepts (like constructors).[/color]

### #28 SteveDeFacto   Banned   -  Reputation: 103

Posted 24 August 2011 - 04:58 PM

• I hope to God your code is better than your web design. Seriously, find someone with some actual graphic design experience and at least get some pointers on how to improve your site. Remember, your site is going to be your first impression for a lot of people, and if that first impression is less than stellar, you're going to lose a lot of potential interest right then and there.

Coded it in notepad, Made UI images in GIMP, and uploaded it with FileZiilla. Not going to work on it until Ovgl is at least in beta and has all major features implemented.

• Your downloads page is depressing. For claiming to be cross-platform, not even having Linux or Mac downloads is an instant loser in my book. If you can't actually support multiple platforms right now and prove it, then don't advertise as such.

How many open source projects do you know of actually keep up to date binaries on their downloads page? It would be a massive wast of time to compile and upload every single minor update. I'm talk 80% of my effort could literally go to maintaining up to date binaries...

Those were posted almost a year ago. I've not updated them and don't plan to until the projects reaches beta.

• Your Google Code page... uh... leaves a lot to be desired. Seriously, put some effort into this - it's what determines how many people will care about your project. Your code could be the best thing ever, but I'll never know as the average Joe stumbling across your site, because you look like you don't even care enough to properly describe your project on its own home page.

Well I agree and I'm going to work on that soon.

• Your examples exhibit a typical failure of example code. You put too much focus on brief, simple-looking demos and not enough focus on showing how a real project would use your library. Unless of course your "real" usages are full of poorly-factored functions, magic numbers, global variables, and other bad engineering practices - which I hope not, for your sake.

Technically not examples. They are more like place holders right now.

Every open source project I know of places the license in the code. A few examples I can pull off the top of my head are Bullet, Box2D, Recast and many many more.The apache license clearly states to place the license in your code as well.
@brief, @file, and others are tags for doxygen. Those are required to use doxygen to automatically generate documentation.

• Your operator== and operator!= implementations look a bit bush-league. This is not a nice thing for me to see as the very first bit of your code that I review. Why not just return (memcmp(...) == 0); instead of the totally unnecessary if and else? This sort of verbose over-implementation of a very trivial code concept doesn't give me much hope for the rest of your code's quality. Now, I'm doing my best not to make snap judgments and just prematurely conclude that all of your code is this questionable, but the average reviewer may not be so gracious.

Fixed

• Why do you explicitly qualify all of your namespaces instead of dropping in judicious using-declarations or explicitly wrapping the implementations in a namespace {} block? This is another newbie-level mistake in code organization and reflects poorly on your code quality once again.

Good point

• Your code formatting is inconsistent, particularly when it comes to spacing and indentation and brace styles. Pick a format and stick with it. This is probably the single biggest smell I detect in new programmers' work - if you aren't disciplined and consistent enough to format things the same way even in the same 20KB file, what else are you cutting corners on?

Fixed

• Magic numbers are evil, and your code is littered with them. What does mesh->Simplify(100, 0) mean? That's just terrible style and, yet again, makes me question if I should even bother looking at the large-picture architectural design of your code. If the implementation is this sloppy, I'm probably not going to like what I find at a ten-thousand-foot perspective.

void Ovgl::Mesh::Simplify( DWORD max_faces, DWORD max_vertices )
To me that speaks for it's self. Simplify mesh to have no more than 100 faces. No further explanation should be require...

• Checking in code with commented-out lines to your version-control repository is the height of sloppy. If you don't need code, remove it. If you need it again in the future, pull it out of revision history. There is no excuse for commenting out large swaths of code and then committing that.

This is true but it's honestly a pain to have to download and search through code every time I want to change something. Especially since all of the code I commented I was actively working on at the time. Those lines are already fixed in the version of the engine I have on my hard drive right now.

• You use std::vector<std::vector<Ovgl::Face>> (note the >> with no separating space) which is not strictly legal prior to C++11, and will make many compilers barf in odd situations.

Fixed

• Your (lack of) naming conventions makes it extremely hard to tell what is a local variable versus a class member versus a global, just by glancing; I don't advocate Hungarian notation, but at least format names in a way that makes it easier to tell where they belong, e.g. lowercasenames for locals, CamelCaseNames for members, and UPPERCASENAMES for constants/macros/etc.

Honestly have never heard that rule. I will work to fix that.

• Your code lacks even rudimentary exception safety, and the use of raw pointers and arrays is a sign of very poor C++ style, at best. At worst, it's a guarantee that your code is riddled with nasty and subtle bugs.
• Anyone who writes a C-style cast in a C++ program should be lashed repeatedly with a USB cable.

Can you show me a few examples of what you are talking about?

• Lots more magic numbers and no documentation. What the hell is the point of all that index shuffling going on in Mesh::Update()? Documentation is your friend!

• You use an awful lot of platform-dependent type definitions (e.g. DWORD) for claiming to be cross-platform code. Not good.

You are right and I've been trying to start changing my style so it will be easier to port the project.

• Your Clean enum has terribly named entries. Better hope you never need a different enum with similarly-named entries! Common convention on every team I've worked with is to prefix enum entries with the enum name itself, e.g. CLEAN_BROKEN_FACES.

Fixed

• extern "C". Inside a namespace. Exporting classes with std::vector members. At this point, I give up; this is hopelessly broken code and it's a bloody miracle it works on Windows, and will certainly never work anywhere else.

extern "C" should be on the outside of a namespace?

### #29 SteveDeFacto   Banned   -  Reputation: 103

Posted 24 August 2011 - 05:12 PM

After reading Apoch's post I got curious and looked at the code. wow, he didn't exaggarate. Why in the world do you have "class Mesh" AND "class CMesh" ? That's just downright confusing. A few other hints:


Ovgl::Vector2 Ovgl::Vector2Set( float x, float y )
{
Ovgl::Vector2 out = {0};
out.x = x;
out.y = y;
return out;
}

This function (as well as all the similar ones for ever data type) are entirely superflous and inefficient. Look up "constructors." Also, no need to zero out the data if you are just about to overwrite it anyway, it's just wasted CPU cycles.

Ovgl::Vector3 Ovgl::Vector3::operator * ( const Ovgl::Vector3& in ) const
{
Ovgl::Vector3 out = {0};
out.x = x * in.x;
out.y = y * in.y;
out.z = z * in.z;
return out;
}


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)....and basically everything else Apoch said about inconsistencies and inefficiencies. You may want to read a good book or two on C++ since you seem to be missing out on some very basic concepts (like constructors).[/color]

Lack of constructors and destructors are the thing I'm most ashamed of. You must realize I started with DirectX and Visual Basic. This exact engine has been built and rebuilt more times than I can count and the release and create functions you see are copy and pasted from my older versions of the engine. The structure of the engine is evolving from what I observe from other languages and APIs. This API has technically been in development for almost 10 years in some form or another. It's like a mash of all previous failed attempts.

### #30phantom  Moderators   -  Reputation: 5016

Posted 24 August 2011 - 05:28 PM

Coded it in notepad, Made UI images in GIMP, and uploaded it with FileZiilla. Not going to work on it until Ovgl is at least in beta and has all major features implemented.

Then why does it even exist now?

How many open source projects do you know of actually keep up to date binaries on their downloads page? It would be a massive wast of time to compile and upload every single minor update. I'm talk 80% of my effort could literally go to maintaining up to date binaries...

A) this has no relevance to his point; his point was you claim to support Win, OSX and Linux yet lack binaries for all but Windows
B) Projects update on major/minor releases but not every little code change. Normally when something is feature complete in some manner/milestone

Those were posted almost a year ago. I've not updated them and don't plan to until the projects reaches beta.

Then why do they still exist? Wy not get rid of them?

Technically not examples. They are more like place holders right now.

Maybe not but for anyone stumbling across your page they will look like it. If they aren't right then TAKE THEM DOWN.

void Ovgl::Mesh::Simplify( DWORD max_faces, DWORD max_vertices )
To me that speaks for it's self. Simplify mesh to have no more than 100 faces. No further explanation should be require...

Yes, but the magic numbers in the code don't tell you what is going on at the point the function is being called. They just look like any old number; and what does '0' for max vertices mean? How does that even make sense?

This is true but it's honestly a pain to have to download and search through code every time I want to change something. Especially since all of the code I commented I was actively working on at the time. Those lines are already fixed in the version of the engine I have on my hard drive right now.

Then they never should have been submitted because they weren't finished.

### #31 SteveDeFacto   Banned   -  Reputation: 103

Posted 24 August 2011 - 05:41 PM

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.

### #32Antheus  Members   -  Reputation: 2381

Posted 24 August 2011 - 05:51 PM

How many open source projects do you know of actually keep up to date binaries on their downloads page? It would be a massive wast of time to compile and upload every single minor update. I'm talk 80% of my effort could literally go to maintaining up to date binaries...

Be next-gen.

If you use git-like source control, you could also run builds locally without any extra hassle.

### #33ApochPiQ  Moderators   -  Reputation: 10412

Posted 24 August 2011 - 05:59 PM

• 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.

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.

...
Seriously?
I think I'm done here. No sense wasting my time if you don't want to listen.
Maker of Machinery

### #34swiftcoder  Senior Moderators   -  Reputation: 7267

Posted 24 August 2011 - 06:20 PM

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.

Tristam MacDonald - SDE II @ Amazon - swiftcoding        [Need to sync your files via the cloud? | Need affordable web hosting?]

### #35Hodgman  Moderators   -  Reputation: 19234

Posted 24 August 2011 - 06:31 PM

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

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

Seriously? I think I'm done here. No sense wasting my time if you don't want to listen.

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.

### #36 SteveDeFacto   Banned   -  Reputation: 103

Posted 24 August 2011 - 07:22 PM

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.

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.

### #37ApochPiQ  Moderators   -  Reputation: 10412

Posted 24 August 2011 - 07:38 PM

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.

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.
Maker of Machinery

### #38Hodgman  Moderators   -  Reputation: 19234

Posted 24 August 2011 - 07:41 PM

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

### #39 SteveDeFacto   Banned   -  Reputation: 103

Posted 24 August 2011 - 08:43 PM

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.

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.

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?

### #40ApochPiQ  Moderators   -  Reputation: 10412

Posted 24 August 2011 - 11:59 PM

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.
Maker of Machinery

Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

PARTNERS