quote: Original post by mrbastard
Truth is, I''m not that good. Certainly not as good as pros who''ve been in the industry for years. So how do you explain it? It was pretty easy for me.

I explain it by saying that I''ve ported 10-15 commercial games to Linux. I have a good idea how long it takes, on the average. It''s good that you write portable code, and this is reflected in the quickness with which you were able to port your game. I''ve worked on teams of 2-3 that have ported games in 24 hours, and I''ve worked on teams of 2-3 that are still trying to finish up game ports after 3-4 months. It depends on the code you start with, and the experience of the people you have porting the game.

quote: Your claim abour d3d: if you mean winner in terms of popularity, then yes. Anything else, then no. OpenGL is technologically on a par with d3d, but is more flexible. This is where you bring up the ''extension hell'' yes? Nothing that can''t be sorted with one of many libs findable thru google, and 10 mins to get it working.

Extensions are not inherently the problem, it''s that the ARB is slow to standardize extensions, and driver manufacturers are even slower to support them reliably. NVidia produces the only semi-reliable drivers on Linux, if you''re using features on par with Direct3D 8. Theoretically OpenGL can produce any effect that Direct3D can, you are right. It''s just a bit more painful in OpenGL, especially on Linux.

In my opinion, yes, Linux does need more games. And yes, OpenGL and OpenAL are great to program for, and will only get better with time. Right now though, Linux lacks a proper ''global API''. If Linux had a global API, a standard set of libraries which must be installed (which people can actively contribute to of course), you could safely rely on these libraries, and the user wouldn''t have to search for these libraries by hand, which is pretty troublesome. Though I''m not saying this is already being enforced, X Windows is a good example (Xlib), as well as KDE (KDELibs), but doesn''t allow for using on Gnome or other desktops. Another attractive standpoint for most users is the easy ''click to install'' installation programs for Windows. Redhat introduced their Package Format (RPM) to ease the pain a bit, as well as RPM managers to install it with a GUI, but what happens if the user doesn''t have the proper libraries? Looks like a failed installation to me.. now had there''ve been the Global API, that wouldn''t of happened. I''m just saying, it would give Linux a huge boost if someone could just visit the products web page, download their installer, install and run.

quote: Original post by Raid
In my opinion, yes, Linux does need more games. And yes, OpenGL and OpenAL are great to program for, and will only get better with time. Right now though, Linux lacks a proper ''global API''. If Linux had a global API, a standard set of libraries which must be installed (which people can actively contribute to of course), you could safely rely on these libraries, and the user wouldn''t have to search for these libraries by hand, which is pretty troublesome. Though I''m not saying this is already being enforced, X Windows is a good example (Xlib), as well as KDE (KDELibs), but doesn''t allow for using on Gnome or other desktops. Another attractive standpoint for most users is the easy ''click to install'' installation programs for Windows. Redhat introduced their Package Format (RPM) to ease the pain a bit, as well as RPM managers to install it with a GUI, but what happens if the user doesn''t have the proper libraries? Looks like a failed installation to me.. now had there''ve been the Global API, that wouldn''t of happened. I''m just saying, it would give Linux a huge boost if someone could just visit the products web page, download their installer, install and run.

Modern linux distributions automatically handle dependencies now. For example, Mandrake have a RPM based system that will installed/remove/upgrade the RPMs needed to get the one you want working, Lindows has one click GUI installing (which is meant to be very good), Debian has apt-get which resolves dependencies etc. There might not be a standard library for games in the sense that everybody uses it, but there are a lot of libraries and programming languages supported on Linux which gives programmers lots of choice. The majority of libraries used are free as well so there''s no reason a distribution will not install it if it is needed.

It''s really no different to what happens if you don''t have DirectX/OpenGL/.NET installed on Windows.

Very good point Seanw, it all depends then on what linux/desktop you choose. I personally use SUSE+KDE, you can choose your packages using YaST2, and has nice auto-updating features, and separates everything into categories. It also handles dependancy features (usually).

quote: Original post by Anonymous Poster
I explain it by saying that I''ve ported 10-15 commercial games to Linux. I have a good idea how long it takes, on the average. It''s good that you write portable code, and this is reflected in the quickness with which you were able to port your game. I''ve worked on teams of 2-3 that have ported games in 24 hours, and I''ve worked on teams of 2-3 that are still trying to finish up game ports after 3-4 months. It depends on the code you start with, and the experience of the people you have porting the game.

I can see how porting a game full of platform specific code can take a lot of effort, and yes it''d depend on what you have to start with. So really the problem is encouraging the big game studios to adopt cross platform libs and methods, essentially by promoting SDL and opengl.

quote:
Extensions are not inherently the problem, it''s that the ARB is slow to standardize extensions, and driver manufacturers are even slower to support them reliably. NVidia produces the only semi-reliable drivers on Linux, if you''re using features on par with Direct3D 8. Theoretically OpenGL can produce any effect that Direct3D can, you are right. It''s just a bit more painful in OpenGL, especially on Linux.

Yeah, sometimes it''s a pain waiting for the ARB to bash out a standard equivalent of proprietry extensions. But what we lose there, we gain in being able to try out the latest stuff as soon as the hardware guys release it.

Obviously theres a trade off to be made between being able to show off the latest effects and being sure all your required features are supported. I can see how people trying to ensure profits would want to make sure it''s all supported in as many potential customer''s computers as possible.

But any high tech engine will still have to have fallback paths for older hardware. The hardest bit about this is engineering it into the engine, writing the specific paths isn''t a major chore (assuming there aren''t hundreds, and you have a good knowledge of your API). Writing versions for vendor specific extensions adds more work to this, but IMHO not an insane amount. At the end of the day, for games you only really have to consider the ATI and NVIDIA extensions. That said, I generally wait until theres an ARB extension before adding a new feature - the time can usually be better spent improving another area of the engine.

quote: Original post by Raid Right now though, Linux lacks a proper ''global API''. If Linux had a global API, a standard set of libraries which must be installed (which people can actively contribute to of course), you could safely rely on these libraries, and the user wouldn''t have to search for these libraries by hand, which is pretty troublesome.

Good point. I think though, it doesn''t have to be a global API, just a standardised set of libs for game and multimedia use. It''s got all the bits, it''s just hard to know which bits to use.

I think this may be one of the best things to come from the GBLD; it will define a standard set of libs for gaming on linux. While users wouldn''t have to use the distro itself, other distros could certify themselves ''GBLD compatible'' to make it easy for users (and devs) to know if their games will work. Of course this depends upon GBLD being successful.

i don see the need there.
graphics: Xlib (or if you like toolkits GTK+) for the window, OGL for the drawing, libs like libjpeg, libpng for loading
sound: ALSA (and to play ogg, lame, ...)
netplay: simple sockets, nothing more
that''s all there is. what more standarized you need?

quote: Original post by RPTD
i don see the need there.
graphics: Xlib (or if you like toolkits GTK+) for the window, OGL for the drawing, libs like libjpeg, libpng for loading
sound: ALSA (and to play ogg, lame, ...)
netplay: simple sockets, nothing more
that''s all there is. what more standarized you need?

How is that saving effort? Supposing your game uses Xlib, ALSA, and bsd sockets, how are you going to link that beast on Win32?

I don''t think anyone is seriously suggesting that any reasonable developer is going to abandon Windows altogether.

Thats why we have SDL

Unless you are like me by making your game engine by hand, by communicating with Xlib/Libc (Linux) and Win32 API (Windows), and of course OpenGL and OpenAL. But I agree with mrbastard, Linux needs a ''standard'' set of libraries. Here are some ways I propose:

a) A web site where one could download all important ''standard'' libraries. This page could also update users on libraries as they are added.

b) A CD, like mrbastard was saying earlier, would be filled with nice goodies, including some games and the standard library.

c) Linux vendors could update their distro''s in their next version to include the standard libs.

d) Perhaps a universal program (for every Linux, not like YaST or any unique-to-the-os program) to update them on necessary libs.

Or a combination of any of the above. Linux highly needs some orginization and standardisation, I totally agree with mrbastard. Linux has a huge potential, and this idea could be the break that Linux needs to get ahead.

1) yes i do make a project (and code in general) without using more than the basics of the system. if SDL does the porting job or my own project doesn`t matter. i just have a 90% portable part and only a 10% native part... but there i can optimize for the target os not like SDL which seems kinda slowpokey.

2) the idea with standard libs won`t work because there are quasi standards around (ones i named). why introducing another set of libs, not yet well done, not accepted? you all talk about KDE libs `n stuff. not everybody is stupid enough to use the bloated KDE or the slow Gnome. GTK+ is the smallest accepted base there. so if for example ALSA is already in the kernel and working and X11 comes with a ready opengl (plus the driver modules), why complicate things that are already easy enough?