RetroPie forum home
    • Recent
    • Tags
    • Popular
    • Home
    • Docs
    • Register
    • Login
    Please do not post a support request without first reading and following the advice in https://retropie.org.uk/forum/topic/3/read-this-first

    Solution for " White Screen of Death "

    Scheduled Pinned Locked Moved Help and Support
    145 Posts 20 Posters 88.6k Views
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • fieldofcowsF
      fieldofcows @mattrixk
      last edited by fieldofcows

      @mattrixk said in Solution for " White Screen of Death ":

      (I'm still sad about not being able to use fan-art though)

      What do you need for this to work?

      mattrixkM 1 Reply Last reply Reply Quote 0
      • mattrixkM
        mattrixk @fieldofcows
        last edited by mattrixk

        @fieldofcows said in Solution for " White Screen of Death ":

        What do you need for this to work?

        I don't know how much work it would be (and I've mentioned it on another thread), but I'd love it if we could have the option to add multiple images to a ROM.

        On vanilla ES, there is only one Image field in the metadata (<image name="md_image">), but in your Video Preview mod, there is also <image name="md_marquee">, so I'm curious how hard it would be for you to add more Image fields to the metadata.

        I suppose the easiest would be just having a second Image field (called <image name="md_image_2"> or something), which I could use for fan-art, but to be honest, I think it would be fantastic to have a separate Image field for each Image:

        • Fan-art
        • Box-art
        • Screenshot
        • Game Logo
        • Marquee

        That way a themer could have a lot more display options. There may be others, but I think they are the main ones. Maybe even an "md_image_misc" just for use with random images someone might want to put in there.

        While I'm on the subject, would it possible to change the z-index of all the metadata fields? At the moment, I think "md_image" sits on top of everything else, no matter where the code for it sits in the XML file. It would be great if we could set the hierarchy of all the metadata fields so we could put anything in front of anything else.

        EDIT: an idea for sparking the WSOD:

        You can take empty .TXT files and name them game.zip and put one in each system folder. The systems accept take zip files will read these as games and show that system on the System view (you obviously won't be able to scrape or play them, but you won't need to).

        Then change to the Simple theme (or another theme with 1080p background images). If you don't have enough systems, go through them one at a time and change game.zip to game.[whatever extension that system accepts] until you have enough to cause the WSOD.

        (I haven't tested this, but it should work)

        My ES themes: MetaPixel | Spare | Io | Indent

        1 Reply Last reply Reply Quote 0
        • K
          KillerQ @Rookervik
          last edited by

          @Rookervik said in Solution for " White Screen of Death ":

          @mediamogul Video Previews and Image Previews are loaded as-needed. Once you change your game selection, the old image is unloaded and the new image is loaded. You shouldn't ever run into WSOD just from previews. Previews are not part of the big canvas. They're overlays.

          I tried to use this as a tricky way of having infinite wallpapers, but alas, the image previews load over the top of EVERYTHING else on the screen except the Logo graphic.

          Thanks for all the info. Reducing image sizes the simple theme allowed me to have 23 systems with no issues whatsoever - but it's still a bandaid.

          You mentioned hat video clips are treated differently as they load when the system is selected - as opposed to being always on and loaded in the background similar to the background canvass.

          What if you told each system selection screen to have a one second (to reduce waste) fullscreen 1080p video clip hat remains paused. This would serve the same purpose, but I wonder if it could be forced into the background?

          Just thinking out loud.

          RookervikR 1 Reply Last reply Reply Quote 0
          • RookervikR
            Rookervik Global Moderator @KillerQ
            last edited by

            @KillerQ It's a hack, but it sounds like it would work. But if you're going to tweak ES to load a video in the background, just tweak it to load an image in the background as soon as the screen has stabilized. Either way, it won't look pretty when you're changing systems. But after you get into the next system and the background loads it will be fine.

            I, for one, don't really care to have a different wallpaper for each system. There are a lot of tricks you can do to make wallpapers different for each system that don't require big full-screen graphics. Tint the wallpaper, add small images to it, and so on. You just have to be a little creative.

            If having a different wallpaper is that important, use Attract Mode. That already supports a different theme for every system. :D

            1 Reply Last reply Reply Quote 0
            • K
              KillerQ
              last edited by

              Thanks for the quick reply. There MUST be some way to crack this problem. There ls always a way - lol.

              I'm tempted to try split images or something else out of the box.

              I'll report back.

              I'm also gonna figure out how to have it load a background once the screen is stabilized for a particular system.

              1 Reply Last reply Reply Quote 0
              • fieldofcowsF
                fieldofcows
                last edited by

                Ok, I may have a simple-ish fix for this. I've just tried modifying the TextureResource component in EmulationStation to keep textures in conventional RAM instead of texture memory and only use texture memory when bound during rendering, freeing it once the render operation is complete.

                On my Linux system this works perfectly and there is no noticable delay when rendering the images. I have yet to try this on the RPi to see if it works ok. I'll give it a go and report back.

                Just as an illustration, I've logged the texture memory that would have been used with the current ES compared with the texture memory used in my modified ES for textures - note that this does not include textures used by fonts at the moment so doesn't give the total texture memory that is used.

                Theme used: Nismo's excellent OldRoom 720p theme (maybe not the latest version)
                Number of systems: 13
                Texture memory used by TextureResource in current ES: 97Mb
                Texture memory used by TextureResource in new ES: 3.5Mb

                Fingers crossed this may be a solution for the WSOD problem :D

                mattrixkM 1 Reply Last reply Reply Quote 5
                • mattrixkM
                  mattrixk @fieldofcows
                  last edited by

                  @fieldofcows said in Solution for " White Screen of Death ":

                  Texture memory used by TextureResource in current ES: 97Mb
                  Texture memory used by TextureResource in new ES: 3.5Mb

                  I don't know much about what you are doing, but that number difference is none-the-less very impressive.

                  My ES themes: MetaPixel | Spare | Io | Indent

                  fieldofcowsF 1 Reply Last reply Reply Quote 0
                  • fieldofcowsF
                    fieldofcows @mattrixk
                    last edited by

                    Well my change definitely seems to solve the problem but it still needs a little bit more work. Regenerating the texture on every render is a bit too much for the poor RPi to handle so it makes the rendering sluggish. It shouldn't be too hard to fix.

                    I tried 'zoid' and 'oldroom 1080p' themes with the maximum amount of systems. Without my changes both failed to render. With my changes they rendered fine, albeit slowly.

                    1 Reply Last reply Reply Quote 2
                    • fieldofcowsF
                      fieldofcows
                      last edited by

                      Well, that's sorted it. I've put a bit of caching in there so I track on every render when a texture has been used or not and purge any texture that was not used in the last render frame. It is automatically recreated on the next render where it is used. This sorts out the performance issue.

                      So, large 1080p themes on RPi are a go :D

                      It's not the most elegant fix but short of reengineering the whole texture code I think it's adequate. I don't suppose the community will complain as long as it fixes the problem...

                      I need to do a bit more testing before I submit this fix. Can anybody suggest some good themes to try that you would normally expect to cause the white screen of death?

                      M mattrixkM 2 Replies Last reply Reply Quote 5
                      • M
                        MWGemini @fieldofcows
                        last edited by

                        @fieldofcows I'm currently using a modified version of the tronkyfran theme, with 18 systems on the main carousel, and videos in one of the systems. At version 2.1.0RP of ES, I did not have a WSOD issue (with an increase memory split of 384- default mem split did cause WSOD). With the latest update (2.1.2RP), I'm getting partial white screens on several systems.

                        fieldofcowsF 1 Reply Last reply Reply Quote 1
                        • mattrixkM
                          mattrixk @fieldofcows
                          last edited by

                          @fieldofcows I know lots of people complained about the original "Simple" theme, but I haven't tried it myself (by the time I came along, Carbon was the default for RetroPie on the Raspberry Pi).

                          My ES themes: MetaPixel | Spare | Io | Indent

                          1 Reply Last reply Reply Quote 1
                          • fieldofcowsF
                            fieldofcows @MWGemini
                            last edited by

                            @MWGemini That's a big theme! I've just tried it with 62 systems if I counted that correctly on my RPi3. I haven't changed the memory split - everything is in it's default configuration. It works!

                            A couple of the backgrounds are rendered a bit blurred. I'm not sure if that's my change or something else but I'll investigate.

                            The other issue is that my caching will consume a fair amount of RAM. I'm not sure if that is going to cause any problems.

                            M herb_fargusH 2 Replies Last reply Reply Quote 0
                            • fieldofcowsF
                              fieldofcows
                              last edited by

                              Commit is here if anybody fancies reviewing the code:
                              https://github.com/fieldofcows/EmulationStation/commit/b4ad5eeda104b166667b8d4bc5262c925f6f86a3

                              1 Reply Last reply Reply Quote 5
                              • M
                                MWGemini @fieldofcows
                                last edited by

                                @fieldofcows 62 systems without a WSOD? Wow! As for blurred backgrounds, I know that at least a few are blurred on mine. Off the top of my head, Sega 32x and Sega CD are both blurred game images, and PC is a slightly blurred PC image. All of the other systems I have in my collection have pretty crisp backgrounds.

                                With regards to the caching, will that be cleared or garbage collected when a game is launched? If not, I can try to pull down your changes and run a few of the more demanding games in my collection and see if I notice any significant performance changes. I'm guessing that PSX, N64 and Dreamcast will be the heaviest, but I don't have any sort of memory profiling system set up currently, so the best I can do is provide anecdotal evidence.

                                dankcushionsD 1 Reply Last reply Reply Quote 1
                                • herb_fargusH
                                  herb_fargus administrators @fieldofcows
                                  last edited by

                                  @fieldofcows if you're talking about some blurred images on the tronkyfran theme, some I think were reduced to 720p which may have cause some blur on downscaling perhaps, also the default simple images were left for systems tronkyfran didn't create a wallpaper for. might have to check against other images you know are full HD just to see if it's reproducible but I'm just guessing it's the incompleteness of the theme

                                  If you read the documentation it will answer 99% of your questions: https://retropie.org.uk/docs/

                                  Also if you want a solution to your problems read this first: https://retropie.org.uk/forum/topic/3/read-this-first

                                  1 Reply Last reply Reply Quote 0
                                  • dankcushionsD
                                    dankcushions Global Moderator @MWGemini
                                    last edited by

                                    @MWGemini said in Solution for " White Screen of Death ":

                                    @fieldofcows 62 systems without a WSOD? Wow! As for blurred backgrounds, I know that at least a few are blurred on mine. Off the top of my head, Sega 32x and Sega CD are both blurred game images, and PC is a slightly blurred PC image. All of the other systems I have in my collection have pretty crisp backgrounds.

                                    With regards to the caching, will that be cleared or garbage collected when a game is launched?

                                    i second this question. if it remains in system memory, if i use a lite theme (pixel) i'd personally want it to use my VRAM over my system ram. VRAM is barely used in retropie outside of emulationstation, but system ram can be used a lot in mame games with large samples, or system compilation.

                                    fieldofcowsF 1 Reply Last reply Reply Quote 0
                                    • fieldofcowsF
                                      fieldofcows @dankcushions
                                      last edited by

                                      @dankcushions, @MWGemini
                                      Yes, I too am concerned about memory usage in this situation so I'm looking at ways to mitigate this. There are two things I plan on looking at:

                                      1. Compressing the images when stored in RAM
                                      2. Freeing RAM for unused textures and reloading from disk where necessary

                                      Compression is easy and will save a large amount of space on most themes. For example, the zoid theme is 36Mb on disk but takes >350Mb of texture memory when it is uncompressed. I'm not sure how much of a delay this will cause on the pi when decompressing just in time for rendering.

                                      The second option may cause significant delay problems due to the speed of SD card storage.

                                      Also, I may try to implement a priority cache where we can set a maximum VRAM usage and purge only the oldest entries to free room for new textures - this in conjunction with 1) or 2) above should hopefully sort us out.

                                      Anyway, I'll try both these and see what happens.

                                      1 Reply Last reply Reply Quote 1
                                      • K
                                        KillerQ
                                        last edited by KillerQ

                                        Nice work.

                                        I released a bandaid for this as well that involved a nice picture resizing algorithm that reduced picture sizes without a notcible difference - but your solution seems more appropriate.

                                        The TronkyFran theme is the best to test with this since the images are so crisp, any resolution is immediately noticible.

                                        Also, a few of the screens on the tronky theme revert to manually blurred images. Ignore those, and just focus on the system console photos.

                                        Email me at mattborkin@gmail.com if you need me to test anything out. I've been working on this for weeks.

                                        Thanks.

                                        fieldofcowsF 1 Reply Last reply Reply Quote 1
                                        • fieldofcowsF
                                          fieldofcows @KillerQ
                                          last edited by

                                          Hi @KillerQ,

                                          Yes the tronky theme is definitely the one to test with. The images are huge. They render perfectly with the exception of a few (e.g. Virtual Boy, Wii, WonderSwan/color, Dragon32, etc.) so I think they are just incomplete images in the theme.

                                          Thanks for the offer of testing. I'm nearly ready to produce a good version of the fix - just a few things to iron out which I'll detail in a minute. The more testing the better :)

                                          1 Reply Last reply Reply Quote 1
                                          • fieldofcowsF
                                            fieldofcows
                                            last edited by

                                            Right, so it works. I've tried a couple of things out and it seems that dynamically loading and unloading the images rather than keeping them cached in RAM is the way to go. It does cause a bit of a delay when scrolling the carousel when using very large images (TronkyFran) but for smaller themes it is not noticable.

                                            I need to finish a few things off before this is complete:

                                            1. Tidy the code - it's still a bit experimental
                                            2. Implement a texture cache where you can set a maximum VRAM size and it will only purge the oldest textures when this limit is reached - this should prevent the jerkyness on configurations where the WSOD was not previously happening
                                            3. More testing

                                            I've added the memory usage to the FPS display and get the following numbers:

                                            Zoid Theme:
                                            Font VRAM 25.17, Tex VRAM 8.90 Tex RAM: 0.00 Tex Total: 381.20

                                            Oldroom (1080p) Theme:
                                            Font VRAM 20.97, Tex VRAM 8.51 Tex RAM: 0.00 Tex Total: 157.91

                                            TronkyFran Theme:
                                            Font VRAM 25.17, Tex VRAM 17.31 Tex RAM: 0.00 Tex Total: 495.21

                                            All the above had ~65 configured systems but each theme does not support all of them. An explanation of the fields:

                                            Font VRAM: VRAM used in Mb to store font textures
                                            Tex VRAM: VRAM in use for images and icons
                                            Tex RAM: This is the one that I was using a lot of in my previous version - amount of system RAM used by textures. Now this is generally zero
                                            Tex Total: The amount of texture memory that would have been used without my fix in place

                                            dankcushionsD M 2 Replies Last reply Reply Quote 5
                                            • First post
                                              Last post

                                            Contributions to the project are always appreciated, so if you would like to support us with a donation you can do so here.

                                            Hosting provided by Mythic-Beasts. See the Hosting Information page for more information.