While this article is informative and the author has shared his views, some of the information provided is simply not correct. We at TransGaming would like our say on a few points.
In response to the comments on TransGaming's contributions to the Wine project, we began development of Cedega while Wine was still under a BSD-style license which fully allows the creation of proprietary derivatives. During the time before the Wine license was changed to the LGPL we contributed dozens of patches to the Wine project including key infrastructure for DirectDraw, DirectSound and DirectInput. The LGPL change made it more difficult for us to work closely with the WineHQ community, but nevertheless we continued to contribute code in areas such as DirectSound, OLE, COM, DCOM, the Wine IDL compiler, a 2D DIB rasterizer, and the WinInet APIs. We also made proposals for improving Wine performance through the use of a prototype shared memory WineServer. Those wishing to view our contributions can easily find them in a simple search of the wine-patches archives:
We continue to work with the Wine project, with Cedega incorporating several of the WineHQ DLLs under the LGPL license. Full source code to these DLLs is of course available from our website. We're also thinking carefully about how we can cooperate further in the future.
On the topic of ease of installation and use of Cedega, the TransGaming team has taken huge strides recently to make Linux gaming much easier. With the inclusion of the Game Disc Database (GDDB) using Cedega has never been easier. Simply insert a supported title in the drive and Cedega will detect the disc and use the optimal settings for both installation and game play. No more messing or tweaking with settings.
Is Cedega hurting Linux gaming development? This topic is hotly debated by armchair quarterbacks, however, as Linux gaming is our business, we have some pretty in-depth and intimate knowledge here. We have been talking to game publishers and developers for years and the fact is that most game publishers prefer to stick to the markets that they know and understand - standard console and PC projects. Working on other platforms would require not only a direct investment of resources, but also means fewer resources directed to traditional console or PC projects that the publishers already know how to make money on.
TransGaming works very hard to show publishers that exactly the opposite is true - that a vibrant gaming culture exists on Linux. Unfortunately, the misconception that all Linux users believe that software should be free-as-in-beer makes many of the decision makers feel that even if they were to produce a Linux game it would simply be pirated rather than purchased. Fear of wide scale piracy plays a significant role in preventing quality commercial games from transitioning to Linux.
TransGaming is still pushing to prove the value of the Linux market and will continue to do so at every opportunity. Meanwhile we will continue our work to improve Cedega, to provide better support for more titles and to give customers the ability to play their favorite games on the platform of their choice.
Cedega is a commercial product, sold though our subscription system for $5 / month (3 month minimum). During your subscription, you have access to updates, support, and voting rights to tell us what games you want to see supported.
You can still use the product even if you let your subscription expire, but you won't receive any futher updates, etc.
You can find out more at http://www.transgaming.com
Cedega, when using the new -monitor-cdrom-eject option, does exactly this. If it detects a press of the drive's eject button, it simply closes the Linux handle for all files it has open, then calls the user-space eject program.
The cdrom eject button monitor is only supported on CDRW or DVD drives though, so for older systems you need to use the Point2Play 'unmount / eject' button to trigger this behaviour.
Battlefront does not currently work, as it uses some DirectX 9.0c features that are not yet implemented. We're looking at this game, and several others that are high on our voting list for inclusion in our next release.
That said, the eject system that was added to Cedega 4.0 should work for almost all titles. The only ones that it may have trouble with are ones where the installer requires the first CD back in the drive after the second one is done. I don't recall whether Jedi Academy is among these titles, but I didn't think it was.
Please drop a note to our support team (support@transgaming.com) with more info on what didn't work for you. There are several things you can accidently do with the command line Cedega that will cause a problem for the eject management code - ie: launch the installer from a shell that is sitting in the cdrom mount point. Using Point2Play can eliminate some of these potential issues.
Cedega is not Open Source software. We make no bones about this. Some of the code is available under the AFPL, and we release other portions under the X11 and LGPL licenses to share with the ReWind and Wine community occasionally, but our core technology will not be released. You can read more about some of the related issues in my column here.
As far as Final Fantasy XI goes, we have not done any work on it, and I have no idea whether or not it works. We do our work based on our users' votes, so if you're interested, subscribe and vote for it!
Steam and Half Life both work. Half Life 2 has been consistently voted #1 on our lists for several months, but as it's not released yet, we can't really talk about support for it at this time.
Finally, benchmarks can vary significantly depending on the application and the system. Some titles run as fast as they do in Windows, others are slower (some significantly so), and we sometimes get reports of a title running faster under Linux for some users. You can check out our forums for more info on what works well.
We have supported render to texture in Cedega, for both Direct3D and OpenGL apps for quite some time. It isn't as efficient in OpenGL in Linux, due to the lack of a specific extension to support it, but it still works. We render to a pbuffer, then copy to the target texture. You can see this to good effect in Far Cry, with their water reflections, for example.
What's interesting about performance is that generally, 3D performs much faster on Cedega than 2D does.
Various 2D techniques used in Windows games often perform much more slowly under Linux due to lack of direct access to the framebuffer. Windows games like to both read/write pixels directly to the framebuffer as well as use GDI APIs to draw to them.
The original HL menu system is a good example of this - it combines GDI with direct drawing in all kinds of ways which are difficult for Cedega to do quickly, but once in-game everything is very fast since it's just going direct to OpenGL.
There is a solution to the 2D issue which is for us to implement our own software GDI renderer (to render directly to the virtual framebuffer ourselves, rather than trying to rely on X and synchronizing bitmaps). It's never been voted terribly high by TransGamers so we haven't done much about it recently.
Anyhow, one final data point. Doom 3 on Cedega on an NVidia 5600 runs exactly as fast as it does in Windows when using the 56.72 NVidia drivers. With the released-one-week-ago Windows drivers (61.77), it's much faster on Windows now. Presumably we'll see whatever optimizations NVidia did on the Windows side moving to Linux soon.
Quake 3 engine games on Cedega basically run at par with Windows and Linux Quake engine binaries.
Indeed, Cedega is not software libre. We've never claimed that it was. It's a commercial product that includes components dereived from Wine and ReWind.
Despite that fact, and despite the fact that we have not yet reached the 20,000 subscriber number in our original plans, we have contributed and we continue to contribute to the Wine project in a number of substantial ways. These include major contributions or rearchitectures of: 2D DirectDraw, DirectSound, DirectInput, DCOM, RPC, the WIDL IDL compiler, and wininet code, including SSL support. Additionally, we continue to maintain the X11 licensed ReWind tree, we've contributed code for a DIB renderer, and the Shared Memory WineServer.
Overall, we've contributed tens of thousands of lines of code under Open Source license term.
In particular, our DCOM, RPC, and WIDL work - required for use of InstallShield based installer - is extremely substantial work, and we are actively continuing to contribute that work to Wine and ReWind. We have probably spent as much engineering efforts on this as we have on our closed source Direct3D support.
If you want to see some of what we've contributed, just browse the wine-devel and wine-patches mailing lists.
1) The Corel version of Wine was able to run other apps if you wanted it to. Certainly it was optimized for WPO, and you had to muck with some startup scripts to get it running other apps.
2) The WPO install specifically put all of its Wine related files in/usr/lib/corel/wine. It set the WINEPREFIX up to be ~/.wpo2000. Thus, it was explicitly designed to *NOT* interfere with any other Wine incarnation.
BTW, CodeWeavers Crossover products were not available until over a year after WPO2000 Linux shipped.
As I indicated above, the problem that most users ran into with the suite was the FontTastic font server requirement, and issues relating to that, NOT the Wine stuff.
Take care,
-Gav
Gavriel State, Co-CEO & CTO TransGaming Technologies Inc.
Ok, so as the former architect for the Corel WINE efforts (I left to start TransGaming a few weeks after WPO2K/Linux shipped), here are my recollections.
We paid Cygnus large buckets of cash to add several features that we needed to gcc. The big one was precompiled headers. Just about any Win32-targeted app needs pch, since they tend to #include everything under the sun and just assume that the compiler will go quickly.
Michael Tiemann (now CTO of RedHat) personally did the work, and made great progress with build times. Building MFC on our dual PII-400 boxes went from 45 minutes to about 45 seconds. Unfortunately, the gcc maintainers didn't like his approach to pch, and they're still trying to work out how to do a better job.
In the meantime, some of our development team was working feverishly to bring the WPO build system over to Linux - since it consisted of thousands of lines of dos scripts, we built a perl-based dos command.com interpreter that mapped the MS compiler options to appropriate gcc options as needed.
While all this was going on, we were also attacking the problem from the binary-compatibility angle, using the.EXE builds from Windows and improving WINE where needed.
After several months of continued work on gcc to get it building some of the stupidly complex C++ code WordPerfect used, we did manage to get large chunks of the suite's engines 'natively' built in gcc. But it was much less stable than the Win32 EXE builds that we had, and it was much more painful to deal with than the EXE builds.
The only thing that building with gcc gave us was debug symbols in the WP code, so we could step through WP code as well as Wine code. Once we had completed the work needed to get cross-debugging working (debug the EXE code executing on a Linux box via the MSDev IDE on the Windows side), that wasn't needed anymore.
At that point, we had no more reason to build with gcc, and so we switched over to using the EXEs. Ultimately, it improved performance, since MSDev generates better code than gcc does in many cases (still true). Despite what some people may believe, there is *NO* performance loss in running with EXE vs.so binaries when linked with Wine. Saying that there is is pure FUD.
Where did WPO2k/Linux fall down? Several places. The biggest one was the Font Server. We chose to use BitStream's 'Fontastic' font server rather than Freetype due to concerns over patents. That meant that WPO needed to have this custom font server running in order to get access to detailed font data such as outlines, etc. XFree86 4.0 shipped at the same time that we did and made some subtle changes to some of the x commands we were using to set up the font server. That meant that immediately, anyone running XFree86 4.0 had trouble with the product. That's where the bulk of user problems were. The font server also had some stability problems, and if it went, so did WPO.
Corel developed a patch, but never released it. I have no idea why - I was long gone by then. The patch was almost all in the Wine code, and several users figured out how to build 'corelwine' packages and get things working with it. The patch fixed some ugly repainting issues, which are among the most problematic things to get right in a Win32 implementation.
That said, other than the font server difficulties, the product ran very well. I used it for several years for real work without any serious trouble. Only in the last 12 months has it suffered due to the glibc changes in recent distributions.
I have no idea what the deal is behind this new release, but I suspect that it's just an update of the old, outdated WP8/Unix code to run on newer systems. It's almost certainly not the whole suite.
Take care,
-Gav
Gavriel State, Co-CEO & CTO TransGaming Technologies Inc.
glibc 2.3.2 issues are fixed with 3.0
on
Winex 3.0 Released
·
· Score: 3, Informative
Please check the release notes - this was one of the things that we fixed with WineX 3.0.
Take care,
-Gav
-- Gavriel State, CEO & CTO TransGaming Technologies Inc. gav@transgaming.com
Unfortunately, very few game developers or publishers are willing to allow their games to be made available online (or, in many cases, offline) without some sort of copy protection.
The copy protection that we provide is very unobtrusive. If you change your hardware or use a different machine, it will simply download a new keyed-to-your machine build. But if the build is widely pirated we will see it and act appropriately.
-Gav
-- Gavriel State, CEO TransGaming Technologies Inc. gav@transgaming.com http://www.transgaming. com/
No one by the name of James Newhart works at TransGaming. This is pure flamebait.
The game runs very well even below our recommended 500MHz minimum. Only the videos are a bit sluggish at slower CPU speeds.
Everyone at TransGaming is greatly appreciative of all the work contributed by the Wine team over the last several years. We have been happy to be a part of that, and we continue to contribute code to the project via the ReWind BSD-licensed branch.
-Gav
-- Gavriel State, CEO TransGaming Technologies Inc. gav@transgaming.com http://www.transgaming. com
While it sounds all nice and all, there is very very little that is actually supported in this library. Most of the Direct3D functions are simply stubs, and this library would be absolutely incapable of running anything more complex than the rotating-cube demo they have a screenshot for. They are about where we were 18-20 months ago, and this is certainly not keeping me up at nights.
-Gav
--
Gavriel State
CEO & CTO
TransGaming Technologies Inc.
gav@transgaming.com
The copy protection related code isn't available on SourceForge for the moment due to DMCA concerns, amongst other things. We've just updated the source code page to mention this.
-Gav
--
Gavriel State, CEO
TransGaming Technologies Inc.
gav@transgaming.com
http://www.transgaming.com
You're right: If WINE had been released under the GPL, then this whole situation could not have occurred.
The WINE implementatin of Direct3D would have improved at the same slow rate of other parts of WINE that are not commercially funded. None of the work that we've already contributed back to WineHQ WINE would exist (our work on DirectSound, 2D DirectDraw restructuring, DirectInput, OLE Automation, and general bug fixes).
There would be no opportunity for our business model experiment with the Street Performer Protocol, which could serve as an effective model for other, similar projects.
You're also right in that this *is* about people getting their stuff working. Nothing stops anyone from taking the code and doing whatever they want with it to improve it to get their software working. If they want to redistribute something commercially, they can come to us to negotiate an appropriate commercial license. If they're commercial developers who want to sell a Linux port that uses our DirectX code, is it unreasonable to ask them to pay to support the project? Under the GPL, of course, they could not do such a thing AT ALL.
-Gav
--
Gavriel State, CEO
TransGaming Technologies Inc.
gav@transgaming.com
http://www.transgaming.com
That's not correct. Alice uses DirectX only for setting the screen resolution. The rest is all OpenGL. Trust me - we have it working just fine in Wine.
-Gav
--
Gavriel State, CEO
TransGaming Technologies Inc.
gav@transgaming.com
As we state on our website, TransGaming will not put efforts into WineX compatability for games that are already available as traditional ports from companies like Loki and tribsoft.
The problem is that we have a chicken and egg issue. Major developers won't take the Linux market seriously unless there are lots of games sold for Linux. But we don't see lots of Linux games being sold in part because the selection is too limited.
We hope that the work we're doing will help the Linux games market grow so that everyone will prosper!
Well, the code is there already, under the AFPL which prevents only commercial redistribution.
Furthermore, we're *not* accepting money now. This is just our first development release. If there's a sufficient base of users who express concern over the escrow issue, we'll look into it.
The Direct3D support lives on top of OpenGL. It can actually use information about what the OpenGL/hardware combination supports to report capabilities to DirectX.
If you're skeptical of performance, check out the 3DMark screenshots. 8-)
Our major performance bottleneck right now is in sending geometry to the hardware. D3D has an API that lets you store geometry directly in video memory. OpenGL can do this, but only with some NVIDIA specific extensions that aren't 100% up to snuff on Linux yet. Once we get past that hurdle, we should be close to 1:1 with Windows performance.
Slashdot Mirror
While this article is informative and the author has shared his views, some of the information provided is simply not correct. We at TransGaming would like our say on a few points.
r =3&s=transgaming&q=b
In response to the comments on TransGaming's contributions to the Wine project, we began development of Cedega while Wine was still under a BSD-style license which fully allows the creation of proprietary derivatives. During the time before the Wine license was changed to the LGPL we contributed dozens of patches to the Wine project including key infrastructure for DirectDraw, DirectSound and DirectInput. The LGPL change made it more difficult for us to work closely with the WineHQ community, but nevertheless we continued to contribute code in areas such as DirectSound, OLE, COM, DCOM, the Wine IDL compiler, a 2D DIB rasterizer, and the WinInet APIs. We also made proposals for improving Wine performance through the use of a prototype shared memory WineServer. Those wishing to view our contributions can easily find them in a simple search of the wine-patches archives:
http://marc.theaimsgroup.com/?l=wine-patches&w=2&
We continue to work with the Wine project, with Cedega incorporating several of the WineHQ DLLs under the LGPL license. Full source code to these DLLs is of course available from our website. We're also thinking carefully about how we can cooperate further in the future.
On the topic of ease of installation and use of Cedega, the TransGaming team has taken huge strides recently to make Linux gaming much easier. With the inclusion of the Game Disc Database (GDDB) using Cedega has never been easier. Simply insert a supported title in the drive and Cedega will detect the disc and use the optimal settings for both installation and game play. No more messing or tweaking with settings.
Is Cedega hurting Linux gaming development? This topic is hotly debated by armchair quarterbacks, however, as Linux gaming is our business, we have some pretty in-depth and intimate knowledge here. We have been talking to game publishers and developers for years and the fact is that most game publishers prefer to stick to the markets that they know and understand - standard console and PC projects. Working on other platforms would require not only a direct investment of resources, but also means fewer resources directed to traditional console or PC projects that the publishers already know how to make money on.
TransGaming works very hard to show publishers that exactly the opposite is true - that a vibrant gaming culture exists on Linux.
Unfortunately, the misconception that all Linux users believe that software should be free-as-in-beer makes many of the decision makers feel that even if they were to produce a Linux game it would simply be pirated rather than purchased. Fear of wide scale piracy plays a significant role in preventing quality commercial games from transitioning to Linux.
TransGaming is still pushing to prove the value of the Linux market and will continue to do so at every opportunity. Meanwhile we will continue our work to improve Cedega, to provide better support for more titles and to give customers the ability to play their favorite games on the platform of their choice.
Take care,
-Gav
Cedega is not affected by this exploit, as we don't support any META_ESCAPE commands in WMF playback at all.
And Marcus Messier's fix for WineHQ was checked in earlier today. 8-)
-Gav
I didn't write 'on their website', I wrote 'here'. The Slashdot editors made that change.
Actually, they already changed it. I wrote 'here', not 'on their website'.
-Gav
Take care,
-Gav
Cedega is a commercial product, sold though our subscription system for $5 / month (3 month minimum). During your subscription, you have access to updates, support, and voting rights to tell us what games you want to see supported.
You can still use the product even if you let your subscription expire, but you won't receive any futher updates, etc.
You can find out more at http://www.transgaming.com
Cedega, when using the new -monitor-cdrom-eject option, does exactly this. If it detects a press of the drive's eject button, it simply closes the Linux handle for all files it has open, then calls the user-space eject program.
The cdrom eject button monitor is only supported on CDRW or DVD drives though, so for older systems you need to use the Point2Play 'unmount / eject' button to trigger this behaviour.
Take care,
-Gav
Battlefront does not currently work, as it uses some DirectX 9.0c features that are not yet implemented. We're looking at this game, and several others that are high on our voting list for inclusion in our next release.
That said, the eject system that was added to Cedega 4.0 should work for almost all titles. The only ones that it may have trouble with are ones where the installer requires the first CD back in the drive after the second one is done. I don't recall whether Jedi Academy is among these titles, but I didn't think it was.
Please drop a note to our support team (support@transgaming.com) with more info on what didn't work for you. There are several things you can accidently do with the command line Cedega that will cause a problem for the eject management code - ie: launch the installer from a shell that is sitting in the cdrom mount point. Using Point2Play can eliminate some of these potential issues.
Take care,
-Gav
Cedega is not Open Source software. We make no bones about this. Some of the code is available under the AFPL, and we release other portions under the X11 and LGPL licenses to share with the ReWind and Wine community occasionally, but our core technology will not be released. You can read more about some of the related issues in my column here.
As far as Final Fantasy XI goes, we have not done any work on it, and I have no idea whether or not it works. We do our work based on our users' votes, so if you're interested, subscribe and vote for it!
Steam and Half Life both work. Half Life 2 has been consistently voted #1 on our lists for several months, but as it's not released yet, we can't really talk about support for it at this time.
Finally, benchmarks can vary significantly depending on the application and the system. Some titles run as fast as they do in Windows, others are slower (some significantly so), and we sometimes get reports of a title running faster under Linux for some users. You can check out our forums for more info on what works well.
Take care,
-Gav
We have supported render to texture in Cedega, for both Direct3D and OpenGL apps for quite some time. It isn't as efficient in OpenGL in Linux, due to the lack of a specific extension to support it, but it still works. We render to a pbuffer, then copy to the target texture. You can see this to good effect in Far Cry, with their water reflections, for example.
Take care,
-Gav
Hi all,
0 9# 4009
I've posted an official response here:
http://transgaming.org/forum/viewtopic.php?p=40
Take care,
-Gav
--
Gavriel State, Co-CEO & CTO
TransGaming Technologies Inc.
gav@transgaming.com
What's interesting about performance is that generally, 3D performs much faster on Cedega than 2D does.
Various 2D techniques used in Windows games often perform much more slowly under Linux due to lack of direct access to the framebuffer. Windows games like to both read/write pixels directly to the framebuffer as well as use GDI APIs to draw to them.
The original HL menu system is a good example of this - it combines GDI with direct drawing in all kinds of ways which are difficult for Cedega to do quickly, but once in-game everything is very fast since it's just going direct to OpenGL.
There is a solution to the 2D issue which is for us to implement our own software GDI renderer (to render directly to the virtual framebuffer ourselves, rather than trying to rely on X and synchronizing bitmaps). It's never been voted terribly high by TransGamers so we haven't done much about it recently.
Anyhow, one final data point. Doom 3 on Cedega on an NVidia 5600 runs exactly as fast as it does in Windows when using the 56.72 NVidia drivers. With the released-one-week-ago Windows drivers (61.77), it's much faster on Windows now. Presumably we'll see whatever optimizations NVidia did on the Windows side moving to Linux soon.
Quake 3 engine games on Cedega basically run at par with Windows and Linux Quake engine binaries.
-Gav
Indeed, Cedega is not software libre. We've never claimed that it was. It's a commercial product that includes components dereived from Wine and ReWind.
Despite that fact, and despite the fact that we have not yet reached the 20,000 subscriber number in our original plans, we have contributed and we continue to contribute to the Wine project in a number of substantial ways. These include major contributions or rearchitectures of: 2D DirectDraw, DirectSound, DirectInput, DCOM, RPC, the WIDL IDL compiler, and wininet code, including SSL support. Additionally, we continue to maintain the X11 licensed ReWind tree, we've contributed code for a DIB renderer, and the Shared Memory WineServer.
Overall, we've contributed tens of thousands of lines of code under Open Source license term.
In particular, our DCOM, RPC, and WIDL work - required for use of InstallShield based installer - is extremely substantial work, and we are actively continuing to contribute that work to Wine and ReWind. We have probably spent as much engineering efforts on this as we have on our closed source Direct3D support.
If you want to see some of what we've contributed, just browse the wine-devel and wine-patches mailing lists.
-Gav
Gavriel State, Co-CEO & CTO
TransGaming Technologies Inc
Both of these assertions are incorrecect.
/usr/lib/corel/wine. It set the WINEPREFIX up to be ~/.wpo2000. Thus, it was explicitly designed to *NOT* interfere with any other Wine incarnation.
1) The Corel version of Wine was able to run other apps if you wanted it to. Certainly it was optimized for WPO, and you had to muck with some startup scripts to get it running other apps.
2) The WPO install specifically put all of its Wine related files in
BTW, CodeWeavers Crossover products were not available until over a year after WPO2000 Linux shipped.
As I indicated above, the problem that most users ran into with the suite was the FontTastic font server requirement, and issues relating to that, NOT the Wine stuff.
Take care,
-Gav
Gavriel State, Co-CEO & CTO
TransGaming Technologies Inc.
Ok, so as the former architect for the Corel WINE efforts (I left to start TransGaming a few weeks after WPO2K/Linux shipped), here are my recollections.
.EXE builds from Windows and improving WINE where needed.
.so binaries when linked with Wine. Saying that there is is pure FUD.
We paid Cygnus large buckets of cash to add several features that we needed to gcc. The big one was precompiled headers. Just about any Win32-targeted app needs pch, since they tend to #include everything under the sun and just assume that the compiler will go quickly.
Michael Tiemann (now CTO of RedHat) personally did the work, and made great progress with build times. Building MFC on our dual PII-400 boxes went from 45 minutes to about 45 seconds. Unfortunately, the gcc maintainers didn't like his approach to pch, and they're still trying to work out how to do a better job.
In the meantime, some of our development team was working feverishly to bring the WPO build system over to Linux - since it consisted of thousands of lines of dos scripts, we built a perl-based dos command.com interpreter that mapped the MS compiler options to appropriate gcc options as needed.
While all this was going on, we were also attacking the problem from the binary-compatibility angle, using the
After several months of continued work on gcc to get it building some of the stupidly complex C++ code WordPerfect used, we did manage to get large chunks of the suite's engines 'natively' built in gcc. But it was much less stable than the Win32 EXE builds that we had, and it was much more painful to deal with than the EXE builds.
The only thing that building with gcc gave us was debug symbols in the WP code, so we could step through WP code as well as Wine code. Once we had completed the work needed to get cross-debugging working (debug the EXE code executing on a Linux box via the MSDev IDE on the Windows side), that wasn't needed anymore.
At that point, we had no more reason to build with gcc, and so we switched over to using the EXEs. Ultimately, it improved performance, since MSDev generates better code than gcc does in many cases (still true). Despite what some people may believe, there is *NO* performance loss in running with EXE vs
Where did WPO2k/Linux fall down? Several places. The biggest one was the Font Server. We chose to use BitStream's 'Fontastic' font server rather than Freetype due to concerns over patents. That meant that WPO needed to have this custom font server running in order to get access to detailed font data such as outlines, etc. XFree86 4.0 shipped at the same time that we did and made some subtle changes to some of the x commands we were using to set up the font server. That meant that immediately, anyone running XFree86 4.0 had trouble with the product. That's where the bulk of user problems were. The font server also had some stability problems, and if it went, so did WPO.
Corel developed a patch, but never released it. I have no idea why - I was long gone by then. The patch was almost all in the Wine code, and several users figured out how to build 'corelwine' packages and get things working with it. The patch fixed some ugly repainting issues, which are among the most problematic things to get right in a Win32 implementation.
That said, other than the font server difficulties, the product ran very well. I used it for several years for real work without any serious trouble. Only in the last 12 months has it suffered due to the glibc changes in recent distributions.
I have no idea what the deal is behind this new release, but I suspect that it's just an update of the old, outdated WP8/Unix code to run on newer systems. It's almost certainly not the whole suite.
Take care,
-Gav
Gavriel State, Co-CEO & CTO
TransGaming Technologies Inc.
Please check the release notes - this was one of the things that we fixed with WineX 3.0.
Take care,
-Gav
--
Gavriel State, CEO & CTO
TransGaming Technologies Inc.
gav@transgaming.com
Unfortunately, very few game developers or publishers are willing to allow their games to be made available online (or, in many cases, offline) without some sort of copy protection.
. com/
The copy protection that we provide is very unobtrusive. If you change your hardware or use a different machine, it will simply download a new keyed-to-your machine build. But if the build is widely pirated we will see it and act appropriately.
-Gav
--
Gavriel State, CEO
TransGaming Technologies Inc.
gav@transgaming.com
http://www.transgaming
No one by the name of James Newhart works at TransGaming. This is pure flamebait.
. com
The game runs very well even below our recommended 500MHz minimum. Only the videos are a bit sluggish at slower CPU speeds.
Everyone at TransGaming is greatly appreciative of all the work contributed by the Wine team over the last several years. We have been happy to be a part of that, and we continue to contribute code to the project via the ReWind BSD-licensed branch.
-Gav
--
Gavriel State, CEO
TransGaming Technologies Inc.
gav@transgaming.com
http://www.transgaming
While it sounds all nice and all, there is very very little that is actually supported in this library. Most of the Direct3D functions are simply stubs, and this library would be absolutely incapable of running anything more complex than the rotating-cube demo they have a screenshot for. They are about where we were 18-20 months ago, and this is certainly not keeping me up at nights.
-Gav
--
Gavriel State
CEO & CTO
TransGaming Technologies Inc.
gav@transgaming.com
The copy protection related code isn't available on SourceForge for the moment due to DMCA concerns, amongst other things. We've just updated the source code page to mention this.
-Gav
--
Gavriel State, CEO
TransGaming Technologies Inc.
gav@transgaming.com
http://www.transgaming.com
You're right: If WINE had been released under the GPL, then this whole situation could not have occurred.
The WINE implementatin of Direct3D would have improved at the same slow rate of other parts of WINE that are not commercially funded. None of the work that we've already contributed back to WineHQ WINE would exist (our work on DirectSound, 2D DirectDraw restructuring, DirectInput, OLE Automation, and general bug fixes).
There would be no opportunity for our business model experiment with the Street Performer Protocol, which could serve as an effective model for other, similar projects.
You're also right in that this *is* about people getting their stuff working. Nothing stops anyone from taking the code and doing whatever they want with it to improve it to get their software working. If they want to redistribute something commercially, they can come to us to negotiate an appropriate commercial license. If they're commercial developers who want to sell a Linux port that uses our DirectX code, is it unreasonable to ask them to pay to support the project? Under the GPL, of course, they could not do such a thing AT ALL.
-Gav
--
Gavriel State, CEO
TransGaming Technologies Inc.
gav@transgaming.com
http://www.transgaming.com
That's not correct. Alice uses DirectX only for setting the screen resolution. The rest is all OpenGL. Trust me - we have it working just fine in Wine.
-Gav
--
Gavriel State, CEO
TransGaming Technologies Inc.
gav@transgaming.com
As we state on our website, TransGaming will not put efforts into WineX compatability for games that are already available as traditional ports from companies like Loki and tribsoft.
The problem is that we have a chicken and egg issue. Major developers won't take the Linux market seriously unless there are lots of games sold for Linux. But we don't see lots of Linux games being sold in part because the selection is too limited.
We hope that the work we're doing will help the Linux games market grow so that everyone will prosper!
-Gav
Well, the code is there already, under the AFPL which prevents only commercial redistribution.
Furthermore, we're *not* accepting money now. This is just our first development release. If there's a sufficient base of users who express concern over the escrow issue, we'll look into it.
The Direct3D support lives on top of OpenGL. It can actually use information about what the OpenGL/hardware combination supports to report capabilities to DirectX.
If you're skeptical of performance, check out the 3DMark screenshots. 8-)
Our major performance bottleneck right now is in sending geometry to the hardware. D3D has an API that lets you store geometry directly in video memory. OpenGL can do this, but only with some NVIDIA specific extensions that aren't 100% up to snuff on Linux yet. Once we get past that hurdle, we should be close to 1:1 with Windows performance.
-Gav