News:

Simutrans Tools
Know our tools that can help you to create add-ons, install and customize Simutrans.

120.1.2 release crash on Win 10

Started by DrSuperGood, January 07, 2016, 06:15:52 AM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

DrSuperGood

Cannot get new Windows GDI build to run on Windows 10. It crashes at startup. Applies to both GDI and SDL.
Exception thrown is "Access violation reading location 0xFFFFFFFF". Cannot debug due to lack of tables.

My self-build of 120-1-2 does work but cannot enter fullscreen mode. It is stuck in windowed mode and appears to ignore all "fullscreen" definitions. My self-build of 120-1-1 does support fullscreen.

EDIT. To summarize.
Official Windows 120-1-2 release is broken and does not work. It crashes before the pak selection screen. This applies to at least Windows 10.
Official Windows 120-1-1 release works.
Self-build (MSVC 2015) Windows 120-1-2 works except for fullscreen which is completely ignored (forced to play in windowed mode).
Self-build (MSVC 2015) Windows 120-1-1 works.

EDIT2.
Self-build (MSVC 2015) Windows 120-1-2 full screen appears to be stretch the window to approximately the appropriate size but not actually fill the entire screen (as if it forces the output method used to fit into a window). Official release builds still crash with fullscreen disabled.

EDIT3.
ChangeDisplaySettings seems to be failing and so turning off fullscreen.

And here is the reason.
Quote
Note  Apps that you design to target Windows 8 and later can no longer query or set display modes that are less than 32 bits per pixel (bpp); these operations will fail. These apps have a compatibility manifest that targets Windows 8. Windows 8 still supports 8-bit and 16-bit color modes for desktop apps that were built without a Windows 8 manifest; Windows 8 emulates these modes but still runs in 32-bit color mode.
You added a Windows 8 compatible manifest recently ("Added highres-aware manifest (Ters)") to Simutrans. Hence it cannot use 16-bit colour mode anymore when run on Windows 8 or latter operating systems.

Fortunately the solution seems simple enough. Just initialize to 32bit colour mode, after all Windows 8 and newer emulate 16bit colour in 32bit colour mode anyway. By hard-coding in "settings.dmBitsPerPel = 32;" full screen worked and there were no noticeable colour bugs. Setting the colour macro to "32" does cause glitched out graphics but still full screens.

This does not solve the official build crashing though, but at least my self-builds are now working properly.

Dwachs

Split this post from the original thread and moved to Bug reports section to catch attention.
Parsley, sage, rosemary, and maggikraut.

Martinwh1

Yes I have the same problem - I just get "Simutrans.exe has stopped working"

TurfIt

I guess then we throw the manifest in the trash, and everyone with scrolling issues will have to manually disable the DPI scaling themselves sine the installer cannot do it. Any other ideas?  32 bit is a non-starter...

DrSuperGood

#4
Quote
I guess then we throw the manifest in the trash, and everyone with scrolling issues will have to manually disable the DPI scaling themselves sine the installer cannot do it. Any other ideas?  32 bit is a non-starter...
The manifest is not a problem, at least for building with MSVC (although it does need some hacking around to work). It is a problem for one part of the code because that code is not compliant with the modern API, which the manifest states it should be.

If you take the display in 32bit colour mode keeping the rest of the code working in 16bit colour mode then full screen works perfectly (fullscreen, correct colours and scale). How this still works I am not sure, just from a hands on test it does. Setting colour mode to 32bit in the compiler option does not work as it causes garbage graphics, this is probably some issue people should look into at some stage.

So what does one do? Try 16bit display mode and if that test fails then try 32bit display mode. On Windows 8 and newer the 16bit test will fail (does not support 16 bit mode) however the 32bit test will pass (does support 32 bit mode). There are likely no performance implications to this either since Windows 8 and newer emulate 16bit colour using 32bit colour internally and the game should still be using 16bit colour logic.

I am not even sure why you are trying to change display mode... The content is being rendered to a Window right? Surely the Window will work no matter the display mode? I can imagine old OSes gaining performance from the 16bit mode, however on newer OSes it should make no difference (runs in 32bit output anyway).

Currently it appears what happens is that the graphics rasterizer creates a bitmap which is then painted onto the window periodically. The process of "painting" should convert the 16bit colour space into whatever colour space the window is in. As such it is not necessary to change display mode to 16bit when working in fullscreen as it will be translated to whatever colour space is currently in use.

I hopefully have a patch ready for this which takes a more relaxed approach to fullscreen which should make it compatible with Windows 8. I have not tested it yet so I am holding back posting it until later. This patch will try to force the display to the specified resolution (should be current anyway based on how it is fetched) and only change color depth if color depth is less than the built color depth (to assure decent colour quality).

This has nothing to do with why the official release builds crash. Something is wrong with the build or there is an ambiguous requirement. MSVC builds of 120-1-2 do work.

Ters

#5
Another case of what having many settings does: It's impossible to test them all.

And I never thought the manifest would exclude some functionality when the manifest says the application is intended for OSes supporting that functionality as well.

Quote from: DrSuperGood on January 07, 2016, 03:13:45 PM
I am not even sure why you are trying to change display mode... The content is being rendered to a Window right? Surely the Window will work no matter the display mode? I can imagine old OSes gaining performance from the 16bit mode, however on newer OSes it should make no difference (runs in 32bit output anyway).

You can't run, say, a 1024x768 window in fullscreen unless the display mode is 1024x768. The way Simutrans ensures that the display mode 1024x768 is to tell Windows to switch to it. And it's easier to also request the bit depth Simutrans uses anyway, rather than query what the bit depth is now and figure out if it's good enough (when that code was written, someone running Windows in high-res 8-bit and games in 16-bit low-res might actually have been something to worry about). Running the screen at the same bit depth would avoid the cost of conversion, which pre-compositing would have to be done on the CPU.

Edit:
By the way, -fullscreen didn't actually change display mode for me long before the manifest was introduced. An executable I have from September exhibit the same behavior as DrSuperGood reports for "Self-build (MSVC 2015) Windows 120-1-2".

DrSuperGood

Quote
And I never thought the manifest would exclude some functionality when the manifest says the application is intended for OSes supporting that functionality as well.
It usually is not a problem. In a proper game it should only disable the 16 bit and 8 bit colour modes from the colour mode selection display option. The problem is that Simutrans display modes are not being flexible and are requiring something that should not really be required in the first place (only recommended).

Quote
You can't run, say, a 1024x768 window in fullscreen unless the display mode is 1024x768. The way Simutrans ensures that the display mode 1024x768 is to tell Windows to switch to it.
Except that is not what is happening. Simutrans fetches the current display resolution from the environment and tries to change the display mode to that display setting at 16bit. This means it does not actually resize the display when in fullscreen as it sets it to the same resolution it is currently.

Quote
And it's easier to also request the bit depth Simutrans uses anyway, rather than query what the bit depth is now and figure out if it's good enough (when that code was written, someone running Windows in high-res 8-bit and games in 16-bit low-res might actually have been something to worry about).
Yes it certainly is easier! It saved a 15 minutes of coding and caused 2 hours odd of searching and learning for the problem.

Quote
Running the screen at the same bit depth would avoid the cost of conversion, which pre-compositing would have to be done on the CPU.
Except that is no longer possible on modern operating systems starting with Windows 8. Even before the manifest broke it, Windows 8, 8.1 and 10 were already running the game in 32bit colour mode so the conversions were already happening.

Quote
By the way, -fullscreen didn't actually change display mode for me long before the manifest was introduced. An executable I have from September exhibit the same behavior as DrSuperGood reports for "Self-build (MSVC 2015) Windows 120-1-2".
The command has always been a bit iffy to use. I usually use the simuconfig approach. Not sure what broke it but I believe the following patch fixes it.

Ters

Quote from: DrSuperGood on January 07, 2016, 05:04:04 PM
Except that is not what is happening. Simutrans fetches the current display resolution from the environment and tries to change the display mode to that display setting at 16bit. This means it does not actually resize the display when in fullscreen as it sets it to the same resolution it is currently.

You can specify otherwise with the -screensize argument.

Quote from: DrSuperGood on January 07, 2016, 05:04:04 PM
Windows 8, 8.1 and 10 were already running the game in 32bit colour mode so the conversions were already happening.

Isn't compositing always on from Windows 8 onwards, so the conversion is hardware accelerated? Unless graphics cards have stopped supporting 16-bit textures, that is. If you run Simutrans on older OSes and have the display mode set to 32-bit, they will run slow (whether it is too slow will vary), which is probably what the -fullscreen option is there to compensate for, by switching to 16-bit display mode. The -fullscreen option is less useful on newer machines, although it can still get rid of the task bar and title bar for those who like the extra height that gives (which is actually more an issue on modern wide-screens).

DrSuperGood

Quote
You can specify otherwise with the -screensize argument.
Not as far as I can tell. It just specifies the default window size when running in windowed mode (same as the setting in simuconfig). In any case that is not the problem as the patch should preserve this behaviour.

Quote
you run Simutrans on older OSes and have the display mode set to 32-bit, they will run slow (whether it is too slow will vary), which is probably what the -fullscreen option is there to compensate for, by switching to 16-bit display mode.
After my patch users will unfortunately have to manually downgrade to 16bit colour if performance is a problem. Perhaps a separate option is needed "fs16bit" (full screen 16 bit colour) which forces 16 bit colour when fullscreen.

Quote
The -fullscreen option is less useful on newer machines, although it can still get rid of the task bar and title bar for those who like the extra height that gives (which is actually more an issue on modern wide-screens).
I like playing games in full screen mode. It removes distractions. I have always played games in full screen mode when possible.

There is still the issue of why the release builds are broken. The game works perfectly when built with MSVC but the way they were built for the release (looks like GCC?) does not work.

Dwachs

@DrSuperGood: should the check

// create window
if (fullscreen)

be changed to

// create window
if (is_fullscreen)

?
Parsley, sage, rosemary, and maggikraut.

Ters

#10
Quote from: DrSuperGood on January 07, 2016, 05:35:44 PM
There is still the issue of why the release builds are broken. The game works perfectly when built with MSVC but the way they were built for the release (looks like GCC?) does not work.

My GCC builds also work, although I am a few revisions behind. I do have some local modifications, however, one of which is necessary to avoid crashes when using the newest mingw-runtime, but which is incompatible with MSVC (and possibly even other versions of mingw). The crash I used to get was at address 0x0, though. And the nightlies seem to work, and they are built using some kind of mingw according to a build log I once saw.

Update:
Although it doesn't explain why it crashes so far, the instruction the executable in simuwin-120-1-2 crashes on for me, is an instruction that I don't think should be there. The instruction is too new for our minumum system requirements. The instruction is only available on Pentium 4, and sometime later for AMDs CPUs, while Simutrans is supposed to support Pentium II or III (actually some slightly newer AMDs that lagged behind on SSE2 support).

DrSuperGood

Quote
@DrSuperGood: should the check
I did not write that part. I think it is correct since is_fullscreen is set by the results from fullscreen computed there. When it fails to initialize the display mode druing full screen initialization it turns off fullscreen.

Quote
My GCC builds also work, although I am a few revisions behind. I do have some local modifications, however, one of which is necessary to avoid crashes when using the newest mingw-runtime, but which is incompatible with MSVC (and possibly even other versions of mingw). The crash I used to get was at address 0x0, though. And the nightlies seem to work, and they are built using some kind of mingw according to a build log I once saw.
The nightly build of the release also works fine for me, although full screen is broken (just like mine was, probably will be fixed with my patch).

It is just whatever made the executable that is marked as the Windows release for 120-1-2 is broken. The executable instantly crashes on startup, not even throwing an error code (I had to debug to find that). Since I lack the appropriate tables I cannot find out where the crash is happening. It looks like it crashes after the window is initialized (again, incorrectly as it is not fullscreen due to the issue my patch should fix) but more than that is hard to tell without spending hours looking at assembly code.

TurfIt

For now I'm just rereleasing the Windows 120.1.2 files without the manifest.

Does your MSVC build use this manifest that was added?
You mention GDI and SDL - both work for you with MSVC? SDL2?
I'll get back to 32vs16 after...


Quote from: Ters on January 07, 2016, 07:59:48 PM
And the nightlies seem to work, and they are built using some kind of mingw according to a build log I once saw.
I understand the nightlies are now MSVC sine the move the the OTTD farm.


Quote from: Ters on January 07, 2016, 07:59:48 PM
Although it doesn't explain why it crashes so far, the instruction the executable in simuwin-120-1-2 crashes on for me, is an instruction that I don't think should be there. The instruction is too new for our minumum system requirements. The instruction is only available on Pentium 4, and sometime later for AMDs CPUs, while Simutrans is supposed to support Pentium II or III (actually some slightly newer AMDs that lagged behind on SSE2 support).
We had discussed and decided quite some time ago Pentium 4 was to be the min target. Hence I compiled to that target. Doing so enables the first SSE instructions and results in a good speed boost. Requiring even newer CPUs did not result in any significant further gains. That may be different not with newer compilers finally being able to make effective use of the newer instructions and should be reassessed.

DrSuperGood

Quote
Does your MSVC build use this manifest that was added?
Yes it does use it. I had to disable the linker build manifest though as that caused a manifest ID collision. Once that was turned off the build worked perfectly, except for the fullscreen bug due to 16bit colour support being dropped.

Quote
You mention GDI and SDL - both work for you with MSVC? SDL2?
Only tested GDI with the MSVC build and that works. As a rough guess SDL and SDL2 will work (although SDL2 has performance issues when loading content, as reported before) but I did not test them as there is no need (I am not even sure what the point is to offering a SDL build for Windows as performance is near identical to GDI from personal experience). The versions provided as the release builds for GDI and SDL both crashed at the exact same point (after window is created, before pakset list is shown) so it is something with the build and not the graphics API.

TurfIt

Can someone try https://drive.google.com/file/d/0B-XmYgbe1q5YLWNJbnJseVdOTzA/view?usp=sharing
GDI build, only difference is removing the manifest. Might as well test if that's it, if it's not, I don't know.
Obviously I can run it fine locally, but I only have access to Win7.
sim.exe is just the unstripped version.

Ters

Quote from: TurfIt on January 07, 2016, 08:23:34 PM
I understand the nightlies are now MSVC sine the move the the OTTD farm.

So did prissi, so he was also a bit surprised when I pointed out that the build log definately looked like GCC. I don't have the URL for the nightly build logs. I don't even know if it was the nightly build logs I once found, or if it was some other build server used by the community.

Quote from: TurfIt on January 07, 2016, 08:23:34 PM
We had discussed and decided quite some time ago Pentium 4 was to be the min target. Hence I compiled to that target. Doing so enables the first SSE instructions and results in a good speed boost. Requiring even newer CPUs did not result in any significant further gains. That may be different not with newer compilers finally being able to make effective use of the newer instructions and should be reassessed.
I remember we talked about Pentium 4, but that it still crashed for somebody, so the persons doing the nightlies back then went back further. That made it work for everybody.

In any case, the SSE2 instruction I get crashes on appears to attempt to read unaligned memory, which it is not capable of. Similar to what happenes in the ALIGN_COPY code in simgraph16.cc when GCC tries to vector optimize it. (Which is why I argued for the simple memcpy, which was vector optimized correctly.)

simuwin-120-1-2b crashes for me as well. It crashes at simgraph16.cc:5099 according to GDB.

TurfIt

#16
Well this is not fun...
What CPU do you have? What OS?
Try https://drive.google.com/file/d/0B-XmYgbe1q5YMTl2OG9fZzJMRUU/view?usp=sharing
_p1 for pentium1
_p1_noopt  - debug only, no optimze
_p2 for pentium2


Do the nightlies from last night work?
There is indeed some mingw references there in the logs, also to a MSBuild.exe though... Would be nice to know the exact version, compiler settings, etc...

The problem with memcpy in the RLE blitter is it's completely inappropriate there. you don't want to even vectorize when you're usually copying only 4-8 bytes... but a vectorized while loop beats memcpy by orders of magnitude.
memcpy  kills gcc since it absolutely refused to inline it in that application - hence you end up with function calls and performance tanks to unusable levels.

Does it crash in the call to dr_texture, or in dr_texture itself? since this is the call to actually push the screen updates to the video card...
DrSuperGoods issue appears completely separate?

Do my builds work for anyone beyond me?

prissi

ChangeDisplaySettings was not an officially documented function when I first included it. I stole this from OpenTTD, which used to switch to 8 bit mode. That is still possible, if there is a compatibility manifest (but windows docs do not tell you which excatly ... ). Hence I would suggest to use 32 bit, since the blitting is done like this anyhow in windowed mode. (It just throws away a lot of performance, as it need twice the bandwidth to the graphics adapter).

Alternatively, it could check if it fails and then try 32 bit afterwards. I submitted some code, please test.

TurfIt

@Ters: please see back to post #16 for many questions. Don't want it missed with this subsequent discussion...


Unfortunately with these builds working fine for me, and for many years with my current setup on many different systems, I'm rather at a standstill to fix the issue.
If someone confirms the nightly build works, I could substitute that in as the release for now, but not knowing its configuration, I hesitate. I presume it's GDI only, but even that info is not available...
For now, the 120.1.2 release is withdrawn.

All I have readily accessible are Win7 and even WinXP machines. The Win8.1 laptop I confirmed the mouse scrolling issue on is 350km away, and in the hands of someone not really up to compiling/testing. I do have a Win7 laptop that's bugging me to update to Win10 that is hardly used, could be 'sacrificed' I guess... but not until next week at the likely earliest.

This 16/32bit / lack of fullscreen mode is taking attention from the big problem - crashing.
It's reasonable to ask for a 16bit screen, and take the 32 if that's all that works. I believe this is what prissi committed.

@DrSuperGood - can you try the SDL backend too with your self build?
With SDL, Simutrans just asks for a certain display, and SDL gives it what it can. I do see it returning 32 bit mode on some systems, 16 on the others, so if it's returning 16 bit for you, and then not working due to the manifest...

As for why offer SDL - it benchmarks out around 5% faster than GDI, or SDL2. For those experience performance woes, 5% can be a lot...

In the past, I remember when you asked for a fullscreen mode, you tended to get a hardware screenbuffer. Hence you had to set the displaymode to the depth/format you intended to render at. I guess now Windows is just giving you a memory surface to blit too, even when asking for fullscreen, and then converting to the actual depth.
As long as the render surface is 16 bit RGB565, Simutrans is happy (correct colors). 16bit surface is also best for speed. Trying to software blit in 32bit comes with a large performance hit - you're moving twice as much bytes around. In total, you add 40-50% to the frame times. Not good.
The 16bit render surface is usually then converted to the 32bit actual display by hardware, so speed there isn't a concern (except perhaps SDL1 with OSX/certain Linux WMs [or they're choking on the limited alpha blending Simutrans does that requires reads from the surface]).

@Ters: Can you in another thread post your current patch to make the newer MinGWs work? At some point we'll have to move to it; Especially if we want to move to SDL2 which requires it. This crashing might be yet another compiler/optimizer bug courtesy of using gcc4.7.x like that last one I ran into (loops that wouldn't!)

DrSuperGood

#19
Quote
Can someone try https://drive.google.com/file/d/0B-XmYgbe1q5YLWNJbnJseVdOTzA/view?usp=sharing
Crashes at same point. Something is incompatible with your builds and other computers. This could easily be a missing library dependency or driver however the errors produced are not helpful at tracking the cause down.

Quote
Do the nightlies from last night work?
Yes the nightly build of the release version does work. Just the release build of the release version does not.

The build still has the fullscreen problem but that is unrelated with the crash.

Quote
DrSuperGoods issue appears completely separate?
Yes the fullscreen issue is completely separate. That is a bug.

The problem is the build marked as "release" crashes on Windows 10 (and possibly other Windows) at startup. It crashes after the window is initialized but before the pakset selection dialog. The nightly build of the release version does not crash.

Quote
If someone confirms the nightly build works, I could substitute that in as the release for now, but not knowing its configuration, I hesitate. I presume it's GDI only, but even that info is not available...
For now, the 120.1.2 release is withdrawn.
Nightly does work. Just it appears not optimized and still has the fullscreen bug. If you are unsure if GDI or SDL just bundle with the SDL library anyway. I honestly have no clue why there is a Windows SDL build as performance is identical to GDI and GDI is part of the OS.

I have not tested a nightly with the fullscreen fix though.

Quote
As for why offer SDL - it benchmarks out around 5% faster than GDI, or SDL2. For those experience performance woes, 5% can be a lot...
Yet the release builds benchmark at like 1/2 the speed of an optimized build. Going for a 5% trivial boost rather than a 50%+ boost is kind of not the point of optimization. Frame rates on my self-build GDI and SDL appeared equal, hence the performance difference is small to the point of triviality compared with moving from the release build at the time to a self-build which boosted frame rate in a complex map massively.

Quote
@DrSuperGood - can you try the SDL backend too with your self build?
This might fix the fullscreen issue, but equally well one could fix the bug with GDI. I will look into testing it later.

If people want I can provide a MSVC build. I am unsure of how it will work on systems older than Windows 10 though or with old processors.

Quote
This 16/32bit / lack of fullscreen mode is taking attention from the big problem - crashing.
It's reasonable to ask for a 16bit screen, and take the 32 if that's all that works. I believe this is what prissi committed.
I recall it messing up desktop colours while Simutrans was running. I wondered why my Windows 10 upgraded "fixed" that issue but now I understand it is because it was no longer changing to 16bit colour. I think the change of colour should be a setting, just like it is in most games.

EDIT:
Fullscreen issue with GDI was fixed by last commit. Tested just now with a self-build.

TurfIt

Please try the sim_p2.exe from the second google link I sent to Ters.
I just duplicated the crash on an old Core2Duo WinXP machine. sim_p2 works fine, the pentium4 version does not. I've run pentium4 target before on an even older Core2, but didn't try this release (never had any reason to suspect an issue - I'll try that anyway tomorrow). I'm currently running it on an IvyBridge CPU no issues...

sdog

Quote
Nightly does work. Just it appears not optimized and still has the fullscreen bug. If you are unsure if GDI or SDL just bundle with the SDL library anyway. I honestly have no clue why there is a Windows SDL build as performance is identical to GDI and GDI is part of the OS.
Better not release that in lieu of the actual stable build. There is no need to rush. In particular as this is a bugfix release, not features all are eagerly waiting for.

Thank you all very much for all the effort you put in this matter.

An_dz

Quote from: TurfIt on January 08, 2016, 01:11:55 AM
If someone confirms the nightly build works, I could substitute that in as the release for now, but not knowing its configuration, I hesitate. I presume it's GDI only, but even that info is not available...
It's GDI, I'll add this info now.

As for testing I did not download the release but I have a Win10 and 8.1 computer. Both the nightly and the versions you uploaded above seem to work for me.

DrSuperGood

We solved the issue online. The crash is a bug in the GCC compiler he used to build the releases. It probably is not forcefully aligning the memory access for the SSE instructions which causes an execution error. The reason it was not crashing for him is either due to some feature of the processor used or just the way the OS allocates the pages for the process. He is building it targeting P3 or something older which will decrease performance but works.

The fullscreen issue is also fixed, although it really should be done by a user setting as changing display mode to 16bit can upset desktop graphics when minimizing.

TurfIt

I have reissued 120.1.2 compiling against a target of Pentium2 to eliminate the SSE crashes. Hopefully nothing more is lurking. Going forward, use of these old MinGWs will have to be discontinued.

Ters

Quote from: TurfIt on January 07, 2016, 09:17:16 PM
The problem with memcpy in the RLE blitter is it's completely inappropriate there. you don't want to even vectorize when you're usually copying only 4-8 bytes...
If naturally does some branching based on how long the range being copied is. That is true for the other versions as well. If you don't like memcpy, write some replacement that doesn't cast int16* to int32*, because that makes GCC generate code that crashes du to misalignment.

Quote from: TurfIt on January 07, 2016, 09:17:16 PM
but a vectorized while loop beats memcpy by orders of magnitude.
How can it, when the machine code is exactly the same? (I haven't done a side-by-side comparison, but I could not deduce that the machine code generate was one or the other.) It has been long since memcpy actually was a function call on GCC, except maybe if you use -Os (or the relevant constituent parameter).

Quote from: prissi on January 07, 2016, 11:24:03 PM
ChangeDisplaySettings was not an officially documented function when I first included it.
Yes it was. I've got official documentation for it dating from 1996.

Dwachs

Quote from: Ters on January 08, 2016, 07:00:33 AM
If naturally does some branching based on how long the range being copied is. That is true for the other versions as well. If you don't like memcpy, write some replacement that doesn't cast int16* to int32*, because that makes GCC generate code that crashes du to misalignment.
Where in simgraph16.cc did the crashes occur for you? The fishy implementations are in display_img_nc and display_fb_internal.

I am all with you to throw out the blocks enclosed by

#ifndef ALIGN_COPY
..
#endif

The casting of pointers will not work if one pointer is aligned to 4byte memory address while the other is not.
Parsley, sage, rosemary, and maggikraut.

Ters

Quote from: Dwachs on January 08, 2016, 07:59:14 AM
Where in simgraph16.cc did the crashes occur for you? The fishy implementations are in display_img_nc and display_fb_internal.

Unless you are talking about the crashing this topic is about, which I have already mentioned, it was over five years ago that I had crashes in simgraph16.cc (r4126 was the fix for that, I think). I don't remember anything beyond it being SSE alignment related. The other crash I mentioned was in simmain.cc, because argv (actually __argv, fetched in simsys_w.cc and simsys_s.cc) is null with the newest mingw-runtime. Or at least that was the case last I checked, which is about a year ago. There should be a topic about both somewhere in here.

An_dz

The re-uploaded release is still crashing.

TurfIt

Then I have no solution. The file now works for DrSuperGood. It also works on the one ancient system I also seen a crash with.

If those experiencing the startup crash would post detailed system specs, maybe some pattern could emerge.
Otherwise unless someone else wants to try reissuing it... I guess point the crashers towards either the nightly, or a different computer / OS.

DrSuperGood

The files in the release page crash for me as well at the same spot as reported before. They must be different from the ones you linked me earlier which worked. Possibly uploaded old files again by mistake?

Also you started your servers with 7720 yet you said the release was going to be 7721 for the Windows 8 full screen fix.

The executable you made "sim_p2.exe" does work. The ones in the release do not work. Both have wrong revision number, since sim_p2.exe uses the revision 7721 (fullscreen works) yet is incorrectly labelled as 7720. How you built the release executables must be different from sim_p2.exe as that works fine.

TurfIt

Files re-uploaded. Presumably the wrong ones got there...

A further bug in the online installer was fixed too that mangled the portable installation when installing both pak64 and pak64 food addon at the same time.

An_dz

Now it's working :D Thanks for the release.

Ters

Quote from: DrSuperGood on January 08, 2016, 03:19:00 AM
We solved the issue online. The crash is a bug in the GCC compiler he used to build the releases. It probably is not forcefully aligning the memory access for the SSE instructions which causes an execution error.
Sounds a lot like https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56597, although that still isn't marked as fixed.

Quote from: DrSuperGood on January 08, 2016, 03:19:00 AM
The fullscreen issue is also fixed, although it really should be done by a user setting as changing display mode to 16bit can upset desktop graphics when minimizing.
Not as much as changing to 8-bit does. That leaves most of the notifications icons stuck in 256 colors until you log off. I never have remember having that much problems with 16-bit, but I might not have had much to do with fullscreen games that only support 16-bit. Changing resolution is a bit worse if you have any significant amount of icons on the desktop and actually use some of them, as they suddenly get rearranged (although my problems with that is mostly self-inflicted and not game related).

TurfIt

I've split off some subsequent discussion as requested. I believe the original topic of the release crashing is solved, will mark i as such.
If there's still crashes, then rereport please.