Spring 93.0
Re: Spring 93.0
jk it wont even launch, have all settings in off, when i double click the spring.exe on launch crash, it says has ocurred 1 error, spring.exe need to be closed. dont even go in menu
Re: Spring 93.0
@Senna:
can you please make a dedicated thread about your problem?!
can you please make a dedicated thread about your problem?!
- Silentwings
- Posts: 3720
- Joined: 25 Oct 2008, 00:23
Re: Spring 93.0
Just did some more tests with this and didn't find any bugs beyond whats already mantised. Collision handling seems to have changed and I like the new settings a lot.
Re: Spring 93.0
I cannot be 100% sure that this is solved, because AFAIK this bug is caused by the compiler (GCC), and it keeps coming back almost every release affecting some random function. Anyway I tried...Jonny5isalivetm wrote:RAI
Got a crash about 15min mark, just locked up using MT
http://pastebin.com/7yvLmuap
https://github.com/spring/spring/commit ... 128a683bb1
Re: Spring 93.0
1500 fighters, speed x20, fighter dont patrol, but move, still fluid with 30 fps (with MT on my old i5 ofc :D), but i got a packet error thingy.
Plus some (tenth of percents - i.e. hundreds - some times more) of the fighters disappear and reappear some where else without getting any freezes (within a few tenth of second). That is kind of hardcore conditions but i want to make it notice.
http://pastebin.com/YW5gLUYq
For the record, I noticed that packet error already on 0.91 or one before I do not remember, when i played some game with truly about 2000 planes. At that time I was told my connection was the problem, but here I test the game on local machine.
(mint 14 cinnamon x64, i750, NVIDIA serie5 card )
Plus some (tenth of percents - i.e. hundreds - some times more) of the fighters disappear and reappear some where else without getting any freezes (within a few tenth of second). That is kind of hardcore conditions but i want to make it notice.
http://pastebin.com/YW5gLUYq
For the record, I noticed that packet error already on 0.91 or one before I do not remember, when i played some game with truly about 2000 planes. At that time I was told my connection was the problem, but here I test the game on local machine.
(mint 14 cinnamon x64, i750, NVIDIA serie5 card )
-
- Posts: 451
- Joined: 03 Jul 2011, 11:54
Re: Spring 93.0
How often do you fight compiler bugs? I cannot imagine anything more frustrating than debug code and then discover the problem lying in the compiler.zerver wrote:I cannot be 100% sure that this is solved, because AFAIK this bug is caused by the compiler (GCC), and it keeps coming back almost every release affecting some random function. Anyway I tried...Jonny5isalivetm wrote:RAI
Got a crash about 15min mark, just locked up using MT
http://pastebin.com/7yvLmuap
https://github.com/spring/spring/commit ... 128a683bb1
This is why all projects should be made to compile every release on at least two compilers...
Also: what is now the reason for delaying 93 going online?
Re: Spring 93.0
@zerver
if it is a compiler bug why is then only GML affected?
if it is a compiler bug why is then only GML affected?
Re: Spring 93.0
Probably because it is compiled with different compiler flags. Another interesting thing is that some processors tolerate this misaligned data and don't crash.jK wrote:@zerver
if it is a compiler bug why is then only GML affected?
Re: Spring 93.0
Is "-mno-tls-direct-seg-refs" really needed? It is the cause of your misaligned accesses and no it's not a bug in gcc, they are a direct consequence of this tag.
Re: Spring 93.0
The only use I am aware of for "-mno-tls-direct-seg-refs" is for 32bit Xen users. They get a big performance penalty without it.
Re: Spring 93.0
>>PS: It was my fault that 92.0 was broken and never went live. Sorry everyone :)
I think it is not bad at all! Suits "release often" rule. Good to have only tested and stable releases online and development releases for testing new features / prepearing your games / find bugs etc. Also, community likes to see progress.
I think it is not bad at all! Suits "release often" rule. Good to have only tested and stable releases online and development releases for testing new features / prepearing your games / find bugs etc. Also, community likes to see progress.
Re: Spring 93.0
Agree with this. And of course there is a correlation with the amount of work you accomplish and the amount of errors you make. Only way to not make errors is to not do anything.jamerlan wrote:
I think it is not bad at all! Suits "release often" rule. Good to have only tested and stable releases online and development releases for testing new features / prepearing your games / find bugs etc. Also, community likes to see progress.
Re: Spring 93.0
"fail fast, fail deadly, leave a pretty corpse stable"
Re: Spring 93.0
maybe we could just call these "Release Candidate" builds until they are "live"? Potentially reduce confusion?
Re: Spring 93.0
I guess that no much people have motivation to test yet another RC or Test buildSinbadEV wrote:maybe we could just call these "Release Candidate" builds until they are "live"? Potentially reduce confusion?
Re: Spring 93.0
MT uses http://www.kevinjhoffman.com/speedy-tls/jK wrote:Is "-mno-tls-direct-seg-refs" really needed? It is the cause of your misaligned accesses and no it's not a bug in gcc, they are a direct consequence of this tag.
I don't see how tls is related to misaligned data, unless GCC has a bug. The flag just tells GCC not to touch the fs register, so it has to solve any thread local storage it needs internally through some other means.The library relies on exclusive use of either the FS register (32-bit) or GS register (64-bit). Make sure that GCC does not interfere (use the -mno-tls-direct-seg-refs GCC option).
Re: Spring 93.0
http://gcc.gnu.org/onlinedocs/gcc-4.4.2 ... tions.htmlzerver wrote:I don't see how tls is related to misaligned data, unless GCC has a bug. The flag just tells GCC not to touch the fs register, so it has to solve any thread local storage it needs internally through some other means.
-> gcc can make sure the address is aligned, but the thread base pointer is NOT -> aligned + unaligned = misaligned-mtls-direct-seg-refs
-mno-tls-direct-seg-refs
Controls whether TLS variables may be accessed with offsets from the TLS segment register (%gs for 32-bit, %fs for 64-bit), or whether the thread base pointer must be added. Whether or not this is legal depends on the operating system, and whether it maps the segment to cover the entire TLS area.
For systems that use GNU libc, the default is on.