Now that's handy.
Recent community posts
I just realized, this is also helpful for people who run windows programs that automatically change the focus to whichever window you mouse over.
A few gamepad-related things I would love to see in future asset packs...
1. Support for legacy DirectInput devices and DOS-era joysticks.
2. Rumble support.
3. Compatibility with Steam's controller mapping APIs, however those work.
4. Redirecting gamepad input logic to run in a separate thread, with optional GPU acceleration (via OpenACC), and various C++ tricks to make input logic even faster.
5. Support for unique features of specific controllers, assuming that somebody can get certain ones to work on PC in the first place;
- XBOX ONE: Vibrating triggers.
- DualShock 3 and later: Motion Controls, Analogue Face Buttons, Analogue D-Pad.
- DualShock 4 and DualSense: Touchpad, Lightbar, Speaker
- DualSense-only: Resistive Triggers
- Nintendo Switch Joycons: Motion Controls, HD Rumble (obviously only if somebody can get them to work on Windows)
- Steam Controller: Just about everything, I guess.
6. A way to automatically detect if a gamepad (or other input device) has been disconnected.
7. Razer Hydra support. Because those are a thing.
1. A way to automatically prevent the window from opening off-screen.
2. A way for the window to automatically snap to the edges of other windows.
3. A way for the window's title to appear in the center of the title bar, instead of on the left of it.
4. A way to hide the standard window controls and window border, and instead use custom ones.
1. Do these extensions support atomic transactions?
2. Are they capable of compressing the contents of an INI file at all, and/or placing the INI file into (or retrieving it from) a ZIP?
3. Do they operate asynchronously and/or on multiple processor threads?
4. Do they work with writing UTF-8 files (without BOM), and reading INI files encoded in UTF-16 (or in UTF-8 that mistakenly contains a BOM)?
5. Can the extension choose the filename when writing an INI file?
6. Can the extension automatically obfuscate a string that it's writing?
To the author: Thank you for making this! I look forward to using it.
To everyone else:
If you are making a top-down game, you may ignore this comment, but if you're making a side-scrolling game, then before you decide to not support this asset here's something to consider; this script can actually have functionality outside of top-down games.
For example if you're making a Metroidvania, and are including an ability that lets players stick to and scale certain types of walls, you could use this top-down collision script to extend that ability to also work on certain background tiles. That way, the background can become a platforming and/or puzzle element.
That is all I had to say. Happy developing~!
Spiderball, spiderball, look in the background and there's a wall!
The wall's magnetic, and you stick, so get ready to do a drop kick!
This is actually perfect for something that somebody I know is working on. Perfect resolution, perfect bit-depth (they use a shader to change the colors around), even the same basic art style.
I would like to help with optimizing this SVG renderer, if you're interested. To this end, I've written a rather lengthy outline. I hope you're ready for a lot of reading.
If I use any terms you are unfamiliar with, and you're unable to find what you need with a quick google search, then feel free to contact me, and I can try to help you find the information that you need.
Just to warn you: Because I typed this in Notepad, the formatting might appear kind of wonky on the website.
OUTLINE FOR FASTER, MORE POWERFUL RENDERING OF VECTOR GRAPHICS IN GAMEMAKER STUDIO
Typeface used: Lucida Sans Unicode, 8pt. Manual word wrap.
GPU Path Rendering:
SECTION 1: NOTES OF CAUTION AND RELEVANCE
And hopefully, interest and utility.
1.1- Because GPU Path Rendering is a non-standard OpenGL extension...
--- It may not work with all device drivers or graphics vendors.
--- --- It also might not work with DirectX.
1.2- Things you might not know about Scalable Vector Graphics:
--- Because it is easily possible to combine XML and HTML, SVGs can easily integrate into HTML applications.
--- SVGs are capable of some rather complex visual effects...
--- SVGs can also be used to make animations, and even self-contained 3D scenes.
--- There have also been experiments in using SVGs as textures for 3D environments.
1.3- OpenACC makes parallelization and GPU Acceleration easy, but there are some caveats:
--- OpenACC will only work when the program is compiled to YYC.
--- OpenACC in GameMaker also requires the ability to insert C++ and/or conventional C directly into your GML.
--- Lastly, OpenACC requires a supported compiler. Oof.
--- OpenACC, right now, is only suggested as a shortcut to replace a lot of the remaining CPU workload.
SECTION 2: RENDERING OPTIMIZATION
It's time to go Full Throttle.
2.1- Begin with Front-to-Back Rendering for all layers (Reverse Painter's Algorithm).
--- If a layer isn't completely opaque or has a non-standard blend mode, do not cull the layer below.
--- Once all layers are rendered, switch to Back-to-Front Rendering to calculate properterties from layer blend modes.
--- Also remember to implement Z-Buffering and the Warnock Algorithm.
--- --- This is necessary if you are using *many* layers, and if any shapes happen to overlap.
2.2- Try to make use of Coverage Buffering.
--- IIRC, these are like Stencil Buffers, except with Anti-Aliasing.
2.3- Parallelization and Low-level Optimization
--- If the capability exists, then be sure to mix as much C and C++ as possible into your GML.
--- Always remember to multithread, and try to slip in some OpenACC.
--- Extensions exist on itch.io for Instance Pooling and for using Vectors. Maybe those can help?
2.4- Divide the on-screen rendering into Tiles, and on subsequent frames, only redraw the Tiles which have been updated.
--- Further subdivision into Scanlines adds another layer of optimization:
--- --- On top of only *Tiles* which have changed being redawn, *Entire Scanlines* will behave likewise.
--- --- --- While a Scanline can only cover a small strip of a single Tile, it can still cover multiple Tiles.
--- --- Scanline-based rendering can also be used as a Visibility Determination and Culling mechanism.
--- --- Furthermore, Scanline-based rendering lets you perform some pretty awesome effects, a la the 16-bit era of consoles.
--- --- --- The Scanline effects can be called *before* Rasterization occurs, which would allow not one, but two things:
--- --- --- --- Soon-to-be-hidden pixels can skip being drawn.
--- --- --- --- Soon-to-be-revealed pixels can be drawn even if they weren't originally visible.
--- Tiles which have already been drawn get converted into raster graphics and cached, enabling them to be quickly redrawn if needed.
--- --- Tiles can be built using Indexed Color, enabling the colors to be easily changed.
--- --- Tiles can also be flipped, rotated, and even broken down into even smaller tiles, making for even more reusability.
--- --- --- It's also possible for a single tile to appear in multiple places on screen.
--- --- Tiles which have been cached should be saved and loaded asynchronously for the best performance.
--- --- --- And of course, everything should be done in a separate thread, if possible.
SECTION 3: GRAPHICS DATA SIZE AND DECODING OPTIMIZATION
SVGs are already small, but they can be even smaller.
3.1- Use Binary XML and the SVG DOM to "bake" the SVGs:
--- Not only does this result in smaller files, but also faster execution; especially when using both C and C++.
--- Can use compression algorithms on the output bytecode to make them even smaller.
--- Don't forget to sneak some OpenACC into the script! Much faster decoding, that way.
3.2- Raster-based Detail Textures can be used to fill in highly noisy details that Vector graphics are ill-suited for:
--- Detail Textures are usually monochrome, but can also be made in indexed color.
--- Because Detail Textures often correspond to materials, they are best used in a tiled format.
--- SVGs can easily function as clipping masks, which prevents detail textures from being drawn where they're not supposed to.
--- Detail Textures do not need to be high resolution to produce fine details, as has been demonstrated by Unreal.
--- --- If you're ever feeling ballsy though, you can go ahead and make a Detail Texture that uses a Signed Distance Field.
SECTION 4: PATH-RENDERING SHORCUTS
And if all else fails, try cheating.
4.1- Convert the SVGs into Signed Distance Fields, with Summed Area Tables:
--- Faster on the rendering side than pure path rendering, but uses CPU time to set up.
--- --- Signed Distance Fields are useful for arbitrary scaling, and at angle or aspect ratio.
--- --- Summed Area Tables have a lower memory footprint than Mip Mapping, and greater flexibility in downscaling.
--- Use RGBE (E is for Exponent) format for floating point precision (and a small file size).
--- --- The use of three color channels can preserve sharp corners, which is more difficult to do.
--- Unfortunately, there is no hardware-accelerated implementation to generate them quickly. As such, this must be done through software.
4.2- There are tradeoffs between producing these SDFs/SATs at Run-time, and making them at Compile-time:
--- When done at Run-time, it has the potential to use a lot of CPU time and/or Memory. But here are *some* possible solutions:
--- --- OpenACC and Multithreading are here to help, as always. But GMS makes it difficult to Multithread.
--- --- Could also try writing most of the heavy lifting directly in a mix of C and C++, instead of relying solely on GML.
--- --- When SVGs are processed into SDFs w/ SATs at Runtime, they can be cached locally for later use.
--- --- --- This means transcoding your SVGs asynchronously may not be a bad idea.
--- When done at Compile-time, the problem becomes file size. As Raster graphics, SDFs are inherently much larger than SVGs.
--- --- Fortunately, it is possibe to optimize the output graphics data so that it is much smaller.
--- --- When you have the SVGs pre-processed, it becomes potentially *orders of magnitude* faster.
--- --- --- This is because you are able to skip using Path Rendering outright.
--- --- Lastly, doing it at Compile-time means that you can take as long as you need, and the end user doesn't need to wait.
Thank you for taking the time to read my outline, and feel free to contact me on Discord or Telegram.
Unless I did something wrong, you can easily view the necessary information on my itch.io page.
There seem to be some inefficiencies in its algorithm. I have a screenshot to back this claim up.
It might be possible to have the algorithm run multiple passes, maybe using GPU acceleration via OpenACC (which could be snuck into your GML so that it gets included via YYC).
Additionally, you could use overlapping instances for some things, to optimize things even further.
BigNum, Instance Pooling, and Vectors, to the rescue!
You can also probably look into Adaptive Mesh Refinement.
If you were to use OpenACC and Adaptive Mesh Refinement, then you could possibly make it even faster.
I could probably encorporate a layer of smooth terrain using this system in between a foreground layer of tile-based, non-destructible terrain, and a background layer of other tile-based graphics/terrain. Perfect if you're playing a Metroidvania that involves exploring structures buried in rubble.
I think you could improve the performance of the raycasting functions with raymarching and/or BSP. If it's possible to use external C++ for your functions, then you could also look into OpenACC for even more speed gains with some of these complex functions.
Here's a link to the itch.io page.
I also shared a link to The_any_Key's own object linking thing in the comments for that cutscene engine.