Slow Tic80 is back.

[aykaramba]

Hi guys.

Just dropping in to mention that slow Tic80 issue is back. It showed up early on in 1.0, got fixed with an updated and compiling from scratch and now the issue is back in version 1.1.2837 Pro. I just downloaded it from itch.io and installed it on Debian 11.

I will try compiling from source.

[aykaramba]

Compiles from source version 1.2.2867-dev Pro. The slowness is present here as well. I don't know what it is but it feels like this is something as simple as decrease of frame rate by 50%, maybe as a result of doubling of some value somewhere else in the system?

Anyway, thx for a fun system. Let me know if I can help and do more testing.

[nesbox]

As I remember previously it was a problem with clock() function 0cd38fd3044fb856be1c9a9db4fc2e1191c696e9

[cdwfs]

I'm seeing the same symptom with a from-source build of 1.1.2837-pro for a Raspberry Pi 5. Curiously, I thought I'd built the same version with the same options for the RPi400 which the Pi5 replaced, but I didn't see ther same slowdown there.

[cdwfs]

Update: for me, it's specifically when I run tic80 in fullscreen mode (whether I pass --fullscreen on the command line, or switch at runtime). When not in fullscreen, things seem to run at full speed; with fullscreen on, everything's chopped & screwed. So, possibly something with the fullscreen upscaling code -- does that sound plausible?

My display is only 1280x720 at 60Hz, so I don't think I'm trying to push a ludicrous number of pixels. As further evidence, if I manually maximize the window to cover nearly my whole desktop, the frame/audio rate is still fine (with or without "integer scale" mode enabled). It's only when I enable fullscreen mode that the slowdown kicks in.

[cdwfs]

Another update: the problem doesn't occur if I force software rendering with --soft on the command line, even in fullscreen mode.

[nesbox]

Could pls someone test it with the disabled lines in src/system/sdl/main.c

[aykaramba]

That seems to work. Just to confirm, the tic80 binary is in the bin dir and labeled player-sdl, correct? That plays my tic files are normal speed.

Anyone else?

[cdwfs]

I must have a different problem. I tried building the main branch today (commit 3cf27c5). Without modifications to sdl/main.c (which includes the else branch in the screenshot) running bin/tic80 --fullscreen is still running slowly on my Pi5, while bin/tic80 (not full screen) runs at normal speed.

Commenting out the else branch and rebuilding, I see no change to this behavior.

[aykaramba]

Correction: I was wrong, re-compiling with lines 1926 & 1927 removed and Tic80 is slow playing local tic games or downloaded over the internet.

My apologies for the false positive in the original follow up. If I had the skills I would help track this down.

Thank you kindly for this great open source project, it really is appreciated. I can always use an older version so I am good. I hope my follow up provides useful in some way.

[msx80]

Hi there, i observe the same behaviour as @cdwfs. On Raspberry Pi 5 Tic80 runs fine when windowed or maximized (still windowed), but slows down considerably when fullscreen. Strange thing is, when fullscreen is basically the same size as maximixed, so i don't think it's about performances. Top tells me tic80 stays at about 30% cpu utilization even when slowed.

I tried to comment the two lines as shown by @nesbox but no change in behaviour. I commented also the previous two (including the one with the delay) and still no change in behaviour, which is kind of strange i think. Shouldn't it run as fast as possible in that situation?

I'll keep investigating a bit

[msx80]

So i got something: i turned to player-sdl. It only runs in windowed mode, but if i add the following line SDL_SetWindowFullscreen(window, SDL_WINDOW_FULLSCREEN_DESKTOP); before the main while loop, it goes fullscreen and runs at normal speed (no slow down!). If i then comment the lines dealing with the delay (SDL_Delay), then the game goes ultra fast, just as expected.

It kind of looks like main.c is doing a delay check somewhere else other than the main loop.

[aliceisjustplaying]

watching this thread, no promises but i do have a RPi4 and a RPi0W and i hope to test this sometime

[aliceisjustplaying]

can repro the slow full screen on the latest RPi OS (64-bit) on the RPi4 at last.

[msx80]

@cdwfs are we sure it's not an Rpi5 issue? i tried to chage display from Wayland back to X and it seems to have improved a lot in fullscreen. You can change it with raspi_config

[aykaramba]

I am running X on on AMD64 though.