What's a more important resource to optimize, the constantly increasing speeds of computer processors, or the constantly decreasing length of your life?
Listen to this talk.

He is practically saying everything that I've been saying...

[quote name='SteveDeFacto' timestamp='1314628755' post='4855064']
[quote name='Alpha_ProgDes' timestamp='1314626947' post='4855057']
If I"m talking out of line, my apologizes. But obviously, if you're creating a game engine obviously you need a clean API that clearly states the method and its purpose. Having duplicate code scattered everywhere is going to make your code execution slower and overall coding slower. Adding new features or even improvements will be a nightmare at best, if you have sloppy code running about. Making the engine super fast won't make a difference if people are too frustrated with your code and walk away from it. Honestly, you don't need a pretty site right now. But you need to remove unnecessary links that have nothing to do with your code or even worse don't work or exist in the first place. These guys are pretty good at what they do. I would heed their advice very closely. So, if I were you, I'd: remove dead links (or links to non-working code) and do a major refactor effort (since that's the number one thing I've seen here). Then micro-optimization can be done. And be done much easier.

I was not aware duplicating code instead of calling a function multiple times would actually somehow make the program run slower... Why does everyone keep saying that?...

As far as I'm aware clean internal code has no effect on the user of my library unless it has an external effect which none of the things anyone has brought up does. Eventually when I have a working product I will worry about cleaning up the code but at the moment the system is not even finished so I consider that a priority over internal polish. Commenting code, refactoring code, and properly capitalizing variables has nothing to do with the experience users of my library will have.
[/quote]
This is an open source API right? Which means that users will be able to see your code not just the method calls. And with most engines tweaks and changes will be made. Also, if this is a mash of 10 years of failed attempts... shouldn't that indicate something? But you're right writing the same code over and over again in different methods won't cause a performance slowdown (and no, I'm not trying to be sarcastic or condenscending). But unless you are going to only expose the method calls, which I doubt you're doing since this is open source, the way the code is written will affect your users. Again, especially those who need to add to or tweak your code. Also you don't really think that you're going to refactor and polish all of that after you get it working. Do you? Everyone participating in this thread knows that is not going to happen. Why? Because programmers don't normally do that after (especially right after) they finish a project. If anything, you'll do one of two things: fix bugs people point out or add features people want. And since that will be on top of what you have already written, the chances of refactoring goes down even more. Which is why everyone is strongly advising you to do it now instead of later.
[/quote]

You need to realize I've only open sourced it as a favor to the indie community and I consider it just another feature. I never planned to make the engine as a commercial project so it only made sense to open source it. I'm not going to spend an excessive amount of time making the code readable to others. Right now I have no problem reading and debugging my own code.

OK.

You need to realize I've only open sourced it as a favor to the indie community and I consider it just another feature.

By taking that attitude you aren't doing anyone any favours, least of all yourself. Features add value to a project. The only two ways that being open-source can add value to your project are a) that more projects utilise your engine, and b) that more people contribute code to your engine.

Now, plainly, nobody is likely to contribute to your code unless they see value for themselves in your project - and in general, that means that they must be using it in a project of their own. So even if we neglect the atrocious code issue for now, you still have a very large problem: marketing. To whit, you don't have any.

Making a library open-source does not magically mean that people will flock to your engine and contribute back to it: the onus is on you to convince them how your library can make their lives easier, their product better, etc.

[quote name='SteveDeFacto' timestamp='1314633175' post='4855103']
You need to realize I've only open sourced it as a favor to the indie community and I consider it just another feature.

By taking that attitude you aren't doing anyone any favours, least of all yourself. Features add value to a project. The only two ways that being open-source can add value to your project are a) that more projects utilise your engine, and b) that more people contribute code to your engine.

Now, plainly, nobody is likely to contribute to your code unless they see value for themselves in your project - and in general, that means that they must be using it in a project of their own. So even if we neglect the atrocious code issue for now, you still have a very large problem: marketing. To whit, you don't have any.

Making a library open-source does not magically mean that people will flock to your engine and contribute back to it: the onus is on you to convince them how your library can make their lives easier, their product better, etc.
[/quote]

Yes, I agree. The problem is that the project is still in alpha and I really don't see the point in marketing it at the moment... Really this post was simply to see what response I would get from my current progress. The main thing I'm starting to question is if it was really a good idea to open source it...

The problem is that the project is still in alpha

It is a pretty major problem - 10 years in alpha is giving Duke Nukem a run for his money

Improving the quality of your code is not primarily about other developers, it is aimed at yourself. At improving the speed at which you can add and test features. Because you dearly need to iterate your code faster - you need to be making progress, if you ever hope to have it out of alpha.

Yes, I agree. The problem is that the project is still in alpha and I really don't see the point in marketing it at the moment... Really this post was simply to see what response I would get from my current progress. The main thing I'm starting to question is if it was really a good idea to open source it...

This thread gave you a lot of invaluable hints on how to improve your code. What point is there to ask other people's opinions if all you want is a pat on the back? You should take those comments at heart and use them for good, but it's up to you. You should also ask yourself why so many people critizice (is that how that word is written!?) your code. Don't take it personally, but for what it is: great advice. I have been there as well, just trying to get things done, but in the end I had to put much more effort into my work, because I screwed up before. I learned from it and don't take the easy way anymore, even if it means working a full month on the foundation without any progress (that can be seen).

Yes, I agree. The problem is that the project is still in alpha and I really don't see the point in marketing it at the moment... Really this post was simply to see what response I would get from my current progress. The main thing I'm starting to question is if it was really a good idea to open source it...

Wait, so you start a thread to get a response to your code. You got a response to your code. And now you will turn around and ignore it because you don't like it?


Listen, 90% of the stuff pointed out in this thread is not "extra work." Keeping a consistent naming scheme, using a constructor instead of a Vector2Set() function, not using C-style features, wrapping things in namespaces instead of directly referencing them each time etc. takes JUST AS MUCH TIME (if not less) as what you are doing now. Except that in the long run, it WILL save you time, it WILL make your code run faster and it WILL make your engine more usable. At no additional cost to you now. So why are you so against these changes?

Because the feedback didn't fit the feedback he wanted ("this is great!") and instead took his code apart and showed that even after 10 years of development he still has a hell of a lot to learn.. I don't blame him, takes a big person to accept that kind of feedback and most people can't do it; see earlier comment about ego stroking.

Lesson here is even though a car engine needs engineering before and during its construction, a game engine obviously needs no part of software engineering.