Linked by Jordan Spencer Cunningham on Fri 3rd Jul 2009 20:56 UTC, submitted by Michael
The folks over at Phoronix had an interesting interview with Linux game porter, Frank Earl. Despite the apparent decline in PC gaming, Earl has worked for Linux Game Publishing for several years and was seeking input from the community at large for game suggestions at Phoronix. He's also done work independently on porting various software over from Windows. The interview covers work that Earl has done, difficulties that arise in porting commercial games to Linux, successes they've had, his views on Linux in general, and his thoughts on the future of gaming in Linux.
Thread beginning with comment 371793
To view parent comment, click here.
To read all comments associated with this story, please click here.
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[3]: Interesting article
by cb_osn on Sun 5th Jul 2009 08:11
in reply to "RE[2]: Interesting article"
Member since:2006-02-26
What do you mean? Unless mistaken, most 2D operations can be made in 3D. Therefore, they should be already accelerated? The only unaccelerated operation that comes to my mind is direct pixel update, like playing a movie. Still, you could use textures and PBO/FBO to make it faster than, say, a glDrawPixel() call.
I was also surprised to read this. In the game industry, all UIs are done with the same primitives that are used for rendering the 3D scene.
In fact, for my current hobby project, I wrote a fully hardware accelerated path shape (fully compatible with the SVG path element) that uses pixel shaders for applying solid colors, images and linear/radial gradients with an arbitrary number of stops. It also supports using a Theora movie for the fill or stroke brush and does the YUV->RGB conversion in a pixel shader. The resulting images are identical to the SVG output of Firefox (which uses Cairo) assuming that the graphics hardware offers at least 4x MSAA.
The advantages of 3D hardware acceleration for 2D elements are tremendous. My implementation is written in C# and absolutely blows Cairo away when it comes to speed.
RE[3]: Interesting article
by Ford Prefect on Sun 5th Jul 2009 13:25
in reply to "RE[2]: Interesting article"
Member since:2006-01-16
That's great to know. I was considering it for a demo, but I didn't want to cope with a dead project. However, 18 months since the last release is a lot of time in software; perhaps they should give more news, as few people are reading mailing lists...
Well, in the case of SDL you have a library that is stable and somewhat feature complete for years now.
So it never came to a surprise for me that there are mostly bugfix releases happening, and those quite rarely.
It is very nice to know however, that great efforts are still put into SDL. We have a very stable, simple and convenient API here that is still getting improved under the hood -- great.
Member since:
2005-06-30
If you check the mailing lists, you will see that lots of work is being put into the 1.3 release. This is going to be a major rewrite of SDL's internals, hence the slow development.
That's great to know. I was considering it for a demo, but I didn't want to cope with a dead project. However, 18 months since the last release is a lot of time in software; perhaps they should give more news, as few people are reading mailing lists...
What do you mean? Unless mistaken, most 2D operations can be made in 3D. Therefore, they should be already accelerated? The only unaccelerated operation that comes to my mind is direct pixel update, like playing a movie. Still, you could use textures and PBO/FBO to make it faster than, say, a glDrawPixel() call.