So slow...

[V22 Osprey]

I've tryed everything to make this game work.I've tryed new versions,updated my drivers,changing to windowed mode,turning shadows off but nothing worked.This game just wants to act slow.

Please help.

[Buginator]

I've tryed everything to make this game work.I've tryed new versions,updated my drivers,changing to windowed mode,turning shadows off but nothing worked.This game just wants to act slow.

Please help.

How about some details?
Which OS?
What hardware?

99.9999999% of the time, if it is 'slow' then that means that  you don't have hardware accelerated openGL.
Why?  I dunno, you don't give any details.  Most likely bad video drivers.

[cliff]

How about some details?
Which OS?
What hardware?

99.9999999% of the time, if it is 'slow' then that means that  you don't have hardware accelerated openGL.
Why?  I dunno, you don't give any details.  Most likely bad video drivers.

I've also been having problems with the latest beta, along with the stable 2.0.10. The stable version just completely crashes with an error that I can't remember. If you need it, I'll have it tomorrow. However, the beta will play, just extremely slowly at less than 1 FPS, no matter the settings. I've tried it all, texture sizes, resolution, windowed, shadows, 16bit, 32bit, fog of war mode, turning sound off. Nothing. I've tried changing settings in my video driver's display settings window, like "convert 32bit textures into 16bit" and v-sync and others. I've also updated my video drivers, directx, and sound drivers. Nothing.

However, the main problem here is that the old 2.0.6 version worked fine. It runs at a playable framerate of 20-30 FPS, so I'm trying to decipher why it would suddenly drop to less than 1 FPS with a newer version. The graphics haven't been changed, so the system requirements should be about the same. I checked the changelog and apparently there was something in 2.0.8 or 2.0.7 that "fixed" the game from falling back to software when using a "slow" AMD OpenGL driver. I'm going to download all versions between 2.0.10 and 2.0.6 and try them all and figure out where the problem arises. Should have the results tomorrow.

One thing I did notice was in the stderr.txt or stdout.txt (I forget which) there was a message saying that the texture size was expected to be 1024x1024, not 32x32 or whatever I had it on. I know for a fact that my card supports OpenGL, other games work with it, and so did 2.0.6.

Here's my specs:

1 GHz AMD Athlon
640 MB PC133 RAM
ATI Rage 128 AGP 32MB
Windows XP Pro SP2

Edit: looks like 2.0.9 was a linux bugfix, so I'll just test 2.0.7 and 2.0.8.

[Chojun]

The retail 1.10 version ran at around 60 FPS on a 233MHz machine with a similar video card.

Although it is better than < 1 FPS, 20-30 FPS is still pretty horrendous.

[Buginator]

The retail 1.10 version ran at around 60 FPS on a 233MHz machine with a similar video card.

Although it is better than < 1 FPS, 20-30 FPS is still pretty horrendous.

What is your point?  If you change the HAL device for DX, you would get similar results.  ???

[/quote]

I've also been having problems with the latest beta, along with the stable 2.0.10. The stable version just completely crashes with an error that I can't remember. If you need it, I'll have it tomorrow. However, the beta will play, just extremely slowly at less than 1 FPS, no matter the settings. I've tried it all, texture sizes, resolution, windowed, shadows, 16bit, 32bit, fog of war mode, turning sound off. Nothing. I've tried changing settings in my video driver's display settings window, like "convert 32bit textures into 16bit" and v-sync and others. I've also updated my video drivers, directx, and sound drivers. Nothing.

However, the main problem here is that the old 2.0.6 version worked fine. It runs at a playable framerate of 20-30 FPS, so I'm trying to decipher why it would suddenly drop to less than 1 FPS with a newer version. The graphics haven't been changed, so the system requirements should be about the same. I checked the changelog and apparently there was something in 2.0.8 or 2.0.7 that "fixed" the game from falling back to software when using a "slow" AMD OpenGL driver. I'm going to download all versions between 2.0.10 and 2.0.6 and try them all and figure out where the problem arises. Should have the results tomorrow.

One thing I did notice was in the stderr.txt or stdout.txt (I forget which) there was a message saying that the texture size was expected to be 1024x1024, not 32x32 or whatever I had it on. I know for a fact that my card supports OpenGL, other games work with it, and so did 2.0.6.

Here's my specs:

1 GHz AMD Athlon
640 MB PC133 RAM
ATI Rage 128 AGP 32MB
Windows XP Pro SP2

Edit: looks like 2.0.9 was a linux bugfix, so I'll just test 2.0.7 and 2.0.8.

Now, that is more like it, enough information to give information on  the issue.
In your case, the Rage128 is a pretty old card, and it only has 32MB of RAM.
Yes, it supports openGL, but it doesn't like something, and it is falling back to software mode.  That is why it is so slow.

If you could, download the nightly build, and on your shortcut for the .exe enter in:
--debug all
at the end of the target line, OR open up a command window, and type warzone2100 --debug all

Then it will make stdout.txt & stderr.txt.  If you can, post (attach) those here, and we can see where it is failing.

[Chojun]

What is your point?  If you change the HAL device for DX, you would get similar results.  ???

I doubt it, since the Ivis02 D3D renderer is essentially a software renderer that uses Direct3D only for rasterization.

[cliff]

If you could, download the nightly build, and on your shortcut for the .exe enter in:
--debug all
at the end of the target line, OR open up a command window, and type warzone2100 --debug all

Then it will make stdout.txt & stderr.txt.  If you can, post (attach) those here, and we can see where it is failing.

I'll try that tonight, and I'll have the results tomorrow. I found out that 2.0.8 through 2.0.10 crash with a dump, and the betas and nightly builds run, just at software fix I think, so that must be the problem. I'll have the debug logs from the latest build tomorrow, so hopefully you guys can solve the problem.

[Buginator]

I doubt it, since the Ivis02 D3D renderer is essentially a software renderer that uses Direct3D only for rasterization.

Well, I did some tests, and it was slow --and it crashed. 

I'll try that tonight, and I'll have the results tomorrow. I found out that 2.0.8 through 2.0.10 crash with a dump, and the betas and nightly builds run, just at software fix I think, so that must be the problem. I'll have the debug logs from the latest build tomorrow, so hopefully you guys can solve the problem.

For the reasons I mentioned in my last post, I am not sure we can do anything to fix the issue, but you never know.
I'll check the logs when you upload them.

[cliff]

Well, I did some tests, and it was slow --and it crashed. 
For the reasons I mentioned in my last post, I am not sure we can do anything to fix the issue, but you never know.
I'll check the logs when you upload them.

It only generated stderr.txt, not stdout.txt, so that's all I have for you. I poked around in there and there doesn't seem to be any indication that it fell back to software mode. I don't know why it would be impossible to fix, since 2.0.7 and previous run at acceptable speeds, yet everything after that point either crashes or runs at less than 1 FPS. However, I'm no programmer, so I'll leave my two cents out.

[Buginator]

It only generated stderr.txt, not stdout.txt, so that's all I have for you. I poked around in there and there doesn't seem to be any indication that it fell back to software mode. I don't know why it would be impossible to fix, since 2.0.7 and previous run at acceptable speeds, yet everything after that point either crashes or runs at less than 1 FPS. However, I'm no programmer, so I'll leave my two cents out.

Can you get the nightly build from ?topic=1664.0
And do --debug 3d

Attach log like last time.

thanks.

[cliff]

Can you get the nightly build from ?topic=1664.0
And do --debug 3d

Attach log like last time.

thanks.

Ok. I'll have it by tomorrow hopefully. I've been using the latest build r4875, which is the most recent one at http://warzone.mortis.eu/nightly-builds/

Looks like it hasn't been updated in a week or so, is that the one I should be using?

[Buginator]

Ok. I'll have it by tomorrow hopefully. I've been using the latest build r4875, which is the most recent one at http://warzone.mortis.eu/nightly-builds/

Looks like it hasn't been updated in a week or so, is that the one I should be using?

It was a bit broken  , but it should be working again. 
Latest version is 5098, as I write this, looks like he has 5090 up right now.

Forgot to mention, please get the debug builds, not the release build.
In this case, it would be warzone2100_r5090-debug.exe  (but get the latest version available)

[cliff]

It was a bit broken  , but it should be working again. 
Latest version is 5098, as I write this, looks like he has 5090 up right now.

Looks like I'll be downloading 5090-debug today, and I'll be able to give you the debug log for that tomorrow. Today I've got the --debug 3d log from the non-debug version of 4875, so I'll attach that.  I've been using the non-debug versions so I'll start using the debug versions from now on.

[Buginator]

Looks like I'll be downloading 5090-debug today, and I'll be able to give you the debug log for that tomorrow. Today I've got the --debug 3d log from the non-debug version of 4875, so I'll attach that.  I've been using the non-debug versions so I'll start using the debug versions from now on.

Thanks.  Hopefully, we can tell which call is causing it to fallback into software mode.

[cliff]

Thanks.  Hopefully, we can tell which call is causing it to fallback into software mode.

Here's the --debug 3d log from r5090-debug. Let me know if you need anything else.