next »

[Average Software]

Code:

#if defined(_WIN32)
//.. win32 code
#endif
#if defined(__linux)
//.. linux code
#endif
#if defined(__APPLE__)
//.. apple code
#endif

This way lies madness.  It does not scale well at all.  Separate source files for each platform with common headers are the way to go.

Look again at my source to see how I did this.

[Crimsontide]

Code:

#if defined(_WIN32)
//.. win32 code
#endif
#if defined(__linux)
//.. linux code
#endif
#if defined(__APPLE__)
//.. apple code
#endif

This way lies madness.  It does not scale well at all.  Separate source files for each platform with common headers are the way to go.

Look again at my source to see how I did this.

I must concur.

[Gregg Williams]

Got to agree with the evil of the define approach. I did it when making our framework that supports pc, mac, ios, blackberry, android, and likely linux. Its a real mess to update now alas. The only real benefit I think is you can easily drop all of the source into an IDE set a define or two and use it.

[Crimsontide]

Got to agree with the evil of the define approach. I did it when making our framework that supports pc, mac, ios, blackberry, android, and likely linux. Its a real mess to update now alas. The only real benefit I think is you can easily drop all of the source into an IDE set a define or two and use it.

You still have defines, you just restrict them to the .c or .cpp files.  Have a standard API-independent header.  Then have a .c/.cpp file for each platform that is guarded by a #define.  That way no platform specific stuff leaks out (in particular all the macros and stuff that often come along with platform headers).  Clean, very easy to extend, and easy to implement.  Though a truly independent header that handles all the bells and whistles can take a bit of time/effort.

[Gregg Williams]

Got to agree with the evil of the define approach. I did it when making our framework that supports pc, mac, ios, blackberry, android, and likely linux. Its a real mess to update now alas. The only real benefit I think is you can easily drop all of the source into an IDE set a define or two and use it.

You still have defines, you just restrict them to the .c or .cpp files.  Have a standard API-independent header.  Then have a .c/.cpp file for each platform that is guarded by a #define.  That way no platform specific stuff leaks out (in particular all the macros and stuff that often come along with platform headers).  Clean, very easy to extend, and easy to implement.  Though a truly independent header that handles all the bells and whistles can take a bit of time/effort.

Ah yeah, not sure what I was thinking there. Though as you say handling the headers can become problematic. Though I suppose if you really had to you could just have a generic header per system/etc that includes the specific platform version.

[Geti]

The "I want to learn" part is fine.
The "portability" part isn't, because the #ifdef xyz #elif yxz #else #endif approach is just a wrapper around the fact that your platform dependent code by definition isn't portable - obviously there are going to be platform specific bits in any framework with "no dependencies", but after you're done wrapping the platforms you support up to the point where everything is platform agnostic (and therefore free of #ifdefs) you're going to be writing code on top of your own implementation of SDL/SFML/Whatever.

The "I want to create my own framework" part... If your intention is to write a game framework handling things like physics, optimised (tilemap, mesh, sprite, whatever) rendering, a nice sound interface, archive access, networking, cryptography, scripting, autoupdating and so on, then you'd be better off introducing even as many as seven or so dependencies to cover ground that's been covered many a time, in a way that's tried and tested (and takes 10 minutes to set up).

As I said, "I want to learn win32" is a fine reason, but I think your other reasons are unfounded.

[kamac]

The "portability" part isn't, because the #ifdef xyz #elif yxz #else #endif approach is just a wrapper around the fact that your platform dependent code by definition isn't portable - obviously there are going to be platform specific bits in any framework with "no dependencies", but after you're done wrapping the platforms you support up to the point where everything is platform agnostic (and therefore free of #ifdefs) you're going to be writing code on top of your own implementation of SDL/SFML/Whatever.

Maybe I should add that those #ifdefs are inside the library itself, and the code (that is using that library) looks/is supposed to look like this?
(Only meant to look this way. It's a subject to change)

Code:

#include <BlueKit/BlueKit.h>

int main(int argc, char* argv[])
{
    BlueKit::InitWindow("title",800,600,BlueKit::POS_DEFAULT,0);
    while(BlueKit::isRunning())
    {
        BlueKit::Update();
        BlueKit::Render();
    }
    BlueKit::Cleanup();
    return 0;
}

The "I want to create my own framework" part... If your intention is to write a game framework handling things like physics, optimised (tilemap, mesh, sprite, whatever) rendering, a nice sound interface, archive access, networking, cryptography, scripting, autoupdating and so on, then you'd be better off introducing even as many as seven or so dependencies to cover ground that's been covered many a time, in a way that's tried and tested (and takes 10 minutes to set up).

That was my intention. Those dependencies can still be manipulated between platforms.. For example, I might use one dependency on windows (like, say, libcurl), and another on android  (Java sided, probably).



By the way, Geti, do you think that I should really care if people find my reasons proper? I have decided that I want to do something, and asked for help with implementing it, not for help with deciding whether I want to do it or not.


Alright, Average Software, that is just code organization, thanks for warning. I'll look at how have you done it.

[Geti]

Sure, but there wouldn't need to be those ifdefs if you used a layer like SDL or SFML, and could focus on the actual game framework part.
We have a bunch of platform specific code in the KAG codebase, and while its nice to work with on the outside, adding a feature that requires modification of that platform dependent code really, really sucks.

I totally get wanting to do stuff as gnarly as possible, but for anything intended as productive work that pays the bills, I'd err on the side of having more dependencies (which are usually fairly trivial to set up, if they're good libs) than having more platform dependent code in your own lib.

[kamac]

Sure, but there wouldn't need to be those ifdefs if you used a layer like SDL or SFML, and could focus on the actual game framework part.

Cool, but if I used SDL/SFML I wouldn't fill the reasons for which I am actually coding that framework. There is a slight difference between a general purpose game framework, and a sepecific framework, for a specific game.

We have a bunch of platform specific code in the KAG codebase, and while its nice to work with on the outside, adding a feature that requires modification of that platform dependent code really, really sucks.

But those are two separate things - you knew what you want to code. It was some kind of a game. You guys knew that Irrlicht and few other libraries/APIs fulfills your needs.
Now, I know what I want to code, too, but it's not a game. It's a framework, and I believe it can be as fun/entertaining as coding a game.

I totally get wanting to do stuff as gnarly as possible, but for anything intended as productive work that pays the bills, I'd err on the side of having more dependencies (which are usually fairly trivial to set up, if they're good libs) than having more platform dependent code in your own lib.

Again, I'll add dependecies where I need it.

[Average Software]

I totally get wanting to do stuff as gnarly as possible, but for anything intended as productive work that pays the bills, I'd err on the side of having more dependencies (which are usually fairly trivial to set up, if they're good libs) than having more platform dependent code in your own lib.

On the subject of paying the bills, the time I've taken to actually learn how to do this kind of work competantly has landed me 4 different (well paying) programming jobs.

The value of this kind of knowledge cannot be understated.  It's worth pursuing for its own sake.

[Crimsontide]

I hate how whenever I post in GameDev.net I spend more time defending WHY I want to learn/do what i want to do rather than actually learn HOW.  Lets not turn TigSource (which is way awesomer BTW) into that.

Even if isn't not the best route learning Win32 will teach him alot of why you don't want to write another SDL/SFML, ect...

[Gregg Williams]

It seems like a strange problem that it doesn't work as a static library. Are you making sure to link libs like user, and kernel into your exe? That could possibly affect things. Admittedly though its been about 15 years since I did win32 coding and raw directx.

[kamac]

It seems like a strange problem that it doesn't work as a static library. Are you making sure to link libs like user, and kernel into your exe? That could possibly affect things. Admittedly though its been about 15 years since I did win32 coding and raw directx.

Hm, I am not sure. This is the first time I am trying to create a library. (Before I used to have the framework and the self-coded engine in the same project as my game)
To create this library, I followed this walkthrough, but omitted "To use the functionality from the static library in the app" point, and simply added include directory path to my library's path and included .h files from there (Also linked to the .lib ofcourse)

Maybe I did something wrong?

[Gregg Williams]

Yeah not sure. Maybe share your project and code and someone will take a peek? It's obviously possible to create a window from a static lib, GLFW and SFML do this. How is it failing? Any errors, window pointer invalid, etc? Might be time to load the static lib up with printf statements to get a better idea of what part is failing.

[Gregg Williams]

I was curious, so I whipped this together in 10 minutes from some old code laying around. Ignore the obvious faults but it does create a window from a static lib happily.

https://dl.dropboxusercontent.com/u/16140569/Win32StaticLib.zip

Likewise if you want to get rid of the console you change the System from Console to Windows under the linker settings.

[kamac]

Phew, I studied through your code, tried to find any differences, if there were any, I copied & pasted, and it still won't work

My two small projects which are broken - available for interested

(The library project adds an include path to GLM lib, althrough, it can be deleted as it's not used there [yet])

[Gregg Williams]

I'm out of town for the day, but I'll take a peek when I can if no one else does. Did you try an compile and run my example, if so did it work?

[kamac]

I'm out of town for the day, but I'll take a peek when I can if no one else does. Did you try an compile and run my example, if so did it work?

I didn't. I'll try it tommorow, perhaps since it's kinda too late now

[Gregg Williams]

Well that took far to long to figure out, but it was interesting returning to the joys and pains of raw win32 API. Maybe I'll say hello again in another 15 some years.

Really came down to just two simple problems, which I've commented.

https://dl.dropboxusercontent.com/u/16140569/DisBeFixed.zip

Cheers

[kamac]

Cheers
All fixed now.