Issues with custom overlay
Opened this issue · 5 comments
Hey, loving tilengine so far!
BuildFullOverlay()
expects the format of the custom overlay surface to be a rgba8888 but when you call SDL_loadBMP()
it doesn't convert the surface. This ends up yielding different results depending on how the bitmap is saved. I was able to get around it by changing it to convert the surface after loading.
additionally it doesn't go through LoadFile()
so if you are hoping to save your overlay image in a resource pack you're SOL
Hi!
I'm glad you're enjoying tilengine :-)
Can you attach the bitmap you're trying to use as an overlay and a screenshot of the result?
Any bitmap you use will come through wrong because there's no way to save a bmp in the format it expects. Here's mine:
I've also got some thoughts on how the overlay is displayed (its wrong if you're going for an authentic look). It should be aligned per scanline of the backbuffer. Currently it's aligned with the window size, which depending on your window size will create a misalignment.
I urge you to check out this vid: https://youtu.be/3BJU2drrtCM?t=201 You can clearly see each scanline has its own 'overlay' aligned with it.
I fixed this in on my end by adjusting the BuildFullOverlay function to build the size based not on the window size but on the backbuffer size multiplied by the size of the overlay.
Not sure if you want an issue created for this as there may be a taste/artistic liscence at play here. but I thought I'd bring it up anyways
Hi!
I'll check the bmp format -I suppose red and blue are swapped-, as stock overlays are hard-coded inside the source code, the bmp -> overlay feature is hardly used and may have been rolled out untested.
Regarding the CRT alignment effect, yes, I know you're right. What I intended here is to create a built-in CRT+RF effect that is looks "good enough" without using too much power. For this, I build a single bitmap overlay that combines both the RGB mask and the scanlines and applies it in a single pass. This is not accurate, but approximates the look and feel without using much resources. An accurate CRT emulation requires several passes and layers, applying the RGB mask and the scanline mask at different scaling levels (2x framebuffer vs upscaled window), full window resolution blurring and composing for glow emulation, etc. I could do it, but it would be a performance overkill. That's why some awesome CRT filters out there like CRT Royale are performance killers. It also may require usage of pixel shaders that aren't implemented in the window pipeline right now. But I have a private development branch in which I use upscaling/dowscaling and render targets to get fast blurring on basic hardware.
That said, I love challenges, and I'm tempted to try this accurate multi-pass emulation on my branch to see if I can achieve a notably superior emulation without sacrificing performance. This is tricky because after applying all that passes, you have to keep original brightness and contrast, and the mixing becomes complex if you don't want to end with an overexposed or desaturated image that isn't accurate.
Thanks for your interest in this issue!