I've been thinking about using OOP for IGE, just because it becomes more and more of a difference what data to save for which kind of graphics. I mean especially for 3D there's a lot more to save than just in 2D and the potential graphical objects are not endless but quite a lot. Color multipliers for each quad edge, additional vector data, whether to draw a single big texture or make sprites of much, whether to draw multiple graphics with the same properties and so on. All of this affects memory consumption (who doesn't possibly want hundrets of sprites on the screen?) and partly also performance when creating them. I would've simply created a base display structure with some homemade derivation and type-dependent size but well - I get the feeling that this is no good idead since a bit of good ol' C knowledge tells me that another approach may be better. I've been thinking about using "property strings" to identify the way objects get rendered. The idea is to have a buffer with commands setting properties and graphics to render as well as for example as different matrix operations not behaving like root-relative translation and rotation etc. This means the user can create all sorts of stuff the way he wants by just lining them up. Not necessarily the most performant but still quicker than applying a shitload of nor needed information for each element to draw. Most objects drawn hundrets of times are simple to describe with a command string - weighing effectively nothing, just a simple condition. So I'm gonna rewrite the way of drawing stuff with some sort of OpenGL command string. It's simple to design, OpenGL commands usually do not have a lot of different parameter formats.
Yep, I'm more comftable with this decision. It's not that I'm working too hard on it right now - term break after all! But way better to keep the original spirit and clean, well-thought C code than just choosing OOP out of randomness. I actually can't find any reason to use OOP in my personal projects. Sometimes coders need their little custom projects will all sorts of peculiarities to be happy. Better than doing false decisions on serious projects just because of one's own love for self-declared code purity (that does sound like an argument, doens't it?).