But, the projection in 2D is automatic, without me having to do anything.Originally Posted by phantomotap
(All the things are already in the window coordinates)
I'll try.. but learning modern OpenGL is reportedly very painful, unless one has a very good knowledge about how the whole graphics pipeline works.One thing we do agree on is using "OpenGL" or "Direct3D" directly.
The project is accounted for by you as you are creating your sprites. If you don't take the projection angles into account your game will look wrong.But, the projection in 2D is automatic, without me having to do anything.
O_oI'll try.. but learning modern OpenGL is reportedly very painful, unless one has a very good knowledge about how the whole graphics pipeline works.
Learning any new API that provides for unfamiliar functionality is always a little painful, but you don't have to know crap about the graphics pipeline to do fixed function graphics with "OpenGL" or "Direct3D". That's like saying you'd need to know about the compression models of "JPEG" to load and use them with "SDL_Image". The API is abstracting a lot of details so that you can safely ignore a lot of fiddly crap for the most part.
*shrug*
Anyway, you misunderstood my comment. I see no reason not to make a 2D game. (I still pretty much only ever work on 2D games. I love them.) I just use 3D tools and API to make them. You really have no reason to use a strict 2D tools and API to make a 2D game.
Look at what was said earlier, do you have the skill to make multiple frames of walk animation facing in four directions with forced parallel perspective? You do? Wow. That's awesome. Do you have the time to do that for multiple characters? Not really? That's why I use 3D tools like scene managers and modelers to render 3D objects and things into backgrounds and sprites. I can use Blender to tweak a skin (mesh), apply a skeleton, run a few scripts to animate the model to a given frame, and render the result with at a specific view. It isn't faster for some, but unless you are an excellent spriter you'll probably get more mileage out of a 3D model that you can rotate and animate to hearts content.
Soma
Well, the newer versions of OpenGl does not support fixed function graphics, unless you request the depreceated functions explicitly.
I'd rather not be stuck with something that'd be removed in near future.
Neat idea !*shrug*
Anyway, you misunderstood my comment. I see no reason not to make a 2D game. (I still pretty much only ever work on 2D games. I love them.) I just use 3D tools and API to make them. You really have no reason to use a strict 2D tools and API to make a 2D game.
Look at what was said earlier, do you have the skill to make multiple frames of walk animation facing in four directions with forced parallel perspective? You do? Wow. That's awesome. Do you have the time to do that for multiple characters? Not really? That's why I use 3D tools like scene managers and modelers to render 3D objects and things into backgrounds and sprites. I can use Blender to tweak a skin (mesh), apply a skeleton, run a few scripts to animate the model to a given frame, and render the result with at a specific view. It isn't faster for some, but unless you are an excellent spriter you'll probably get more mileage out of a 3D model that you can rotate and animate to hearts content.
Soma
I didn't understand it at first.
There is no reason that rendering must happen in realtime, though.
I could just as easily use those tools to cheat and generate the 2d artwork.
The fixed function components can be largely rewritten over the modern API regardless thanks to the "programmable" nature of the thing.Well, the newer versions of OpenGl does not support fixed function graphics, unless you request the depreceated functions explicitly.
O_oI'd rather not be stuck with something that'd be removed in near future.
Okay. That's as fair as you can go, but before deciding you should know that I recommend people new to "OpenGL" who want to use the latest API still start with a couple of shaders that emulate the old fixed function behavior. This allows people to get used to the core (C API) calls without learning much about shaders until they are comfortable.
That's still more than the fixed function API, but you may still want to look around for a bit.
O_oThere is no reason that rendering must happen in realtime, though.
Yes. That's what I said.
The backgrounds and "sprites" are rendered in advance and used as simple 2D textures.
o_O
Well, I guess you might mean "don't have to use 3D API" for that. In that case, you are exactly right, but before you run off with that logic wait until I've told you why I use "OpenGL" (or hardware relevant 3D) almost exclusively.
I use the "OpenGL" because you can craft some spectacular special effects using emitters that would require tons of sprites to emulate and be much slower to boot.
So, in my stuff:
Fire = partially transparent hard drawn texture with an emitter running behind it
Clouds = partially transparent hard drawn texture with an emitter running behind it
Smoke = partially transparent hard drawn texture with an emitter running behind it
Blood = partially transparent hard drawn texture with an emitter running behind it
Soma
The part of shaders is quite simple for me, and I could probably write the vertex shaders involved for emulating it myself.
(But have very little idea about the fragment shaders needed for the texture and lighting, at this moment).
The only part of OpenGL I'm totally unable to comprehend and remember is the cumbersome way of passing data to the gpu.
The jargon is convoluted and the concept of binding something to a target still eludes me.
Learning Modern 3D Graphics Programming
Best up-to-date OpenGL tutorial/book around, no fixed-function stuff.
How I need a drink, alcoholic in nature, after the heavy lectures involving quantum mechanics.
That is where I'm learning it from.
Attachment 11745
It's quite simple. 2D works against all the hardware. 3D works with it. But honestly the only difference in an API between 2D and 3D is the final projection matrix. Collision detection and the like is different in 3D but overall the same principles apply. In fact you can use the same separating axis theorem for 3D in 2D (don't do the calculations for z) and it works the same way.
Regardless of what you choose you will still need to learn OpenGL. Also if you do not understand transformations, matrix math, and coordinate spaces you will want to read up on that. I would say you do need a basic understanding of the pipeline both in 2D and 3D since shaders and the like can be used in both.
I honestly do not think 3D is hard or difficult and find 2D graphics much harder in modern APIs. They are born, bred and built for 3D and doing good fast 2D graphics in a modern 3D API requires far more under the hood knowledge than one might think.
I stand by my statement and will up it by saying if you do this in 2D you will require far better art assets than you would in 3D to pull it off. Do it in 2D and you will shoot yourself in the foot.
Let's analyze your screenshot for a second and think how you are going to pull this off with the old iso painter's algorithm.
- Each 'tile' is a quad with a very detailed bitmap - however notice the underlying grid is hidden so well and at times the quads overlap each other due to the iso. This will have to be accounted for.
- Alpha testing will have to be performed and objects will have to be drawn in the right order to get this to work. The iso painter's algorithm should handle this but you would have to implement it to find out.
- The sheer amount of good art assets in that one screenshot is staggering which means you will need an artist...and a very good one. Fitting all those pieces together in the same screen...or even creating assets with the same lighting and color scheme with that much detail is no small feat.
- How are you going to create those cliffs in 2D? How are you going to fit the cliff pieces together in 2D without some very good pre-planned art pieces?
- The sprite shadows are perfect - these will have to be done in a second pass and you must ensure the flat quads they use do not interpenetrate any other quads or you will get some very strange artifacts. A brute force approach here will look ugly. Shadows will only be able to be done in very specific areas of the map so the map must be carefully crafted due to this limitation of the drawing algorithm.
- There will be a ton of quads on the screen if you do this tile based. You will have to do this by using different sized sprites which will make it harder to detect what world cell the player is in since the cells are of different sizes.
The biggest obstacle to making this game in 2D is the art assets. They will not be easy to create. Also if you do not use a tile-based approach (which I do not recommend based on the scene) then scrolling the screen will become problematic as you cannot use the standard grid scrolling algorithm. You will have to find out when each different sized object is no longer within the scene, etc., etc. None of that sounds fun to me and it sounds error prone.
For 3D you could literally create several models of cliffs and/or objects and use one to two textures, throw in a shader that does lighting, normal mapping, and shadowing and your scene would look pretty good. If you use bump maps and detail maps along with some light maps the scene becomes easier to reproduce. Collisions are a snap with Bullet or you can roll your own AABB to AABB algo or OOBB to OOBB algo and it should suffice. Lighting and perspective are taken care of by the hardware and math involved.
The rendering algorithm in 3D is a simple one where you divide your world into sectors and then divide each sector in two or in four. You can easily find out what to render using an algorithm like this.
You can then use pre-rendered 3D sprites as has been suggested for the characters.
Attached is your screenshot with an iso grid overlay. I did this in GIMP so it is not a perfect iso grid but I did my best to align it with the plane the graphics are in. Notice how difficult this would be to re-create without some very good artists. This game was produced by artists who know how to hide the grid, fit pieces together and are experienced in making 2D games.
Last edited by VirtualAce; 06-14-2012 at 05:44 PM.
So 3D it is, with OpenGL.
It'll take much longer than I expected, to get the basic part running satisfactorily, but if I'm not mistaken, it'll be equally smoother afterwards (and a much more ..err.. mechanical workflow ).
If you really analyze the scene you can also tell that the iso portion is very minimal. Most of that screen is most likely a bitmap on the first layer that is drawn in iso perspective and the actual 'walkable' parts are rendered as the top layer. But note that there are shadows where the stones overlap some of the dirt due to perspective. In a tile based world this means those tiles can only be next to stones that overlap. If you want a good sample of how to do this check out Command and Conquer's level editor. It does some of this same thing with some very cool art assets and pieces that you can place on the map. I am not saying it cannot be done b/c with a skilled team of artists it definitely can and has been done.
I would not throw out soma's idea of doing it 2D wihtout looking at your requirements, timeline and goals for the game b/c with the right tools it can be done. But drawing assets is hard enough when they are top down or dead on...iso is even tougher and only skilled artists can pull it off.
The 3D actually should take less time since the renderer is much simpler to build.It'll take much longer than I expected, to get the basic part running satisfactorily, but if I'm not mistaken, it'll be equally smoother afterwards (and a much more ..err.. mechanical workflow ).
Last edited by VirtualAce; 06-14-2012 at 05:53 PM.
As it is a hobby project almost solely for getting my feet wet, "requirements, timeline" are almost non existent.
And the goals are yet ot be defined, other than some vague ideas jotted down.
But I have the overhead of learning and experimenting with the API (s) I'm going to use and all the theory and algorithms.The 3D actually should take less time since the renderer is much simpler to build.
(I understand coordinate systems and projections a bit but have absolutely no idea yet about lighting, texturing, and other nice stuff)
Also, whether it is OpenGL and everything else handcrafted or using complicated behemoths like Ogre3D and Bullet, I still have to learn much.
Most of that screen is most likely a bitmap on the first layer that is drawn in iso perspective and the actual 'walkable' parts are rendered as the top layer.^_^But drawing assets is hard enough when they are top down or dead on...iso is even tougher and only skilled artists can pull it off.
Someone, and I'm not saying who, didn't read this thread with a lot of attention.
O_oI stand by my statement and will up it by saying if you do this in 2D you will require far better art assets than you would in 3D to pull it off.
You seem stuck on the notion that doing a 2D game means doing without 3D tools and API instead requiring 2D tools and API with classic algorithms.
The background image here, for example, was clearly built with a 3D tool. It looks nice, but it is obviously not a purely "hand drawn" image or being spliced together with isometric tile algorithms as you took the time to note.
O_oThis game was produced by artists who know how to hide the grid, fit pieces together and are experienced in making 2D games.
If they did know what they were doing they must have set out to do a lousy job. The quality of the background is infinitely superior to the foreground and sprites. Someone who knew what they were doing, and also cared, would have balanced the effort in favor of a smooth look even if it meant eliminating some background detail.
No. This was more likely done by a "quicky" company who knows just enough to build games to get decent advertising revenue for a few months by throwing existing assets into new situations without a care in the world.
*shrug*
Look at what a first glance would suggest is a smoothed shadow on the raised parts of the background! That isn't a shadow. It is a part of the texture for the rock; it looks the same (with rotation) everywhere that same rock is used.
Heck, look at the shadows themselves! Shadows can't behave in so many different ways in the same "sunlit" scene.
Even with those problems it is a nice looking scene.
You have that to look forward to anyway.But I have the overhead of learning and experimenting with the API (s) I'm going to use and all the theory and algorithms.
You have some experience with "SFML". Do you really think what you already know about "SFML" is going to translate into a full game without having to learn and experiment with a lot of new stuff?
Soma
No, but I had the impression that things are much simpler for 2D.
I'll have to use SFML anyway, for input handling, windowing and managing the OpenGL context. (And possibly for audio and rendering fonts)
Well, that's another area where VirtualAce and I kind of agree.
Regardless of the look and play of the game, using 3D mathematics and API isn't significantly more difficult than just using 2D mathematics and API if the "look and feel" of the game is going to be 2D anyway.
Once you get the projections and crap setup you can almost ignore the extra dimension.
Soma
I'll devise it such that the camera is only movable in a particular plane. (that looks and feels like 2D, right ?)
If everything works out with it, I'll move to a more sophisticated controlling system allowing more freedom.
If that does not cause random glitches, that will stay.
But that is still very far off. I've got to learn OpenGL and some graphics theory first.
Should be enjoyable.
