VOGONS


Tie Fighter Collector's CD-ROM :: FPS vs. Turret AI : An Inverse Relationship ::

Topic actions

  • This topic is locked. You cannot reply or edit posts.

First post, by TomJeffersonJones

User metadata
Rank Newbie
Rank
Newbie

I thought I had the Tie Fighter Collector's CD-ROM running perfectly in Dosbox 0.74, I'm using the official release version available from Dosbox.com. Running the flight-engine at 640x480 with a dynamic core and cycles on auto or max gives me perfect, and I mean perfect performance in flight and during cut-scenes, concourse and briefings.

But, under those settings, certain multi-turret ships like platforms, escort shuttles, cargo ferries and container transports, corvettes etc, do NOT fire their turrets at all, except in rare instances like during their death-roll when there are a lot of explosions on screen. Fighters and mines seem to function fine. Interestingly enough, large cap-ships DO fire their turrets and missiles as is normal.

If I fix or limit the cycles to about 70,000 these malfunctioning turreted objects will target and fire normally. The further I limit the cycles, the more often they fire and the range at which they begin firing seems longer. The problem is, at 60,000 cycles and below, the playability starts to suffer. 60-70,000 cycles is playable in battle, but there is a lot of chop when something big blows up. Increasing the cycle limit to 80, 90 and 100,000 starts to eliminate this, but the increase in fluidity results in the turreted ships mentioned above firing less and less, which unbalances the game.

At 75,000 cycles platforms for example will fire when I fly towards them in cockpit view, but will actually stop firing if I view them from a side window or in the threat display, presumably because the rendering load is decreased causing the game to speed up....

The Tie-Fighter CD is a popular game around here, I believe - so I thought I'd appeal to the community for suggestions. I've tried many different cycle settings, tried the normal core which slows the game down to unplayable levels, tried different emulated vga machines, all emulated cpu types, surface, ddraw, and opengl outputs, different full and window resolutions, filters and scaling settings, different priorities and different cpu cores. I've also tried replacing the game's DOS4GW with DOS32A.

The problem is no better with any of those settings....no worse either (aside from the settings greatly slow the game or keep it from launching.)

My current .conf is listed below....My goal is full fluidity w/ the flight engine set at 640x480, with proper turret behavior. atm it seems like there's an inverse relationship there. Playing the thing at 65-70000 cycles is fine, but like I said, large objects exploding cause the FPS to suffer noticeably, frameskip doesn't seem to help this any either.

The game is completely fluid at all times under max or auto cycles.

I installed the game through Dosbox 0.74 and am playing it with the same mountings I used during the installation. Installation went without a hitch, and I'm running the game with the CD in the drive during play.

the essentials of my system:

Opteron 165 @2.4ghz
2gig RAM
Win XP pro
____________________________________________________________

[sdl]

fullscreen=true
fulldouble=false
fullresolution=original
windowresolution=original
output=ddraw
autolock=true
sensitivity=100
waitonerror=true
priority=higher,normal
mapperfile=mapper-0.74.map
usescancodes=true

[dosbox]

language=
machine=svga_s3
captures=capture
memsize=16

[render]

frameskip=0
aspect=true
scaler=normal2x

[cpu]

core=dynamic
cputype=auto
cycles=auto limit 65000
cycleup=10
cycledown=20

[mixer]

nosound=false
rate=44100
blocksize=1024
prebuffer=20

[midi]

mpu401=intelligent
mididevice=default
midiconfig=

[sblaster]

sbtype=sb16
sbbase=220
irq=7
dma=1
hdma=5
sbmixer=true
oplmode=auto
oplemu=default
oplrate=44100

gus=false
gusrate=44100
gusbase=240
gusirq=5
gusdma=3
ultradir=C:\ULTRASND

[speaker]

pcspeaker=true
pcrate=44100
tandy=auto
tandyrate=44100
disney=true

[joystick]

joysticktype=2axis
timed=false
autofire=false
swap34=false
buttonwrap=false

[serial]
serial1=dummy
serial2=dummy
serial3=disabled
serial4=disabled

[dos]
xms=true
ems=true
umb=true
keyboardlayout=auto

[ipx]
# ipx: Enable ipx over UDP/IP emulation.

ipx=false

[autoexec]
mount D: E:\ -t cdrom
mount C: C:\Dosgames\Tie
d:\
Tie
_____________________________________________________________

If any has a suggestion thanks in advance!

yours, in nostalgia

TJJ

Last edited by TomJeffersonJones on 2010-05-28, 20:32. Edited 1 time in total.

Reply 1 of 31, by ripsaw8080

User metadata
Rank DOSBox Author
Rank
DOSBox Author

There is a good possibility you simply need more processing power to run the game with everything being ideal. If I'm not mistaken, your CPU is of 2006 vintage, and being dual core does not really help because DOSBox is single-threaded.

Reply 2 of 31, by TomJeffersonJones

User metadata
Rank Newbie
Rank
Newbie
ripsaw8080 wrote:

There is a good possibility you simply need more processing power to run the game with everything being ideal. If I'm not mistaken, your CPU is of 2006 vintage, and being dual core does not really help because DOSBox is single-threaded.

Perhaps, but wouldn't the fact auto or max cycles results in perfect FPS at all times indicate my processor is up to the task? When flying with auto/max cycles the cap-ship threat indicator will light up while in the presence of a non-firing turret equipped craft indicating that it is indeed targeting ... but the code that times the actual firing is somehow getting overlooked or overloaded....

Reply 3 of 31, by ripsaw8080

User metadata
Rank DOSBox Author
Rank
DOSBox Author

You'd need to analyze the code to understand how the game manages limited processing resources. Have you tried anything to minimize processing (e.g. disable sound, use a lower video resolution, etc.) to see if it helps achieve both smooth flight and normal enemy AI?

Reply 4 of 31, by TomJeffersonJones

User metadata
Rank Newbie
Rank
Newbie
ripsaw8080 wrote:

You'd need to analyze the code to understand how the game manages limited processing resources. Have you tried anything to minimize processing (e.g. disable sound, use a lower video resolution, etc.) to see if it helps achieve both smooth flight and normal enemy AI?

Disabling sound in the .conf or ingame doesn't change anything. Dropping the in-game resolution to 320x200 lowers the threshold at which objects stop firing their turrets.

For example 60,000 cycles at 640x480 gets me a healthy firing space platform in Tie Bomber Combat Chamber Mission # 2.

dropping down to 320x200 at the same cycle count gets me a non firing platform in the same mission, same as if I ran 640x480 at 80,000+ cycles.

The 320x200 platform at 60,000 cycles did indeed fire when it started to explode....the same behavior can be observed in the 640x480 platform at 80,000 cycles.

Reply 8 of 31, by ADDiCT

User metadata
Rank Oldbie
Rank
Oldbie

Well wouldn't it make sense for someone to verify the behaviour before jumping to conclusions? I especially wonder where leilei has got her wisdom from. I bet she has the sourcecode for evey LucasArts game on her hd.

For example 60,000 cycles at 640x480 gets me a healthy firing space platform in Tie Bomber Combat Chamber Mission # 2.

dropping down to 320x200 at the same cycle count gets me a non firing platform in the same mission, same as if I ran 640x480 at 80,000+ cycles.

So, are you saying that platform doesn't fire at all in one case and a lot in another? This should be easy enough to verify.

Reply 10 of 31, by TomJeffersonJones

User metadata
Rank Newbie
Rank
Newbie

For example 60,000 cycles at 640x480 gets me a healthy firing space platform in Tie Bomber Combat Chamber Mission # 2.

dropping down to 320x200 at the same cycle count gets me a non firing platform in the same mission, same as if I ran 640x480 at 80,000+ cycles.

So, are you saying that platform doesn't fire at all in one case and a lot in another? This should be easy enough to verify.

That's exactly what I'm saying, no firing behavior at high cycle counts relative to the in-game resolution.

Don't know if its relevant but the same behavior was observed when I installed and ran the game under Dosbox 0.73.

Reply 11 of 31, by ADDiCT

User metadata
Rank Oldbie
Rank
Oldbie

Hmmm difficult to say. I've played the mission (tried to rather (; ) a few times and the platform didn't fire for some time. It started to do so after a while though and promptly killed me. I was playing in SVGA@75000 cycles, DOS4GW replaced with DOS/32A. To me it seemed as if the platform was reacting to some other things going on though, like other bombers being destroyed etc. . Is there another mission that could be used for verification? Preferrably one with fewer other craft? (;

Reply 12 of 31, by TomJeffersonJones

User metadata
Rank Newbie
Rank
Newbie
ADDiCT wrote:

Hmmm difficult to say. I've played the mission (tried to rather (; ) a few times and the platform didn't fire for some time. It started to do so after a while though and promptly killed me. I was playing in SVGA@75000 cycles, DOS4GW replaced with DOS/32A. To me it seemed the platform was reacting to some other things going on though, like other bombers being destroyed etc. . Is there another mission that could be used for verification? Preferrably one with fewer other craft? (;

I'll see if I can find a better example...in the meantime check out a general idea of my experience through Ctrl-Alt-F5 capture. The recorder does slow things down, meaning the platform does fire more in the auto/max video than it does when running without the recorder. In the video comments I chose to describe the behavior of the thing as shown in the vid for clarity's sake. Without the recorder turned on at auto/max I get no firing until the thing starts exploding...

but you can easily see the difference in the initial approaches.

60,000 Cycles ::
http://www.youtube.com/watch?v=XDyaxV6-AXA

Auto/Max Cycles ::
http://www.youtube.com/watch?v=xMsdsBGagSU

The game is running MIDI commands while I'm recording I just didn't bother to include them....

ADDiCT I bet you'd see the platform fire a lot more if you went to 60,000 cycles or less.

Reply 13 of 31, by ADDiCT

User metadata
Rank Oldbie
Rank
Oldbie

OK, I think I've seen the effect. I'm using fixed cycles because the joystick "jerks" from time to time when using auto/max. Out of curiousity: are you playing with a joystick, TomJeffersonJones?

Anyway, the two videos illustrate the problem quite well. It only takes a few seconds to verify the effect, from launching TIE Fighter to the point where your bomber is approaching the platform. I've run several tests using official 0.74 and Gulikoza's last build (based on 0.73), with fixed cycles @ 25,000 and @ 85,000. It seems as if the effect is always reproducible.

IMO, TIE Fighter is one of the "important" games to emulate. It'd be nice therefore if a dev or "debug specialist" (ripsaw?) could take a look at the issue. I'm at a loss as to what to try next.

Reply 14 of 31, by TomJeffersonJones

User metadata
Rank Newbie
Rank
Newbie
ADDiCT wrote:

OK, I think I've seen the effect. I'm using fixed cycles because the joystick "jerks" from time to time when using auto/max. Out of curiousity: are you playing with a joystick, TomJeffersonJones?

Yes I'm using a CH USB joystick - I had bizarre control anomalies w/ auto/max until I set timed=false which cleared them up.

Reply 15 of 31, by ADDiCT

User metadata
Rank Oldbie
Rank
Oldbie

Ah OK, for some reason i thought the game needed "timed=true", seems my memory failed there (; .

Btw: it could very well be that the effect is a game bug and there's no way of fixing it from the DOSBox side. I've tried lots of stuff today: different extenders, machine settings, etc. etc. . The damned game just won't work correctly at high speeds. It'd be very interesting to see if the effect also happens on a fast DOS machine. I don't have that kind of metal around unfortunately. Anyone?

Reply 16 of 31, by TomJeffersonJones

User metadata
Rank Newbie
Rank
Newbie
ADDiCT wrote:

Ah OK, for some reason i thought the game needed "timed=true", seems my memory failed there (; .

Btw: it could very well be that the effect is a game bug and there's no way of fixing it from the DOSBox side. I've tried lots of stuff today: different extenders, machine settings, etc. etc. . The damned game just won't work correctly at high speeds. It'd be very interesting to see if the effect also happens on a fast DOS machine. I don't have that kind of metal around unfortunately. Anyone?

not I,

but the game worked fine on the Pentium 90mhz I ran it on originally...32mb RAM IIRC (I was in gradeschool) does that qualify as a fast machine?

Reply 17 of 31, by TomJeffersonJones

User metadata
Rank Newbie
Rank
Newbie

On may way to confirming that the Xwing Collector's Cd has the same problem...

Tour 1 mission 2 - The frigate warspite and assorted corvettes attack more frequently and at longer ranges around 20,000 cycles on a dynamic core.

They attack less if at all at 40,000 cycles

And not at all at auto/max cycles....where the graphics performance is the best....

Reply 18 of 31, by ADDiCT

User metadata
Rank Oldbie
Rank
Oldbie

I'd like to bump this topic as TIE Fighter is one of my favourite games, and as I've stated before one of the most "important" DOS games.

I don't currently have an old PC to test the issue, so I've played around a bit with virtualizers. The game wouldn't run in my VMWare DOS install so I've fiddled around with BOCHS. After some trial and error I got the SVGA mode working in BOCHS. For now I'm running the game with its included extender and SDD 6.53 for VESA support (couldn't get the SVGA flight engine working with the BOCHS BIOS).

I only did some quick tests (more to follow if necessary), but I've made an interesting observation. The space flight engine runs much too fast in my current config, I'd say about 3 to 4 times "normal" speed. Yet the platform in the "test mission" used by TomJeffersonJones (TIE Bomber Combat Chamber Mission #2) starts firing as soon as I approach it. I believe that's the intended behaviour.

Of course I'm far from being a specialist in DOS emulation (at least from the coding side (; ), but I think this behaviour hints towards an emulation bug in DOSBox, not a game bug. If the bug was related to "pure CPU speed" I'd have seen it in BOCHS.

Any comments from the devs on this? If you need more info about my setup just tell me.