My game lags on Steam.

[Joubarbe]

I've posted a very detailed post of my problem on Steam: https://steamcommunity.com/groups/steam ... 1763746079

Roots of Harmony is not 3D accelerated, and it works with a canvas that I update every time I receive a "refresh request" event, basically after each user interaction. On Steam, the game is a lot slower. For instance, the world generation takes about 20 times longer than it does on my own PROD version. If I don't DRM the exe, and I run it outside of Steam, there's no problem. If I run it through the Steam launcher (whether or not it has the DRM), it's slower.

There's something Steam doesn't like about a game that doesn't really run like a game, and I don't know why. Maybe some of you would know?

UPDATE: If anyone wants to help, please download the demo, and try 1/ via the steam launcher 2/ via RH.exe. The world generation ("Generate hope") should take about 4 seconds via Steam, and be instant via RH.exe. If not, please report!

[Fred]

Did you try to have a log file to see how much refresh you do ? So you could compare with and without steam

[Joubarbe]

What I tried was to get a few ElapsedMilliseconds() in a few functions, and all of them takes longer.

When the game loads, it has a single popup, and the refresh function is not called. Only once to show the modal, and another time to remove it once the loading is over.

EDIT: I'll try anyway, thanks
EDIT2: Nope, there's no difference:

Code: Select all

[INFO] 11:06:56 RenderTerminal(): 10
[INFO] 11:06:56 RenderTerminal(): 60
[INFO] 11:06:56 RenderTerminal(): 121
[INFO] 11:06:56 RenderTerminal(): 197
[INFO] 11:06:56 RenderTerminal(): 260
[INFO] 11:06:56 RenderTerminal(): 311
[INFO] 11:06:56 RenderTerminal(): 372
[INFO] 11:06:56 RenderTerminal(): 447
[INFO] 11:06:56 RenderTerminal(): 509
[INFO] 11:06:56 RenderTerminal(): 571
[INFO] 11:06:56 RenderTerminal(): 634
[INFO] 11:06:57 RenderTerminal(): 909
[INFO] 11:06:57 RenderTerminal(): 929
[INFO] 11:06:57 RenderTerminal(): 1421
[INFO] 11:06:57 RenderTerminal(): 1476
[INFO] 11:06:58 RenderTerminal(): 2341
[INFO] 11:06:58 RenderTerminal(): 2652
[INFO] 11:06:59 Starting event 'intro'.
[INFO] 11:06:59 RenderTerminal(): 3329
[INFO] 11:07:00 RenderTerminal(): 3846
[INFO] 11:07:04 RenderTerminal(): 8368
[INFO] 11:07:04 RenderTerminal(): 8382
[INFO] 11:07:04 RenderTerminal(): 8397

Nothing alarming, that's not thousands of events.

[Fred]

May be you can try to pinpoint which part is slower using elapsed milliseconds

[Joubarbe]

That's the thing. It's super hard to find out. I used ProcMon, and I can see that every write and read operation (text files) is slower; basically everything the program does is slower in every operation. I don't know what to do with that information. My understanding is that everything is slower, not only a specific part. I thought about antivirus, but no. I'm still awaiting for Steam support...

EDIT: if someone wants a key to take a look into it, I'll gladly provide one!

[benubi]

Wild speculation:

I could suspect that this may be connected to the UI overlay Steam uses. Perhaps the overlay has to read the image & redraw it (with no additions), and then return it in a "copy by value" way or something like that (drawing hook). I'm not an expert but maybe there are possibly anti-cheat systems that also may interfere in a similar way, but I would be surprised if they used something on your app without you knowing about it.

Edit: you can enable/disable steam overlay in the properties of the game (general options)

[Joubarbe]

Agree. The thing is the overlay doesn't work with my game. Probably because of non 3D acceleration. But then on ProcMon, you see the game overlay log being written on... So I guess there's always a process in the background...

[benubi]

It may have a fallback mechanism for console & window applications and this is much slower because it has to copy the image multiple times between the processes - but that's just my theory. Something must be blocking between the updates. My other thought was that your application waits for remote network events between the frames and it's the latency / round trip time. Then the overlay process may just start and fail all the time, looking for a 3d-hook possibility that never shows up, because there is no fallback mechanism.

Have you tried switching the overlay out?
I hope I'm onto something

[Joubarbe]

Thank you for trying anyway!

Activating or deactivating the overlay doesn't make any difference. I've even tried to end the Steam process while the game was running, and it continues to be super slow.

I'll need to check the demo tomorrow, so that you can try. I'm not super sure which internal version it's running, but the result should be the same.

[idle]

Are you composing render directly to canvas or composing to image then canvas?
I don't know anything about steam so just guessing

[Joubarbe]

Are you composing render directly to canvas or composing to image then canvas?
I don't know anything about steam so just guessing

Directly to canvas. Do you think that would make a difference?

[idle]

Are you composing render directly to canvas or composing to image then canvas?
I don't know anything about steam so just guessing

Directly to canvas. Do you think that would make a difference?

Yes it makes a bit of difference though I think it's more to do with the drawing mode of the canvas aditionaly if you render in a thread to an image you can then free up the event loop and pole that image to the canvas at whatever rate you need.
I was experimenting with caching in the avgscenegraph and I noticed an improvement switching to composing to an image even before threading it.

Can you run native threads with steam?
Is steam hooked into your event loop?

[Joubarbe]

I don't use threads, but that wouldn't be a problem with Steam. It just runs the .exe.

Steam hooked? There's no link with Steam within my program.

Yeah, maybe there's something wrong with the event loop. I'll investigate.

[idle]

It sounds Like it's virtualize the exe.
And if it's due to drm it maybe decrypting the datasection access on demand.
The asm backend all immediate Strings are stored in the datasection.
C backend they are stored in static char arrays which may still be in the exe code section.

So if your using asm backend you can easily try with c backend to see if there's a difference.

And if you can't use c backend then you would need to load all the Strings into an array from the datasection.

[Joubarbe]

There's no difference between ASM and C.

The demo behaves the same as the game: slow through Steam, instant through RH.exe (world generation).
There is a guy on the Steam forum who says that he doesn't see any difference on Win7 and Win10. I'm using Win11.

My main loop is:

Code: Select all

Repeat : WaitWindowEvent() : ForEver

Not much to see there!