Posted: 21 May 2007, 17:06
They desync with linux builds and with the official release build.Caydr wrote:They desync period, of they desync with linux builds?Tobi wrote:They desync.
Spring RTS Engine
Open Source Realtime Strategy Game Engine
https://springrts.com/phpbb/
Evidence of major performance increase in new version(?) 56k
Page 2 of 2
Posted: 21 May 2007, 17:09
I know I'm biased since I don't use linux, but a 40% performance difference just for compatibility seems unreasonable when the majority of players use Windows.
This would be a nightmare to develop for probably, but maybe there could be a Windows-only version, just for people with slow computers? Maybe some autodetect in the lobby, where if all players in a game have Windows, it uses the VS build? People would be confused by the inconsistent performance, but for a lot of people here, 40% FPS increase would be the difference between being able to run refractive water, shadows, and reflective units or not. Or, just being able to participate in larger games with more players/units.
How many games have you been in where one or two players with crappy computers slow down a large game? That could be largely elminated with a 40% efficiency boost.
This would be a nightmare to develop for probably, but maybe there could be a Windows-only version, just for people with slow computers? Maybe some autodetect in the lobby, where if all players in a game have Windows, it uses the VS build? People would be confused by the inconsistent performance, but for a lot of people here, 40% FPS increase would be the difference between being able to run refractive water, shadows, and reflective units or not. Or, just being able to participate in larger games with more players/units.
How many games have you been in where one or two players with crappy computers slow down a large game? That could be largely elminated with a 40% efficiency boost.
Posted: 21 May 2007, 17:12
If the Visual Studio version causes desyncs then that means replays would also be broken / desynced across versions. I don't think anyone wants to switch to a system which breaks replay compatibility across platforms.This would be a nightmare to develop for probably, but maybe there could be a Windows-only version, just for people with slow computers?
Posted: 21 May 2007, 18:08
All the active devs (tvo + trepan) are using linux, so dropping linux compat is not really going to happen i think.
And optimizations are always relative... if you wait long enough it will be less and less a problem because of improving hardware
Especially with cpu-killing supcom as a competitor, i think dont think its really an issue.
And optimizations are always relative... if you wait long enough it will be less and less a problem because of improving hardware
Especially with cpu-killing supcom as a competitor, i think dont think its really an issue.
Posted: 21 May 2007, 18:40
hmmm that really does suck....
KEEP TO LAMP! No more games!
KEEP TO LAMP! No more games!
Posted: 21 May 2007, 20:23
Why not make code that isn't affected by something so trivial?
Stuff seems to desync ridiculously easily.
God damn linuxfags :C
Stuff seems to desync ridiculously easily.
God damn linuxfags :C
Posted: 21 May 2007, 20:26
Congratulations, you fail. Cross-platform compatibility is one of the things that is nearly unique to spring, as a modern RTS.tooleh wrote:Why not make code that isn't affected by something so trivial?
Stuff seems to desync ridiculously easily.
God damn linuxfags :C
Posted: 21 May 2007, 20:36
It isnt linux that causes it, its a multimillion dollar budget at microsoft R&D that does it.
Nobody has really tested VC++ builds save me who tried once and found it crashed when playing the mingw32 builds as soon as the game started, presumably caused by the checks spring does that peopel keep mentioning when they talk about cheating using modified binaries.
Nobody has really tested VC++ builds save me who tried once and found it crashed when playing the mingw32 builds as soon as the game started, presumably caused by the checks spring does that peopel keep mentioning when they talk about cheating using modified binaries.
Posted: 21 May 2007, 21:09
Besides that, a release VS8 build of trunk crashes while loading unit and weapons (SmallDivide, XTA 8.1), and the debug build runs fine at about 20% of the performance of MinGW.
Either way, as JC suggested, there's no discussion about the release compiler vendor possible anyway
(can just argue 'bout the GCC version )
(But I may take a look at enabling somewhat more optimization, at the expense of features and bug fixes of course)
Oh, and tooleh fails indeed
EDIT: k it runs fine with war evolution. Now tested MinGW build and VS8 build on Small Divide doing nothing, camera at default position I get ~82 FPS in VS8 build, 62 FPS in MinGW build. Pressed tab once to zoom out to full map view, then the FPS reduced to ~44 FPS in VS8 build and ~47 FPS in MinGW build, So depending on the situation a VS build is 6% slower to 32% faster, which indicates (as I expected) that 40% is exaggerated: I get an average of 13% FPS increase.
Either way, as JC suggested, there's no discussion about the release compiler vendor possible anyway
(can just argue 'bout the GCC version )(But I may take a look at enabling somewhat more optimization, at the expense of features and bug fixes of course
)Oh, and tooleh fails indeed
EDIT: k it runs fine with war evolution. Now tested MinGW build and VS8 build on Small Divide doing nothing, camera at default position I get ~82 FPS in VS8 build, 62 FPS in MinGW build. Pressed tab once to zoom out to full map view, then the FPS reduced to ~44 FPS in VS8 build and ~47 FPS in MinGW build, So depending on the situation a VS build is 6% slower to 32% faster, which indicates (as I expected) that 40% is exaggerated: I get an average of 13% FPS increase.
Posted: 21 May 2007, 21:24
That may indeed be cause for concern, if only to increase engine stability and reliability. The fact it crashes under release but not under debug suggests that its pointer related.
Perhaps it would be best modifying release builds to include at least line numbers rather than full debugging databases, that should yield much more information.
Perhaps it would be best modifying release builds to include at least line numbers rather than full debugging databases, that should yield much more information.
Posted: 21 May 2007, 21:57
Haha, I like linux, I have a ubuntu partition somewhere. Learn to take a joke, linuxfags ^_^
But surely if the syncing system is this fragile, something has been done wrong?
I can understand different versions of the program having issues, but different compiles?
But surely if the syncing system is this fragile, something has been done wrong?
I can understand different versions of the program having issues, but different compiles?
Posted: 21 May 2007, 22:42
different handling of uninitialized variables and pointer arithmetic bugs, for example. coding large projects in c++ ain't easy.
Posted: 21 May 2007, 22:43
should have been coded in python tbh
Posted: 21 May 2007, 23:09
actually, eiffel :D
Posted: 21 May 2007, 23:21
iirc its to do with the lengths of variables and how memory is handled by different binaries from different compilers?
Posted: 22 May 2007, 00:25
HHSSS HSSSSSS HSS!!Dragon45 wrote:should have been coded in python tbh
Posted: 22 May 2007, 01:42
Yeah...interpreted lanuages are epic win when it comes to 3d games...Hell, let's do it in qBasic!Muzic wrote:HHSSS HSSSSSS HSS!!Dragon45 wrote:should have been coded in python tbh
Posted: 22 May 2007, 02:00
Posted: 22 May 2007, 07:31
ftw
