itch.io

Ah ok. So when you've tried it up until now, did you move all of your Draw GUI code into the Post Draw event, and used crt_draw_begin() and crt_draw_end() BEFORE the crt draw method is called?

If you haven't already, you might try using the GUI demo included the package, and seeing if you can get your game's GUI to work properly there in the example project. That would help figure out where the issue is.

So that I'm sure I understand, you want your GUI to be drawn in front of the CRT? So not affected by it at all, just a clean GUI over top? If that's the case, then keeping your GUI code in the Draw GUI event should be fine. If it has a pixel aesthetic, then you might have to use display_set_gui_size() to make sure your GUI layer is the size that you expect.

Comparing your two screenshots, I can see that your game exhibits what are commonly called "mixels." Some sprites have chunkier pixels than others (said another way, the floppy disk is higher-resolution than everything else). When you run your game normally, GameMaker usually provides you with a high resolution framebuffer, which means that the camera and your sprite positions don't have to conform to a strict pixel grid. This is incompatible with the CRT shader, since CRT TVs expect a uniform, low resolution input. Your game might look like 320x240 or so, but is actually, secretly 1080p (or similar).

To solve this without having to get too down into the details, the CRT constructor provides the convenience function crt.draw_to_backbuffer(), which just wraps crt.draw:

static draw_to_backbuffer = function(source=application_surface) {
    // Prevent the application surface from being drawn over our work
    if (application_surface_is_enabled()) {
        application_surface_draw_enable(false);
    }
    
    // Ensure the application surface matches the internal content resolution
    if (surface_get_width(application_surface) != geometry.content_width) {
        surface_resize(application_surface, geometry.content_width, geometry.content_height);
    }
    
    // Render
    draw(source, 0, 0, window_get_width(), window_get_height());
}

This function automatically resizes the application surface down to your intended low resolution. But when the shader is disabled, you might prefer the look of the high-resolution rendering and the associated mixels. To restore this appearance after toggling the CRT shader off, you simply need to resize the application surface, and potentially the GUI surface, back to the native window dimensions (which is what GameMaker silently does for you by default).

if (global.crt_preset == CRT_PRESET_OFF) {
    var w = window_get_width();
    var h = window_get_height();
    // This should fix undersampled sprites and camera jitter by increasing the size of the framebuffer
    if (surface_get_width(application_surface) != w) or (surface_get_height(application_surface) != h) {
        surface_resize(application_surface, w, h);
    }
    // If this shrinks your GUI, then just comment it out (I don't know your setup)
    if (display_get_gui_width() != w) or (display_get_gui_height() != h) {
        display_set_gui_size(w, h);
    }
}

If I've interpreted your problem correctly, this should return your game's appearance back to what you expect. If you ever decide to make your game pixel-perfect, then this step won't be necessary. I hope this helps!

Hmm, I don't have any issues on my end, but I wonder if you're exporting to html5 or GX? window_get_height() might be reporting the canvas or display size incorrectly or something. I haven't been able to test non-desktop targets very extensively, but the canvas size could definitely be playing into it if that happens to be your target. As a quick band-aid fix, you can replace a couple of lines in the main fragment shader (shd_pass_dot_matrix). 

in pipeline_background() (line 46):

// Function that handles everything required for the background
vec3 pipeline_background(vec2 uv) {
    vec2 flipped_uv = uv; // New: create a new temporary variable
    flipped_uv.y = 1.0 - uv.y; // New: Flip the vertical UV
    vec4 bg_src = clamp(texture2D(u_blur_sampler, flipped_uv), vec4(0.0), vec4(1.0)); // Edit: pass flipped_uv instead of uv

In pipeline_main() (line 76):

// Sample the content
uv_main.y = 1.0 - uv_main.y; // <- New: flip the main UV
uv_shadow.y = 1.0 - uv_shadow.y; // <- New: flip the shadow UV
vec4 src_color = pow(texture2D(gm_BaseTexture, uv_main), vec4(1.0/u_content_gamma));
vec4 shadow_src = pow(texture2D(gm_BaseTexture, uv_shadow), vec4(1.0/u_content_gamma));

These just do an explicit flip of the main game surface to counter-act the flipping you're seeing. Depending what your export target is, I might be able to narrow down the source of the problem further. I hope this helps!

Just bumping to let you know I have an easy solution for your GUI question!

If you want GUI elements to be a part of the CRT, do this in any object's Post-Draw event. Just note that if you have an HD HUD over a pixel art game, it's gonna look weird. This works best for pixel HUDs at native game resolution. If you're using a view surface instead of the application surface as your CRT input, just add a reference to it as a parameter for crt_gui_begin().

crt_gui_begin();

draw_text(10, 10, "\n\nTest GUI");

crt_gui_end();

May I ask how long it takes for this to occur? Minimizing doesn't seem to matter on my end, but there could potentially be color precision issues after 2 or 3 hours for the NTSC effect, because the frame counter is unbounded. I would try replacing this on line 605 of CRTFunctions:

_frame_acc++;
_frame_counter = _frame_acc div max(1, floor(game_get_speed(gamespeed_fps) / 60));

With this:

var _div = max(1, floor(game_get_speed(gamespeed_fps) / 60));
_frame_acc = (_frame_acc + 1) mod (32768 * _div);
_frame_counter = _frame_acc div _div;

Let me know if that works out, and I can update the pack if so!

Thanks for providing that; I’ll see if I can replicate it on my machine this afternoon, and determine if it’s the CRT or the NTSC composite shader responsible.

Interesting… is there any way you can provide a screenshot of what’s going on? My first instinct is that maybe the window gets resized but for some reason the resize event isn’t getting triggered.

When you say you set a 16:9 aspect ratio, do you mean that you set crt.geometry.aspect_ratio to 16/9? The CRT struct's settings drive the mouse function, so if you only resize the viewport, it will be off. I've just tested setting it to 16:9 in the demo project and it works as expected for me; If it's still causing problems please let me know!

Hi Joyhop,

Thank you for your question and support! 

Eliminating the dark gaps between scanlines is still very much doable, It's just a bit of a different process due to the new physically-based scanline logic. Scanlines (that is, the bright electron beam, not the dark gaps) are now represented with Gaussian distributions that smoothly fade out after a certain width. Dark lines are thinner with more noticeable dark gaps, while bright lines are thicker and bloom into the surrounding gaps. The minimum and maximum size of the beam are controlled with the parameters CRT.lines.min_sigma and CRT.lines.max_sigma. To make the dark gaps disappear, all you need to do is set these parameters high enough to cause the beam to be very wide at all times. The included demo project actually has an example of this (press 7 to cycle through beam widths). In code, it just looks like my_crt.configure_lines({min_sigma:0.5, max_sigma: 0.5}); This should replicate the "no scanlines" look you're going for. I hope this helps!

Thanks,

Sitting Duck Games

hi tayfuntuna,

It looks like you replaced the view surface code with simply drawing the application surface; this solves the common issue in version 2 that occurs when developers don’t use the GameMaker viewport system. I’m glad you made it work for you!

If you don’t mind, I would love to hear your experiences regarding version 3; I want to ensure the extension is easy to use and free of bugs that prevent people from making good use of it. Would you be willing to shoot me an email at sitringduckgamesco@gmail.com? I would be happy to patch any issues you might be having or provide better documentation.

Thank you!

Hello,

This asset is only for GameMaker 2.3+, as it uses modern features such as constructors. If you dedicated a lot of time, it could be backported; however, this is not something I have any plans for, especially as GMS1 continues to age.

Thank you for your interest!

Hello,

Thank you for pointing out the missing license on the store page; This asset is licensed under MIT, as it includes derivative work of an MIT-licensed NTSC shader. You can already find the license declarations in the asset's main script, and in the NTSC shader code, but I've also included them below. I'll also be sure to add an easy license file to the downloads in addition to its current location in the .yymps

Asset Pack:

MIT License

Permission is hereby granted, free of charge, to any person obtaining a copy

of this software and associated documentation files (the "Software"), to deal

in the Software without restriction, including without limitation the rights

to use, copy, modify, merge, publish, distribute, sublicense, and/or sell

copies of the Software, and to permit persons to whom the Software is

furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all

copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR

IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,

FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE

AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER

LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,

OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE

SOFTWARE.

NTSC Shader:

Adapted from the following:

https://github.com/GlaireDaggers/Godot-RetroTV

MIT License

Copyright (c) 2024 Hazel Stagner

Permission is hereby granted, free of charge, to any person obtaining a copy

of this software and associated documentation files (the "Software"), to deal

in the Software without restriction, including without limitation the rights

to use, copy, modify, merge, publish, distribute, sublicense, and/or sell

copies of the Software, and to permit persons to whom the Software is

furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all

copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR

IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,

FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE

AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER

LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,

OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE

SOFTWARE.

The shader is designed to tile the phosphor mask against your screen at a 1:1 resolution, as is common in CRT shaders for emulation and retro gaming. There is, however, a parameter in the presets called mask_scale, that will simply resize the mask relative to your screen. If you want a fully consistent look regardless of screen resolution, I would probably recommend disabling the phosphors altogether, or using a neutral mask like the shadow mask. If you're hard-set on it, then what you would need to do is pick your "default" resolution, like 1080p, and then set crt.mask_scale = (1080 / window_get_height()) when necessary, such as after room transitions or when the window resizes. This would ensure there are a consistent number of phosphor triads between resolutions, but it can begin to look very broken at lower resolutions, so use with caution.

Sorry to hear about the issues. My first suggestion would be to ensure that it works on your own machine both in debug mode and as a packaged executable. Then, I would try setting your monitor to a few different resolutions and try running the game in and out of fullscreen mode. If all of those work, then I can only assume the issue lies with the other computer. Some possible things to look at include making sure graphics card drivers are up to date, DirectX or OpenGL are up to date (depending on export target), and that the other computer supports GameMaker's shader model. The shader doesn't use any extensions or HLSL-specific features, so my guess is that one of the above steps should expose the source of the issue. I hope this helps!

hello,

I’m sorry to hear the effect isn’t working for you. Are you trying to add it to an existing game? Does it at least work in the example project? If the example project doesn’t work, then you may need to update GameMaker or your video drivers.

Hello,

The random noise in the glow can be removed by changing one line in the glow() function of the shader:

Before: vec2 texel = gold_noise(uv * 1000.0, u_random_seed) * u_glow_spread / u_game_size;

After: vec2 texel = 0.5 * u_glow_spread / u_game_size;

This should give you the result you're looking for

Hello,

The random noise in the glow can be removed by changing one line in the glow() function of the shader:

Before: vec2 texel = gold_noise(uv * 1000.0, u_random_seed) * u_glow_spread / u_game_size;

After: vec2 texel = 0.5 * u_glow_spread / u_game_size;

This should give you the result you're looking for

If I'm understanding you correctly, you're saying that the phosphors appear too big relative to your game screen when running in a small window. This is actually by design; the shader reads your window size and outputs the phosphors in sync with your actual screen's resolution. For example, if you are using a phosphor mask with 3 columns (red, green, blue), it will always tile every 3 pixels on your real-life screen, and it can't go any smaller without completely breaking the effect. If you need a finer pattern, you can swap the mask out for the included 2-column wide (green, magenta) texture that takes advantage of your screen's RGB subpixel layout to squeeze everything as small as physically possible. If this still isn't acceptable for your needs, then you may want to disable the phosphors when your window size is very small. This effect generally requires an output resolution of 720p at the very least to begin looking correct.

As far as your code, it looks like it should generally work fine. However, this shader comes with built-in aspect ratio correction, meaning that you should be able to resize your output window to any shape at all, and the shader will automatically ensure the simulated CRT screen has the correct 4:3 ratio (or whatever your game is) with reflective borders filling any leftover space. I'd generally recommend just setting the output width and height to the actual window width and height (window_get_width(), etc), and let the shader handle everything else with constant game height, width, and aspect ratio settings.

hello,

You can edit the preset’s variable definitions directly! By default, they’re simply set to inherit from the base preset. You can either edit the parameters of the base preset object, or untick the lock icon next to each variable definition in the VGA preset object to allow them to be overwritten. GameMaker doesn’t have very easy to find documentation on this, so I understand being confused!

Hello,

You can set either crt.border_width or crt.border_brightness to zero to effectively disable the bezel effects.

Hello,

The room size can be anything you like! By default, the example project uses the Viewport 0 surface as the source for the CRT screen. That surface gets drawn directly to the real-life screen using a shader. Setting the game_width and game_height variables in the provided CRT object will automatically resize your viewport to whatever you specify. Your game's rooms themselves are free to vary in size to accommodate scrolling, etc. Be sure to take a look at the provided documentation for in-depth explanations of the underlying systems.

I'm a bit confused about what you mean by afterimage; are you saying something remains on the screen after you close the game? This asset isn't doing anything nonstandard (it all comes down to drawing a fullscreen surface in a Draw GUI event), so if you find your game isn't closing correctly, this might be more of a bug on YoyoGames' side or perhaps a driver issue. If you can provide a bit more information to sittingduckgamesco@gmail.com, I can at least ascertain whether or not I can resolve your issue with a patch to the asset pack.

Copied from another comment: GameMaker has a tendency to resize the display buffers when switching (or restarting) rooms. Calling the included crt.resize_surfaces() method after each room change with a persistent crt object should do the trick, but please let me know if it doesn't, and I can take another look.

GameMaker has a tendency to resize the display buffers when switching rooms. Calling the included crt.resize_surfaces() method after each room change with a persistent crt object should do the trick, but please let me know if it doesn't, and I can take another look.

If you're looking for the public domain art used in the screenshots, you can find it here: surt | OpenGameArt.org

A purchase of this asset permits use for any and all commercial and non-commercial projects, so long as the shader's source code is not redistributed in an editable way. No need to credit, though it is always appreciated!

Hello,

Support for this asset is only provided for desktop targets. That's not to say that it couldn't work on HTML5; however, it would likely require some tweaking to work properly. In particular, the resizing of the GUI surface may need to be handled differently on web exports.

I just took a look, and it seems that the screen edge antialiasing is responsible for that 1 or 2 content-pixel reflection. For a quick fix, just change line 134 of shd_crt from this:

float width = max(1.0 / u_output_size.x, 1.0 / u_output_size.y) * 8.0;

Into this:

float width = max(1.0 / u_output_size.x, 1.0 / u_output_size.y) * 1.0;

Hope this helps! I'll most likely fix this in the download at some point in the near future.

The shader will work with any resolution you specify. In the variable definitions of the crt object, just set game_width, game_height, and screen_aspect_ratio to whatever is appropriate for your game.

Hi, thanks for using my asset! If you want to be able to resize your game window, you’ll need to resize the GUI surface; GameMaker doesn’t do this for you except at the start of the game. In either a step event or the resize event, you’ll just need to check if the window dimensions are different from the GUI surface size, and if so, call display_set_gui_size(), and grab the window dimensions with window_get_width() and window_get_height().

Just uploaded a quick patch to fix the one line of code that was causing this! Just an oversight in a with() clause where I forgot to reference crt.gui_user_event instead of gui_user_event.

Thank you for trying my asset! I would suggest taking a look at the "Draw GUI" events for the CRT object, where you'll see that the rendering is wrapped up in a single function call. If you call this function while your surface is the current target, the CRT screen will be drawn directly to your surface instead of the GUI surface. You'll need to ensure that crt.output_width and crt.output_height match the size of your surface, and I'd also recommend disabling the phosphor mask if your surface will be zooming or stretching around the screen.

Hello,

Thank you for trying my asset!

This asset hijacks the application surface to use as the basis of the simulated CRT screen. If you want your HUD to appear on top of the CRT screen, then you'll need to draw it after the CRT object calls crt_apply() in the Draw GUI End event. Alternatively, if you want the HUD to be included inside the CRT screen, then you'll want to draw it directly to the application surface in the Draw GUI event using surface_set_target(application_surface) followed by surface_reset_target().

Hello,

Thank you for trying my asset!

Whenever you change any of the CRT object's settings at runtime, you'll need to have it call the function "update_uniforms()" to see the changes reflected in-game.

To disable the effect at runtime, If deleting the CRT object causes issues, you could also choose to disable it by setting its "shader" variable to shd_raw. This shader is more or less a passthrough shader that only handles aspect ratio and optionally curvature (which you could disable for a raw pixel art look).

I hope this helps!