Welcome, Guest. Please login or register.
Did you miss your activation email?

Login with username, password and session length

 
Advanced search

1027525 Posts in 41223 Topics- by 32837 Members - Latest Member: DeadlyAngel

July 28, 2014, 08:26:27 AM
TIGSource ForumsDeveloperTechnical (Moderators: Glaiel-Gamer, ThemsAllTook)Creating a win32 window
Pages: 1 [2] 3
Print
Author Topic: Creating a win32 window  (Read 1483 times)
Xienen
Level 3
***


Greater Good Games


View Profile WWW
« Reply #15 on: May 09, 2013, 06:16:37 AM »

That doesn't actually work.

Maybe I should've mentioned that window creation function is inside a static library? Because, when I copy that code and paste it into int main(..), it works. Weird?

I've run into that issue before.  I believe it has something to do with the WinProc needing to be built in the executable rather than in a library...maybe?  I can't remember
Logged

soryy708
Level 3
***


Where is my tea?


View Profile Email
« Reply #16 on: May 09, 2013, 06:31:59 AM »

Uh... You're talking about portability but using win32? Hmm... Does not compute.
Logged

Portfolio:
  • Cacto Loco! - 'Additional Tunes' (Composer)
  • To be continued...
kamac
Level 10
*****


Notorious posts editor


View Profile Email
« Reply #17 on: May 09, 2013, 06:45:09 AM »

Uh... You're talking about portability but using win32? Hmm... Does not compute.

Please, why does there always have to be one person who enters a thread and wants to know why I don't want to use something they'd prefer?
And that happens to almost any technical thread on tigsource, but I have already made my choice, I considered alternatives like glfw, SFML, SDL and so forth, but I have picked this way for a reason.

If you want to know so badly what that reason is, then I am happy to say that I want to:
A) Get more comfortable with Win32 API
B) Be less dependant on 3rd party libraries
C) Create a framework on my own

Also,

Quote
You're talking about portability but using win32?

Yes?

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

That's what I am using. Seems quite portable to me. Alternatively, I could've make separate libraries for platforms of choice, but instead I prefer to have that all in once place, so I don't end up surrounded with libraries.
Logged

sup
Xienen
Level 3
***


Greater Good Games


View Profile WWW
« Reply #18 on: May 09, 2013, 08:42:44 AM »

If you want to know so badly what that reason is, then I am happy to say that I want to:
A) Get more comfortable with Win32 API
B) Be less dependant on 3rd party libraries
C) Create a framework on my own

...

That's what I am using. Seems quite portable to me. Alternatively, I could've make separate libraries for platforms of choice, but instead I prefer to have that all in once place, so I don't end up surrounded with libraries.

Hear hear!  If you could be so kind, soryy, just let this one go.  Some of us just prefer to build things ourselves to learn more about them even if it doesn't "make sense" to others.
Logged

Crimsontide
Level 3
***


View Profile
« Reply #19 on: May 09, 2013, 12:18:21 PM »

I've run into that issue before.  I believe it has something to do with the WinProc needing to be built in the executable rather than in a library...maybe?  I can't remember

I've been able to put the WinProc function in a library and statically link it.  Never tried with a dll and dynamic linkage though.  Perhaps the library has different compiler options that don't mesh with the main program?
Logged
Average Software
Level 10
*****

Fleeing all W'rkncacnter


View Profile WWW Email
« Reply #20 on: May 09, 2013, 05:09:10 PM »

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.
Logged

Franchise - The restaurant wars begin!

What would John Carmack do?
Crimsontide
Level 3
***


View Profile
« Reply #21 on: May 09, 2013, 05:26:32 PM »

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.
Logged
Gregg Williams
Level 10
*****


Retromite code daemon


View Profile WWW Email
« Reply #22 on: May 09, 2013, 09:13:58 PM »

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.
Logged

Crimsontide
Level 3
***


View Profile
« Reply #23 on: May 09, 2013, 09:27:10 PM »

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.
Logged
Gregg Williams
Level 10
*****


Retromite code daemon


View Profile WWW Email
« Reply #24 on: May 09, 2013, 09:34:16 PM »

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.
Logged

Geti
Level 10
*****



View Profile WWW
« Reply #25 on: May 10, 2013, 04:41:13 AM »

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.
Logged

kamac
Level 10
*****


Notorious posts editor


View Profile Email
« Reply #26 on: May 10, 2013, 07:01:36 AM »

Quote
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;
}

Quote
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.
« Last Edit: May 10, 2013, 07:07:49 AM by kamac » Logged

sup
Geti
Level 10
*****



View Profile WWW
« Reply #27 on: May 10, 2013, 07:06:42 AM »

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.
Logged

kamac
Level 10
*****


Notorious posts editor


View Profile Email
« Reply #28 on: May 10, 2013, 07:12:27 AM »

Quote
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.

Quote
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.

Quote
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.
Logged

sup
Average Software
Level 10
*****

Fleeing all W'rkncacnter


View Profile WWW Email
« Reply #29 on: May 10, 2013, 12:57:11 PM »

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.
Logged

Franchise - The restaurant wars begin!

What would John Carmack do?
Pages: 1 [2] 3
Print
Jump to:  

Theme orange-lt created by panic