![]() So I suspect that it might be down to a race condition, and that it is in fact slower, or slowed-down, systems that are less prone to the crashes. It seems back then that was the only system I owned that could run the game. Note 1: For what it's worth, I remember that many years back, already having trouble trying the play the same game, I finally resorted to playing it on an Asus eeePC netbook running WinXP (I believe I played the software version back then). Have any of you ever had anything similar, a game running or not running depending on energy settings? If I could find the underlying cause of this, it might help figuring out how to get it to run on other systems. Even the software version runs a bit better – no more access violations, and the game can actually be played for a few seconds before crashing in the f2pi() call. It turns out that the game, in its D3D version, works only if the laptop is in energy save profile. at home: I had disabled power save mode in energy settings in the meanwhile, and set the system back to high performance. I have now found out what was the difference between trying the game in Starbacks vs. However, while waiting for a friend in Starbucks, I tinkered some more with my laptop (Lenovo T420s, Win7 圆4, i7, Intel HD 3000 + NVIDIA NVS 4200M), and suddenly, as long as I forced the system to run the game on the NVIDIA GPU, I could actually get the game to accept setting the Direct3D version, which seemed to play fine! Later at home, though, on the same system, it suddenly wouldn't anymore, draw one buggy frame and then crash like on all the other systems. The software version always crashed immediately, the Direct3D mode wouldn't be accepted with the stated messages. I have tested on my main desktop computer (Win7 圆4, i7, GTX 970), several virtual machines (VMware Player, VirtualBox, XP Mode) running different guest OS (95, 98, XP), and D3D wrappers (WineD3D, DXGL, dgVoodoo2). Which would suggest that there is some floating point overflow happening somewhere (the "f2pi(): param too large -nan." bit seems to be the same always, while the part below (the calling function?) changes occasionally). ![]() Copy code to clipboard 1 Internal error, please contact (
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |