Crossplatform Idea; what do you think?

[Kzinti]

[Pejo Software - Per]

[Kzinti]

[fzammetti]

It seems to me that a lot of what your talking about wanting to do can be done just by the way you architect your own application...

For instance, the way I'm doing my current game is in a whole bunch of very small, discrete units of work. I've taken a very object-oriented approach to things, even though I'm not actually doing everything as classes and object (i.e., it's a lot of procedural code, some classes, a mix of concepts). What this allows for is having small pieces of code to port rather than the core logic of the application. Note that I haven't invented any great strategy here, this is how cross-platform work is generally done.

In other words, rather than call GapiDraw's BltFast function, I instead call my own DrawImage function. I pass it a simple set of parameters (Surface*, x, y, opts) where opts is a custom struct. In this way, if I want to switch to a different library, I just modify that DrawImage function, nothing else gets touched. Same for file I/O, sound functionality and control I/O, it's all very atomized code.

Likewise, my main game loop is not GapiDraw's main loop. I call a function FROM GapiDraw's main loop, but it's not tied in any way to GapiDraw itself.

Really, doing cross-platform code is fairly easy, it's the WORA concept that usually gets in the way because doing that is virtually impossible without some sort of VM foundation, and that doesn't generally fly well for performance in games (even what I'm doing has performance implications, but done smartly they are acceptable).

I think the bigger issue is resources... Designing a game that will run well on a SmartPhone screen as well as a PC screen as well as a Palm device, all with different resolutions and such, seems to me quite a nightmare (I've abandoned the idea of a SmartPhone port of my current project because it simply won't work on that small a screen real-estate, same for cell phones). Even just thinking of varying memory footprints, things like sound becomes quite an issue because you can just use straight WAVs so as to not have to deal with audio codecs of any sort, but then your talking much more memory, and that won't fly on many limited devices.

But, now I'm off on one of my prototypical tangents My point is that just by coding your app with a procedural/OO mentality, you can get 98% of the way towards your goal. Incidentally, I'd try and stay away from C++ just because it's somewhat less portable than straight C is. But again, if you've broken your app up into a number of small pieces, porting it should be a lot easier, regardless of C vs. C++ or whatever libraries you choose to use.

[mlepage]

Fzammetti is exactly right. I don't call GapiDraw or a sound engine or anything like that. I call my own functions, which in turn call those functions.

You can see the exact same technique at work in the GPL source code for Quake 1. Quake essentially has its own API, with very few points of contact with the outside world.

The software engineering principle at work here is high cohesion, low coupling.

So the first thing you have to stop doing, to be more cross platform, is spitting out files, sucking in resources, and groping the registry from the bowels of your code.

[Kzinti]

[fzammetti]

[mlepage]

To me it's also a risk management thing. I want to reduce my dependencies on third party code.

This insulates me from API changes, and if necessary, I can swap out the entire third party library.

A good (though older) book for this is John Lakos' Large Scale C++ Software Design.

[kaiton]

[Kak]

[fzammetti]

[mlepage]

[fzammetti]

All valid points. But, the orignial poster was proposing the idea, so I was just laying down the challenge that since it only involves writing up some function prototypes and drawing up some UML, why not go for it?

Any stand, all-encompassing anything will almost by definition have to cater to some lowest common denominator. *I* personally wouldn't use what he's proposing for no other reason than I understand the underlying concept and can do it myself. I prefer writing my own code whenever possible, so long as it doesn't take so much time as to not be worth it (like using GD instead of completing my own library is worth it to me), I do so. This is a prime example.

No one here is disagreeing that an abstraction layer is, generally speaking, a good thing (tm). All I'm saying is that rather than continuing to debate that (and there's really no debate!), why not go ahead and spec it out so we can really argue about something concrete (relatively speaking anyway)

*I'M* not going to do it, but I think the original poster now has a clear idea of what to do, he should go off and do it and come back when it's done. Maybe he'll pull it off and we'll all say "wow, I didn't think of that, I'm going to use that!". More than likely though we'll say "not bad, but here's a list of reasons mine is better, or I'm just not going to use it anyway because..."