search

afritz1 / OpenTESArena

Open-source re-implementation of The Elder Scrolls: Arena.
MIT License
988 stars 68 forks source link

No text or parchment UI rendering on Raspberry Pi 4 #198

Closed afritz1 closed 3 years ago

afritz1 commented 3 years ago

When compiling and running current master https://github.com/afritz1/OpenTESArena/commit/72acacfb5e0b10561aae0a78a9c0c630cd58053a on a Raspberry Pi 4, there is no rendered text anywhere in-game and certain pop-up parchment screens (from .CIF tiles) are not displayed.

I think the issue is because bit manipulation behaves differently on ARM devices. It might be signed/unsigned right shifts that are the problem.

https://github.com/afritz1/OpenTESArena/blob/771bfa8c1053bddbbbea37896d725105a402128e/OpenTESArena/src/Assets/FontFile.cpp#L69 https://github.com/afritz1/OpenTESArena/blob/771bfa8c1053bddbbbea37896d725105a402128e/OpenTESArena/src/Assets/FontFile.cpp#L111 https://github.com/afritz1/OpenTESArena/blob/13cfe69c20c844b341f56aebc1e12763d9c601e9/OpenTESArena/src/Assets/Compression.h#L49

afritz1 commented 3 years ago

Possible test case: check the value of mask in FontFile.cpp after being right-shifted to see if it brings in 0's or 1's for the bits. Print results on x86 machine and ARM64 and see if they differ.

Also see if the size of the integer makes a difference.

afritz1 commented 3 years ago

Looks instead like the problem is around SDL_BlitSurface(), like the SDL_Rects are being clamped in a strange way. Using a manual for loop to copy the pixels seems to make the text render but doesn't handle the text shadow properly. The src and dst SDL_Rects might be given the wrong values, or they are interpreted differently on ARM, or something else. I noticed that the SDL version was 2.0.9 -- I've been developing mostly with 2.0.4 and maybe something changed between then.

https://github.com/afritz1/OpenTESArena/blob/771bfa8c1053bddbbbea37896d725105a402128e/OpenTESArena/src/Interface/TextBox.cpp#L83

Allofich commented 3 years ago

Probably a low chance that this is the issue, but doing a search for SDL_BlitSurface() problems and ARM, I found this: https://stackoverflow.com/questions/4476792/cant-set-video-mode-for-sdl-screen-on-embedded-device

Could the lack of a mouse or other things be affecting SDL's initialization like the person there says?

afritz1 commented 3 years ago

Hmm, not sure. My Raspberry Pi is built into a keyboard and has a mouse, so it's basically a standard desktop environment. That Stack Overflow question is also for SDL 1 which might be too old to be useful.

afritz1 commented 3 years ago

I'd like to have this done for 0.13.0 so I can put ARM64 support in the release changes, although I am not sure I will put a build there since the current severe performance issues on that device mean that whoever wants to run it should compile it themselves with max optimizations (-Ofast, -flto, -march=native, etc.) to get workable FPS. A build with -march=native might be compatible but I don't want to chance it. I'm also not comfortable enough with how to distribute shared libraries for Linux builds.

Some simple performance tests on the chunk-system branch (#200):

I don't want to say this text/parchment issue is an SDL bug because a bug of this kind seems highly unlikely, but it's possible. I have some replacement code I can add that simply does the source->destination pixel copy manually instead of relying on SDL_BlitSurface().

afritz1 commented 3 years ago

Fixed in commit a387d9f9c7d584ddf8b425e9da8d92951a77313a. Note that the workaround applies anywhere the engine is used with SDL 2.0.9. That was just the most obvious fix for this, and like I noted in the commit, it doesn't really affect performance at all.