Voronoi Splitscreen
A downloadable asset pack for Windows
Voronoi Splitscreen is a type of dynamic split-screen that adapts the split depending on where players are, leading to regions that merge together when players are close, and split when they move apart, with the split always being performed in the direction between the players, no matter how they move around in the level.
This asset is a from-the-ground-up implementation in GameMaker:Studio 2.2 using a simple shader to merge views together, with most of the work being done GML-side (finding the anchor points for the separate views). Easy to use, and implemented in a compartmentalized way that should make it easy to merge with an existing project.
Each player's view is rendered to a separate surface using view_surface (as if the game used ordinary views) and then they are merged together onto the application surface using a voronoi tesselation shader.
Supports 1-4 players, could theoretically be extended for up to 8. (The primary bottleneck is the GLSL fragment sampler unit limit - you can't pass more than 8 textures into a shader)
Purchase
In order to download this asset pack you must purchase it at or above the minimum price of $4.99 USD. You will get access to the following files:
Download demo
Comments
Log in with itch.io to leave a comment.
Hey! Decided to purchase this and it's pretty neat. Made some adjustments and it turned out pretty much perfectly.
However, GM almost explodes when closing the project and I keep getting the error "Trying to set texture that is also bound as depth buffer - bailing...". Any way to fix this?
I tried it out in the latest version and I can't reproduce it, no errors neither when closing the game window, nor when loading a different project or closing GM. Did it happen before you made those modifications?
Did some research on that error message and it seems to happen if you attempt to make a loop between two surfaces, like drawing a surface while it's set as the render target (and a common way to trigger it is having old surface IDs that aren't cleaned up, so that they later refer to new surfaces due to ID reuse). I think a good starting point for debugging what's happening is adding
to the Post-Draw event of obj_viewcontrol. If you see multiples of the same surface index here (other than -1 which means "not in use") it means something goes wrong.
If the problem only happens when you terminate the game, I think you could hack your way around it using draw_enable_drawevent(false) triggered in the event that closes the game, but before you do the actual closing procedure - if you aren't going to draw anything anyway, you can turn off all the draw events before you start freeing up surfaces and weird things happen with the IDs.