Factorio Forums

As far as I can tell, the apitrace replay is not simply a captured video. It's really re-rendered from the trace file, as it contains all the textures/vertex data etc. and api calls that were used while capturing the trace.

The 11MB file is probably useless. I got a small trace when factorio crashed very early on in the loading process (due to the radeon bug). Just loading the main menu and quitting the game results in a very big trace file, more than 100MB even in low-res mode (as it contains all the textures in low-res).

That 200MB file sounds much better. When you replay the trace, do you see corrupted graphics? I'd like to replay the same trace on my radeon card to see if it works for me, but you'll probably need to ask someone from the factorio team for permission to share that file with me (and if it turns out to work for me, share it on the mesa bug tracker so Intel devs can hopefully take a look at it, or privately with an Intel dev at least).


Edit: Looking at my trace file, I notice there are loads of "glEnable(GL_BLEND); glBlendFuncSeparate(…); glBlendEquationSeparate(…);" each frame. I'm an OpenGL noob, but this seems like a ~once-per-frame setup thing? Is there any reason to do thousands of iterations? Or maybe it's just a glitch with apitrace? Anyway, it probably doesn't hurt performance too much because it's just a setup thing and no actual heavy processing takes place when doing this? Just makes the trace file hard to read.

Yes, replay displays the same (=corrupt) as the game did (otherwise I wouldn't ask )
Do you think that the trace SHOULD run on a better gpu? No intel-specific quirks by the library?

I also noticed that it seems that menu frames are repainted even when nothing changed.
Not important as-of-alpha IMO.

If I can somehow help (such as tracing it myself and send those files to you so you could compare), just ask.

Have you tried comparing this trace to normal trace?

MF- wrote:Do you think that the trace SHOULD run on a better gpu? No intel-specific quirks by the library?

I'm not sure I completely understand the way apitrace works, but currently I think: Yes, the trace should render correctly on a GPU for which the driver is "factorio compatible". Maybe you have access to both, a radeon/nvidia/modern intel *and* a broken Intel setup? If so, can you try replaying the intel trace on the compatible GPU? If it renders correctly, I think this is a valid candidate for the mesa bug tracker. It could still be a bug (incorrect OpenGL usage) in factorio/allegro library that has consequences on older Intel GPUs only, but since it works on most drivers and GPUs, hopefully the Intel developers can take a look at it.

Maybe I'm wrong and the trace is not "driver-agnostic" because it contains some parts that are generated by the driver itself, so the trace renders incorrectly on and hardware. In that case, maybe comparing traces from a good and bad driver (using the same savegame and same settings) can tell us where the problem is?

bump

I just found a computer on which I can replicate this! Moving to bug reports.

... and we have a work around: In 0.10.3 there is a new config option max-texture-size in the [graphics] section of config.ini.
Setting it to 4096 helped in my case

Great, it works!

Awesome, one of the longest living issues finally getting some solution

AWESOME.
So the texture-size-override did the trick.

It also seems, that it indeed was possible to autodetect the corruption?

kovarex wrote:Hello,
Factorio 0.10.4 experimental bugfix release has just been released.

• Bugfixes:
  • Added checks for validity of allocated bitmaps to work around a bug on some intel graphics cards on linux (https://forums.factorio.com/forum/vie ... f=7&t=1991)

I am surprised it's not mentioned here, though.
I guess noone report that it works because everyone affected is busy playing factorio now?


Sadly, I cannot check right now
+ I am really worried whether I'll like what's now called "factorio"

Did you figure out exactly which system library function returns the incorrect texture size?
Running unmodified older factorio version might be as simple as injecting a LD_PRELOAD, overriding that function.
(It might be easier on me to catch up slowly instead jumping straight from 0.7 to 0.10)

I also wonder where exactly the issue with some Intel drivers is. It's great that the workaround appears to work (no confirmation yet)?

I guess the problem is either a missing error return code when a big texture allocation fails. Or it should theoretically work and the texture allocation does not actually fail, but somehow the driver manages to corrupt the texture during allocation or later on. In any case, it sounds like something the developers at the Intel Open Source Technology Center / the mesa bug tracker might be interested in.

Also, MF-, I haven't played 0.7 since 0.9.8 was out when I first heard of factorio. Not sure why you're afraid of updating, AFAICT every new release since then brought improvements and fixes. Is there anything in 0.7 that is missing in 0.10? Well, slightly off topic I guess.

The autodetection fix did't make it into any release, because it didn't work reliably. It just remained in the changelog by accident.

There are some difficulties with testing it exactly, because it doesn't happen on my computer.... I have to borrow the machine, do a few tests, rebuild... and all that only on weekend once in a few weeks ... But we'll get there :-)

Oh, ok

It's nice to hear this isssue now has THAT optimistic prospects.

Booted up the game on my ThinkPad (i5-3230M on-die, Ubuntu-Gnome 14.04), and there's some graphics issues, but nowhere near as bad as the screenshots in this thread... There's a flickering checkerboard pattern in some terrain tiles, distracting, but perfectly playable. Let me know if you think this is related or a separate issue.

roothorick wrote:Booted up the game on my ThinkPad (i5-3230M on-die, Ubuntu-Gnome 14.04), and there's some graphics issues, but nowhere near as bad as the screenshots in this thread... There's a flickering checkerboard pattern in some terrain tiles, distracting, but perfectly playable. Let me know if you think this is related or a separate issue.

That is a separate issue. Now that I think about it, it happens on my computer too! I just got so used to it that I don't notice anymore :-) We should fix this.

Hah. I also got the checkerboard pattern once, but it disappeared when I switched to low-graphics, so I ignored it

cube wrote:... and we have a work around: In 0.10.3 there is a new config option max-texture-size in the [graphics] section of config.ini.
Setting it to 4096 helped in my case

I had issues when I first ran the game, even the main menu was horrible to use but this has fixed all my issues.
Just wanted to add that in, I can also help with debugging it if needed. I'm a Java/Scala programmer with work in assembly so I might be better than the average user for help

(I might even be able to allow remote connection so you can just get on and work on my computer as if it was there...)

Where has the option gone in 0.11?

lordoflinks wrote:Where has the option gone in 0.11?

I just added the line into the config and it worked

Just to confirm, I'm using 0.12.14 on Xubuntu 14.04 x64 with an old Intel GM45 Express chipset and at first, most of the menu backgrounds were missing. This was resolved by editing the config.ini and setting the video-memory-usage to low. Then, a lot of the in-game textures were missing. I stumbled across this post via Google and setting the max-texture-size to 4096 in the config resolved the missing textures (it was set to 0 by default).

EDIT: Specified Linux distro