Just a heads up for anyone looking for an engine that Shiva3D is currently half price.  Been having a look at it recently since the latest update allows for native code development and noticed the sale was on.  For that price I figured I'd give it a spin.

Eh. I just split collision into x and y, doing a sweep on x and then y separately.

The benefit of this is that it's really simple. And because most platformer characters aren't using both axis all the time, you don't have to test both axis all the time. And you slide off walls in a pleasant way.

Well to be fair, doing proper continuous collision testing is hardly difficult either.  The algorithms are well documented online and if anything I would say it ends up being simpler since you wont have to deal with edge cases.  I've not written a 2d platformer myself though so I could be wrong.

Please discuss below if you have any experience with this kind of thing or opinions about it.

If we're discussing alterantive collision methods you might be interested in this tutorial I wrote a while back for ShmupDev.  It goes into continuous collision techniques as well as a special time filter collision optimisation I designed specificaly for bullet hell style shoot-em-ups.  You might find it interesing:

Art Of Collision [part 2] : Circles, Dynamic Testing, and Time Filtering

PS: Unfortunately it seems all the images with that tutorial have dissapeared since the forum was archived.  Sorry about that, hopefully you can still understand what I'm getting at.

Well the point I'm making is that using a swept test you would only have to perform the collision test once for each object per frame that object moves and you would be garaunteed that one test would work in all scenarios and provide a correct answer.

Trying to reliably prevent object penetration using discrete collision checks without missing any collisions will always result in lots of edge cases to deal with, lots of special cases that need writing for different collision types such as slopes, and lots of situations where you'll end up having to perform many iterations each frame to resolve an objects movement.

Ultimately discrete collision checks just aren't suitable for solving these kinds of problems which can be resolved more easily and reliably using continuous collision algorithms.

Maybe this is a special case though since you're dealing with a fairly well defined grid environment, I'll be interested to see what you come up with.



Edit - Just realised I took a bit of a tangent there, the issue isn't one of discrete versus continuous.  You are in-fact trying to do continuous collision detection of sorts but just doing it incorrectly by splitting your continuous collision test into seperate x and y axis components rather than dealing with it once along the true direction.  My point still holds though, trying to do it this way rather than using a true continuous test will result in all the same issues I described.

Finding the boundary is just the beginning, I have only described the simplest implementation so far.

A slightly more in-depth way of doing it is to:

• update the boundary in the x direction
• move the player in the x direction
• update the boundary in the y direction
• move the player in the y direction
• repeat until:
• the player has moved the maximum amount described by their velocity
• OR the player's position hasn't changed since the last step

This kind of movement handling becomes more important with entity-to-entity collisions, which I will cover later.

This doesn't seem to be the most efficient solution and would be very slow in the worst case scenario when the player is moving along a diagonal slope which would result in a large number of iterations of your algorithm to resolve.  A simple swept collision test would solve all these issues.

PS:  Just realised there's also the problem that your algo would fail to find collision against floating islands of terrain that lie in a diagonal direction to the player along the direction they wish to move but dont overlap the players x or y axis projections.  I can draw a diagram if you dont see what I'm getting at, let me know. 

Your algorithm fails if the player is allowed to move along both axes at once, for example:



The blue box shows the bounds your algorithm would constrict the player too, but the player should be able to move unrestricted along the green line I've drawn which ends outside of the blue box.

The correct way to deal with collision detection when you dont want to deal with resolving object penetration from using discrete collision checks is to instead use continuous collision detection techniques (sometimes called swept tests).  There's plently of tutorials out there, have a look on google.

Programming techniques are pretty transferable to any language so I wouldn't get too stressed about choosing the right language straight away.  Once you've learnt to code in one language you'll be able to transfer those skills to most other languages with a little effort.  Also a lot of the popular languages are actualy pretty similar in syntax and style as well, perhaps the only one that is significantly different from the others being objective C from what I've seen of it so maybe avoid that one as your first choice.

Myself I'm an advocate of C++ and if you wanted to learn that one like you suggest I dont think you'll be doing yourself any harm.  It'll certainly give you a good grasp of things since it probably has the most programming features and gives you the most control since its a non-managed language with pointers and such that doesn't hide anything from you.

If you're not interested in writing core modules such as graphics, physics, etc but want to focus more on behaviours and the such like you say then you might be better off with a higher level managed language however.  Perhaps C# might be a good stating point for you since its currently a popular language, its more suitable for the tasks you want to acheive since its a managed higher level language, and its not such a big jump for you to then switch to C++ if you want to go low level later on.

There's no need to store any additional arrays.  Just make your world map (or whatever it is that's using the perlin noise) a power of 2 size in each dimension and it will wrap.

I might be able to give you further information is you post more about what it is you're trying to do since I'm having to guess what it is you're trying to acheive.

You're in luck, one of the properties of perlin noise is that as long as you make your array dimensions a power of 2 then the results will be tileable which also means it will wrap with itself.

Sounds good.  Good luck to you mate, its gonna take a hell of a lot of work to get all these featues and 2 games written in the next couple of years.

Indeed.  I've been a professional programmer for near 10 years now and if anything I write appears to work perfectly first time I'm usualy very suspicious of it 

Hehe true 

I guess the problem was somehow caused by having my vectors in global scope.

Do you have one global object calling methods of or accessing another global object in its contructor?  This could be a problem caused by the fact that you cant predict the order of global initialisation.

Its been a long time since I used OpenGL raw like this so I might be wrong but I think I see two potential issues.  For a start it looks like you're building your colours array incorrectly, you're pushing on two red vals next to each other, then two green vals, etc.

Secondly I think this is wrong:

glBufferData(GL_ARRAY_BUFFER,sizeof(_BASICSHAPES_VARS::temp_vertices.data()),
      _BASICSHAPES_VARS::temp_vertices.data(),GL_DYNAMIC_DRAW);

Here you're going to be returning the size of the data pointer, ie. the size of the memory address, not the size of the data itself.  Use something like this instead:

glBufferData(GL_ARRAY_BUFFER,sizeof(float) * _BASICSHAPES_VARS::temp_vertices.size(),
      _BASICSHAPES_VARS::temp_vertices.data(),GL_DYNAMIC_DRAW);

Not all vertices in a vertex buffer need be attached to each other.  Since your draw mode is set to quads, then each group of 4 verts in your vertex buffer will be intepreted as a seperate quad, the spaces inbtween each quad aren't auto filled in.

These are good advices I guess, though I wonder how would I merge two textures into one?
 

Open them both in photoshop, position them next to each other, click save

What he said  , if you sort your sprites by texture used and combine your images into as few texture atlases as possible you'll then be able to maximise how many sprites you can combine into the same vertex buffer and minimise your draw calls.  Once sorted into seperate lists by texture, you might also want to then further sort each list by z depth with closer sprites at the start and further away sprites at the end which will reduce over-draw.  If you have semi-transparent sprites though then you''ll have to sort them the opposite way in order to get alpha blending to work correctly so you might want to create seperate lists for opaque and transparent sprites.

Even if you're not using the editor, you get Unity's cross-platform, hardware accelerated rendering. Including via the browser plugin which many people already have installed (which also gives gamepad support and mouse capture).

But there's plenty of other cross platform render frameworks out there which would probably be more suitable in this case.

Then why aren't people using them?

People are, you really think Unity is the only engine people use? 

Besides anyway, my point isn't that other engines are better than Unity, I use Unity plenty enough myself and really enjoy it, just check out my blog, so dont take offense.  What I'm getting at is that different engines are more suited to different workflows and different tasks.  Why go to all the effort of writing your own engine within Unity just to circumnavigate most of Unity's main features and try to force it to fit your workflow when all of its design works against it.  Alternatively there's likely another engine or framework out there that you could use out of the box that is much more suited to your desired workflow and still has the features you wanted from Unity such as cross-compatibility etc.

Even if you're not using the editor, you get Unity's cross-platform, hardware accelerated rendering. Including via the browser plugin which many people already have installed (which also gives gamepad support and mouse capture).

But there's plenty of other cross platform render frameworks out there which would probably be more suitable in this case.

Unity and "rolling your own" aren't mutually exclusive.  There are big projects that use Unity but completely ignore the editor environment and its component-based architecture.  The new version of Universe Sandbox was shown at Unite last week, and it's literally just a single scene with a single GameObject running a bootstrap script.  Everything else lives in code.

Futile is another example of ignoring the editor and doing your own thing: http://struct.ca/futile/

I posted in the other 'futile' thread about this but didn't get any feedback.  I'm scratching my head a bit about what the point of writing an engine within an engine is?  If you plan to not make use of all the main features of an editor based engine like Unity then I gotta wonder why you would use Unity in the first place.  Surely this is a case of another engine being more suitable to the task at hand rather than writing your own engine within another engine?

A lot of people say they don't like unity's physics, well you are free to write your own if you really want.  Most of the time however the issues can be resolved by adjusting the global physics settings.  Unity uses PhysX.  Somehow I suspect that most people on this forum (or any forum where poeple complain about unity physics) aren't going to write a better general purpose physics engine than PhysX, if you really think you can, you should call NVIDIA and get a job.  That of course not to say that if you are trying to do some unusual physics interaction that is unique to your game that your own code might not be better suited to the task.

From my experience the problem people have with Unity physics, myself included, isn't PhysX itself (although the lack of determinism really sucks) but rather how Unity wraps PhysX which really gimps the physics capabilities.  Unity doesn't give you any direct access to PhysX itself but instead only provides physics through a very limited wrapper interface around PhysX which really limits what you can do with it.