Slashdot Mirror
Company Seeks To Boost Linux Game Development With 3D Engine Giveaway
binstream writes "To support Linux game development, Unigine Corp. announced a competition: it will give a free license for its Unigine engine to a seasoned team willing to work on a native Linux game. The company has been Linux-friendly from the very start; it released advanced GPU benchmarks (Heaven, Tropics, Sanctuary) for Linux before and is working on the OilRush strategy game that supports Linux as well."
Yell at the manufacturer of your card, not the linux devs. They can only do so much without the full details of how the card arcitecue is tsructured.
GENERATION 24: The first time you see this, copy it into your sig on any forum and add 1 to the generation. Social exper
When I read the headline I, foolishly perhaps, imagined a free-for-all release. Nonetheless this is excellent news!
We are now entering a transition period when the masses are starting to migrate to low-spec tablet computers from the PCs. The iPads, the new wave of Android tablets and such.. There is no need for the old PC-format packaged computer, the average joe consumer is quicky realizing that fact. The games that need gigs of memory, are CPU/GPU hungry, draw lot of power and require these 3D engines might not be such a hot genre to dive in and develop for right now.
Volume!
How is he yelling at Linux devs? He's pointing out this engine licensing doesn't do much for the main bottleneck facing 3d gaming on Linux.
What I find curious about the general poverty of the linux gaming scene is how the prerequisite elements that do exist seem to have come together much less well than I would have expected, even as, in other areas, the prerequisite elements come together better than I would expect.
A lot of effort gets dumped into Linux and the software ecosystem that people generally mean when they say "linux"(gnome, KDE, prominent programs for both, etc.) A fair percentage of it is paid for(kernel work that makes it more suitable for vendor X's servers and vendor Y's embedded platforms, some Freedesktop consortium stuff, etc.); but much of it is purely voluntary, even the sort of thing that corporations might shy away from under the advice of their lawyers(swift reverse-engineering of iPod and MTP syncing, that one French physicist who single-handedly built support for about a bazillion pre-UVC webcams, etc.).
Similarly, a lot of purely voluntary effort gets dumped into the modding scene. On occasion, a very prominent and successful mod team gets snapped up and goes pro; but that is a sucker's bet. There is a lot of hard, sometimes tedious, modding/art/game balance work going on around commercial games purely voluntarily.
On the Linux side, support for cutting-edge, just-released games and engines is rather sparse; but there are a number of fully free engines and generic asset packs that have been kicking around for a while. All of ID's older engine properties have been cleaned up and open-ified, some from-scratch engines have as well, as well as a few other scratch developed or commercially abandoned projects.
There exist the engines(not cutting edge; but adequate enough for reasonably pretty graphics), there exists a talent pool, as proven by the modders, and their exists a reasonable amount of volunteerism and paid-for-by-people-unconcerned-by-free-riders paid work in the linux ecosystem generally. Why does that so seldom come together on the Linux side? Are the modding tools with contemporary-release proprietary games just that superior to the tools available to the freed engines? Is the mass of potential gamers to turn into modders just that much larger on Windows? Something else?
This is a nice gesture but, I don't really see it jump starting linux game development. I don't think linux will be considered a viable gaming market until a gigantic name like Blizzard starts releasing native linux clients. In fact, I think Blizzard could single handedly make linux a gaming platform. They already release OpenGL versions for the Mac so technologically, they are a short hop from a linux client rather than a giant leap. I wonder if thousands of e-mails to release Diablo 3 with a native linux client would be enough to persuade them to do it.
He should keep preaching over and over to get ATI and Nvidia to release all of their code as GPL or they will be crippled. Free the Software..
YEAH LIKE THAT'LL WORK LOL.
I'd rather use alternatives such as Ogre3D or Irrlitch even if not technologically advanced. I think that's the best way to support Linux-based game development, the same way Blender3D has been doing with their animated short films. Otherwise I feel the community will gain nothing from this. You know, what bugs the the most is that even though Unigine is closed sourced, It has never been used in any important industry title, despite being around for years.
If you already have a fairly successful Linux game now, why wouldn't you put in a bid for this? It would take less work for you to port your game than one designed from scratch. And you can prove that you already know how to deliver on the Linux platform.
That being said, shooters come and go. Their are 10 million. Even with shooters being the most popular genre typically, I think a great platform game would be more likely to steal headlines and gain attention.
Retro-style platform games (New Super Mario Bros, Megaman 9 and 10, Sonic 4) are all the rage. Deliver a good looking game with old school sensibility as a platformer, and everyone will fall in love.
If I'm a start-up trying to explode with a commercial product, I'd see if I could buy the Commander Keen license on the cheap, end up landing a great engine here for free and capture the social/platformer market with releases on XBox Live, PSN, Wiiware, PC, Mac, Linux and maybe even iOS.
If someone steals this idea and does literally make a new Commander Keen game, please consider bringing me on for design.
http://blindscribblings.com - Tasty pop-culture in conceptual fashion.
there are plenty of FREE (as in GPL) 3D engines on Linux. These posers should take their closed-source engine and cram it up their ass.
Do you even lift?
These aren't the 'roids you're looking for.
You mean like how they were but nothing came of it?
Actually, the first step towards good linux drivers is entirely in the dev's hands. No one to blame but the kernel hackers. Provide a stable interface. Provide a stable binary interface, and the manufacturers will provide drivers, at least for common processors. It really is that simple. As long as the drivers need to be rewritten every few months because the kernel was changed (often for no other reason than to break compatibility), linux will have crummy drivers. No sane company is going to sign up to do 10 times the work for a platform with 1% of the usage.
Right on: you nailed it, clearly and succinctly and thoroughly.
Although you didn't take an outright "call to arms" tone, I hope the ideas you are propounding get the attention and action they deserve.
-kgj
Welcome fellow moron.
To those marking the parent as insightful, I'd like to see one single link that backs up what he says about video cards being "just framebuffers" under Linux. You realize that most of the OpenGL driver code is shared with the Windows implementations (which is why Heaven pretty much has the same framerates in both OSes), right?
Yes, you'll eventually see "GNU" on game boxes, along with pictures of your corpulent guru, $tallman.
The Unigine tech demos look excellent, and have been used to showcase just what Linux gaming can look like.
Provide a stable binary interface,
This is wrong on so many levels in linux land.
For starters, unlike windows land, in linux drivers tend to have common things that many drivers need put into modules and re-used. For example the mac80211 stack. In this example all the actual card drivers have to do is basically tell the kernel where the registers are and what they do and bam, working wifi.
Bug fixes in used modules fix bugs in all things that use it. Code re-use to the extreme.
It also helps with portability, can you run your nvidia binary driver on mips? Hell no, could you run neauvou which exposes the hardware through gallium and uses GEM etc.
As long as the drivers need to be rewritten every few months because the kernel was changed (often for no other reason than to break compatibility), linux will have crummy drivers.
Linux by far has the most in-built driver support of any operating system that has ever existed. To call it crappy is a bit of a farce.
All hardware vendors need to do is give a kernel dev specs and a driver which will be indefinitely supported is created. I can still use a tv tuner card from 2001 on my machine now, could you do the same with windows 7?
Having a stable ABI limits improvements to the kernel, and loses a great deal of flexibility and usefulness. So really, screw that. If you 'want' a stable ABI, it is a good sign you are doing it wrong anyway.
There aren't any characters in those images, or videos... just an empty landscape. How does the engine perform with 300 armed ogres running around?
Comment of the year
now if video cards run under linux were more than just framebuffers we might go someplace.
Linux already had pretty solid 3D support going all the way back to the Vodoo1 days. Yeah, sometimes you needed to take a little care to buy a card that actually worked in Linux and not just the next best random piece of junk, but that isn't really that that much different from Windows where when you don't take care you might be stuck with some unusable on-board graphics solution.
If 3D hardware would be the problem of Linux gaming, it would have been solved ages ago.
It sure looks great, I especially loved how the shadows worked realistically when interacting with water.
As for performance: I ran the demo in benchmark mode in Windows 7 using both DX10 and OpenGL, and in Ubuntu 10.10 using OpenGL, and I got the same numbers. Of course since the demo is rather limited it doesn't reflect the full picture of how a game would run, but what it does do is show that Linux is perfectly capable of running a good-looking, modern graphics demo just as well as Win7 at the same speed. That should already be enough to debunk OP's claim: if it was nothing more than a simple framebuffer under Linux it wouldn't achieve equal performance as compared to Win7.
why there is even a question of "Why isn't there more gaming on Linux?" Look at how many desktops Linux currently occupies. I don't have the numbers in front of me but it's pretty small compared to Windows and Mac. Now look at how many of those users are going to be interested in playing games. Comparatively, not many. Hell, they already chose a free OS with mostly free apps, why would they pay for a game? The logic may not necessarily hold up, but I can imagine thats how the game companies see it. Nobody is going to put all the time, effort and resources into creating a port of a game for Linux when their return on investment is almost guaranteed to be negative. How people can't see this is beyond me. It's simple economics folks.
Please hell no. If windows is an example of doing this right then I don't want it. The ABI for windows hasn't changed in 20 years and it's horrible riddled with bugs and simply a PoS. All one has to do is look at how lame their visual c++ compiler is because it has to compile down for their archaic abi to realise that's not the way to go.
This is pretty much what my problem with Linux is: politics interfere with development.
I use Unigine on Linux at work. Everybody else uses it on Windows. OpenGL performance is slightly faster on Linux than Windows but DirectX11 runs a bit faster than OpenGL/Linux I think this is down to DirectX11 multi-threading better thus the CPU becoming less of a bottleneck.
This is with the nVidia drivers.
Unigine is really targeted at DirectX10+ class hardware and is one of the first engines to support new DirectX11/OpenGL 4 features. Our most recent project involves perhaps 100kms of Railway track with animated crowds of people and thousands of animated cars. We have it running on about as fast a systems as you can get. But we don't do optimisation either unless we have to.
Unigine is really good at cross compatible too. All the tools are equally available on Windows/Linux and almost all the code I write under Linux will work the same on Windows.
> Provide a stable binary interface, and the manufacturers will provide drivers, at least for common processors.
Are you sure it's all about binary interfaces? Hardware vendors lose control of whatever runs under linux, while a slightly incompatible windows release/service pack every now and then ensures forced obsolescence.
That would change a bit with binary interfaces but not that much.
And it would get in the way of kernel development.
But I could be wrong so somebody could mantain some kernel with a fixed ABI and see what happens. T2 project does have specified targets already IIRC.
---- MISSING MISCELLANEOUS DATA SEGMENT --- [sigdash] trolololol
A polygon is a polygon, no matter what it's representing. Animated characters require a bit more CPU time and state changes for matrix manipulation, but that's about it.
The problem is not a lack of good engines. There are plenty of good engines. The problem isa lack of good and open source art, models, music, and sound effects. the creative commons really needs boosting here
In my opinion, being Linux-friendly *cannot* exclude being Open-Source and GPL-friendly, as these are really the heart and soul of Linux. Releasing a free *license* is not like releasing the source code. This should not be applauded.
Yeah, driver for my Asus WL-167g wifi was created and worked, but now I can't compile it anymore, because someone thought that net_device struct is no longer needed (starting from kernel 2.6.31). Driver is still open source, but I'm not good enough at driver programming so I can't use this with newest kernels. Now imagine normal user, which buys a card which has "Compatible with linux" on a box but when he tries to compile the driver he is greeted with errors. Yes, I found what happened on some obscure forum, but I had others means of connecting than this card.
Moral: Constant ABI changes are just frustrating.
Extreme Programming - Redundant Array of Inexpensive Developers
Yes, the political and other agendas that go along with Linux essentially result in it fucking itself over in this respect.
So who REALLY do you expect to care that you can't run it on a reasonable obscure OS ... with a rather obscure (these days) processor? You might care, and maybe some guy in Europe ... but no one else does, so you're not really doing anything to help your argument in the minds of people who actually want to serve the most amount of people. You want to run some odd combination, you cut yourself off.
And to ignore what every major developer complains about and uses as their reason for not developing for Linux is just utterly ignorant. If you want people to develop for Linux you have to address their reason for not doing it, not sit around and tell them they are wrong.
Really? You're using an analog tuner to receive what? Analog was done away with last year in the US, I suspect that any other major country in the world is either already there or going that way soon as well, so its awesome that you can get your old TV card working, I don't think any Windows 7 user will cry that they can't get the card they bought 9 years ago to work ... since even with drivers its effectively useless. I guess you could hook it up to cable providers until they drop analog completely.
Actually, you have that backwards. If you can't make a reasonable stable ABI, you're doing it wrong. Its just a sign of a dev who either is incapable of thinking about the future or or don't care, either way, you won't find people who bother to follow you constantly doing anything useful. The fact that you think this way shows that you have no concept of how proper software development works. Its not even unique to software development, standardized interfaces are considered one of the major innovations that brought us to where we are today as far as production is concerned.
Do you think an assembly line would work if every engine, tire, bolt, or whatever had 'improvements to its interface' every day? Oh, today we get new bolts, gotta update the engines ... oh, the engines have a change that requires transmission modifications.
The interface doesn't have to stay the same forever, and indeed can't, but consistency and stability are a good thing, even if you don't understand why. Perhaps you should try living in a world where every electric company providers their own 'optimized' form of electricity, complete with different voltages and frequencies. How well would that work out?
Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager
Wow, fanboys modded you up fast didn't they?
The ABI generally maintains backwards compatibility to a good extent, but if you think it hasn't changed you're completely ignorant and blind.
If it hasn't changed ... why do drivers designed for Win7 not work in XP or Win3.1? How do applications now take advantage of more than 640k? How do these Windows apps interact with the new security bits of Windows 7. Why did AV makers shout and scream about the changes made that screwed over their 'ability' to provide virus protection?
Your visual studio statement makes it clear you're a clueless fanboy.
Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager
Let me understand you. A person who wants to understand how a computer works ... Mac Check ... Mac Check ... Mac Check ... Mac Check ... Mac Check ... Mac Check .. Mac Check ... Mac Check ... Mac Check ... Mac Check
Wants an Open Source Unix environment
High quality software development tools for free
Great available technical documentation
A large pool of similar minded fellow enthusiasts
The ability to write device drivers and kernel extensions
Great user level software choices both free and commercial
High performance options including graphics and distributed computing
Lots of media to incorporate in projects
Great dead tree books about how the computer works and software development
Works out of the box and doesn't frustrate people attempting to accomplish a goal
(1) The were paying high rent and high electricity bills on their development building before releasing a ground-breakingly profitable port of a Title,
(2) Developers were being payed salaries that allowed them to subsist elsewhere when this should have been more of a College-dorm facility that had on-sight living quarters with low-pay (consider a Ryan "Icculus.Org" Gordon lived on-sight because his car wasn't good-enough for himmm),
(3) The employees gave the President too-much stress that when he gave them reverse-engineered employment changes through IRS Tax Forms they all turned on him because it exposed employees to more liabilities,
(4) The president of Loki Software, with a family of 4 including the wife, a house, and a big-screen TV that the entire team would join under at times after work, were all lost in-order to maintane Payroll to a group of employees that had no prior profitable employment under this industry yet demanded the Status & Image of such respectable Pay,
(5) Loki Software was a pack of Betas that gutted their own Alpha male President Scott Draeker,
(6) Every software porting group has always been an extension of the original title company, not an expensive Storate locker full of whiny over-paid bitching employees.
The one that lost on Loki was Scott. His payed-off house was taken under his feat, his car too, wife took the kids and left him abruptly to assume over $300k debt, employees have nothing good to say about him despite him making their Payroll as long as he did while they didn't perform a reputable task at bringing a ported Title to market for profit.
I agree. Linux video drivers are a b**** to work with. If that weren't the case, I'd be using it as my main OS instead of Window$.
No YOU are the troll. Ever wonder why developers think STL vectors are slow? You can thank visual c++.
Hell no. Think about the differences in the ways you do (or better to say, fake) lighting and shadows - whether your "polygon" is static or not makes HUGE difference. It's like saying "vehicle is vehicle, no matter how it gets propelled. Rockets require a bit more fuel and different controls than cars, but that's about it".
Coding etudes
Overall problem with accelerator card support in Linux is that it's several layers "thicker" than in Windows, and those layers tend to be uncontrollable by neither user nor even developer. E.g.
This is partially caused by OpenGL being much more higher level than (experienced) game developer needs it to be (and thus affects MacOS X and mobile platforms as well), and compounded by the fact that even (often incosistent) OpenGL features do not get uniform support on all hardware Linux runs.
I don't see any good solution for this situation.
Coding etudes
Provide a stable interface.
Here NVIDIAs (you know, those who actually do the drivers) opinion on the topic:
The lack of a stable API in the Linux kernel. This is not a large obstacle for us, though: the kernel interface layer of the NVIDIA kernel module is distributed as source code, and compiled at install time for the version and configuration of the kernel in use. This requires occasional maintenance to update for new kernel interface changes, but generally is not too much work.
Srouce: phoronix interview
now if video cards run under linux were more than just framebuffers we might go someplace.
Linux already had pretty solid 3D support going all the way back to the Vodoo1 days. Yeah, sometimes you needed to take a little care to buy a card that actually worked in Linux and not just the next best random piece of junk, but that isn't really that that much different from Windows where when you don't take care you might be stuck with some unusable on-board graphics solution.....
Well, given that ATI and Nvidia make the only video cards that can go faster than 20 FPS It is even easier since ATI's 3-d support has never worked in their proprietary driver.
.
Really? You're using an analog tuner to receive what?
Actually I'm using it to capture the composite output of various consoles. But you missed the point, this is one example of many I can give.
The fact that you think this way shows that you have no concept of how proper software development works. Its not even unique to software development, standardized interfaces are considered one of the major innovations that brought us to where we are today as far as production is concerned.
Standardised interfaces are a great thing for enabling functionality between discrete projects. Remember that this is the kernels INTERNAL functions we are talking about.. You would essentially be mandating the codebase to freeze.
I think it has been well and truly established that having a release every few years as opposed to consistent incremental improvements is a bad idea. But you are free to argue for this if you wish.
The interface doesn't have to stay the same forever, and indeed can't, but consistency and stability are a good thing, even if you don't understand why.
If you want the same interfaces why not just keep using a single kernel version then? after all any improvements the newer kernels bring are changes which detracts from the codebase staying the same.
And to ignore what every major developer complains about and uses as their reason for not developing for Linux is just utterly ignorant. If you want people to develop for Linux you have to address their reason for not doing it, not sit around and tell them they are wrong.
We can't be blamed for thinking long-term, after all why should we care for binary only drivers when they will eventually be broken anyway (not to mention technically break the gpl anyway). And if they are open source they should be encouraged to go into mainline so they get updated to fit with the rest of the kernel automatically.
Do you think an assembly line would work if every engine, tire, bolt, or whatever had 'improvements to its interface' every day? Oh, today we get new bolts, gotta update the engines ... oh, the engines have a change that requires transmission modifications.
Within a single project, when dependent parts communicate to eachother about the changes and improvements, incremental improvements are far better than complete overhalls (do you really want a linux 3.0 that comes in five years time that has problems an order of magnitude worse than vista did? while having a stable abi that whole time just from lack of updates?).
Yes it can come across as nasty to simply ignore those that propose retardedly stupid ideas such as a stable in kernel ABI, but unless you make release cycles longer and suppress technical improvements to single big releases, you can't do it.
And more to the point if you are doing things 'the right way' the lack of a stable ABI does not effect you in the slightest.
This is a perfect example of why having drivers in the mainline kernel tree are a good idea.
If it was it would get automatic updates as the other parts of the kernel are changed. What tends to happen though when there is an open source driver not in kernel, people study the source and within 3-6 months create an in kernel driver that supports it.
So typical worst case is you are stuck using an old kernel version for maybe a year until the new proper drivers are ready for prime time.
Had this happen to me with my eeepc that has an rt2860 chip in it for wifi. At first dependent on their module, it broke, kept old kernel for six months now in kernel driver works a charm.
Moral: Constant API changes are just frustrating.
FTFY.
I know tobacco is bad for you, so I smoke weed with crack.
Solid state switching PSU?
I know tobacco is bad for you, so I smoke weed with crack.