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.3 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.
Hello is that tool still updated? Seems pretty good!
Just to make sure I test-ran the GMS2.3 version in IDE v2024.8.0.169 / runtime v2024.8.0.216 (latest version) and everything seems to be working fine, so there's currently no need to update it.
I'll go ahead and hide the GMS2.2 version since nobody uses that anymore, hopefully that helps avoid some confusion.
thank you a lot I think i’m going to buy, I just want to ask, is there any possibility to create the camera just in certain moments outside of the view and slowly bring that at the half of the view?
I don't understand your question, could you please elaborate?
If you mean turning the effect on/off: yes, obj_viewcontrol takes control over the application surface when it is created and returns it when it's destroyed / the room ends, so you should be able to just create one when you want the effect to happen and remove it when you don't want it anymore.
If you mean controlling the effect so the alternate view slowly slides in from outside the screen: I think the easiest way to do this would be adding a new uniform vec4 to the fragment shader which contains a "distance bias" for each of the 4 players. Subtract the corresponding value when calculating which player is nearest. This means if you set distance_bias[0] to (size of your view) and then gradually decrease it, player 1 will have the entire screen space to themselves because their view "bleeds over" the others, but as you decrease it the other views fade in.
Sorry for my lack of clarity.
Basically my game is a single player, what I want to achieve is very similar to the second option you told me.
I want a camera that focus on the main mission to do that slowly slide in from outside of the view when the player do some progress.
For example: to open the gate the player have to activate 2 terminals, when the player activate 1 of them, the view slowly slide to the center and show the progress, maybe the gate has 2 lights and I want to show that he turned ON one of them.
OK, for cases like that the second option probably will work - basically manipulating how the "distance" is computed in the shader so you can overlay the views however you want.
If you want the additional views to take precedence no matter what, it gets a bit more complicated, but I'm thinking something like this:
So basically you don't pick the nearest view, you check if you're in one of the popin views and just want a yes/no answer.
(Additionally, you can fade in/out the views by changing the view size that gets passed into the shader, and set it to 0 to disable the popin view entirely - and of course modifying the focal point moves the view around the screen as well, like before)
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.