Thread: [GD-General] RE: Hardware Survey
Brought to you by:
vexxed72
Menu
▾
▴
gamedevlists-general
|
From: Daniel V. <vo...@ep...> - 2003-01-04 21:10:04
|
This is off-topic though I assume a couple of developers might be interested in it anyways. Below are our numbers with regard to OS distribution. The percentages are unique CD keys used to connect to our master server over time seen per OS for the client and active dedicated servers at the time of the database query (roughly a week ago). UT 2003 Client Server Linux 0.69 % 40.66 % Windows 98/ME 19.63 % 2.74 % Windows NT 0.00 % 6.03 % Windows 2000 11.87 % 34.96 % Windows XP 67.78 % 15.62 % This discussion should be moved to a more appropriate list so I CC'ed the GD-General list at gam...@li.... Please only reply there. Thanks, -- Daniel, Epic Games Inc. > -----Original Message----- > From: Developer-only Forum for DirectX programming issues > [mailto:DIR...@DI...]On Behalf Of Andrew Grant > Sent: Saturday, January 04, 2003 3:47 PM > To: DIR...@DI... > Subject: Hardware Survey > > > I came across this which I found rather interesting and thought > I'd pass it > along. Not sure how old this is (or if it's updated, I think originally it > was generated when users installed a new patch). > > http://hlsdk.valve-erc.com/ > > Some very unexpected stats in there, especially the choice of OS! > > > Andy @ > Climax Brighton > > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > FAQ: http://msdn.microsoft.com/library/techart/DirectX8faq.htm > Web Interface: http://DISCUSS.MICROSOFT.COM/archives/DIRECTXDEV.html > Problems/Suggestions: DIR...@di... > Use the Web Interface (above) to unsubscribe from the list. > Use plain-text only. HTML is not accepted. Attachments are removed > MSDN DirectX Developer Centre: http://msdn.microsoft.com/DirectX > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > |
|
From: <ti...@ea...> - 2003-01-04 21:38:35
|
That's very useful info, thanks Daniel. I'm aware of the valve surveys, but they do seem to be rather dated. Do you happen to have any other recent stats, such as network connection or video card? That 40% for Linux servers makes it very clear that we absolutely have to do a dedicated linux port, sigh <g>. At least we don't have to worry about the client -- 0.69% -- very generous for you guys to even bother with a client port, it clearly had no financial benefit. Tim > From: Daniel Vogel vogel@ep... > RE: Hardware Survey >2003-01-04 13:10 > This is off-topic though I assume a couple of developers might be >interested > in it anyw... -- Personalised email by http://another.com |
|
From: Daniel V. <vo...@ep...> - 2003-01-04 22:10:18
|
> That's very useful info, thanks Daniel. I'm aware of the valve surveys, > but they do seem to be rather dated. Do you happen to have any > other recent stats, such as network connection or video card? Only from people submitting bug reports via our bug report form though we haven't had time to extract useful stats apart from "where it's crashing" yet. -- Daniel, Epic Games Inc. |
|
From: erik r. <er...@fi...> - 2003-01-04 23:09:05
|
On Sat, 2003-01-04 at 13:39, ti...@ea... wrote: > That's very useful info, thanks Daniel. I'm aware of the valve surveys, > but they do seem to be rather dated. Do you happen to have any > other recent stats, such as network connection or video card? > > That 40% for Linux servers makes it very clear that we absolutely have > to do a dedicated linux port, sigh <g>. At least we don't have to worry > about the client -- 0.69% -- very generous for you guys to even > bother with a client port, it clearly had no financial benefit. I'd like to state for the record that I bought UT2K3 *because* it had a Linux client... although I'm not likely to register on any surveys, because I never have time to play ;) |
|
From: Javier A. <ja...@py...> - 2003-01-07 11:07:12
|
ti...@ea... wrote: > That 40% for Linux servers makes it very clear that we absolutely have > to do a dedicated linux port, sigh <g>. At least we don't have to > worry about the client -- 0.69% -- very generous for you guys to even > bother with a client port, it clearly had no financial benefit. That's actually a good question. Daniel, what was the motivation behind building and supporting a Linux client? Javier Arevalo Pyro Studios |
|
From: Ray <ra...@gu...> - 2003-01-07 20:29:35
|
Here are some main reasons we have a port to Linux: - One of our programmers prefers linux to windows - There are a couple linux debugging tools that are really good like oprofile and valgrind - It forces us to keep os-specific code contained - approximately 30% of our users use Linux - In general, supporting multiple clients helps debugging and code organization - Ray Ratelis ra...@gu... Javier Arevalo wrote: > ti...@ea... wrote: > > >>That 40% for Linux servers makes it very clear that we absolutely have >>to do a dedicated linux port, sigh <g>. At least we don't have to >>worry about the client -- 0.69% -- very generous for you guys to even >>bother with a client port, it clearly had no financial benefit. > > > That's actually a good question. Daniel, what was the motivation behind > building and supporting a Linux client? > > Javier Arevalo > Pyro Studios |
|
From: Daniel V. <vo...@ep...> - 2003-01-07 21:09:47
|
> > That 40% for Linux servers makes it very clear that we absolutely have > > to do a dedicated linux port, sigh <g>. At least we don't have to > > worry about the client -- 0.69% -- very generous for you guys to even > > bother with a client port, it clearly had no financial benefit. > > That's actually a good question. Daniel, what was the motivation behind > building and supporting a Linux client? Mark summed it up nicely in his post to our forums. http://www.ina-community.com/forums/showthread.php?s=&threadid=201170 Apart from that it's really neat to have an engine that compiles on a lot of different platforms with an even larger variety of compilers. Also, having a Linux client made the Mac port much easier as we are using gcc on both platforms and it allowed us to showcase UT2003 running on AMD's 64 bit processor at Comdex. -- Daniel, Epic Games Inc. |
|
From: J. V. <jva...@in...> - 2003-01-07 21:19:25
|
Daniel Vogel writes: > > > That 40% for Linux servers makes it very clear that we absolutely have > > > to do a dedicated linux port, sigh <g>. At least we don't have to > > > worry about the client -- 0.69% -- very generous for you guys to even > > > bother with a client port, it clearly had no financial benefit. > > > > That's actually a good question. Daniel, what was the motivation behind > > building and supporting a Linux client? > > Mark summed it up nicely in his post to our forums. > > http://www.ina-community.com/forums/showthread.php?s=&threadid=201170 > > Apart from that it's really neat to have an engine that compiles on a lot of > different platforms with an even larger variety of compilers. Also, having a > Linux client made the Mac port much easier as we are using gcc on both > platforms and it allowed us to showcase UT2003 running on AMD's 64 bit > processor at Comdex. What Daniel neglected to mention is that there are several Linux users who possess photographs of Daniel in a, *ahem*, compromised state. I don't think we can rule out blackmail. -- jv |
|
From: Pierre T. <p.t...@wa...> - 2003-01-13 11:43:19
|
Hi, I would like to have two versions of the same library : - a static version (simple .lib) - a dynamic version (a .dll) This is easy enough by creating two projects (.dsp) and #defining appropriate tokens. But the original DLL project has a particular source-tree (in VC++), that seems to be saved in its DSP file. Is there a way to somehow copy that source tree to the other DSP (from the lib version), without recreating everything in VC++ ? More important, how to easily keep both in sync ? (the same problem arises with project settings, if I change them in one version (say using RTTI or not), I'd like the other version to use the same settings automatically...) I'm afraid it's not possible, but it's worth asking. Pierre |
|
From: Peter L. <pe...@to...> - 2003-01-13 16:26:16
|
we do an unfortunate amount of hand-editing of DSPs. This has its own problems, and it's certainly not an automated solution for keeping synchronization. But at least with a text editor you can more easily look at the whole data set that controls your build, rather than having to look into a bunch of little dialog box fields. Hmmm.. sounds like makefiles give all those benefits too... I suppose it would be best if VC++ had designed a gui front end to -real- make so you could use either mode, as appropriate. I haven't tried to generate a DSP from a makefile, but I thought that VC++ had some technique for importing nmake source files. Maybe that would be worth exploring. Peter -----Original Message----- From: gam...@li... [mailto:gam...@li...]On Behalf Of Pierre Terdiman Hi, I would like to have two versions of the same library : - a static version (simple .lib) - a dynamic version (a .dll) This is easy enough by creating two projects (.dsp) and #defining appropriate tokens. But the original DLL project has a particular source-tree (in VC++), that seems to be saved in its DSP file. Is there a way to somehow copy that source tree to the other DSP (from the lib version), without recreating everything in VC++ ? More important, how to easily keep both in sync ? (the same problem arises with project settings, if I change them in one version (say using RTTI or not), I'd like the other version to use the same settings automatically...) I'm afraid it's not possible, but it's worth asking. Pierre |
|
From: <cas...@ya...> - 2003-01-13 19:41:32
|
This is what I sometimes do: - Create the .lib in one project. - Create an empty dll project, that includes the library and defines some exports. However, I don't know if that would be possible if you are not using a .def file. The cygwin tools and mingw also, come with a handy tool (dllwrap) that automatically creates complex .def files for a project (parsing the declspec commands), maybe you could use it as a custom build step. If you are interested in this approach I could elaborate more. Ignacio Castaño cas...@ya... Pierre Terdiman wrote > Hi, > > I would like to have two versions of the same library : > - a static version (simple .lib) > - a dynamic version (a .dll) > > This is easy enough by creating two projects (.dsp) and #defining > appropriate tokens. > > But the original DLL project has a particular source-tree (in VC++), that > seems to be saved in its DSP file. Is there a way to somehow copy that > source tree to the other DSP (from the lib version), without recreating > everything in VC++ ? More important, how to easily keep both in sync ? (the > same problem arises with project settings, if I change them in one version > (say using RTTI or not), I'd like the other version to use the same settings > automatically...) > > I'm afraid it's not possible, but it's worth asking. > > Pierre > > > > ------------------------------------------------------- > This SF.NET email is sponsored by: FREE SSL Guide from Thawte > are you planning your Web Server Security? Click here to get a FREE > Thawte SSL guide and find the answers to all your SSL security issues. > http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en > _______________________________________________ > Gamedevlists-general mailing list > Gam...@li... > https://lists.sourceforge.net/lists/listinfo/gamedevlists-general > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_id=557 ___________________________________________________ Yahoo! Móviles Personaliza tu móvil con tu logo y melodía favorito en http://moviles.yahoo.es |
|
From: Pierre T. <p.t...@wa...> - 2003-01-14 08:04:13
|
> This is what I sometimes do: > - Create the .lib in one project. > - Create an empty dll project, that includes the library and defines some > exports. > > However, I don't know if that would be possible if you are not using a .def > file. The cygwin tools and mingw also, come with a handy tool (dllwrap) that > automatically creates complex .def files for a project (parsing the declspec > commands), maybe you could use it as a custom build step. If you are > interested in this approach I could elaborate more. I just tried with a single function and it seems to work without def files. So I think I'll do that..... :) Thanks, Pierre |
|
From: <cas...@ya...> - 2003-01-14 14:09:48
|
Pierre Terdiman wrote: > I just tried with a single function and it seems to work without def files. > > So I think I'll do that..... :) Oh fine! I just thought that the export/import information was not preserved in the lib file, and I had never tested that without a def file. It's nice to know that it just works. Ignacio Castaño cas...@ya... ___________________________________________________ Yahoo! Móviles Personaliza tu móvil con tu logo y melodía favorito en http://moviles.yahoo.es |
|
From: Pierre T. <p.t...@wa...> - 2003-01-14 14:38:49
|
> Oh fine! I just thought that the export/import information was not
preserved
> in the lib file, and I had never tested that without a def file. It's nice
> to know that it just works.
Now that I think about it, I might be confused a bit. Here's the thing :
1) In a standard DLL, if I want to export a function I write something like
:
__declspec(dllexport) int SomeFunction(int some_param);
Then SomeFunction() can be found in the DLL, with a decorated name. Any
application that wants to use it has to include the header, link with the
.lib, and the .dll is used at runtime. You can't use GetProcAddress on
SomeFunction(), unless you use a .def file.
2) In a standard DLL, if I write this instead :
extern "C" __declspec(dllexport) int SomeFunction(int some_param);
Then we have the same story, except you can now use GetProcAddress on
SomeFunction() without a .def file, i.e. the name is not decorated. This is
handy in MAX file to get rid of the .def file, for example.
3) Now, in a static library, I don't have any import / export marks. I just
have :
int SomeFunction(int some_param);
If a DLL wraps that library, SomeFunction() doesn't appear in the DLL (with
a decorated name or not), so you can't use GetProcAddess() on it, but you
can still use it in your app (the app beeing otherwise using the wrapping
DLL).
What are .def files useful for, exactly, when not using GetProcAddress() ?
Pierre
|
|
From: <cas...@ya...> - 2003-01-14 18:56:06
|
Pierre Terdiman wrote: > Now that I think about it, I might be confused a bit. Here's the thing : > > 1) In a standard DLL, if I want to export a function I write something like > : > > __declspec(dllexport) int SomeFunction(int some_param); > > Then SomeFunction() can be found in the DLL, with a decorated name. Any > application that wants to use it has to include the header, link with the > .lib, and the .dll is used at runtime. You can't use GetProcAddress on > SomeFunction(), unless you use a .def file. You can't use GetProcAddress unless you know the C++ decorated name of the function. > 2) In a standard DLL, if I write this instead : > > extern "C" __declspec(dllexport) int SomeFunction(int some_param); > > Then we have the same story, except you can now use GetProcAddress on > SomeFunction() without a .def file, i.e. the name is not decorated. This is > handy in MAX file to get rid of the .def file, for example. In C the names are not decorated, so you can use it as is. > 3) Now, in a static library, I don't have any import / export marks. I just > have : > > int SomeFunction(int some_param); > > If a DLL wraps that library, SomeFunction() doesn't appear in the DLL (with > a decorated name or not), so you can't use GetProcAddess() on it, but you > can still use it in your app (the app beeing otherwise using the wrapping > DLL). > > > What are .def files useful for, exactly, when not using GetProcAddress() ? The .def file and __declspec(dllexport) does exactly the same thing. On mingw the compiler does not understand the __declspec(dllexport) directive, so it depends on another tool that generates a .def file for it. The result is the same. The problem is that gcc and vc++ decorate the function names in a different way, so that tools is not as usefull as I thought. What I think it could be going on, is that you are building the .lib file as if it were a dll. The functions preserve the export/import tag in the lib file. When you build the it as a DLL everything works as expected, and when using a .lib file, the exported functions are added to the export and import tables. I assume that the compiler is smart enough to notice that the function does not need to be imported, like when you use an exported function within the dll that exports it. Well, I could be totally wrong, so just take your own conclusions. Hope that helps. Ignacio Castaño cas...@ya... ___________________________________________________ Yahoo! Móviles Personaliza tu móvil con tu logo y melodía favorito en http://moviles.yahoo.es |
|
From: Colin F. <cp...@ea...> - 2003-01-16 17:11:34
|
2003 January 16th Thursday I have created a C# wrapper for the OpenGL API. http://www.colinfahey.com/opengl/csharp.htm I think this wrapper represents an improvement over the few others that are available (for reasons I discuss on the web page). --- Colin cp...@ea... http://www.colinfahey.com |
|
From: Nicolas R. <nic...@fr...> - 2003-01-14 14:55:33
|
Hi, This is what we do here: Let say that we have a "MyLib". First the static library: We have first a "MyLib.h" header which is: including all headers of the library. We have a "MyLibDefines.h" header which is included by all headers of the library, and starts with: #ifndef MYLIB_API #define MYLIB_API #endif Then all public functions/classes are using MYLIB_API declaration. The DLL project. Only two files (usually in same directoy as MyLib) MyLibDLL.cpp which is only doing: #define MYLIB_API __declspec(dllexport) #include "MyLibDLL.h" And MyLibDLL.h: #ifndef MYLIB_API #define MYLIB_API __declspec(dllimport) #endif #include "MyLib.h" In outer project, when using the DLL, we just include "MyLibDLL.h". When using the static lib, we include "MyLib.h" Nicolas. -----Original Message----- From: gam...@li... [mailto:gam...@li...] On Behalf Of Pierre Terdiman Sent: Monday, January 13, 2003 12:42 PM To: gam...@li... Subject: [GD-General] Sharing DSP between static lib / DLL Hi, I would like to have two versions of the same library : - a static version (simple .lib) - a dynamic version (a .dll) This is easy enough by creating two projects (.dsp) and #defining appropriate tokens. But the original DLL project has a particular source-tree (in VC++), that seems to be saved in its DSP file. Is there a way to somehow copy that source tree to the other DSP (from the lib version), without recreating everything in VC++ ? More important, how to easily keep both in sync ? (the same problem arises with project settings, if I change them in one version (say using RTTI or not), I'd like the other version to use the same settings automatically...) I'm afraid it's not possible, but it's worth asking. Pierre ------------------------------------------------------- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en _______________________________________________ Gamedevlists-general mailing list Gam...@li... https://lists.sourceforge.net/lists/listinfo/gamedevlists-general Archives: http://sourceforge.net/mailarchive/forum.php?forum_id=557 |
|
From: Enno R. <en...@de...> - 2003-04-29 11:01:27
|
Daniel Vogel wrote: >>>That 40% for Linux servers makes it very clear that we absolutely have >>>to do a dedicated linux port, sigh <g>. At least we don't have to >>>worry about the client -- 0.69% -- very generous for you guys to even >>>bother with a client port, it clearly had no financial benefit. >> >>That's actually a good question. Daniel, what was the motivation behind >>building and supporting a Linux client? > > > Mark summed it up nicely in his post to our forums. > > http://www.ina-community.com/forums/showthread.php?s=&threadid=201170 I'm a latecomer to this list, and reading archives. This thread has disappeared from the boards, can anyone point me to a mirror? Enno. |
|
From: Daniel V. <vo...@ep...> - 2003-04-29 15:33:56
|
> I'm a latecomer to this list, and reading archives. This thread has > disappeared from the boards, can anyone point me to a mirror? The summary basically is that if we have a Linux server there will be a Linux client. To make this slightly on-topic again, it's actually much easier to test the server if you have the client running on the same OS as well as it's not exactly fun to track down issues that only appear in client/server scenarios. In the past we (or to be more precise, Ryan Gordon) usually went down the road of porting "ucc" (the standalone command line tool) and once that is up and running you basically have most of the engine running at which point you can focus on rendering and sound. That usually uncovers the remaining nastyness if you port to a different endian or 64 bit system. -- Daniel, Epic Games Inc. |
|
From: Parveen K. <pk...@al...> - 2003-04-29 16:16:07
|
On Tue, 2003-04-29 at 04:01, Enno Rehling wrote: > Daniel Vogel wrote: > >>>That 40% for Linux servers makes it very clear that we absolutely have > >>>to do a dedicated linux port, sigh <g>. At least we don't have to > >>>worry about the client -- 0.69% -- very generous for you guys to even > >>>bother with a client port, it clearly had no financial benefit. > >> > >>That's actually a good question. Daniel, what was the motivation behind > >>building and supporting a Linux client? > >=20 > >=20 > > Mark summed it up nicely in his post to our forums. > >=20 > > http://www.ina-community.com/forums/showthread.php?s=3D&threadid=3D2011= 70 >=20 > I'm a latecomer to this list, and reading archives. This thread has=20 > disappeared from the boards, can anyone point me to a mirror? IIRC, the conversation went something like: "We are impatient fanboys. Why are you wasting time with a Linux client? We want the game yesterday." "We are intelligent developers. And we realize that porting our engine to many platforms results in a stronger product." Of course, I'm paraphrasing a little bit. --=20 Parveen Kaler <pk...@al...> http://www.sfu.ca/~pkaler |
|
From: Pierre T. <p.t...@wa...> - 2003-05-09 20:24:04
|
Hi, I'd like to create docs as .chm files. Doxygen supports this but I'd like to create a user-manual for an app, not something for programmers, and I think Doxygen only works with source files (tell me if I'm wrong here), when I'd like to work from already existing html files. So I tried HTML Help Workshop, which works fine and does what I want. But I have a slight problem with it, and I can't find any info on the web about this : sometimes, images (jpegs) are not included in the resulting CHM (though they are correctly displayed in source html files). Any ideas ? Thanks, - Pierre |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X