guide about game programming
Pages: 12
| imi wrote: |
|---|
| 'that's not portable' - non-issues. |
See?
This is exactly where my frustration lies.
Why is this so easily dismissed as a "non-issue" for you? Mac and *nix users make up what... 25-30% of the market? (read: that's a total guess -- I didn't do any research, but I figure it's something like that.) Why intentially alienate a third of your potential customers?
It's not like crossplatform code is hard to write. You just have to be aware of it, and it takes a different mindset. The only reason why people don't have this mindset is because they were brought up not to (ie: taught bad practices). They form all these bad habits and do things just because that's the way they always did it, and it takes a bulldozer to get them to change (if getting them to change is even possible).
Which brings me back around to what I said before...
| Disch wrote: |
|---|
| The coder could give a long list of reasons to the reader why he should change his practies, but because he doesn't seem as "official" as a tutorial, it might fall on deaf ears. |
I feel like I'm in this situation right now. Here I am with a valid point as to the merit of crossplatform code, and I'm just being met with a casual dismissal of it being a "non-issue".
Last edited on
closed account (z05DSL3A)
In over ten years in my current job, we have had precisely two request for non windows versions of our products. Therefore, for us, Cross Platform in a not even considered.
Having said that, my views on cross platform may also be different to others. Data structures and logic should be separated from UI* and written in a cross platform manor and the UI* should be written natively (without the level of abstraction put on top).
* By UI I mean the windowing and menuing system.
Having said that, my views on cross platform may also be different to others. Data structures and logic should be separated from UI* and written in a cross platform manor and the UI* should be written natively (without the level of abstraction put on top).
* By UI I mean the windowing and menuing system.
closed account (S6k9GNh0)
@Grey Wolf: I would think that the reason why someone would not ask about a commercial product having *nix or Mac support is because they use other free or open source (or a commercial application that DOES support *nix) applications that fit their needs. There's no reason why someone would randomly go up to a Windows based application and ask for a port unless it was truly worth it. It's possible that you are losing a LOT more customers than you may actually think. A native GUI can be accomplished by one of the many great third-party GUI libraries such as GTK+, wxWidgets, Qt, FLTK, etc. There is no reason why that should be a problem.
@OpenGL tutorial: I've been reading the OpenGL bible. It's a pretty open book that gives a lot of detail and explanation to the most basic to the most advanced concepts (whatever is in the scope of the OpenGL API). It's not exactly possible to simply stick an OpenGL tutorial in 2 or 3 pages and call it complete. The OpenGL bible is 200+ (I think? I'll check it when I get home) pages long, each page giving extended and detailed documentation on how OpenGL works. The book is actually on an older version (2.1) of OpenGL, so the new one would probably be much much larger. And best of all, although he used mainly Microsoft C in the book, it gives examples for every platform.
@OpenGL tutorial: I've been reading the OpenGL bible. It's a pretty open book that gives a lot of detail and explanation to the most basic to the most advanced concepts (whatever is in the scope of the OpenGL API). It's not exactly possible to simply stick an OpenGL tutorial in 2 or 3 pages and call it complete. The OpenGL bible is 200+ (I think? I'll check it when I get home) pages long, each page giving extended and detailed documentation on how OpenGL works. The book is actually on an older version (2.1) of OpenGL, so the new one would probably be much much larger. And best of all, although he used mainly Microsoft C in the book, it gives examples for every platform.
Last edited on
Also I think the business world is different from the gaming world.
Windows has a grip on the business market. Most Mac users have Macs for home use, so for a game, the number of people in the target audience that use a Mac will likely be much larger than the target audience for business style applications.
Windows has a grip on the business market. Most Mac users have Macs for home use, so for a game, the number of people in the target audience that use a Mac will likely be much larger than the target audience for business style applications.
closed account (z05DSL3A)
computerquip,
The software component is a small part of the products that we supply. The software is supplied free of charge to our customers and there is no open source software for this market.* This market sector has few suppliers and non of them offer non windows solutions. If the need was there we would know about it.
As any cross platform code ultimately comes down to native, that goes without saying but I did say without the level of abstraction put on top. I have used cross platform UI libraries in the past and always found them wanting.
* I have to be cryptic because I have a nondisclosure agreement with the company I work for, The first rule of fight club...
The software component is a small part of the products that we supply. The software is supplied free of charge to our customers and there is no open source software for this market.* This market sector has few suppliers and non of them offer non windows solutions. If the need was there we would know about it.
| A native GUI can be accomplished by one of the many great third-party GUI libraries such as GTK+, wxWidgets, Qt, FLTK, etc. |
* I have to be cryptic because I have a nondisclosure agreement with the company I work for, The first rule of fight club...
| It's not like crossplatform code is hard to write. |
Actually, I think it is. You give up a lot of things if you always strive for cross-platform. It probably varies how long you will go the way..
You may not even realize what you give up if you do it all the time. I have a recent example for that. For a game, I wrote a particle engine based on templates. I wanted to have the users of the template (which are: "me" :) to implement certain functions in helper-structs which then get called in a callback-fashion. Except that I don't wanted to use virtual functions nor any kind of function pointer (performance reason. The update code itself was plain simple, but the virtual call made an overhead of about 10-15%).
So I used conditional calling teqniques. (Edit: well, that wasn't alone the reason, I could use plain inheritance too. But it was one of them. It's complicated. ;) ) A lot of heavy template stuff to determine whether a template argument has implemented a function or not.
Yesterday, someone in another forum pointed me to __if_exists() in MSVC and this is basically exactly what I wanted, except that there are no 150 lines of ugly template-code and 20-line error messages if something goes wrong. I am kind of scared at the moment what I could miss out by restricting my mind to "must be portable"... ;-)
That doesn't mean you should disregard the standard c++ and "write by trying". It means you should know your compiler, know your platform and all above know your requirements and then write the best thing you can do.
And don't get me wrong about the original spark that started this discussion: I am not advocating that people should put "\" in their header files under windows. I just think it's worth about a small side-note comment to the author of the guide like:
"Hey, yaknow.. even if your section is only about Windows and even if the MSVC-wizard generates files with \ in includes all the time, mixes up case of header files and so on.. and even if it might seem easier to copy'n'paste path things from windows without changing \ to /... you know that Windows works with / perfectly well and since you are writing an OpenGL guide and people might want to use OpenGL precisely because it's platform independend.. and people might jump from Google directly on your Guide without realizing your tips are windows-only and the Mac-section is just a couple of clicks away.. I think you should really strive to clean up your code from Windows-specifica where it isn't necessary. Regards."
Actually that's quite a lot of words for a side-note, but you get the idea of what "level of complain" I would expect for such a minor thing like "in which direction slashes are facing". Certainly not "Boah, look at that.. BACKSLASHES.. what an idiot. *Everyone* knows you get shot for using backslashes!"
Ciao, Imi.
Last edited on
That is a realistic, understandable, and legitimate reason to not write portable code. I'm personally not a fan of compiler extensions, but I don't fault you for using them in this instance.
(on a side note I'm surprised that conditional calling techniques yielded better performance than callbacks. I guess it depends on the complexity. Plus that sounds like it would be a nightmare to maintain.)
I didn't mean to say that ALL code should be crossplatform ALL the time. I don't feel that way at all.
Like I say if there's a reason you [reasonably] can't make it crossplatform, okay, fine. But you shouldn't disregard the crossplatform route entirely without a reason to do so.
(on a side note I'm surprised that conditional calling techniques yielded better performance than callbacks. I guess it depends on the complexity. Plus that sounds like it would be a nightmare to maintain.)
I didn't mean to say that ALL code should be crossplatform ALL the time. I don't feel that way at all.
Like I say if there's a reason you [reasonably] can't make it crossplatform, okay, fine. But you shouldn't disregard the crossplatform route entirely without a reason to do so.
closed account (S6k9GNh0)
Even then, boost has something that is equivalent to __if_exists() on all platforms that support C++.
Topic archived. No new replies allowed.
Pages: 12