Viewing 1 post (of 1 total)
|4 January 2012 at 1:39 #551|
Originaly posted by kornerr at the old forum.
Why I am against DirectX/MSVC support on Windows.
Or: do the job which has not yet been done.
At the time of writing, it is 2010-08-15. We (OGS team) have recently released Mahjong version 0.6. During the development many things have happened.
The switch from Lightfeather 3D engine to OGRE engine between versions 0.4 to 0.5 has been made.
I’ve read the “Pragmatic programmer” book and have found out the very fundamentals of software development, and life in general.
I’ve walked a difficult path of self-development not related to games at all and found out the world has its reasons to have what we have.
Here I present the reasons of the following:
1. my switch from Ligthfeather to OGRE;
2. my hatred of Windows;
3. my reluctance to support DirectX/MSVC on Windows.
After 0.6 release KaiSD (responsible for game design, content, and QA), proposed DirectX support for Mahjong which, I’m 90% sure, leads to MSVC support.
At a first glance, that looked like a good idea. But then I looked closer into the time needed to support completely different 3D API and completely differend compiler.
If we support different rendering APIs, we need to make it available in the options. That automatically means we need some game launcher which will be used to select the API in case the other API is absent. Or its drivers are old. Or any other reason.
The two APIs work quite differently. And thus may have different bugs. Or only one API can have a bug. Or some bug can only appear in a certain API. Even on a certain video card (yes, ATI, I mean you). Anything is possible. But all that means we will need twice more time just to find bugs. Twice more time just to make sure the game actually runs. We will be forced to debug DirectX applications on Windows, which I hate as a development platform.
I give you one reason for the hatred. Windows has no system wide include/lib directories, so every packager decides himself on the standards. That means chaos. I hate chaos.
I spend a lot more time on Windows than on Linux just to *setup* development environment. This is a maintenance time which can be spent on actual game progress, not fighting with Microsoft not wishing to support or introduce any such standards.
The reason for standards being absent is simple though: the Windows world is a world of separate applications which rarely share the same base, apart from Windows API.
The Windows world suffers from a numerous applications duplicating the same functionality. UNIX world has that desease too, but at a lot lesser scale. With UNIX, since applications are Open source, if they become popular, they go into “core”, i.e., into many distributions. The recent example is CMake.
In Windows the applications are closed source, so they cannot be united.
Unfortunately, some developers fight the core libraries and introduce the Windows world policies into UNIX.
One example of this is FreeImage. Its developers decided to statically link libjpeg, libpng and other “core” libraries for a good purpose – to ease deployment on Windows where, as I already mentioned, development is a hell when you have a lot of dependencies. Unfortunately, static linkage introduces severe security implications: http://sourceforge.net/tracker…..tid=111504
And it means duplication. It also takes part of the audience from direct usage of well supported/tested/spread libjpeg, libpng, etc. to a less supported/tested/spread FreeImage.
So did the OGRE developers. I do not agree with that choice. OGRE used libjpeg, libpng directly before DevIL was used. Then it switched to FreeImage from DevIL because of the new OGRE MIT license.
I think the all-formats layer should have been left in OGRE itself, like it is now in Lightfeather.
Because the job should be done for the areas where the job is necessary. Of course, it’s good to have a choice of ten thousand applications, libraries, game engines in particular, doing exactly the same. But I now believe it is more important to have consistency/standards prevail over the variation.
That’s one of the reasons we develop the game. The area of open source game development is full of high quality rendering engines. But there’s no open source high quality game. We struggle to reach that point, to fill the hole.
That is another reason for no DirectX/MSVC support on Windows. Why do the work which is redundant? Why support FreeImage (read MSVC) when we can support open, free, less Windows version dependent (certain MSVC versions work only on certain Windows versions) libpng (read MinGW)? Why do we need to do the work that has already been done? The guys at MinGW/Cygwin experienced a lot more problems with Windows than any of the developers using MinGW/Cygwin. Why do we need to go their path? For our work to be done, there’s no need to learn Windows API. To make the same mistakes they made, to suffer from the bugs (read FreeImage) they already solved. Who will benefit from this?
I do not deny experience you gain from this, but at what cost? The balance must be kept. You must see the big picture, you must not get lost in the details. The big picture is this: people need open source high quality 3D game.
If you just make another goddamn 3d engine, you just make more problems for people that decided to make a game. Which engine to choose?
My transition of game engines was as follows:
CrystalSpace3D, Irrlicht, Lightfeather, and currently OGRE.
I’ve already mentioned the minus of OGRE, but so far it’s a little sacrifice to what OGRE offers compared to the other 3 engines.
I switched from Lightfeather, because it did not use C++ exceptions like any other 3D engines I’ve seen. Only OGRE uses exceptions.
So other engines, beg my pardon, authors, are like copies to me. Yes, I understand you’ve spent a great amount of time (several years!) to make your engine excellent. But so did the number of others. And all they differ is in function calls. It’s exceptions that differ OGRE so much from all of the rest engines. There’s the plugin architecture, of course, but that’s what all engines eventually gain.
So we end up to have 10 thousand different FreeImage’s (read game engines) and we need to choose only one. All they differ is lexis. What’s the point?
The second reason for the switch was community. The OGRE has the largest community. That means more people work on OGRE. It gets more attention and thus is better tested (read consistency/standards).
The third reason for OGRE is CEGUI. CrazyEddie develops CEGUI, GUI system for games. CEGUI, unlike, again, many other GUIs out there uses C++ exceptions. And just like OGRE it was used in several commercial applications. Also, Eddie is the most supportive man I’ve ever met in my game development life. He saved me days of life. Thank you
Now about MSVC. Honestly, I heard nothing good of it. And personally, I don’t use any IDE for development. I use VIM, simply an editor. That said, if we support MSVC, it means more #defines and #ifdefs. I hate non-crossplatform code. I hate to introduce those #ifdefs. Since MSVC is able to build OpenGL and DirectX based apps, support for MSVC means that we will have a completely different application on Windows. With different warnings, polices, and other errors. This, again, means a lot of maintenance time. It’s a time sink, duplication, inconsistency, variation.
That’s why I propose the drop of MSVC/DirectX support once and for all for those platforms for which we can develop using the tools we already mastered. Drop , not just wait for a guy to introduce the maintenance nightmare and put it on our shoulders. If that happens, I won’t be able to say: “Hey, I do not support DirectX/MSVC, I built the OpenGL/MinGW Mahjong. Either use OpenGL/MinGW game, or go ask the guy whom we haven’t seen since he finished the DirectX/MSVC patch”. Do we need this nightmare? Why do we need this? Isn’t Windows support a good disaster already to have? As of Mahjong version 0.6, most bugs have been found on Windows, not Linux. Aren’t those bugs enough for us?
That said, I do not completely deny DirectX/MSVC as a kind. If we ever reach XBox audience, we are *forced* to use DirectX/MSVC. Here we have no choice. But on Windows, there’s a little portion of UNIX unity we can exploit. There’s no reason to skip consistency (read MinGW) in the world of chaos (read Windows).
Here’s the log of conversation happened at CEGUI IRC channel on 2010-08-14 about MSVC. Since CEGUI is a well spread library, CrazyEddie is bound to support MSVC on Windows, but we are not. We do not develop a library (only OGSSound of which we are the sole users), we develop end-user applications.
(19:49:40) Kulik: CrazyEddie: I’ve found some weird multi inheritance in OpenGL
(19:49:47) Kulik: OpenGLRenderTarget inherits RenderTarget
(19:49:57) Kulik: OpenGLRenderTexture inherits both RenderTarget and OpenGLRenderTarget
(19:50:07) Kulik: it works because OpenGLRenderTarget’s methods are inherited via dominance
(19:50:28) Kulik: I think OpenGLRenderTexture should only inherit OpenGLRenderTarget
(19:51:31) Kulik: hmm OpenGLTextureTarget inherits OpenGLRenderTarget and TextureTarget
(19:51:35) Kulik: I misread
(19:51:46) Kulik: but VS generates lot of warnings about this
(19:54:34) CrazyEddie: Yeah, I read a bug report to MSVC about this when dealing with pure interfaces, they acknowleged it from what I recall, and then proceeded to do nothing about it.
(19:55:45) CrazyEddie: sucks to be them
(19:56:30) Kulik: I kinda assumed MSVC is right and then misread the names of inherited classes :DD
(19:57:45) CrazyEddie: heh
(20:02:40) CrazyEddie: http://connect.microsoft.com/V…..l-function
(20:02:54) CrazyEddie: I guess they didn’t find time yet.
(20:03:17) CrazyEddie: Probably too busy with all them security issues they have, fnar! :-p
(20:03:46) emarcotte: too busy breaking visual studio font rendering instead
(20:04:09) CrazyEddie: did they? wow!
(20:04:26) emarcotte: vs2010 rendered font like arse when i used it on my laptop
(20:04:57) CrazyEddie: man, I so hate 2010. I can’t bare to use it.
(20:05:19) CrazyEddie: I still use 2008 when I have to code on Win
(20:05:44) kornerr: let me use the last 20 minute log to make our team never support MSVC
(20:06:36) Kulik: I think 2010 will be usable with SP1
(20:06:40) Kulik: same as 2008
(20:06:46) Kulik: I still use 2008
(20:06:57) CrazyEddie: I think 2010 is too Mickey mouse
(20:07:12) kornerr: what?
(20:07:19) CrazyEddie: lol
(20:07:30) CrazyEddie: Too much UI bullshit
(20:07:36) kornerr: oh
(20:07:52) ***kornerr said the creator of CEMickeyMouse
(20:08:01) CrazyEddie: I don’t want a flashy UI, I just want to get work done. The VC6 UI was fine for this.
(20:08:24) kornerr: ok. I’ll use this too. as a proof. in the face of MS fanboys
(20:08:35) CrazyEddie: every release makes it a bit worse. 2010 has gone too far IMO
(20:10:04) Kulik: plus code completion never works consistently… even though it works in pretty much all open source IDEs…
(20:11:09) CrazyEddie: what I want to know, is, if some FOSS IDEs can make it work, and if Visual Assist can make it work in MSVC, what the fuck are the actual MSVC devs playing at?
(20:11:36) Kulik: exactly
(20:11:45) Kulik: they intentionally do bugs so MS keeps them to fix it
(20:11:53) CrazyEddie: lol
(20:12:43) Kulik: and the budgets of Visual Assist and MSVC are quite different…
(20:12:47) Kulik: not even speaking about FOSS IDEs
(20:13:01) CrazyEddie: yeah, there is no rational explanation
A few notes about one of the maintenance problems I already had, caused by variation.
A year or years before 2010, MinGW suite, as I understood from OGRE forum, had hard times. The GCC version the official MinGW supported was not updated frequently enough, and some people created the unofficial MinGW build (TDM). Other people (http://www.ogre3d.org/forums/v…..mp;t=50579) did use it.
Looking at the TDM site revealed that there were a lot of developers who did the switch. So for some time TDM has become the de facto MinGW used.
Then we (OGS) come. I compile Mahjong with TDM MinGW.
Mahjong uses C++ exceptions just like OGRE. One day I find out that the TDM version compiles DLLs incorrectly. It compiles GCC libraries statically into the library, which makes it impossible for exceptions to leave the DLL boundary and reach my application where I have the try/catch clause.
So in the case of exception in one of the DLLs I use, I just end up with a standard Windows “Runtime has requested to terminate the application in an unusual way” error dialog. For me, the TDM is simply unusable. After I found out this, I looked closer at the standard MinGW. I found out the new version of MinGW with recent GCC, for which no installer is yet made, but packages are present.
I compiled the DLL, and my application did successfully catch the exception. Thus, the official MinGW appeared to be more thoroughly tested.
Viewing 1 post (of 1 total)
You must be logged in to reply to this topic.