gamedevlists-general Mailing List for gamedev (Page 60)
Brought to you by:
vexxed72
Menu
▾
▴
gamedevlists-general — List for discussing general game development issues
You can subscribe to this list here.
| 2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(3) |
Oct
(28) |
Nov
(13) |
Dec
(168) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2002 |
Jan
(51) |
Feb
(16) |
Mar
(29) |
Apr
(3) |
May
(24) |
Jun
(25) |
Jul
(43) |
Aug
(18) |
Sep
(41) |
Oct
(16) |
Nov
(37) |
Dec
(208) |
| 2003 |
Jan
(82) |
Feb
(89) |
Mar
(54) |
Apr
(75) |
May
(78) |
Jun
(141) |
Jul
(47) |
Aug
(7) |
Sep
(3) |
Oct
(16) |
Nov
(50) |
Dec
(213) |
| 2004 |
Jan
(76) |
Feb
(76) |
Mar
(23) |
Apr
(30) |
May
(14) |
Jun
(37) |
Jul
(64) |
Aug
(29) |
Sep
(25) |
Oct
(26) |
Nov
(1) |
Dec
(10) |
| 2005 |
Jan
(9) |
Feb
(3) |
Mar
|
Apr
|
May
(11) |
Jun
|
Jul
(39) |
Aug
(1) |
Sep
(1) |
Oct
(4) |
Nov
|
Dec
|
| 2006 |
Jan
(24) |
Feb
(18) |
Mar
(9) |
Apr
|
May
|
Jun
|
Jul
(14) |
Aug
(29) |
Sep
(2) |
Oct
(5) |
Nov
(4) |
Dec
|
| 2007 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(11) |
Sep
(9) |
Oct
(5) |
Nov
(4) |
Dec
|
| 2008 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
(34) |
Jun
|
Jul
(9) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(4) |
| 2016 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
|
From: <phi...@pl...> - 2003-01-14 00:13:30
|
Alternatively invest in seperate test and development machines. So in t=
he
same way that a console developer has a devkit, a PC developer gets a
min/reccomended-spec machine to test on. Remote debugging fixes a lot o=
f
the heisenbug issues too. Plus my main machine HAS to run Maya at a use=
able
speed, so a low spec is completely out of the question.
Cheers,
Phil
PS Personally I hated PC development, primarily because it's almost
impossible to polish a moving target, and your game will always look li=
ke
shit on one or other of the billion configurations out there. PC monito=
rs
are like flourescent lights. Not flattering.
=
=20
"Grills, Jeff" <jg...@so...> =
=20
Sent by: To: =
"'gam...@li...'" =20
gam...@li...urc <game=
dev...@li...> =20
eforge.net cc: =
=20
Fax to=
: =20
Subjec=
t: RE: [GD-General] IncrediBuild =20
01/13/2003 09:05 AM =
=20
Please respond to gamedevlists-general =
=20
=
=20
=
=20
To elaborate more, I find that programmers stop optimizing when code
performs acceptably on their machine. So, if their processors are 3 ti=
mes
as fast as the min spec machine, you've got problems waiting to bite yo=
u.
Consoles solve that - you run the code on the console, which is the
min-spec
machine (and the max too). I'm basically proposing applying that model=
to
PC development, while still getting faster compile times.
j
-----Original Message-----
From: Skelton, Jeff [mailto:jsk...@ea...]
Sent: Monday, January 13, 2003 10:48 AM
To: gam...@li...
Subject: RE: [GD-General] IncrediBuild
Make sure there is no possibility that your programmers will ever have =
to
do
console work in the future ;)
Jeff
-----Original Message-----
From: Grills, Jeff [mailto:jg...@so...]
Sent: Monday, January 13, 2003 8:37 AM
To: 'gam...@li...'
Subject: RE: [GD-General] IncrediBuild
Too expensive? That's insane. The amount of programmer time it saves =
is
immense -- it pays for itself very rapidly. Besides, you don't need to=
upgrade programmer machines nearly so often, because compile times are =
much
faster. In fact, on the next project I lead, I'm going to push to leav=
e
all
the programmers on the minimum spec CPU machine, and use Incredibuild t=
o
keep them working efficiently.
j
-----Original Message-----
From: Emmanuel Astier [mailto:e_a...@ya...]
Sent: Monday, January 13, 2003 10:20 AM
To: gam...@li...
Subject: RE: [GD-General] IncrediBuild
I also used it for a project where compile times were
important ( more than 30 minutes for a complete
rebuild), and as we were quite a lot working on this
title, we had to make a 'rebuild all' quite often...
The gain was impressive ( around 4x / 5x faster ),
it's really easy to use, the interface is really nice.
We had some problems with some settings, but nothing
really important...
All the team wanted to buy it, but our manager said
the cost was too high. Gosh...
It was quite hard to get back to plain VC when the
test period ended...
Emmanuel
--- "Grills, Jeff" <jg...@so...> a =E9crit=A0: >
> We use it, and we couldn't live without it - it cuts
> our compile times in
> half or more. It only supports MSVC6, and right now
> we won't upgrade to
> MSVC7 until Incredbuild supports it properly. It
> also does a much better
> job of finding necessary dependencies that MSVC6.
> Sometimes a normal build
> will fail to link, or have runtime problems, but
> after doing an incredibuild
> all those issues go away.
>
> It has some problems with custom build steps. We
> have some projects that
> won't properly build with it (like any of our apps
> that use QT). But the
> majority of our code works well with it.
>
> I think, if we had less programmers on the team and
> could make sure they
> were more diligent reducing compile time
> dependencies, that it might not be
> as beneficial. But we're not in that situation, and
> the package is crucial
> to improving programmer workflow.
>
> Jeff Grills
> Technical Director, Austin Studio
> Star Wars Galaxies
> Sony Online Entertainment
>
> -----Original Message-----
> From: Gareth Lewin [mailto:GL...@cl...]
> Sent: Monday, January 13, 2003 6:57 AM
> To: Gamedevlists-General (E-mail)
> Subject: [GD-General] IncrediBuild
>
>
> I just saw IncrediBuild linked from flipcode, and
> wanted to know if anyone
> has used it ?
>
> (Hoping this isn't OT, but I know this list is
> fairly open, and discussions
> of speading up compile times is quite common even in
> SWeng )
>
> _____________________
> Regards, Gareth Lewin
>
>
>
-------------------------------------------------------
> 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=3D557
___________________________________________________________
Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en fran=E7ais ! Yah=
oo!
Mail : http://fr.mail.yahoo.com
-------------------------------------------------------
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=3D557
-------------------------------------------------------
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_idU7
-------------------------------------------------------
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_idU7
-------------------------------------------------------
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_idU7
=
|
|
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: Grills, J. <jg...@so...> - 2003-01-13 19:17:02
|
Well, I think my argument still holds. If you have programmers working on high end machines, and recommended machine specs are lower, I don't think the game usually ends up running well on the recommended machine. Put programmers (and all team members) on the machines that you want the game to run well on, whether that's the minimum or recommended, or something in between. And I in general agree that, the high end at the start of a project can be a good target machine when the game ships. j -----Original Message----- From: Nicolas Romantzoff [mailto:nic...@fr...] Sent: Monday, January 13, 2003 11:59 AM To: gam...@li... Subject: RE: [GD-General] IncrediBuild Depends on how you working... We, here, don't care about min. specs at all (which are usually considered as the worst case), we only care about recommended ones.. I do think that recommended specs should be (when the game actually goes on the shelfs) the average machine specs. For a one year dev, it means that recommended specs are one year "ahead" which are usually the current top specs. For a two years dev (like ours currently) this is more tricky, like targetting 40fps on a GeFX + Opteron, or 20fps on a Radeon9700+Athlon2800 But that's for PCs... Consoles are different story (I do personnaly hate consoles since they are by definition already outdated when coming out). Nicolas Romantzoff > -----Original Message----- > From: gam...@li... > [mailto:gam...@li...] On > Behalf Of Grills, Jeff > Sent: Monday, January 13, 2003 5:37 PM > To: 'gam...@li...' > Subject: RE: [GD-General] IncrediBuild > > > > Too expensive? That's insane. The amount of programmer time > it saves is immense -- it pays for itself very rapidly. > Besides, you don't need to upgrade programmer machines nearly > so often, because compile times are much faster. In fact, on > the next project I lead, I'm going to push to leave all the > programmers on the minimum spec CPU machine, and use > Incredibuild to keep them working efficiently. > |
|
From: Noel L. <ll...@co...> - 2003-01-13 19:11:10
|
On Mon, 13 Jan 2003 07:17:18 -0800 "Grills, Jeff" <jg...@so...> wrote: > I think, if we had less programmers on the team and could make sure they > were more diligent reducing compile time dependencies, that it might not be > as beneficial. But we're not in that situation, and the package is crucial > to improving programmer workflow. Having lots of compile-time dependencies is usually a much bigger problem than long compile times. Long compile times are just one of the manifestations of a deeper problem with how the program is architected. Ignoring the problem just because compile times are more bearable now does not seem like a good long-term solution, especially not with the code for a long-lived game like a MMORPG. The refactoring and maintenance costs you'll be paying in the long term will probably dwarf any extra time spent now making sure all programmers are minimizing dependencies. Then again, that's a lot easier said than done from this side of the keyboard ;-) --Noel ll...@co... |
|
From: Nicolas R. <nic...@fr...> - 2003-01-13 17:59:46
|
Depends on how you working... We, here, don't care about min. specs at all (which are usually considered as the worst case), we only care about recommended ones.. I do think that recommended specs should be (when the game actually goes on the shelfs) the average machine specs. For a one year dev, it means that recommended specs are one year "ahead" which are usually the current top specs. For a two years dev (like ours currently) this is more tricky, like targetting 40fps on a GeFX + Opteron, or 20fps on a Radeon9700+Athlon2800 But that's for PCs... Consoles are different story (I do personnaly hate consoles since they are by definition already outdated when coming out). Nicolas Romantzoff > -----Original Message----- > From: gam...@li... > [mailto:gam...@li...] On > Behalf Of Grills, Jeff > Sent: Monday, January 13, 2003 5:37 PM > To: 'gam...@li...' > Subject: RE: [GD-General] IncrediBuild > > > > Too expensive? That's insane. The amount of programmer time > it saves is immense -- it pays for itself very rapidly. > Besides, you don't need to upgrade programmer machines nearly > so often, because compile times are much faster. In fact, on > the next project I lead, I'm going to push to leave all the > programmers on the minimum spec CPU machine, and use > Incredibuild to keep them working efficiently. > |
|
From: Grills, J. <jg...@so...> - 2003-01-13 17:05:48
|
To elaborate more, I find that programmers stop optimizing when code performs acceptably on their machine. So, if their processors are 3 = times as fast as the min spec machine, you've got problems waiting to bite = you. Consoles solve that - you run the code on the console, which is the = min-spec machine (and the max too). I'm basically proposing applying that model = to PC development, while still getting faster compile times. j -----Original Message----- From: Skelton, Jeff [mailto:jsk...@ea...] Sent: Monday, January 13, 2003 10:48 AM To: gam...@li... Subject: RE: [GD-General] IncrediBuild Make sure there is no possibility that your programmers will ever have = to do console work in the future ;) Jeff -----Original Message----- From: Grills, Jeff [mailto:jg...@so...]=20 Sent: Monday, January 13, 2003 8:37 AM To: 'gam...@li...' Subject: RE: [GD-General] IncrediBuild Too expensive? That's insane. The amount of programmer time it saves = is immense -- it pays for itself very rapidly. Besides, you don't need to upgrade programmer machines nearly so often, because compile times are = much faster. In fact, on the next project I lead, I'm going to push to = leave all the programmers on the minimum spec CPU machine, and use Incredibuild = to keep them working efficiently. j -----Original Message----- From: Emmanuel Astier [mailto:e_a...@ya...] Sent: Monday, January 13, 2003 10:20 AM To: gam...@li... Subject: RE: [GD-General] IncrediBuild I also used it for a project where compile times were important ( more than 30 minutes for a complete rebuild), and as we were quite a lot working on this title, we had to make a 'rebuild all' quite often... The gain was impressive ( around 4x / 5x faster ), it's really easy to use, the interface is really nice. We had some problems with some settings, but nothing really important... All the team wanted to buy it, but our manager said the cost was too high. Gosh... It was quite hard to get back to plain VC when the test period ended... Emmanuel --- "Grills, Jeff" <jg...@so...> a =E9crit=A0: > > We use it, and we couldn't live without it - it cuts > our compile times in > half or more. It only supports MSVC6, and right now > we won't upgrade to > MSVC7 until Incredbuild supports it properly. It > also does a much better > job of finding necessary dependencies that MSVC6. > Sometimes a normal build > will fail to link, or have runtime problems, but > after doing an incredibuild > all those issues go away. >=20 > It has some problems with custom build steps. We > have some projects that > won't properly build with it (like any of our apps > that use QT). But the > majority of our code works well with it. >=20 > I think, if we had less programmers on the team and > could make sure they > were more diligent reducing compile time > dependencies, that it might not be > as beneficial. But we're not in that situation, and > the package is crucial > to improving programmer workflow. >=20 > Jeff Grills > Technical Director, Austin Studio > Star Wars Galaxies > Sony Online Entertainment > =20 > -----Original Message----- > From: Gareth Lewin [mailto:GL...@cl...] > Sent: Monday, January 13, 2003 6:57 AM > To: Gamedevlists-General (E-mail) > Subject: [GD-General] IncrediBuild >=20 >=20 > I just saw IncrediBuild linked from flipcode, and > wanted to know if anyone > has used it ? >=20 > (Hoping this isn't OT, but I know this list is > fairly open, and discussions > of speading up compile times is quite common even in > SWeng ) >=20 > _____________________ > Regards, Gareth Lewin >=20 >=20 > ------------------------------------------------------- > 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=20 > Gam...@li... > https://lists.sourceforge.net/lists/listinfo/gamedevlists-general > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_id=3D557=20 ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en fran=E7ais ! = Yahoo! Mail : http://fr.mail.yahoo.com ------------------------------------------------------- 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=3D557 ------------------------------------------------------- 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_idU7 ------------------------------------------------------- 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_idU7 |
|
From: Skelton, J. <jsk...@ea...> - 2003-01-13 16:48:23
|
Make sure there is no possibility that your programmers will ever have = to do console work in the future ;) Jeff -----Original Message----- From: Grills, Jeff [mailto:jg...@so...]=20 Sent: Monday, January 13, 2003 8:37 AM To: 'gam...@li...' Subject: RE: [GD-General] IncrediBuild Too expensive? That's insane. The amount of programmer time it saves = is immense -- it pays for itself very rapidly. Besides, you don't need = to upgrade programmer machines nearly so often, because compile times = are much faster. In fact, on the next project I lead, I'm going to push = to leave all the programmers on the minimum spec CPU machine, and use = Incredibuild to keep them working efficiently. j -----Original Message----- From: Emmanuel Astier [mailto:e_a...@ya...] Sent: Monday, January 13, 2003 10:20 AM To: gam...@li... Subject: RE: [GD-General] IncrediBuild I also used it for a project where compile times were important ( more than 30 minutes for a complete rebuild), and as we were quite a lot working on this title, we had to make a 'rebuild all' quite often... The gain was impressive ( around 4x / 5x faster ), it's really easy to use, the interface is really nice. We had some problems with some settings, but nothing really important... All the team wanted to buy it, but our manager said the cost was too high. Gosh... It was quite hard to get back to plain VC when the test period ended... Emmanuel --- "Grills, Jeff" <jg...@so...> a =E9crit=A0: > > We use it, and we couldn't live without it - it cuts > our compile times in > half or more. It only supports MSVC6, and right now > we won't upgrade to > MSVC7 until Incredbuild supports it properly. It > also does a much better > job of finding necessary dependencies that MSVC6. > Sometimes a normal build > will fail to link, or have runtime problems, but > after doing an incredibuild > all those issues go away. >=20 > It has some problems with custom build steps. We > have some projects that > won't properly build with it (like any of our apps > that use QT). But the > majority of our code works well with it. >=20 > I think, if we had less programmers on the team and > could make sure they > were more diligent reducing compile time > dependencies, that it might not be > as beneficial. But we're not in that situation, and > the package is crucial > to improving programmer workflow. >=20 > Jeff Grills > Technical Director, Austin Studio > Star Wars Galaxies > Sony Online Entertainment > =20 > -----Original Message----- > From: Gareth Lewin [mailto:GL...@cl...] > Sent: Monday, January 13, 2003 6:57 AM > To: Gamedevlists-General (E-mail) > Subject: [GD-General] IncrediBuild >=20 >=20 > I just saw IncrediBuild linked from flipcode, and > wanted to know if anyone > has used it ? >=20 > (Hoping this isn't OT, but I know this list is > fairly open, and discussions > of speading up compile times is quite common even in > SWeng ) >=20 > _____________________ > Regards, Gareth Lewin >=20 >=20 > ------------------------------------------------------- > 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=20 > Gam...@li... > https://lists.sourceforge.net/lists/listinfo/gamedevlists-general > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_id=3D557=20 ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en fran=E7ais ! = Yahoo! Mail : http://fr.mail.yahoo.com ------------------------------------------------------- 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=3D557 ------------------------------------------------------- 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_idU7 |
|
From: Grills, J. <jg...@so...> - 2003-01-13 16:43:16
|
I wrote a perl script that scans some project setting files and searches for source files, and generates a DSP from that. It works well for us. We can change a setting (such as RTTI) in one place, and regenerate all the DSPs in seconds. j -----Original Message----- From: Peter Lipson [mailto:pe...@to...] Sent: Monday, January 13, 2003 10:30 AM To: gam...@li... Subject: RE: [GD-General] Sharing DSP between static lib / DLL 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 ------------------------------------------------------- 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: Grills, J. <jg...@so...> - 2003-01-13 16:36:36
|
Too expensive? That's insane. The amount of programmer time it saves = is immense -- it pays for itself very rapidly. Besides, you don't need to upgrade programmer machines nearly so often, because compile times are = much faster. In fact, on the next project I lead, I'm going to push to = leave all the programmers on the minimum spec CPU machine, and use Incredibuild = to keep them working efficiently. j -----Original Message----- From: Emmanuel Astier [mailto:e_a...@ya...] Sent: Monday, January 13, 2003 10:20 AM To: gam...@li... Subject: RE: [GD-General] IncrediBuild I also used it for a project where compile times were important ( more than 30 minutes for a complete rebuild), and as we were quite a lot working on this title, we had to make a 'rebuild all' quite often... The gain was impressive ( around 4x / 5x faster ), it's really easy to use, the interface is really nice. We had some problems with some settings, but nothing really important... All the team wanted to buy it, but our manager said the cost was too high. Gosh... It was quite hard to get back to plain VC when the test period ended... Emmanuel --- "Grills, Jeff" <jg...@so...> a =E9crit=A0: > > We use it, and we couldn't live without it - it cuts > our compile times in > half or more. It only supports MSVC6, and right now > we won't upgrade to > MSVC7 until Incredbuild supports it properly. It > also does a much better > job of finding necessary dependencies that MSVC6.=20 > Sometimes a normal build > will fail to link, or have runtime problems, but > after doing an incredibuild > all those issues go away. >=20 > It has some problems with custom build steps. We > have some projects that > won't properly build with it (like any of our apps > that use QT). But the > majority of our code works well with it. >=20 > I think, if we had less programmers on the team and > could make sure they > were more diligent reducing compile time > dependencies, that it might not be > as beneficial. But we're not in that situation, and > the package is crucial > to improving programmer workflow. >=20 > Jeff Grills > Technical Director, Austin Studio > Star Wars Galaxies > Sony Online Entertainment > =20 > -----Original Message----- > From: Gareth Lewin [mailto:GL...@cl...] > Sent: Monday, January 13, 2003 6:57 AM > To: Gamedevlists-General (E-mail) > Subject: [GD-General] IncrediBuild >=20 >=20 > I just saw IncrediBuild linked from flipcode, and > wanted to know if anyone > has used it ? >=20 > (Hoping this isn't OT, but I know this list is > fairly open, and discussions > of speading up compile times is quite common even in > SWeng ) >=20 > _____________________ > Regards, Gareth Lewin >=20 >=20 > ------------------------------------------------------- > 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=20 > 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=3D557=20 ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en fran=E7ais ! Yahoo! Mail : http://fr.mail.yahoo.com ------------------------------------------------------- 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=3D557 |
|
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: <e_a...@ya...> - 2003-01-13 16:19:42
|
I also used it for a project where compile times were important ( more than 30 minutes for a complete rebuild), and as we were quite a lot working on this title, we had to make a 'rebuild all' quite often... The gain was impressive ( around 4x / 5x faster ), it's really easy to use, the interface is really nice. We had some problems with some settings, but nothing really important... All the team wanted to buy it, but our manager said the cost was too high. Gosh... It was quite hard to get back to plain VC when the test period ended... Emmanuel --- "Grills, Jeff" <jg...@so...> a écrit : > > We use it, and we couldn't live without it - it cuts > our compile times in > half or more. It only supports MSVC6, and right now > we won't upgrade to > MSVC7 until Incredbuild supports it properly. It > also does a much better > job of finding necessary dependencies that MSVC6. > Sometimes a normal build > will fail to link, or have runtime problems, but > after doing an incredibuild > all those issues go away. > > It has some problems with custom build steps. We > have some projects that > won't properly build with it (like any of our apps > that use QT). But the > majority of our code works well with it. > > I think, if we had less programmers on the team and > could make sure they > were more diligent reducing compile time > dependencies, that it might not be > as beneficial. But we're not in that situation, and > the package is crucial > to improving programmer workflow. > > Jeff Grills > Technical Director, Austin Studio > Star Wars Galaxies > Sony Online Entertainment > > -----Original Message----- > From: Gareth Lewin [mailto:GL...@cl...] > Sent: Monday, January 13, 2003 6:57 AM > To: Gamedevlists-General (E-mail) > Subject: [GD-General] IncrediBuild > > > I just saw IncrediBuild linked from flipcode, and > wanted to know if anyone > has used it ? > > (Hoping this isn't OT, but I know this list is > fairly open, and discussions > of speading up compile times is quite common even in > SWeng ) > > _____________________ > Regards, Gareth Lewin > > > ------------------------------------------------------- > 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 ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com |
|
From: Grills, J. <jg...@so...> - 2003-01-13 15:17:22
|
We use it, and we couldn't live without it - it cuts our compile times in half or more. It only supports MSVC6, and right now we won't upgrade to MSVC7 until Incredbuild supports it properly. It also does a much better job of finding necessary dependencies that MSVC6. Sometimes a normal build will fail to link, or have runtime problems, but after doing an incredibuild all those issues go away. It has some problems with custom build steps. We have some projects that won't properly build with it (like any of our apps that use QT). But the majority of our code works well with it. I think, if we had less programmers on the team and could make sure they were more diligent reducing compile time dependencies, that it might not be as beneficial. But we're not in that situation, and the package is crucial to improving programmer workflow. Jeff Grills Technical Director, Austin Studio Star Wars Galaxies Sony Online Entertainment -----Original Message----- From: Gareth Lewin [mailto:GL...@cl...] Sent: Monday, January 13, 2003 6:57 AM To: Gamedevlists-General (E-mail) Subject: [GD-General] IncrediBuild I just saw IncrediBuild linked from flipcode, and wanted to know if anyone has used it ? (Hoping this isn't OT, but I know this list is fairly open, and discussions of speading up compile times is quite common even in SWeng ) _____________________ Regards, Gareth Lewin |
|
From: Ivan-Assen I. <as...@ha...> - 2003-01-13 13:05:49
|
We tried it, it works. However, I don't think it can justify its cost, so we didn't buy it. There's a problem if you have custom build steps, since it can't distribute them, and support for VS.NET is |
|
From: Gareth L. <GL...@cl...> - 2003-01-13 12:57:10
|
I just saw IncrediBuild linked from flipcode, and wanted to know if anyone has used it ? (Hoping this isn't OT, but I know this list is fairly open, and discussions of speading up compile times is quite common even in SWeng ) _____________________ Regards, Gareth Lewin |
|
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: 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: 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: 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: Gareth L. <GL...@cl...> - 2003-01-07 11:13:44
|
Hello. Has anyone tried to implement FUBI on a non-MS platform ? We already have it working nice and dandy on the xbox and win32. Now I haven't started looking at the PS/2 ( or NGC ) yet, and will be doing that real soon, but was wondering if anyone else has done it yet ? _____________________ Regards, Gareth Lewin |
|
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: <phi...@pl...> - 2003-01-06 20:42:19
|
"Grills, Jeff" <jg...@so...>: > GCC's code gen for this stuff is apparently a fair bit better. I had a brief look at this, with the view to potentially replacing some hand-rolled RTTI that had caused some minor bugs (the problem with hand-rolled RTTI is entirely one of maintenance). IIRC, my only gripe with GCC was that it kept the RTTI tables seperate from the vtables. Although I'm sure there's a good reason for this, it was going to add yet another potential cache miss, and so out it went. I don't think I even looked at the dynamic_cast code, as I was just going to be comparing types. Although I'm now tempted to turn it on in debug builds, to assert the hand-rolled RTTI is working. Cheers, Phil |
|
From: <phi...@pl...> - 2003-01-06 20:09:20
|
Bob <ma...@mb...>: > For the pirate it's easy warez on someone else's bandwidth, and for the cracker it is something akin to fixing an annoying bug For the cracker, it's often more fun removing the copy protection, than playing the game itself. Cheers, Phil |
|
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: 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: <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 |
12 messages has been excluded from this view by a project administrator.
