Elysian Shadows

THAT LOOKS SO FRICKIN BAD MAN! xD
Who cares for whether it's XNA, it just looks so cool I couldn't even believe your first screenshot was actually from a game.
Great job, that's definitely skill you have there.

Dude, those images look AMAZING!
They really do look REAL.
Great job. I love it.

You sir, deserve a very large chocolate chip cookie!

Great job.

Thanks for the support, everyone! I do not have a game in mind to use this on, and still can't create a huge RPG like some guys here yet

janequorzar, is OpenTK pretty flexible? It says that it provides low level access so I'm guessing it's just as powerful and flexible as XNA. Man, this just makes my decision to port more difficult because I have one more option to think about.

CC Ricers wrote:Thanks for the support, everyone! I do not have a game in mind to use this on, and still can't create a huge RPG like some guys here yet

janequorzar, is OpenTK pretty flexible? It says that it provides low level access so I'm guessing it's just as powerful and flexible as XNA. Man, this just makes my decision to port more difficult because I have one more option to think about.

Yes VERY flexible. And to me is more flexible then XNA, not to mention, cross-platform. XNA is not cross-platform outside of the XBOX and windows Phone ( or Windows OS ). And OpenTK is full open source.

The point is you can talk directly to OpenGL within C#. But it would mean you would have to write a function and DLL reference every time you want to use an OpenGL function. BUT with OpenTK, it does all that for you. Just call the function you want and use it. Simple.

Here is one example you can get up and running in a couple minutes. You just have to make sure your C# IDE resets the OpenTK DLL path. I use SharpDevelop for my C# IDE. ( There is two of them in his demo of a terrain Heightmap ) The example is not optimized and runs slow as a dog, but that's because its ONLY for demonstration purposes.

http://www.opentk.com/node/618

I had asked a question there as a noob just a few days ago. Because I am new to OpenTK. But thats my point. I fully understand how it works in only a few days. THAT'S HOW EASY IT IS.

Also, get a copy of 4th Edition SuperBible. OpenTK uses the functions from THAT book which most Operating Systems are still using. In fact MAC computers have not gone past OpenGL 2.1.

Do not bother with the 5th edition Superbible because the example code there plane do not work since that book is more geared toward phone apps.

This brings me to another point, The SuperBible ( especially 4th edition ) is REALLY good at teaching you HOW OpenGL works from the ground up. And if you can understand OpenGL's Functions, then using C Sharp's ( C# ) OpenTK wrapper for OpenGL will be a breeze. [ NOTE : If you do not know C++, its ok, the BOOK does help you at least in the descriptions of what a lot of the functions do. And if you know how OpenTK works, you can write your first app within minutes and never need to know C++ ]

EDIT : One thing I would like to make clear here. XNA / DirectX are hardware based Libraries. OpenGL is Software based. Basically its Microsoft VS everyone else.

Wow, sounds enticing. On one hand it's good to know there's an easy way to port C# games that use hardware accelerated graphics, but on the other hand it makes my choice more difficult on what path to take. I would still like to get it working with C++ somehow. Good thing that I'm only about a month and a half into this project so I guess I should start moving stuff as soon as possible, right?

So right now I can choose two paths to port code:

C#/XNA -> C#/OpenTK -> C++/OpenGL

C#/XNA -> C++/DirectX -> C++/OpenGL (my original choice)

I'm still preferring the C++ route since I have some solid experience with it, and gives me some more flexibility with APIs and more familiar with the DirectX way of doing things. But it's all up in the air and I will experiment a bit to see which one will save me time.

Changing topics a bit, the system for the rendering paths will be based on Unreal Engine's material shader. But instead of configuring everything individually for each object it is just one render path for drawing the entire scene.



This image is just to make it easier to picture the process, I won't be making something as full-fledged as the Unreal editor.
In more complex rendering render targets (or frame buffer objects for the OGL oriented) are usually passed from one rendering step to the other to give the final image. Stepping through the path is shader-based like Unreal, so this system will work well. Basically it's a more modular rendering system that will make it easier to program a chain or graph of rendering steps or code your own steps for any graphics style.

Here is where you might be taking one too many steps. Observe :

C#/XNA -> C#/OpenTK -> C++/OpenGL

C#/XNA -> C++/DirectX -> C++/OpenGL (my original choice)

XNA is JUST another easier version of DirectX. You do not need it by any means. Your end goal however is the same. So if I am reading you correctly, your wanting to learn both HardWare and Software rendering. ( Meaning DirectX and OpenGL )

If your not going to use C# for your end goal, then your correct and you should bypass C# altogether. Then C++/DirectX -> C++/OpenGL should be your correct choice. But be warned, they both are WAY different from each other in how they work and how you program them.

The only reason I like C# is because it can handle memory easier and I do not have to code it. C++ can do the job, but its more coding. And since there is the CLR for BOTH C# and C++, your not gaining in speeds since both are DOT NET oriented. That and I can code like a Mad Man in C# and put out an app faster then I can in C++ because of the OOP nature of C#.

The Native C++ however, WILL BE and ALWAYS WILL BE faster then using a C++ CLR. So yes, I concur, if your going to learn C++ and you are wanting to stick with it, then I say go for it. And I wish you the best. I look forward to seeing more of your brilliant work.

Even when using C++ with OpenGL, platform interoperability is not guaranteed. I for example am trying to make a program for windows and linux using compiler switches and the original APIs, which isn't that easy (because I'm so unfamiliar with how to program those kinds of things in linux). So I don't see why C++/DirectX should not be a legitimate aim as well, since on Windows it's not that much of an improvement to use OpenGL over DirectX, right?

BugInTheSYS wrote:Even when using C++ with OpenGL, platform interoperability is not guaranteed. I for example am trying to make a program for windows and linux using compiler switches and the original APIs, which isn't that easy (because I'm so unfamiliar with how to program those kinds of things in linux). So I don't see why C++/DirectX should not be a legitimate aim as well, since on Windows it's not that much of an improvement to use OpenGL over DirectX, right?

That is his goal. I agree totally with this. He is not saying that C++ / DirectX is not an end goal, what he is saying is he wants to learn it in that order. Which is a good idea beings that OpenGL is considered a lot tougher to learn then directX is.

Although according to those pictures he is showing, I think he has a very firm grasp on it.

Not a XNA fan my self, but really good job sir.

janequorzar wrote:Also, get a copy of 4th Edition SuperBible. OpenTK uses the functions from THAT book which most Operating Systems are still using. In fact MAC computers have not gone past OpenGL 2.1.

The recent OSX Lion update introduced OpenGL 3.2 support.

janequorzar wrote:Do not bother with the 5th edition Superbible because the example code there plane do not work since that book is more geared toward phone apps.

The code samples do suck, but it is one of few precious books that actually focus on OpenGL 3. I cannot tell you how frustrating it is having books that cover BOTH OpenGL 2.1 and 3. You cannot easily distinguish which features are deprecated. Personally, I like owning both. That way, I have one whole book for 2.1 stuff and one whole book for 3 stuff.

BugInTheSYS wrote:Even when using C++ with OpenGL, platform interoperability is not guaranteed. I for example am trying to make a program for windows and linux using compiler switches and the original APIs, which isn't that easy (because I'm so unfamiliar with how to program those kinds of things in linux). So I don't see why C++/DirectX should not be a legitimate aim as well, since on Windows it's not that much of an improvement to use OpenGL over DirectX, right?

I used to run into platform-specific issues with OpenGL, but each problem exposed a serious problem in my code. In other words, each operating system handles code mistakes differently. Something that works just fine in Windows would seg fault my Linux build. Something that works just fine in Linux would hang in Windows. With each problem, I discovered some aspect of OpenGL that I was mishandling. Now that I have cleaned up how I handle that code, all those problems have disappeared. My OpenGL apps run great across all platforms.

TheBuzzSaw wrote:The recent OSX Lion update introduced OpenGL 3.2 support.

Your right, I checked it out and seen that they did come out with it this past summer. Apparently Apple is having to write their own drivers, which is why they are so far behind. So thanks for letting me know they finally moved on. AND OSX 10.7 Lion still only support 3.2 though, which IS partly covered in the OpenGL 4th edition SuperBible ( Even though the book says 2.1 the functions are still there for 3.x) . The 5th edition covers OpenGL 3.3 and higher, which is not used in MAC OSX yet. So you still need the 4th Edition book.

TheBuzzSaw wrote:The code samples do suck, but it is one of few precious books that actually focus on OpenGL 3. I cannot tell you how frustrating it is having books that cover BOTH OpenGL 2.1 and 3. You cannot easily distinguish which features are deprecated. Personally, I like owning both. That way, I have one whole book for 2.1 stuff and one whole book for 3 stuff.

Well that's sort of true. 4th Edition covers some of OpenGL 3.x as well. BUT, the 5th Edition covers 3.3 and higher. Again, 5th edition sucks, not everything is supported there yet. And the code does not work. Heck, you have to have the writer's Library to use any of the OpenGL 3.3 functions by using GLTools. Which is a joke because that library is setup for Phone Apps. At least 4th edition uses Glut / FreeGLUT as its main library and it works with no problems right out of the book.

TheBuzzSaw wrote:I used to run into platform-specific issues with OpenGL, but each problem exposed a serious problem in my code. In other words, each operating system handles code mistakes differently. Something that works just fine in Windows would seg fault my Linux build. Something that works just fine in Linux would hang in Windows. With each problem, I discovered some aspect of OpenGL that I was mishandling. Now that I have cleaned up how I handle that code, all those problems have disappeared. My OpenGL apps run great across all platforms.

If you got any of the demos for 5th Edition working, please, share. I still have all the code and the book in my hands. It would be nice if I could get at least one example running without needing / requiring their GLTools. Which is total BS that they require you to use THEIR made up library.