VOGONS


Terminator Skynet problem

Topic actions

Reply 60 of 117, by HunterZ

User metadata
Rank l33t++
Rank
l33t++

Oh it was definitely a crappy monitor, although it was only a few months old at most when it died. I only know it was crappy because it blew out 2 more times in the time that I had it. By the time I had figured out how to fix it myself I had already junked it.

Reply 61 of 117, by HunterZ

User metadata
Rank l33t++
Rank
l33t++

I managed to beat Terminator: Future Shock in non-SkyNet-intergrated mode and it was pretty stable in DOSBox 0.73. The worst problem I had was that 2 times the game generated a corrupted save file that would crash the game whenever I tried to load it.

I just installed SkyNet plus the 1.01 patch and am finding it to still be quite unstable in DOSBox using memsize=32 and machine=svga_s3 and 640x480 mode. Often it would cause DOSBox itself to lock up or self-terminate within a couple minutes of starting the first level.

I tried SysGOD's file and was able to play for about 15 minutes until the game finally crashed while entering a building (crashed with DOS4GW error codes all over the screen rather than by killing DOSBox). I'm also curious what SysGOD's changes are. I did an fc /b on the two versions and got this:

Comparing C:\SKYNET\SKYNET.EXE and C:\SKYNET\SKYNET2.EXE
0017E23C: E8 è 90 
0017E23D: 6F o 90 
0017E23E: 84 „ 90 
0017E23F: 01 90 
0017E240: 00 90 
0017E241: 72 r 90 
0017E242: 45 E 90 
0017E252: 72 r 90 
0017E253: 34 4 90 
0017E267: E8 è 90 
0017E268: 38 8 90 
0017E269: FF ÿ 90 
0017E26A: FF ÿ 90 
0017E26B: FF ÿ 90 
0017E272: 66 f 33 3
0017E273: 85 … DB Û
0017E274: DB Û 90 

I'm not proficient enough with DOS disassemblers/debuggers to be able to gain any useful from that, though.

I also tried running SkyNet with DOS32A, but as with most games under 0.73 I've tried, it seems to actually make it *less* stable.

I've also noticed that even if I run fullresolution=640x480, DOSBox triggers a hardware resolution change when transitioning between 320x200 menus and 640x480 gameplay modes. This is highly annoying on my laptop because full-screen mode changes often take 10+ seconds with the screen flashing 5+ times.

Reply 62 of 117, by fluxit

User metadata
Rank Newbie
Rank
Newbie

E8h is either a jmp or a call(it's been a while since I last looked at X86 machine code.) 90h is nop(no operation.) If I had to guess I'd say a couple of called procedures have been nopped out(skipped.)

To know what goes wrong at that point you'd need to debug(or disassemble) the original code at that address and trace the calls(or ask SysGOD 😉 )

Reply 63 of 117, by HunterZ

User metadata
Rank l33t++
Rank
l33t++

Tried all sorts of stuff over the weekend to optimize the DOSBox+SkyNET experience. I finally settled on output=ddraw and fullresolution=640x480 so that hardware resolution changes do not occur when the game switches between emulated 640x480 and 320x200 modes.

I noticed that the game tends to run quite well in 640x480 in outside environments, but has a noticeably low/choppy framerate while in indoor environments for some reason. I tried all of the SVGA machine= settings (using SDD/UNIVBE for the ones that don't provide native VESA support) and none of them were better than the default svga_s3 or whatever.

I've been having decent luck with crashes - it seems that I get them when trying to enter buildings or load indoor saved games about 15-20% of the time.

It seems that the version of XnGine used for SkyNET was not optimized very well for 640x480 or indoor environments.

Reply 65 of 117, by HunterZ

User metadata
Rank l33t++
Rank
l33t++

Honestly they haven't improved much in that respect. Fallout 3 for example has tons of issues that Bethesda has ignored in their frenzy to milk the lucrative console and DLC craze cash cows. Their ongoing issues with making huge games run stable on the PC platform is probably going to push them more and more towards the console market. Oh well.

And yeah, DOSBox has come a good way at emulating SkyNET (and SysGOD's hack helps, although I still wonder what it does).

Reply 66 of 117, by liqmat

User metadata
Rank l33t
Rank
l33t

The mods will probably hiss at me for posting this here almost 8 years after the last post, but it is related to this issue. Basically this is the door bug in Skynet which is not present in the original Future Shock. A quick way to test this is load the game and run the tutorial mission. Walk, run, limp or crawl over to the only building with a door on that level and enter and then exit and then enter again. On your second entry the game will always crash and DOSBox freezes if your CPU cycles are on auto or just too fast. This bug is apparently related to CPU speed. I have found the magic CPU cycles to eliminate this, for me, is 75000 for 640x480 and 50000 for 320x200. Anything faster and the door crash comes back. The only drawback to this is 640x480 runs a tad choppy with that CPU cycle count, but 320x200 runs smooth. That's the best I've got on this problem, but at least it is now playable without crashing every time the door hits you where the hex don't shine.

Last edited by liqmat on 2017-07-30, 17:10. Edited 1 time in total.

Reply 67 of 117, by Stiletto

User metadata
Rank l33t++
Rank
l33t++
liqmat wrote:

The mods will probably hiss at me for posting this here almost 8 years after the last post, but it is related to this issue.

Grrr.

"I see a little silhouette-o of a man, Scaramouche, Scaramouche, will you
do the Fandango!" - Queen

Stiletto

Reply 68 of 117, by Osprey

User metadata
Rank Member
Rank
Member

In case anyone else has the same issue and this helps, I've found that SkyNET has really choppy 640x480 performance in some older SVN builds of DOSBox and pre-0.74 official versions that I've tried. If it's pretty much unplayable for you, trying switching to v0.74 or newer SVN builds.

Last edited by Osprey on 2017-08-06, 08:49. Edited 1 time in total.

Reply 69 of 117, by liqmat

User metadata
Rank l33t
Rank
l33t
Osprey wrote:

In case anyone else has the same issue and this helps, I've found that SkyNET has really choppy 640x480 performance in the SVN builds of DOSBox and pre-0.74 official versions that I've tried. If it's pretty much unplayable for you and you're not using the 0.74 official version, switch to that.

Huh, weird. I get exactly the same performance with 0.74 and SVN 4025. Maybe some other SVN builds are different. At 75000 CPU cycles @ 640x480 so it wont crash going in and out of doors the FPS is a bit choppy, but not unplayable.

Reply 70 of 117, by ripsaw8080

User metadata
Rank DOSBox Author
Rank
DOSBox Author

For the problem of SkyNET crashing when entering and exiting interior areas, a setting of cputype=486_slow or cputype=pentium_slow seems to help in my tests, even with auto (i.e. max) cycles on a fast host CPU. However, it may only reduce the odds of a crash, and limiting cycles may still be necessary, but perhaps not so limited as with cputype=auto.

Reply 71 of 117, by liqmat

User metadata
Rank l33t
Rank
l33t
ripsaw8080 wrote:

For the problem of SkyNET crashing when entering and exiting interior areas, a setting of cputype=486_slow or cputype=pentium_slow seems to help in my tests, even with auto (i.e. max) cycles on a fast host CPU. However, it may only reduce the odds of a crash, and limiting cycles may still be necessary, but perhaps not so limited as with cputype=auto.

Excellent. I'll give that a shot. Any theories as to why this happens in this game and not Future Shock? (probably a question for the dev team 20 years ago)

Reply 72 of 117, by Osprey

User metadata
Rank Member
Rank
Member
liqmat wrote:

Huh, weird. I get exactly the same performance with 0.74 and SVN 4025. Maybe some other SVN builds are different. At 75000 CPU cycles @ 640x480 so it wont crash going in and out of doors the FPS is a bit choppy, but not unplayable.

I haven't used that SVN build. I had the problem with SVN Daum and, perhaps, one other. In another thread, someone remarked that Daum is "broken," so that could be symptom of that. I tried 0.73 and had the same unplayable framerate, so 0.74 definitely fixed it. Maybe Daum accidentally undid whatever 0.74 did to fix it.

As for the crashing, that happened to me once, after I saw your post and tried to duplicate it, but eventually solved itself without me having to change the cpu options any. I wish that I could remember what I thought fixed it. I wasn't registered here at the time or else I would've written it down then. I want to say that it was simply switching to 0.74, but it sounds like you have crashes in that. I just checked and I still don't have crashes. It doesn't look like there are any non-standard options set in my dosbox.conf, so I don't know why it crashes for you with cpu options on auto.

Reply 73 of 117, by liqmat

User metadata
Rank l33t
Rank
l33t

This is more than likely a problem with the game and fast machines as it happens on real hardware as well. It is well documented in other forums with entering buildings causes a crash and then dumps out to DOS. A quick way to test is load up Skynet and run the tutorial. Go over to the only building with a door down the road and enter the building, exit the building and then enter the building again. When you try to enter the building the second time the crash will usually happen if the CPU cycles or the system you are on is too fast. I am going to try what ripsaw suggested when I get a chance.

Reply 74 of 117, by liqmat

User metadata
Rank l33t
Rank
l33t
ripsaw8080 wrote:

For the problem of SkyNET crashing when entering and exiting interior areas, a setting of cputype=486_slow or cputype=pentium_slow seems to help in my tests, even with auto (i.e. max) cycles on a fast host CPU. However, it may only reduce the odds of a crash, and limiting cycles may still be necessary, but perhaps not so limited as with cputype=auto.

Tried what you suggested. I actually got worse performance this way. Using the 75000 cpu cycles with 640x480 gives me the best FPS without crashes, but thanks for the suggestion. This is an in-game speed bug. Don't think we're fixing this anytime soon or never. I would like to know what is different between Future Shock and Skynet as Future Shock does not have this issue at all. With Skynet I have to run 640x480 @ 75000 max cpu cycles to prevent the enter/exit crash and with 320x200 I have to set cpu cycles @ 50000 to prevent the crash. Interesting the resolution effects what CPU cycles I have to set it to. Maybe that narrows it down a bit on what the issue is.

Reply 75 of 117, by ripsaw8080

User metadata
Rank DOSBox Author
Rank
DOSBox Author

I suggested you try the cputype=486_slow setting in concert with cycles=auto, which should have given better performance than 75000 fixed cycles, but perhaps use the word "performance" for something other than speed.

Though speed does appear to affect the issue, it often manifests as a page fault. The _slow CPU types have different page fault handling, so it's worth trying them here, and in my case the crash stops happening at the tutorial interior. However, there are many interiors throughout the game, and some may be more crash-prone than others.

Reply 76 of 117, by liqmat

User metadata
Rank l33t
Rank
l33t

Yes. I understood the first time. I did that exactly. Cycles=auto and tried both pentium_slow & 486_slow. I get better FPS on my system with a fixed 75000 cycles @ 640x480. Anyways, I just pulled up this other Vogons thread and it looks like this subject has already been beaten to death so I'm just going to leave it here. The last post of this thread on page 2 is what I suspected. They tried it on real hardware and the problem came up on a 450MHz machine, but went away on a 166MHz machine. So there it is.

Skynet (crash when re-entering buildings)

Reply 77 of 117, by ripsaw8080

User metadata
Rank DOSBox Author
Rank
DOSBox Author

Here is a modified SkyNET version 1.01 executable that prevents the door crash regardless of cycles in my tests. Likely effective for "too fast" real DOS systems as well. However, it only addresses a specific problem, and of course there could be others, because this is a Bethesda game. 😉

Attachments

  • Filename
    skynet101_door_fix.zip
    File size
    450.96 KiB
    Downloads
    124 downloads
    File license
    Fair use/fair dealing exception

Reply 78 of 117, by liqmat

User metadata
Rank l33t
Rank
l33t
ripsaw8080 wrote:

Here is a modified SkyNET version 1.01 executable that prevents the door crash regardless of cycles in my tests. Likely effective for "too fast" real DOS systems as well. However, it only addresses a specific problem, and of course there could be others, because this is a Bethesda game. 😉

WTF???!!! What is with you Ripsaw? You just pull out your magical coding unicorn and everything works? Completely fixed with your exe. Thank you!

giphy.gif
Filename
giphy.gif
File size
1 MiB
Views
2275 views
File license
Fair use/fair dealing exception

Reply 79 of 117, by Osprey

User metadata
Rank Member
Rank
Member

Unfortunately, whereas I wasn't having the door crash before, now (with ripsaw's exe), DOSBox (v0.74 official), itself, consistently crashes either as the 3D engine is loading or very shortly after. Playing with resolution, cputype or game mode doesn't make any difference. At least it works for liqmat.

In other news, I just re-discovered that this game as FMV briefings. Who knew that that they were entirely optional and you'd easily miss them if you didn't click on the Briefing button at the top.