Hi!
I'm fine, thanks :-) hope you too.
1. Window resizing: It could be possible to change the window at runtime, of course. I limited the ability to dinamically resize it in order to keep consistent integer scaling. Pixel art doesn't play well with arbitrary scaling. The only exception is fullscreen scaling, where non-integer scaling happens. This gets mitigated by the use of CRT post-processing. Talking about CRT effect, the overlay texture gets built for whatever resolution the window is using. Should I add dinamyc resizing, the current overlay would be kept during resizing until releasing the mouse button, where the new overlay would be built. Rebuilding it in realtime for each mouse event during drag would be overkill.
2. Framerate limiting. This feature has been already mentioned in the past, but it can be tricky. Let me explain. In modern 3D games, keyframed animation uses natural time as pacekeeping (milliseconds), and the game engine interpolates intermediate frames in realtime. So having different refresh rates is quite trivial, as the source material is expressed in time, not frames. However, hand-drawn pixel art has a finite set of discrete frames that have been pre-drawn with a specific frame-rate in mind. Game logic usually has the frame as the basic unit of pacekeeping, not time. Like "set sprite animation and keep it 4 frames before setting the next one" instead of "delay 66.6666 ms". This leads to smooth, predictable animation speed at the cost of flexibility. Pacekeeping with time instead of frame is possible, but it will lead to jerky animation, as rounding time to the nearest frame won't get integer results, and rounding errors will translate to uneven frame rate.
Sure I could add a mechanism to set a target frame-rate for animations so the engine would delay or skip frames as needed. But the main issue is that Tilengine only handles graphics, but the game logic itself, implemented on the application layer, should be variable frame-rate-aware, too. Your game character can't have the speed expressed in pixels/frame, for example. So it's not just a problem on the graphics side, but of the game implementation in general.
3. Shaders. SDL2 doesn't support shaders per se, it's the underlying OpenGL context that allows you to play with them. For built-in window rendering I use basic SDL2 primitives, not direct OpenGL access. Of course you could implement a Window.c replacement that uses GLSL shaders instead of SDL2 primitives. But I find much more convenient to just ship the game bundled with reshade with just crt-lottes shader included and configured for whatever resolution your framebuffer uses. Have you tried it?
I'm fine, thanks :-) hope you too.
1. Window resizing: It could be possible to change the window at runtime, of course. I limited the ability to dinamically resize it in order to keep consistent integer scaling. Pixel art doesn't play well with arbitrary scaling. The only exception is fullscreen scaling, where non-integer scaling happens. This gets mitigated by the use of CRT post-processing. Talking about CRT effect, the overlay texture gets built for whatever resolution the window is using. Should I add dinamyc resizing, the current overlay would be kept during resizing until releasing the mouse button, where the new overlay would be built. Rebuilding it in realtime for each mouse event during drag would be overkill.
2. Framerate limiting. This feature has been already mentioned in the past, but it can be tricky. Let me explain. In modern 3D games, keyframed animation uses natural time as pacekeeping (milliseconds), and the game engine interpolates intermediate frames in realtime. So having different refresh rates is quite trivial, as the source material is expressed in time, not frames. However, hand-drawn pixel art has a finite set of discrete frames that have been pre-drawn with a specific frame-rate in mind. Game logic usually has the frame as the basic unit of pacekeeping, not time. Like "set sprite animation and keep it 4 frames before setting the next one" instead of "delay 66.6666 ms". This leads to smooth, predictable animation speed at the cost of flexibility. Pacekeeping with time instead of frame is possible, but it will lead to jerky animation, as rounding time to the nearest frame won't get integer results, and rounding errors will translate to uneven frame rate.
Sure I could add a mechanism to set a target frame-rate for animations so the engine would delay or skip frames as needed. But the main issue is that Tilengine only handles graphics, but the game logic itself, implemented on the application layer, should be variable frame-rate-aware, too. Your game character can't have the speed expressed in pixels/frame, for example. So it's not just a problem on the graphics side, but of the game implementation in general.
3. Shaders. SDL2 doesn't support shaders per se, it's the underlying OpenGL context that allows you to play with them. For built-in window rendering I use basic SDL2 primitives, not direct OpenGL access. Of course you could implement a Window.c replacement that uses GLSL shaders instead of SDL2 primitives. But I find much more convenient to just ship the game bundled with reshade with just crt-lottes shader included and configured for whatever resolution your framebuffer uses. Have you tried it?