platform independence?

I''ve never done this, shit i''ve never even used linux.

But im 99% sure this is how it goes.

Your trying to do your stuff at runtime, when I think you do it at compile time

You would make a platform header and it would contain a define like


#define WIN32

or

#define LINUX


Then maybe in this same header or another you would have your include''s for opengl or your differnt window creation functions

like


bool CreateWindow()
{

#ifdefine WIN32

createwindow this way

#endif
#ifdefine LINUX

createwindow that way

#end if
}


But then that dosnt solve the problem for like distributing your cd that can run on many platforms, unless the installer installs a specific exe compiled on that platform.


In msvc i''m pritty sure it already declares a few things for you.

win32 i think (or maybe after you include windows.h
and like an _msvc or something letting you write code depending on the type of compiler (which goes in hand with differnt platforms).


But like i said i have zero experience with this so this may all be complete BS.

Yeah, per-OS stuff is _usually_ done through conditional compilation using the preprocessor. It can also be done using alternative implementation files; but however you do it, it''s a function primarily of your build process, not your code.

---

"Sneftel is correct, if rather vulgar." --Flarelocke

haha good one about SDL.

so coming to SDL, any commercial quality games use it? Because I am concerned at how well SDL will perform, speed wise.

You essentially write a separate version of each platform-specific function, each in its own platform-specific file, and during your build process (configure script+make or some other way - you could have a separate makefile for each platform, a VC project file, a BCB whatever-files, etc) you select one set of source files (./src/win32/foo.c) or the other (./src/irix64/foo.c), possibly sharing the same headers (./include/foo.h).

If you want to rely on macros, cpp -dM will dump all the predefined macros for your platforms (on windows, check your compiler doc).

However, interleaving platforms in a single file leads to, IMHO, ugly and unmaintainable code. Not to mention that any change to any versions of this code will trigger a rebuild (and, in the Real World, retesting) for all the platforms: you'll have maximized platform dependence instead of minimizing it.

---

“Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.” — Brian W. Kernighan (C programming language co-inventor)

[edited by - Fruny on March 3, 2004 9:58:49 PM]

quote:

---

Original post by soggie
so coming to SDL, any commercial quality games use it? Because I am concerned at how well SDL will perform, speed wise.

---

What''s to worry about "speed wise" if you''re just using it to setup an OpenGL context? (It is the OpenGL forum, which makes me assume that''s all you''re interested in using it for without any additional information.)

Anyway: Loki created it to help them port commercial games (look up a list of the things Loki ported), which I''d assume would qualify for "commercial quality". For some more specificity: every Unreal Tournament (the "original" UT, 2003, and 2004) all use SDL.

I believe the Linux port of Neverwinter Nights uses SDL as well.

As an alternative, you could try GLFW. I''ve been playing with it and it seems fairly solid. Not quite as in-depth as SDL (for instance, it is only an OpenGL framework; no 2D implementation) but good if all you want is cross-platform OpenGL window creation and input handling. The license (zlib license, permits static linking) is slightly more liberal the SDL''s LGPL if that is an issue for you for some reason.

---

Golem
Blender--The Gimp--Python--Lua--SDL
Nethack--Crawl--ADOM--Angband--Dungeondweller

vertexnormal, out of curiousity. is glfw working in fullscreen for you? i get the background color but nothing else and i dont see where fullscreen is so different from windowed to cause that behaviour. that and the sluggish input at lower fps are leaving a bad taste. with sdl leaving its bad tastes im somehow running out of platform independent wrappers.

From what I understand you have to make diffrent builds of your app for diffrent OS''s. It would have been grand to have a multi-OS compatible app. but think of how large your exe file must have been.

If you program in JAVA (but you don''t want that performance loss) you can port to just about any OS. But you need a JVM.

It would be cool to have an app that OS indipendant but very small. When you run that app, it detects which OS you''re on and loads the application thats compiled for that OS accordingly.
Think of it as a OS-Handler, if Windows then load game_win.exe else if Linux then load game_linux.exe .
Something like that.

// Last Attacker \\---=( LA )=---// LA Extreme \\

ICQ Number : 120585863

E-mail: laextr@icqmail.com

thanks guys for the great information. guess now i gotta go see how SDL handles to my requirements. thanks again.

Trienco: Fullscreen works fine for me under Linux in all video modes supported by my X server. It also works fine for me under Win32 MingW, though I haven''t done anything fancier than a bog-standard multi-colored triangle in 1024x768x32 mode as a preliminary test there. What platform/hardware/settings do you use?

GLFW is still relatively new, and I''ve helped Marcus iron out a few tiny bugs having to do with the X side of things, so it''s not impossible that there is a bug somewhere.

If you feel like emailing Marcus (his address is under Author at glfw.sourceforge.net) I am certain he will be willing to try to help you figure out what the problem is. Or if you want to email me, perhaps to keep from cluttering up this thread, I''ll try as well as I can to help (vertexnormal ATLATL linuxmail DOTNOSPAMMERSON org). I''m sorta lean on alternatives for cross-platform libraries myself, so my only choice seems to be "get one working well whatever it takes."

As far as the sluggish controls at low FPS, it may be a result of the default way GLFW polls for events. By default, it polls every time glfwSwapBuffers() is called, so if this is called at a very low frequency it could cause sluggishness. I always turn this auto polling off with glfwDisable(GLFW_AUTO_POLL_EVENTS) at initialization, and manually poll with glfwPollEvents() once per loop during my physics/logic updating.

From the source, it appears that the X polling is a direct wrap of an XPending() loop, and Win32 polling is a direct wrap over a PeekMessage() loop, so just offhand I can not see any obvious other sources of sluggishness-- unless there are issues to using PeekMessage() I am not aware of (highly likely, since I rarely program for Windows without using a wrapper, and know diddly-squat about the finer points of Windows-specific stuff).

Anyway, if I can help, let me know.




soggie: For an idea of how cross-platform projects are handled, take a look at how the source code for SDL or GLFW is organized. You have files/modules that provide the main interface, and these call worker functions that are implemented on a per-platform basis. The functions in each platform-specific file have the same names in all implementations, so conditional compilation is used. In the case of GLFW, part of the job is performed in the Makefile which is provided a specific target--x11, win32-mgw, etc.--and executes the proper shell script or batch file, rather than solely as #ifdef #else #endif constructions in source. Although, there are still #if constructions in the source, to handle some pecific build cases or conditions.




LastAttacker: That might be nice, but to do so all OS developers would have to play fair by the same rules and standards as far as interfaces are concerned. When you throw dynamic linking into the mix, you exacerbate the problem, since an executable that checks for OS support would likely be either linked against shared libraries (.so, .DLL, whatever your poison) or against static functions that may or may not make sense to the platform executing it. I can''t see Microsoft suddenly becoming willing to switch to ELF format shared object libraries, nor can I see Linux zealots willing to switch to .DLL format even if Microsoft allowed it. I also can not see Microsoft cooperating in any sort of endeavour that would make it easier to promote cross-platform compatibility, so in addition to the technical obstacles you have some political ones as well.

As it stands, conditional compilation is the only way to perform cross-platform compatibility, and still retain anything remotely resembling sanity.

---

Golem
Blender--The Gimp--Python--Lua--SDL
Nethack--Crawl--ADOM--Angband--Dungeondweller

quote:

---

Original post by VertexNormal
As far as the sluggish controls at low FPS, it may be a result of the default way GLFW polls for events. By default, it polls every time glfwSwapBuffers() is called, so if this is called at a very low frequency it could cause sluggishness. I always turn this auto polling off with glfwDisable(GLFW_AUTO_POLL_EVENTS) at initialization, and manually poll with glfwPollEvents() once per loop during my physics/logic updating.

From the source, it appears that the X polling is a direct wrap of an XPending() loop, and Win32 polling is a direct wrap over a PeekMessage() loop, so just offhand I can not see any obvious other sources of sluggishness-- unless there are issues to using PeekMessage() I am not aware of (highly likely, since I rarely program for Windows without using a wrapper, and know diddly-squat about the finer points of Windows-specific stuff).

---

I suspect that could be the issue and the reason why DirectInput was invented, if SDL uses that behind the scenes for windows it could explain why the SDL responds better than GLFW

quote:

---

Original post by _the_phantom_
I suspect that could be the issue and the reason why DirectInput was invented, if SDL uses that behind the scenes for windows it could explain why the SDL responds better than GLFW

---

would have been my guess, as i wouldnt see why sdl would care about direct input and the annoying debug-issues it brings along with acquiring and unacquiring (using emulation seems to only work with dx debug runtimes).
the fps are still at 20-40, still there sometimes seems to be a small lag between moving the mouse and the reaction. but thank god he's treating the wheel as axis and not using that $%& button-hack (especially that ugly workaround of sending a down event immediately followed by an up event and making it completely useless if you DONT use events, but just check the states).
also: i like the timer stuff (i can throw away my "not checking for anything" rdtsc timer and still get the best timer available.. unlike sdl which might use a perfectly good timer but decides to screw precision by always rounding to milliseconds and making the timer yet again useless for a handful of things like profiling code or timing fast loops). though i might change the part to measure cpu speed after checking how much overhead the performance counter really has and if its making any relevant difference for the result.

about fullscreen. i just tried it again and this time i could see something.. about 1cm in the lower left corner of the screen was showing the upper right quarter of the particle system (at least it looked like that). but i want to make sure its not my setup or something that just "happens" to work in windowed mode first. after all it just seems that the viewport is screwed.

edit: shoot me please. with all my dividing things up and putting everything where it belongs the call to glviewport simply got lost. no problem for windowed mode, as the window has the right dimensions which are set as default when the context is attached. for fullscreen this seems to work in a different order (though without trying i cant tell if its different in general or if glfw creates it as something like 10x10 and later resizes it).

so the only remaining problem are the controls and im quite sure thats a problem with the win api itself (else: why bother with direct input for mouse and keyboard?).

[edited by - Trienco on March 4, 2004 2:06:19 PM]

Trienco: Would it be worth it in your opinion to include the option to compile with DirectInput support for some things? Just a question, and I can''t say if Marcus would want to take it in that direction or speak for him in any way, but if DirectInput offers responsiveness that you can''t get out of the standard Windows message pump, it might be something to consider. I do plan on releasing Windows versions for my games, so now would be the appropriate time to figure this out, before response-time issues become too deeply ingrained.

And, yeah, according to the source, SDL wraps DirectInput if present. But it does include standard Windows code (in the src/video/windib branch) so it can be built without DirectInput support; basically, this also is just a PeekMessage() loop. I''d be curious to see how performance compares between the two, to see if using DirectInput really makes that great a difference, or if SDL just structures theirs in a different enough manner to make the difference. Hmmm...

.shoots Trienco

---

Golem
Blender--The Gimp--Python--Lua--SDL
Nethack--Crawl--ADOM--Angband--Dungeondweller

download nethack and check out any of the include files... they have all kinds of
#ifdef __WIN32

stuff...

you can use these same flags

quote:

---

Original post by soggie
haha good one about SDL.

so coming to SDL, any commercial quality games use it? Because I am concerned at how well SDL will perform, speed wise.

---

the quake3 linux version used SDL with OPENGL

I don''t know what to put here.

quote:

---

Original post by VertexNormal
Trienco: Would it be worth it in your opinion to include the option to compile with DirectInput support for some things? Just a question, and I can't say if Marcus would want to take it in that direction or speak for him in any way, but if DirectInput offers responsiveness that you can't get out of the standard Windows message pump, it might be something to consider.

---

i remember that i wanted to drop sdl earlier for the annoying freezing during debugging. including direct input wasnt that much work (basically you can just copy/paste the example code from the sdk docs). but the acquiring/unacquiring was the problem: hitting a break point while the app had the mouse and keyboard i got the same problem. if its added it would be great if there was a simple switch, so somelike like a
#if DEBUG
glfwUseDInput(GL_FALSE);

would help debugging.

quote:

---

I do plan on releasing Windows versions for my games, so now would be the appropriate time to figure this out, before response-time issues become too deeply ingrained.

---

im not sure where exactly things are handled differently. maybe you could get away with polling in a seperate thread. if you can already test it on windows, just add tons of objects until the fps are in the 20-30 area. it feels like there are jumps every now and then and the mouse suddenly realizes "oh damn, i have been moved" and rushes to the new position (i'll try polling myself later, but im swapping buffers with every update anyway).

quote:

---

.shoots Trienco

---

thanks. somehow the whole screen being updated with the background color while the viewport was just a little something in the corner got me off track. but so are point sprites on my ati (besides only working in immediate mode they screw up texturing on a simple quad, even when disabled and using push/pop on all possible attribs). maybe thats an interesting "cross platform" thought. we worry a lot of different os's while often just two different vendors or even drivers can be a real pain...

btw. did you ever manage to "crash" your graphics card? i never thought thats really possible, but just try and leave point sprites enabled on an ati with cat 4.2. freeze, signal lost, if your lucky vpu recover works (NOW i know why ati has that feature), but screwed up and without 2d acceleration (ever tried scrolling without? ouch). trying to trick it into a reset by changing the d3d settings (why on earth do they even do that?) resulted in garbage on screen and a reboot.

considering that the same code will most likely work without problems (never had any trouble with point sprites on my old gf3) that kind of thing will cause just as much headache as being cross platform. just imagine all the "friendly" mails from ati-users if you develop on nvidia ,-)

[edited by - Trienco on March 5, 2004 1:56:22 AM]

hmm noticed one thing... i initialized the window, and then there''s a half sec lag before my application runs. it is where the window borders are seen without the rendering context, and then half a second later my scene shows. Dont ask me how i know its a half second delay... some people just have quick eyes

i dont think this is a problem, i''ve noticed the same thing happening sometimes with the UT2K4 demo before it runs

About that quick pause: Actually, I''ve noticed that problem a lot as well. I think it happens because apps initialize their main window first, then pause while they initialize everything else. I get around this by creating a hidden window to pass to DirectX APIs, then show the window when everything is initialized and ready. I don''t know how that might work with SDL though.