Depends on how mature it was before it was abandoned. If it was fairly mature (ie, no game-breaking bugs) then no biggie. Additionally, it depends upon your ability and willingness to fix for yourself any bugs that do occur. If it's so complex that a bug would stymie you, then maybe don't use it. Finally, it might also depend on the availability of other, more active, libraries that can fill the same need.
One quick and hacky way to do it is to advance along the curve using very tiny increments of the curve parameter, s, accumulating distance as you go until you reach the distance you want to move. It's not as elegant as a numerical solution, but it's easy to do and should probably be fast enough for most applications.
Couple of them are Ruby, I didn't really want to install Ruby so I didn't try them. Here are my comments (don't expect any kind of system, here):
Lucentbeam - This entry had a cool visual vibe, I like the clockwork look and theme. But the controls seemed wonky and confusing. Left and right didn't map directly to counterclockwise/clockwise, but instead seemed to toggle. If I pressed left once, it would go clockwise; press left again and it would reverse. Same with left. They seemed to switch meanings, and it confused me.
crow007 - While it doesn't look like much, it's actually the one I played for the longest. Ball speeds seemed kind of unpredictable.
Noctumus - Very smooth, very fast paced. A little too fast paced for my slow, creaky old reflexes. It looked decent, played well.
wintertime - Didn't play.
vortez - I really liked the updated/traditional look. True to the original, but with a modern upgrade to it. Played fast and smooth (again, a bit too fast) but the predictability was a snag. Ball always launches at the same angle. Of course, given the disparity between the ball speed and paddle speed, this is probably for the best.
shadowisadog - This one was pretty basic, visually. Biggest issue I noticed was that it ran very roughly, as if no smoothing or interpolation were being done on the ball movement. Made it very difficult to play for more than a few seconds.
segmented - Loved the style and look of it. Theme was pretty cool. Biggest issue was that the "splash" or explosion the ball makes when hitting the walls made it hard to know if my paddle was lined up on the ball properly. Made for a confusing play experience.
ml_ - Didn't play.
staunsholm - Didn't play.
mippy - "Hot balls!" This one made me chuckle, when I got the "Hot Balls!" message. Was a little bit confusing to know what was going on. I sometimes got blown up and wasn't sure why.
I will hold off agreeing or disagreeing with you for now, Aspirer, and ask a question. I have pretty much made Super Metroid and Megaman X clones before. How much harder would a Final Fantasy VI clone be?
This depends entirely on your definition of "pretty much". Were they finished, polished and shippable clones? Or were they basically prototypes that emulated a few of the core aspects of those game, using assets ripped from those games or others, enough that you told yourself that you were finished? Because the former is so, so drastically different from the latter.
Third party libraries like Bullet, especially mature ones that have been well-used and much-iterated, tend to be fairly complex to look at because the iteration tends to follow along the lines of a) making it more general-purpose, and accounting for as many use cases as possible and b) making it as performant as possible. General usefulness can add a lot of complexity, since the library authors have to code in such a manner so as not to exclude use cases. Bullet wouldn't be as useful if it could only be used for Angry Birds, for example. And highly performant code tends to be hard to read because often the code that reads the easiest isn't necessarily the code that executes the fastest. Once you start dipping into the more esoteric forms of optimization (you mentioned ASM and SSE) then it gets even more difficult to read, especially if you have little or no familiarity with them.
Don't worry too much if your own code isn't as seemingly complex. Worry more that it does what you need it to. Upper level code that uses these underlying frameworks will typically be less complex than the framework code itself, since the whole point of framework code is to abstract away a lot of messy detail.
At some point, you have to stop talking about your game project and start actually working on it. All the discussion in the world amounts only to windy, hot air blown across the forums. It's all meaningless unless you actually start writing code. People don't believe you've got what it takes to make this, hence the constant off-railing that goes on as people try to tell you to try simpler things. The only way you'll ever convince us otherwise is to show some concrete progress. Concrete progress won't be made if all you ever do is create threads trying to drum up some kind of discussion.
Exactly what actual concrete design/development have you done on this? Because the difficulty in this task simply isn't in creating the function used to represent/generate the world, but rather lies in the abstraction that you use to translate the outputs of this function into concrete vertex buffers to feed to the GPU. Therein lies the difficulty. Sure, you could construct a noise function that takes (phi, theta, r) as an input. But what then? How is the underlying geometry structured? How are your LoDs handled? How are they stitched together?
The fundamental difficulty lies in sphere tessellation. The most common forms of sphere tessellation are (pictured here): cube map (top), uv sphere (left) and icosphere (right).
You can see that in the cube map there are the distortions of patch size/shape that increase as you draw nearer the corners. In the uv sphere representation (which most closely approximates polar coordinates), you still see distortion of patches, this time as you near the north and south poles. The icosphere is the only one of the three that has non-distorted, uniform patch sizes, and if you can figure out techniques for dealing with LoD on the triangular patches, this is probably your best bet for side-stepping distortion issues. Simply thinking you can use polar coordinates to magically eliminate distortion just won't work.
Personally, I think your best bet is to ditch the spherical basis and go with a volumetric approach. You can use dual contouring to stitch between LoD levels, and the shape of the planet is 100% determined by the shape of the function used to generate it, rather than being forced by the underlying abstraction onto a sphere. This means that if you want planets shaped like mountainous donuts, then no problem. The techniques underlying both the sphere planet and Planet Donut are exactly the same. Plus, a volumetric approach works out-of-the-box with a standard 3D noise function basis, so you don't have to do any weird tricks in constructing your basis.
Posted by FLeBlanc
on 25 September 2013 - 12:17 PM
Even outside of the legality of the act, consider it from the point of view of a player. Say Joe likes Super Mario Bros. He's played it before, he's got the original NES version plus everything that Nintendo has done in the way of remakes and re-releases. He can beat it on a speedrun in 5 minutes flat. Now he wants to play something else, something similar but new. So he goes to Google Play (or any other service) and searches for Super Mario clone, because that's the nearest search term he can think of. Now he has to wade through entry after entry of literal clones, trying to find what he is actually looking for: a spiritual clone, rather than a literal clone. Granted, Google Play isn't so big yet that there are entries upon entries, but take it through its eventual progression and you can see that as more and more games are added, it becomes more difficult to find one among the crowd.
One of the largest problems facing indie and small developers on distribution platforms like Google Play, and pretty much in general, has been obtaining visibility in such a noisy and crowded market. The signal-to-noise ratio on some of those platforms is very low, at least partially because of so many direct clones being pushed. Releasing yet another literal clone, regardless of if you do so for free or not, just adds one more bit of clutter making the problem worse for everyone else, without any of the redeeming benefits of it being an original game that brings something new to the table. You're just adding noise, with no signal.
Now, you're proud of what you have accomplished, and you should be. Making even a literal clone of something is an accomplishment. But it's the kind of accomplishment that you share with your friends and family, and maybe on a personal blog or facebook or twitter; it is not the kind of thing that you share on a distribution service such as Google Play or Steam or anything else where you provide no benefit to the community at large in doing so, and in fact make the service just that much worse for the people that are trying to release original and new works.
Posted by FLeBlanc
on 25 September 2013 - 09:13 AM
This all begs the question of why you (or anyone) would want to do this. The world already has Super Mario Bros. You should make something new that the world hasn't seen yet and add something positive to the sum of human culture, instead of pouring in another "me too, me too" copy of something else.
Posted by FLeBlanc
on 21 September 2013 - 08:47 AM
GUI code is quite frequently ugly, especially when you go through the steps of hand-configuring the elements as you are doing here. Most GUI frameworks provide some sort of instantiation of elements, whether from XML configuration or some other means, but if you refrain from using these configuration schemes and build your elements by hand instead then your code ends up looking a whole lot like what you have written here. There's just no way to write a fully configurable and flexible GUI system without having to specify a lot of data, either by hand or by config file. So don't feel too bad.
Posted by FLeBlanc
on 17 September 2013 - 03:58 PM
I'm just curious what the point of all this posting is. Are you asking for help with your (godawful spaghetti) code, or what? The running commentary here just seems sort of bizarre, and probably more suited for a journal or blog of some sort than the Game Programming forum.
Posted by FLeBlanc
on 13 September 2013 - 10:04 AM
std::map::find() returns an iterator, not a const T&. You can indirect the iterator to get the std::pair for the key/value pair the iterator points to, then get the value with second, and dereference this value to get the actual object. ie, auto iter=resource.find(s); return *((*iter).second);. This ignores the case where find returns resources.end(), meaning it wasn't found, in which case you throw an exception trying to dereference iter.
A common idiom used in this situation is to store a weak_ptr in the resource map, and return shared_ptr from GetResource(). GetResource will search the map and if an entry is found, test the weak_ptr stored. If this weak_ptr is valid then it will create a shared_ptr from it and return. If this weak_ptr is not valid (meaning all existing shared_ptrs have gone out of scope) then the resource is reloaded into a shared_ptr, a new weak_ptr is created and stored in the map and the shared_ptr is returned. If no entry at all is found, then a new entry is created, a new shared_ptr made, a weak_ptr stashed in the map, and return.
The point of this is that you aren't handing out possibly unsafe references to an object held by a unique_ptr, when you can't guarantee that the unique_ptr isn't going to go away at some point. Returning the reference just means that you have a potentially dangling reference if/when you wipe your resource map. By storing handed-out pointers as shared_ptrs, then the objects that request these resources have a say in managing the lifetime of the resource object. That is, the resource object can't disappear without everyone who has a pointer to the resource dropping it. Using a weak_ptr in the map means that if all shared_ptrs have been dropped, then the map itself won't stubbornly try to hold onto the resource, since a weak_ptr can't keep it alive.