Or do you actually believe everything you just said?
The Structure of Array link is actually fairly interesting, but if you think about it it has no meaning to this argument. OpenGL has allows allowed you to specify seperate streams, but X/Y/Z are still bound together. That's not SOA, and not what Intel likes. When you get down to it the whole SOA thing was basically just Intel making up excuses and workarounds for poor CPU design.
In fact most modern hardware (Radeon, Geforce) will prefer it if you pack all your vertex components together, as DirectX has always worked. This all to make more efficient use of memory bandwidth.
Ofcouse that link to Paul Hsieh's site is ancient, and reflects a persons opinion of a battle that raged years ago, based on years old facts. Not all that interesting really.
While it might be true that DX8.0 added a lot of features that only worked on the Geforce3 back then, the new Radeon 8500 supports all those features just fine as well.
DX8.1 adds new features only available on the Radeon 8500, but a new NVidia card will be able to run all that just fine as well.
The plan is for this to continue in this fashion, so the next NVidia card will probably support PS1.4 again (the R8500) stuff, and so forth.
This is a very different situation from OpenGL where the way to do pixelshaders is completely different on ATI or NVidia hardware, and anything you do for an NVidia card will never work on an ATI card, and not the other way around either. As far as I know the same applies to vertexshaders, and ATI still doesn't have their own version of NV_VertexArrayRange. (And they certainly need it).
On OpenGL2.0, it seems like an interesting plan at first (I'm always open for API innovation), but atleast for gaming it doesn't seem to be a very interesting API, and not very forward thinking either. For example keeping the framebuffer blend out of the programmable pipe goes directly against what game programmers have been asking for.
In addition it seems the API would have a lot of problems running on current hardware (not to mention how long it would take for drivers to even get close to stability). OpenGL2.0 would expose model for vertex and pixelshader programming that would be completely unsupported by current hardware. This means you will have a lot of rules to follow to achieve hardware acceleration on specific hardware. When using more features you'd drop back to mostly unacceptably slow software emulation. This would either be hidden (and you could only find out by browsing PDFs hidden somewhere on some IHV site), or it would have to be exposed through some sort of caps system. (Exactly what the OpenGL crowd so seems to dislike.)
Anyway, I don't see this working yet, not for the games market, maybe for others. Best of luck to them anyway.
DirectX is an API. The API is perfectly documented. Anyone capable could implement this API on whatever platform they feel like, without MS releasing any further 'specs'.
I don't feel like splattering my CV and everything all over Slashdot. But feel free to mail me at nix@knoware.nl.
Some issues I don't mind adressing here on Slashdot:
1. I guess Glide on Linux was first mainstream/public/free 3D acceleration Linux had, I think that was something in 97, maybe 98.
2. FireGL. I think different FireGL models have always used different chipsets. And I'm quitte sure one of them (a cheapo one) used a Permedia 2, quitte a while ago. This worked quitte well in DX, even though drivers where far from perfect. I've been spending some time on a game a long time ago to get some stuff nicely working on it, using DX, yes. In general, there is NO 3d card that couldn't support DirectX decently, not by definition of the API. It is always a driver problem. This doesn't necessarily mean all games will work flawlessy, since games might assume things they shouldn't assume, but they do, since it was fine on the hardware they did care about.
3. Oh, and those funny things called WinModems, there is ofcourse nothing 'Windows' about them. It's just that this was how they where marketed, since they wouldn't work with legacy dos apps, if hardware specs are available, any OS that has hardware abstraction could use WinModems.
4. All books on DirectX suck. Period. I think this is mainly because a book that targetted DirectX in the way it was intended wouldn't sell very well, since it's not massmarket enough. Guides on the internet are strangely enough the same thing. Maybe because most people writing a guide want to be done in 500 lines? And want it to basically learn people 3d programming in general while they're at it?
- I didn't say first '3d hardware', I said first 3D driver in linux. Oh maybe you just had the first version of Glide back then, but I wouldn't be all that sure.
- All those games indeed use DX. All those games are maybe by very qualified very competent programmers. Not by 'your average programmer that wants to do games'. Ofcourse it's fine for them to use it. But making it nice and easy for them is not the purpose of DirectX.
- Hardware isn't 'written' for a platform. Granted, lots of hardware gets designed around DX featuresets, but it's just as much the other way around. That's why MS and IHVs pretty much design DX together.
- DirectX doesn't take advantage of specific hardware features like EnvBump etc etc, DirectX allows the software to take advantage of those features, on any hardware that has decided they want to support those.
- In general DX is not more poorly documented as OpenGL. It's for a reason most people consider the MSDN one of the best OpenGL references.
- I wonder what you consider badly abstracted. I think it's well abstracted in that hardware having the same feature gets exposed in the same way. That makes sense to me, and to others.
- MS doesn't have to support hardware, hardware just has to provide drivers for the platforms they care about. Also, your Linux box is most likely not different hardware, just different software.
- I try DirectX? I've used it for years, and happily so. Shipped several games using it. Have you done the same with anything you prefer over it?
- Yes boy. I wouldn't mind explaining them to you, since you obviously don't understand.
- In contact with one of them, ok, me. Others? Pretty much any developer I know, and I know quitte a few, having produced quitte some product.
- Ofcourse we use it because it's standard and the thing to use as well. But we also know why it works the way it works. Actually most of us have had a lot of input in how DX works. MS has regular tours around developers offices and talks with them about DX, what they want in it, and how. I doubt SGI does that =)
Any further issues you need clarification on? Thanks.
---
1 January 2000: Tidied up tutorial a bit.
4 April 1999: Tidied up front page a bit.
2 September 1997: Changed error-checking to use the SUCCEEDED and FAILED macros; this is the correct way to check for errors with COM objects.
---
So basically september 1997 was last time any real work was done on it.
Also interesting to see how the latest revision of the document by Brian Hook is 0.46, which seems to be somewhere from the pre DX5 timeframe. I'm sure 3D programming on Linux was great fun 3 years ago. (Oh, oops, there wasn't even a single 3d driver out yet:)
Point is just, DirectX isn't intended to be for your average programmer who wants to do games. It's intended as an extremely powerful hardware abstraction layer, to be used by profesionals to get the most out of the gamers hardware. This is why DirectX exposes a lot of functionality that is close to the hardware, and can be directly supported by the hardware, or not supported. This is why DirectX functionality is continously being updated to reflect changes in the hardware.
This means DirectX _should_ be complex. We're talking about a complex issue here, where a lot of things determine ultimate performance. And ultimate performance is what you want in the end, isn't it? Fast, lots of features, best on all different hardware.
That's why it was designed and exists.
Do you want to work to get this performance? No? Then get another job. Not smart enough to understand all the issues at play? Then get another job.
Most professional game programmers have been happy with this approach for a long time now, and adopted DirectX years ago.
For the average programmer who justs wants to get some simple stuff going DirectX might indeed not seem ideal, and perhaps it is not, but again, that's not what it was intended for, and not what makes or breaks it.
DirectX is a HAL. Not an easy of use utility library.
How can anyone be taking those Indrema guys seriously? They have exactly nothing to show for themselves (a PC with Linux running Quake 3 using a gamepad is hardly something new), they have NO actual professional development support, they don't seem to have been lobbying towards that either. Indrema is a COMPLETE noname in the game industry.
Their OpenSouce comment is just insane, what are they going to do, put consoles in the shops complete with a box of manuals, and hope that people will start writing games on them? Games that will actually get published and sell? Or games that would actually be good enough for anyone to buy the console _without_ intending to program on it?
Does anyone here seriously believe that OpenSource will lead to better and more efficient games being produced? How would 'ownership' of the platform by the development community lead to better games? Do you think Indrema will be able to provide more information on the NVidia chipset to anyone, as Microsoft will be able to provide to NDAed developers? Not likely. And will Indrema be able to provide so much more information as the stack of PS2 manuals on my desk? I don't think so.
The worst part is, I don't think Indrema even _intends_ to be succesfull in the console market, I think it's just a huge scam.
If it's not a scam, those people are incredibly stupid.
That sounds more like you nuked your Explorer. And not internet explorer. (or maybe it's just one of those cases in which they both go down.) Simply restart explorer.exe, and there you go.
Pretty solid OS I'd say.
(Remembering all the 'No no, Linux didn't crash! You just need to telnet into it and kill X!')
It think it's a real pity how such questions (that where asked as well) haven't been given to Scott. Ok, right, he probably wouldn't have answered them anyway. But this are really important issues.
I was thinking of more something like an NVidia Quadro, to really put on some really good competition:) I don't think NVidia was started by ex-SGIers, but there atleast are a lot of ex-SGIers working their now.
MS indeed is ultimate judge about what gets implemented, but since this interaction process has started it's never really worked out in any bad way as I see it.
Geometry acceleration support is ofcourse about the API supporting it, and the hardware being on the way. Ofcourse GL supports it as well, and in it's most basic form has supported it since its existance. But the D3D methods are much more flexible. This will be even more so with DX8.
And no, there is no reason for D3D to be tied to Windows. It could be implemented on Linux. Just nobody does it. Because it wouldn't be considered very cool:)
Well. Just happens to be that no D3D code actually works in that way. Deal is that it's pretty rare to have geometry in your code in such a static way. It would be coming from your data files, which would contain precreated vertex and indexlists.
How do we choose an API? 1. Consumer demand. 2. features/performance 3. Ease of use to developer 4. portability. But first 3 are way more important.
And even if the code would be a clean recompile another platform, publishing it properly for another platform takes a lot of testing anyway. Testing, customer support, etcetc
And for now it indeed looks like the Windows OpenAL is just a layer ontop of DirectSound. Doesn't that basically mean you have one extra reason not to use it?
The only sortof usefull thing would be to reimplement DX on Linux. There is no reason why COM can't work on Linux. (See CrystalSpace).
Oh great. I'm a troll because I think reinventing the wheel is a bad thing.
gl style syntax is the horrid syntax you can see in OpenGL, and now in OpenAL. Thing like 'alSource3f'. Game development world on PC has pretty much moved over to classes/interfaces for APIs.
Also both are not hardware specific.
And as a game developer, I can tell you, we couldn't care less about the API porting across. If we publish on another platform, this takes a fair bit of cash anyway. A programmer to rewrite specific lowlevel code is hardly an issue.
This is what happens all the time when doing ports between PC and various consoles.
I'm sure this better hardware would be $5000 hardware that barely outperforms $500 consumer hardware nowadays.
Anyway. Nice to see you putting down my technical knowledge. You might be suprised by the truth. I have afterall been doing both D3D and GL (much less intensively, since I hate it) for several years. And that's in software that actually has to work on your average users machine.
The average user doesn't have the latest and greatest SGI.
And about the geometry, older style hardware might be quitte happy accelerating geometry using GL. But for modern hardware in normal pricerange D3D offers a direct path to exactly what the hardware does. And that is the result of carefull crafting and discussing by lots of major developers and IHVs.
So the windows world has been seeing EAX and A3D for quitte a while now. It is being used by a lot of developers to provide high quality 3D sound. The API specs are available to anyone. And Creative could just as well implement this on Linux?
Now WHY do we need a totally new API? Because it's hip to use the totally outdated gl style syntax?
A3D and EAX are here. They are far more well featured. Have had bugs hammered out of them for a long time. This are PROVEN APIs.
How about sticking to some standards people? Instead of creating a new primitive thing, and sticking Open in front of it to make the whole OpenSource community love it.
Lets just ignore your very biased and unfounded 'and it is crap'.
Now I would very much like you to explain why OpenGL would be more suited for general-purpose work? The only thing I can think of is the _driver_ (not API) support for all sorts of line features.
Apart from that, DX provides a much cleaner and much more direct path to the latest hardware features, mainly geometry acceleration. In general MS is just very good in working with both the proffesional software developers and the hardware manufacturers in providing the best API possible.
(I'm sure I'll be considered a troll for this, but having worked with D3D for years now, and having been in meeting with MS about it as well, I really do feel this is true.)
- How do you see Linux being a succesfull gaming platform in the long run? The Windows games market allready is not much more as an afterthought for most publishers, with the consoles being the major money makers. Do you think Linux will change this? If not, how do you see the future of linux gaming and your company? As a niche market, which most major publishers won't touch, but which will leave a nice gap for you to fill? Or do you see yourself moving away from Linux and PCs in the long run, to be a more profitable company on consoles?
Slashdot Mirror
And you've probably never coded or thought about vertexshaders, because what he is saying makes a lot of sense.
Jeez. Major trolling.
Or do you actually believe everything you just said?
The Structure of Array link is actually fairly interesting, but if you think about it it has no meaning to this argument. OpenGL has allows allowed you to specify seperate streams, but X/Y/Z are still bound together. That's not SOA, and not what Intel likes. When you get down to it the whole SOA thing was basically just Intel making up excuses and workarounds for poor CPU design.
In fact most modern hardware (Radeon, Geforce) will prefer it if you pack all your vertex components together, as DirectX has always worked. This all to make more efficient use of memory bandwidth.
Ofcouse that link to Paul Hsieh's site is ancient, and reflects a persons opinion of a battle that raged years ago, based on years old facts. Not all that interesting really.
While it might be true that DX8.0 added a lot of features that only worked on the Geforce3 back then, the new Radeon 8500 supports all those features just fine as well.
DX8.1 adds new features only available on the Radeon 8500, but a new NVidia card will be able to run all that just fine as well.
The plan is for this to continue in this fashion, so the next NVidia card will probably support PS1.4 again (the R8500) stuff, and so forth.
This is a very different situation from OpenGL where the way to do pixelshaders is completely different on ATI or NVidia hardware, and anything you do for an NVidia card will never work on an ATI card, and not the other way around either. As far as I know the same applies to vertexshaders, and ATI still doesn't have their own version of NV_VertexArrayRange. (And they certainly need it).
On OpenGL2.0, it seems like an interesting plan at first (I'm always open for API innovation), but atleast for gaming it doesn't seem to be a very interesting API, and not very forward thinking either. For example keeping the framebuffer blend out of the programmable pipe goes directly against what game programmers have been asking for.
In addition it seems the API would have a lot of problems running on current hardware (not to mention how long it would take for drivers to even get close to stability). OpenGL2.0 would expose model for vertex and pixelshader programming that would be completely unsupported by current hardware. This means you will have a lot of rules to follow to achieve hardware acceleration on specific hardware. When using more features you'd drop back to mostly unacceptably slow software emulation. This would either be hidden (and you could only find out by browsing PDFs hidden somewhere on some IHV site), or it would have to be exposed through some sort of caps system. (Exactly what the OpenGL crowd so seems to dislike.)
Anyway, I don't see this working yet, not for the games market, maybe for others. Best of luck to them anyway.
Uhhhh.
DirectX is an API. The API is perfectly documented. Anyone capable could implement this API on whatever platform they feel like, without MS releasing any further 'specs'.
I don't feel like splattering my CV and everything all over Slashdot. But feel free to mail me at nix@knoware.nl.
Some issues I don't mind adressing here on Slashdot:
1. I guess Glide on Linux was first mainstream/public/free 3D acceleration Linux had, I think that was something in 97, maybe 98.
2. FireGL. I think different FireGL models have always used different chipsets. And I'm quitte sure one of them (a cheapo one) used a Permedia 2, quitte a while ago. This worked quitte well in DX, even though drivers where far from perfect. I've been spending some time on a game a long time ago to get some stuff nicely working on it, using DX, yes. In general, there is NO 3d card that couldn't support DirectX decently, not by definition of the API. It is always a driver problem. This doesn't necessarily mean all games will work flawlessy, since games might assume things they shouldn't assume, but they do, since it was fine on the hardware they did care about.
3. Oh, and those funny things called WinModems, there is ofcourse nothing 'Windows' about them. It's just that this was how they where marketed, since they wouldn't work with legacy dos apps, if hardware specs are available, any OS that has hardware abstraction could use WinModems.
4. All books on DirectX suck. Period. I think this is mainly because a book that targetted DirectX in the way it was intended wouldn't sell very well, since it's not massmarket enough. Guides on the internet are strangely enough the same thing. Maybe because most people writing a guide want to be done in 500 lines? And want it to basically learn people 3d programming in general while they're at it?
Well =)
Ok, for anything else, email me.
Ok. Let me just shoot that down line by line:
- I didn't say first '3d hardware', I said first 3D driver in linux. Oh maybe you just had the first version of Glide back then, but I wouldn't be all that sure.
- All those games indeed use DX. All those games are maybe by very qualified very competent programmers. Not by 'your average programmer that wants to do games'. Ofcourse it's fine for them to use it. But making it nice and easy for them is not the purpose of DirectX.
- Hardware isn't 'written' for a platform. Granted, lots of hardware gets designed around DX featuresets, but it's just as much the other way around. That's why MS and IHVs pretty much design DX together.
- DirectX doesn't take advantage of specific hardware features like EnvBump etc etc, DirectX allows the software to take advantage of those features, on any hardware that has decided they want to support those.
- In general DX is not more poorly documented as OpenGL. It's for a reason most people consider the MSDN one of the best OpenGL references.
- I wonder what you consider badly abstracted. I think it's well abstracted in that hardware having the same feature gets exposed in the same way. That makes sense to me, and to others.
- MS doesn't have to support hardware, hardware just has to provide drivers for the platforms they care about. Also, your Linux box is most likely not different hardware, just different software.
- I try DirectX? I've used it for years, and happily so. Shipped several games using it. Have you done the same with anything you prefer over it?
- Yes boy. I wouldn't mind explaining them to you, since you obviously don't understand.
- In contact with one of them, ok, me. Others? Pretty much any developer I know, and I know quitte a few, having produced quitte some product.
- Ofcourse we use it because it's standard and the thing to use as well. But we also know why it works the way it works. Actually most of us have had a lot of input in how DX works. MS has regular tours around developers offices and talks with them about DX, what they want in it, and how. I doubt SGI does that =)
Any further issues you need clarification on? Thanks.
Oh Yes. _VERY_ up to date tutorial:
---
1 January 2000: Tidied up tutorial a bit.
4 April 1999: Tidied up front page a bit.
2 September 1997: Changed error-checking to use the SUCCEEDED and FAILED macros; this is the correct way to check for errors with COM objects.
---
So basically september 1997 was last time any real work was done on it.
Good flamebait.
:)
Also interesting to see how the latest revision of the document by Brian Hook is 0.46, which seems to be somewhere from the pre DX5 timeframe. I'm sure 3D programming on Linux was great fun 3 years ago. (Oh, oops, there wasn't even a single 3d driver out yet
Point is just, DirectX isn't intended to be for your average programmer who wants to do games. It's intended as an extremely powerful hardware abstraction layer, to be used by profesionals to get the most out of the gamers hardware. This is why DirectX exposes a lot of functionality that is close to the hardware, and can be directly supported by the hardware, or not supported. This is why DirectX functionality is continously being updated to reflect changes in the hardware.
This means DirectX _should_ be complex. We're talking about a complex issue here, where a lot of things determine ultimate performance. And ultimate performance is what you want in the end, isn't it? Fast, lots of features, best on all different hardware.
That's why it was designed and exists.
Do you want to work to get this performance? No? Then get another job. Not smart enough to understand all the issues at play? Then get another job.
Most professional game programmers have been happy with this approach for a long time now, and adopted DirectX years ago.
For the average programmer who justs wants to get some simple stuff going DirectX might indeed not seem ideal, and perhaps it is not, but again, that's not what it was intended for, and not what makes or breaks it.
DirectX is a HAL. Not an easy of use utility library.
Do you have a link to what you wrote on OSOpinion? Can't find it.
How can anyone be taking those Indrema guys seriously? They have exactly nothing to show for themselves (a PC with Linux running Quake 3 using a gamepad is hardly something new), they have NO actual professional development support, they don't seem to have been lobbying towards that either. Indrema is a COMPLETE noname in the game industry.
Their OpenSouce comment is just insane, what are they going to do, put consoles in the shops complete with a box of manuals, and hope that people will start writing games on them? Games that will actually get published and sell? Or games that would actually be good enough for anyone to buy the console _without_ intending to program on it?
Does anyone here seriously believe that OpenSource will lead to better and more efficient games being produced? How would 'ownership' of the platform by the development community lead to better games? Do you think Indrema will be able to provide more information on the NVidia chipset to anyone, as Microsoft will be able to provide to NDAed developers? Not likely. And will Indrema be able to provide so much more information as the stack of PS2 manuals on my desk? I don't think so.
The worst part is, I don't think Indrema even _intends_ to be succesfull in the console market, I think it's just a huge scam.
If it's not a scam, those people are incredibly stupid.
That sounds more like you nuked your Explorer. And not internet explorer. (or maybe it's just one of those cases in which they both go down.) Simply restart explorer.exe, and there you go.
Pretty solid OS I'd say.
(Remembering all the 'No no, Linux didn't crash! You just need to telnet into it and kill X!')
Very well said. I couldn't agree more.
It think it's a real pity how such questions (that where asked as well) haven't been given to Scott. Ok, right, he probably wouldn't have answered them anyway. But this are really important issues.
And have you ever used Windows 2000?
I was thinking of more something like an NVidia Quadro, to really put on some really good competition :) I don't think NVidia was started by ex-SGIers, but there atleast are a lot of ex-SGIers working their now.
:)
MS indeed is ultimate judge about what gets implemented, but since this interaction process has started it's never really worked out in any bad way as I see it.
Geometry acceleration support is ofcourse about the API supporting it, and the hardware being on the way. Ofcourse GL supports it as well, and in it's most basic form has supported it since its existance. But the D3D methods are much more flexible. This will be even more so with DX8.
And no, there is no reason for D3D to be tied to Windows. It could be implemented on Linux. Just nobody does it. Because it wouldn't be considered very cool
Well. Just happens to be that no D3D code actually works in that way. Deal is that it's pretty rare to have geometry in your code in such a static way. It would be coming from your data files, which would contain precreated vertex and indexlists.
How do we choose an API? 1. Consumer demand. 2. features/performance 3. Ease of use to developer 4. portability. But first 3 are way more important.
And even if the code would be a clean recompile another platform, publishing it properly for another platform takes a lot of testing anyway. Testing, customer support, etcetc
And for now it indeed looks like the Windows OpenAL is just a layer ontop of DirectSound. Doesn't that basically mean you have one extra reason not to use it?
The only sortof usefull thing would be to reimplement DX on Linux. There is no reason why COM can't work on Linux. (See CrystalSpace).
Oh great. I'm a troll because I think reinventing the wheel is a bad thing.
gl style syntax is the horrid syntax you can see in OpenGL, and now in OpenAL. Thing like 'alSource3f'. Game development world on PC has pretty much moved over to classes/interfaces for APIs.
Also both are not hardware specific.
And as a game developer, I can tell you, we couldn't care less about the API porting across. If we publish on another platform, this takes a fair bit of cash anyway. A programmer to rewrite specific lowlevel code is hardly an issue.
This is what happens all the time when doing ports between PC and various consoles.
I'm sure this better hardware would be $5000 hardware that barely outperforms $500 consumer hardware nowadays.
Anyway. Nice to see you putting down my technical knowledge. You might be suprised by the truth. I have afterall been doing both D3D and GL (much less intensively, since I hate it) for several years. And that's in software that actually has to work on your average users machine.
The average user doesn't have the latest and greatest SGI.
And about the geometry, older style hardware might be quitte happy accelerating geometry using GL. But for modern hardware in normal pricerange D3D offers a direct path to exactly what the hardware does. And that is the result of carefull crafting and discussing by lots of major developers and IHVs.
Thanks for listening.
Ok. Great.
So the windows world has been seeing EAX and A3D for quitte a while now. It is being used by a lot of developers to provide high quality 3D sound. The API specs are available to anyone. And Creative could just as well implement this on Linux?
Now WHY do we need a totally new API? Because it's hip to use the totally outdated gl style syntax?
A3D and EAX are here. They are far more well featured. Have had bugs hammered out of them for a long time. This are PROVEN APIs.
How about sticking to some standards people? Instead of creating a new primitive thing, and sticking Open in front of it to make the whole OpenSource community love it.
Uh right.
Lets just ignore your very biased and unfounded 'and it is crap'.
Now I would very much like you to explain why OpenGL would be more suited for general-purpose work? The only thing I can think of is the _driver_ (not API) support for all sorts of line features.
Apart from that, DX provides a much cleaner and much more direct path to the latest hardware features, mainly geometry acceleration. In general MS is just very good in working with both the proffesional software developers and the hardware manufacturers in providing the best API possible.
(I'm sure I'll be considered a troll for this, but having worked with D3D for years now, and having been in meeting with MS about it as well, I really do feel this is true.)
Ok, question:
- How do you see Linux being a succesfull gaming platform in the long run? The Windows games market allready is not much more as an afterthought for most publishers, with the consoles being the major money makers. Do you think Linux will change this? If not, how do you see the future of linux gaming and your company? As a niche market, which most major publishers won't touch, but which will leave a nice gap for you to fill? Or do you see yourself moving away from Linux and PCs in the long run, to be a more profitable company on consoles?