[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [glob2-devel] why libgag
Re: [glob2-devel] why libgag
Sun, 18 Oct 2009 16:40:36 -0700
I'm not a globulation developer, but I think I can predict what they're going to tell you. You mentioned using an external library, the developers have decided that they would prefer to keep dependencies down to a minimum, which is more a personal decision than anything, but does rule out the possibility of using a pre-existing library.
This leaves us with choosing between making a library or making a (giant) generic class. For one, I doubt that the developers started by saying, "Let's make libgag." They most likely did something close to what you're described, which is to make a few classes that handle graphics. As time went on and more features were added the developers made more and more classes with the prefix GAG, and one day they decided these should be separated into their own library, for the sake of the sanity of everybody browsing the code.
At least this is what I think happened. You could even think of libgag as the generic drawing class you've described, as it is a single entity that handles graphics. I think there was some discussion recently to do the same thing to all the YOG code, and make a libyog library.
This is a far better solution than your generic class for several reasons, but the most important one is developer sanity. Nobody likes searching for a bug in a class 10,000 lines long, it's almost impossible. C++ is a object oriented language and it would be a shame to waste that power by simulating Cs static global methods. By separating big classes into small simple classes that do one thing and one thing only, and concentrating on how those classes interact with one another, you can drastically reduce the complexity of your code. And reducing complexity increases the ability of the developers to understand what's going on and solve any problems that may come their way.
An additional, slightly irrelevant, reason why a library is helpful is that most graphics handling has been decoupled from the main game code. So if the developers decide they would like to use a different backend for their graphics they can with a lot less effort than if graphics code was floating around in every class.
On Sun, Oct 18, 2009 at 3:59 PM, fede <address@hidden>
Thanks for reply.
Your answer sounds to me like defensive, but i didn't write to blame. My
question was just about game ingeneering. If you would start now globulation2
like you did (around 2001 right?), would you still use any toolkit (writing
libgag from scratch or external one) or a generic drawing class like i
described may be a better solution?
Take my ask like a newbie consulting expert programmers, this doesn't have to
do directly with actual globulation2/libgag code. That's why i wrote a long
story, wanted to be informal.
In data domenica 18 ottobre 2009 15:40:29, Stéphane Magnenat ha scritto:
> Libgag is a modulare solution to providing a Toolkit for graphics and
> system operation. While it is not perfect, it is the result of years of
> thinking and evolution, so it's probably not too bad either.
> By the way, I'm the author, so if you have specific questions, I'll be
> happy to answer.
> Have a nice day,
FREE 3D EARTH SCREENSAVER - Watch the Earth right on your desktop!
Check it out at http://www.inbox.com/earth