nice summery of the subject, didn’t go into alot of the finer details but did a good job.
it suprizes me that developers don’t use more cross platform api’s.
its quite simple to write threads apps that run on BeOS, QNX, fBSD, Sun, AtheOS, Windows and a hand full of other OS’ without much work.
with toolkits like Qt and hand rolled ones (like the one i’ve done for my company) its odd that some devs still shy away from writing cross platform frendly code.
i have made it our companies policy to have at least 3 OS impimentations. It not only provides a good way to Objectify code but it also is a extreamly helpfull debuging tool. I have found that many OS’s implementations fo thread libs, mutex, time, etc are verry differant in what types of “errors” they catch and what type of debug info they offer up.
it also teaches one the value of seperation of GUI and logic … which i am a big fan of
Excuse me, bludger, but did you imagine for a second that maybe Doom 3, UT, quake may be limited by something more than the CPU? From my experience, it seems like part of the problem with Mac games has been unoptimized porting, the quality of the video drivers compared to Wintel drivers, and the Mach-O kernel that OSX is based on.
Also, if you look up Quake 3, you’ll see that the Quake port was highly optimized, and runs better on macs than comparable pcs. I haven’t tested this, since I’m not really a gamer, but this is what I’ve read.
And furthermore, can you imagine that there are people who aren’t buying computers purely for videogames? I know I didn’t get my mac mini for that…
Lastly, OSX runs on x86, so your whole arguement goes out the window.
No the biggest problem with porting games from Windows to OSX is the fact a lot of them require DirectX now and not OpenGL. If you want them to run on OSX you need to have them be able to use OpenGL such as World of Warcraft. Which as anyone can tell you at least on Windows if you edit your Config.wtf to use OpenGL it is much slower which is why it is slower on OSX.
“its quite simple to write threads apps that run on BeOS, QNX, fBSD, Sun, AtheOS, Windows and a hand full of other OS’ without much work.”
You are right, except for BeOS — BeOS has no pthreads, so unless we are talking for a project that doesn’t do much thread synchronisation (and then you could easily add a BeOS native threads code path), threading code written in pthreads does indeed work on every operating system you listed (not sure about AtheOS, but its Syllable derivative does have pthreads now), but with the exception of BeOS.
I’d like your input though — it’s interesting how you support BeOS.
This article gives you a good look at how threads in Win32, *nix (POSIX) & 2 flavours of Apple, and gives you a pretty good “intro” of each. If I was just starting Linux dev and needed a quick look at how threads work, esp. if porting from Win32, then this article wouldn’t be a waste of time to look at. I wasn’t saying it was the article to look at, there are plenty of good ones out there.
I’ve coded threads on Win32 (C++ and Delphi (native and Win32 style depending on the circumstance or how lazy I was) and Java), so appreciated some of the areas raised by this article, that’s all I was saying I guess…
I agree and can relate to your other points re multiple OS porting and separation of GUI logic and core functionality logic. This is the error-proof and scalable way to go when possible.
Not a bad article. Those in the Linux world who haven’t used threads much might find this a good primer too…
Apple is bringing their hardware right under the more massive x86 code base.
A triple OS box is just too irresistible for professionals to ignore.
Apple is giving away WebObjects for free, a previously $50,000 program
http://www.macworld.co.uk/news/index.cfm?NewsID=11860
nice summery of the subject, didn’t go into alot of the finer details but did a good job.
it suprizes me that developers don’t use more cross platform api’s.
its quite simple to write threads apps that run on BeOS, QNX, fBSD, Sun, AtheOS, Windows and a hand full of other OS’ without much work.
with toolkits like Qt and hand rolled ones (like the one i’ve done for my company) its odd that some devs still shy away from writing cross platform frendly code.
i have made it our companies policy to have at least 3 OS impimentations. It not only provides a good way to Objectify code but it also is a extreamly helpfull debuging tool. I have found that many OS’s implementations fo thread libs, mutex, time, etc are verry differant in what types of “errors” they catch and what type of debug info they offer up.
it also teaches one the value of seperation of GUI and logic … which i am a big fan of
Excuse me, bludger, but did you imagine for a second that maybe Doom 3, UT, quake may be limited by something more than the CPU? From my experience, it seems like part of the problem with Mac games has been unoptimized porting, the quality of the video drivers compared to Wintel drivers, and the Mach-O kernel that OSX is based on.
Also, if you look up Quake 3, you’ll see that the Quake port was highly optimized, and runs better on macs than comparable pcs. I haven’t tested this, since I’m not really a gamer, but this is what I’ve read.
And furthermore, can you imagine that there are people who aren’t buying computers purely for videogames? I know I didn’t get my mac mini for that…
Lastly, OSX runs on x86, so your whole arguement goes out the window.
Have fun in the dark, buddy…
No the biggest problem with porting games from Windows to OSX is the fact a lot of them require DirectX now and not OpenGL. If you want them to run on OSX you need to have them be able to use OpenGL such as World of Warcraft. Which as anyone can tell you at least on Windows if you edit your Config.wtf to use OpenGL it is much slower which is why it is slower on OSX.
Open GL is also rooted in the kernel, which gives us benefts of running a game in a window for instance, but at a performance penalty.
On my DP G5 I can actively play 2 3D games at once over 40 fps each, naturally I can only use one keyboard so one game is in spectator mode.
http://homepage.mac.com/hogfish/PhotoAlbum2.html
Other pictures where I got 3 3D games going is just rotating between each at will, it pays to have plenty of RAM and a DP.
I know it’s considered bad form to point out spelling errors, but jeez – here is a list from Y’s post.
suprizes
alot (ok, a typo)
impimentations
extreamly
helpfull
debuging
verry differant
seperation
Peace
I missed one:
summery
Not a bad article. Those in the Linux world who haven’t used threads much might find this a good primer too…
>
>
You’re assuming someone would be interested in porting anything to OSX
“its quite simple to write threads apps that run on BeOS, QNX, fBSD, Sun, AtheOS, Windows and a hand full of other OS’ without much work.”
You are right, except for BeOS — BeOS has no pthreads, so unless we are talking for a project that doesn’t do much thread synchronisation (and then you could easily add a BeOS native threads code path), threading code written in pthreads does indeed work on every operating system you listed (not sure about AtheOS, but its Syllable derivative does have pthreads now), but with the exception of BeOS.
I’d like your input though — it’s interesting how you support BeOS.
I think that MacOs X have support for pthreads library… but I don’t know if MS Widows have this support too….
Does Windows support pthreads library?
BSDero
MacOS X pthreads support has been fairly broken prior to 10.3; Windows has through (thanks to open source programmers) http://sources.redhat.com/pthreads-win32/
No, I wasn’t assuming that at all…
This article gives you a good look at how threads in Win32, *nix (POSIX) & 2 flavours of Apple, and gives you a pretty good “intro” of each. If I was just starting Linux dev and needed a quick look at how threads work, esp. if porting from Win32, then this article wouldn’t be a waste of time to look at. I wasn’t saying it was the article to look at, there are plenty of good ones out there.
I’ve coded threads on Win32 (C++ and Delphi (native and Win32 style depending on the circumstance or how lazy I was) and Java), so appreciated some of the areas raised by this article, that’s all I was saying I guess…
Hm, no response re BeOS.
I agree and can relate to your other points re multiple OS porting and separation of GUI logic and core functionality logic. This is the error-proof and scalable way to go when possible.