Topic: Free Perspective, OpenGL and CastAR

@Tino Thanks for the clarification.

SirVer wrote:

That sounds like a good plan. Try to reuse code as much as possible and feel free to propose the branch for merging whenever you want some feedback. Ok I will do this, but it will probably take some time until I will propose it for merging. First I have to sort out the compiler stuff... and then it has to work reliable. But I will try to setup it like Tino suggested, so that you will be able to view my coding attempts in an branch on launchpad, so that changes can be discussed early. Please keep the technical discussion in the forum and/or the bug tracker so that everybody can participate. Of course I will do this, but I will stick to this thread.

If noone mind, I will also try to get rid of all OpenGL calls, which are not compatible with OpenGL ES, to prepare for embedded device compatibility.

This sounds like a GREAT idea. We need to move to SDL 2.0 before moving to android, but that is a firm plan of mine. Compatibilty might be an issue, but we can sort this out.

Really excited that you want to work on the rendering engine. That part always needs love. :) Good, that you like the idea, I will probably touch these parts any way, and I have some experience with open gl es. I do not know if I will target android maybe raspberry pi but we will see....

@adamant I do not get your point either. OpenGL ES is a subset of OpenGL and widelands should work fine with mobile hardware.

The engine of widelands only uses OpenGL function, which are very basic and can be easily handled by OpenGL ES. It only means instead of supplying a vertex one by one using vertex buffers. The second thing is that quads are not supported. But converting them to triangle strip etc. is not a big deal, your driver will do it anyway for normal OpenGL. Not using opengl es will be bad for mobile devices, since the cpu is normally not as powerful as the gpu.

Marten

Top

Quote

WTF!

What has a bunch of - yet to be released - 3d / VR glasses to do, with going full 3d of widelands???
The software for the glasses won't even be free (as free in speech) software nor dual licensed.


Despite this total irritating reasoning ... Why would one spend so much time (someone mentioned ~3 man months coding, which can easily translate to half a calendar year or prob. even more) on such a massive code rewrite and end up with your very own thing?

Think of the bus factor guys! Even if MartenR successfully finishes this job and dumps the code in your git. He can change his mind (i.e. choose another hobby / project) anytime, which ofc he has the right to do. However this would left the widelands community with no one of understanding the deeper insides of the code. Even worse there would be no one else in the whole world, because MartenR wrote it all by himself.


As you see I think this is a very bad idea. ... however I also have a solution to this: :-)

Port Widelands to an open source game engine already used by other projects!

This is IMHO also more along the free software spirit: share code and knowledge and everyone profits! (Widelands code is open source, but since it is not used by other projects there is currently no sharing at all.)


Some suggestions on game engines I just researched:
If you want to stay with 2d / pseudo 3d, but enable zoom, lighting and other fancy stuff:
Flexible Isometric Free Engine (FIFE): http://fifengine.net/ (my favorite)
it is already used by Unknown Horizons and upcoming "Projekt-Zero", seems also to have strong german user base.

Full 3d:
Pyrogenesis used by 0.A.D and developed by Wildcard Games: http://en.wikipedia.org/wiki/0_A.D._%28video_game%29#Pyrogenesis

Or choose one on your own: http://en.wikipedia.org/wiki/List_of_game_engines#Free_and_open_source

... but please don't continue with very own development (when there is a major rewrite).

Top

Quote

Ok, I have posted it now to launchpad: lp:~marten-r/widelands/feature-3d-rendering-open-gl-es-compat

So far I introduced a 3D point and I have converted the object rendering so far to 3D coordinates. One thing I have stumbled across, if the coordinates in a point are negative, the blit function has a problem, caused by signed and unsigned mismatch of w and h of rect (unsigned) and point coordinates (signed). A simple typecast helped, I could drop some of the clipping stuff since opengl does it now. I am wondering, if you can also remove the manual clipping, in the 2D rendering if the unsigned signed mismatch is fixed or is it required with SDL? Anyway a rect with signed w and h would cause less trouble in the drawing routines. Should I change it?

Point3D and draw3D is not the perfect way in the moment. I will probably change the interface in the future.

Marten

Top

Quote

@SirVer I have pushed it to lp:~widelands-dev/widelands/feature-3d-rendering-open-gl-es-compat as you proposed. But I will not propose it for merging now, since the changed interfaces and coordinate systems are still a bit oscillating and the graphics output is slightly buggy.

(The problem is to generate for the meantime a meaning full z-coordinate for animations. In the moment I am using the difference of image height and hotspot position for the z correction. But this causes some problems with the drawing order, anyway this is fixable...) I wait until this is stable.

Anyway, my plan is after temporally fixing the glitches to introduce an abstract camera interface with cameras for isometric, perspective projection etc. . Where should I place this? In graphics folder or in wui?

Marten

Top

Quote