Spring 93.0

[Senna]

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

[abma]

@Senna:

can you please make a dedicated thread about your problem?!

[Silentwings]

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.

[zerver]

RAI

Got a crash about 15min mark, just locked up using MT

http://pastebin.com/7yvLmuap

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...

https://github.com/spring/spring/commit ... 128a683bb1

[albator]

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 )

[varikonniemi]

RAI

Got a crash about 15min mark, just locked up using MT

http://pastebin.com/7yvLmuap

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...

https://github.com/spring/spring/commit ... 128a683bb1

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.

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?

[jK]

@zerver
if it is a compiler bug why is then only GML affected?

[zerver]

@zerver
if it is a compiler bug why is then only GML affected?

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]

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.

[dansan]

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.

[jamerlan]

>>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.

[Jools]

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.

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.

[smoth]

+1

[Anarchid]

"fail fast, fail deadly, leave a pretty corpse stable"

[Silentwings]

+1, progress - mistakes > 0

[SinbadEV]

maybe we could just call these "Release Candidate" builds until they are "live"? Potentially reduce confusion?

[jamerlan]

maybe we could just call these "Release Candidate" builds until they are "live"? Potentially reduce confusion?

I guess that no much people have motivation to test yet another RC or Test build

[zerver]

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.

MT uses http://www.kevinjhoffman.com/speedy-tls/

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).

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.

[jK]

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.

http://gcc.gnu.org/onlinedocs/gcc-4.4.2 ... tions.html

-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.

-> gcc can make sure the address is aligned, but the thread base pointer is NOT -> aligned + unaligned = misaligned