Skip to main content

On Sale: GamesAssetsToolsTabletopComics
Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics
SalesBundles
Jobs
TagsGame Engines

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.

(1 edit) (+1)

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:

  • Add additional uniforms for "view size" parameters for all views (these could be vec2 if you want different aspect ratio horizontally or vertically or a single vec4 for them all if you want uniform size)
  • Rather than checking all positions to see which one is nearest, the loop checks the popins only (view 1-3) and if it's closer to the focal point than "view size", it uses that texture.
  • If it's NOT close enough to any focal point, it always uses the view 0 texture.

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)

So basically i'm pretty bad with shaders, is there any chance to add the feature in this tool?

I can pay a supplement for the trouble, I tried a lot by myself without success and I think is the moment to ask people more good than me!

(+1)

Got a minimal example working with these changes:

Control Create event at the bottom:

u_voron_vsize = shader_get_uniform(        sh_voronoimerger,    "vsize"            )
p2size = 0

(+ added some keyboard events to let me increment/decrement p2size with 0.001 at a time - it's in screenspace coordinates so 1.0 means "100% of the screen width/height" so in-game you want small decimal values for a small pop-in view)


Control Post Draw event, line 14:

shader_set_uniform_f(        u_voron_vsize,    0,    p2size,    0,    0)

(note how vsize[0] doesn't matter so I always set it to 0, but player 3 and 4 are set to 0 because we wanna disable their views - so different reasons)


sh_voronoimerger (Fragment):

New line before main:

uniform vec4 vsize;

Lines 20~31 changed like so,

     //Go find the nearest screen position and use that
     float bestdist = 999999.99, dist;
     int bestid = 0;
     for(int c = 3; c > 0; c--){
         if(c < num_players){
             dist = distance(screenpos[c].xy,v_vTexcoord);
             if(dist < vsize[c]){
                 bestdist = dist;
                 bestid = c;
             }
        }
     }
     gl_FragColor = sampcol[bestid];

I.e. run the loop backwards, don't run it for 0, but default to 0 if you don't pass the distance check any time.

(5 edits)

Ok I made the changes you told me and added a keyDown event that increase the p2size and that's the result.

The other view appear from the top right (but I think is because the 2nd player was in that position) in a oval way while instead, I would like it in a circular way and in a fixed position, top right is ok to me.

Is there any chance to have even a black outline of the circular view?


(+1)

Your first guess is correct, the view is still centered around the 2nd player's relative position, but you can just explicitly change that (since you're not going to actually have a second player) to get the cut-in wherever you want.

The black outline is pretty simple, check if the distance is "close to the max value" (e.g. < 0.001 difference, change to a larger/smaller value to change thickness) and if so, set the gl_FragColor to black rather than any of the sampled colors.

Despite the simple idea it's a bit of a mess but I'm thinking two changes will be enough:

#1, the distance check

if(dist < vsize[c]){
      bestdist = dist;
      bestid = c;
      if(dist > vsize[c] - 0.0001){ //This part is new
           bestid = 9;
      }
}

#2, at the end

if(bestid < 9){
    gl_FragColor = sampcol[bestid];
}
else{
    gl_FragColor = vec4(0.0, 0.0, 0.0, 1.0);
}

Making it circular gets more complicated but I think you can "cheat" a bit to simplify this - instead of taking the distance between the actual pixels when doing the distance check, make two new vec2 variables which are copies of the player position / current fragment position but you multiply the x coordinate by 9.0/16.0 (the inverse of the aspect ratio).

So something like this might be enough, just replacing the dist check:

dist = distance(screenpos[c].xy*vec2(9.0/16.0, 1.0),v_vTexcoord*vec2(9.0/16.0, 1.0));

Thank you for your support! I made the changes you told me but the result seems strange.

The other view is still an oval, instead I think is more oval than before. 

 The black outline is present but is too much thin.

I'm not clear on how to keep the other camera's appearance fixed at the top right. 

 The oval camera appearance is not perfectly centered on player 2.

Thank you so much for the support!


(1 edit) (+1)

Oh right, multiplying by a smaller value makes distances shorter than they actually are - my bad, the 9/16 factor should probably go for the y value instead of the x value.

To make the outline thicker just increase the "0.0001" used for that comparison, 0.001 is probably too thick so maybe 0.0005 will look better? (If you have a specific pixel width you want, just divide that with the screen width to get the value to use here)

As you can see for both of these, I don't really know everything and a lot of this is trial and error :P You kinda can't get away from it with shaders, they're very visual compared to regular game logic code...


The "player 2 position" used in the shader is set in the control object's Post Draw event, it's the third and fourth row of the pos array and they're percentages (since they're coordinates in screen space). So for instance if you always want the pop-in in the top right corner, you could change it to something like this:

var pos = [
     global.voron_screenpos_x[0],
     global.voron_screenpos_y[0],
     0.85,
     0.15,
     global.voron_screenpos_x[2],
     global.voron_screenpos_y[2],
     global.voron_screenpos_x[3],
     global.voron_screenpos_y[3]
];
(+1)

Thank you a lot for the support I will try as soon as possible! 

I really appreciate your kindness!

Just one last thing! ( everything you told me works pretty well just the start point of the other view is not centered to player 2 )

 

If I want to import the tool in my project and have a camera that always points to the level target, what do I have to do?

(+1)

I think the reason the P2 camera isn't centered is because the view isn't allowed to go outside the level and it's always 1 screen big, so when forcing it to focus on a given position without taking the relative positions into account you can end up with a suboptimal view. It's easy to tweak at least, it's the lines near the bottom of obj_viewcontrol's End Step event.

global.voron_tlc_x[c] = clamp(global.voron_worldpos_x[c] - VIEW_W*xf,0,room_width  - VIEW_W)
global.voron_tlc_y[c] = clamp(global.voron_worldpos_y[c] - VIEW_H*yf,0,room_height - VIEW_H)

Just removing the clamping to let the view poke outside the room might help (though we don't wanna do that for the main view following the player)

if(c > 0){
   global.voron_tlc_x[c] = global.voron_worldpos_x[c] - VIEW_W*xf
   global.voron_tlc_y[c] = global.voron_worldpos_y[c] - VIEW_H*yf
}
else{
   global.voron_tlc_x[c] = clamp(global.voron_worldpos_x[c] - VIEW_W*xf,0,room_width  - VIEW_W)
   global.voron_tlc_y[c] = clamp(global.voron_worldpos_y[c] - VIEW_H*yf,0,room_height - VIEW_H)
}

You might need to add a factor adjusting the view position based on where you have the pop-in (since the popin isn't centered in the view, the view should be offset to make sure the bit you cut out is actually centered) but I'm unsure what direction and magnitude will be correct here so I'd just recommend you to play around with the numbers until you get it right - but my guess is subtracting VIEW_W*0.425 from the x coordinate and VIEW_H*0.075 from the y coordinate (half of the 0.85, 0.15 coordinates we use for the center).


To import this to an existing project it should be enough to import obj_viewcontrol, sh_voronoimerge, and the voron_init, voron_player_get_id scripts (either right click empty space in the asset browser and pick Add Existing, or open the stuff in an external editor and copypaste the code into fresh objects created in your new project - I prefer the latter method for more control but the former is probably the most convenient), the init script has a pragma that makes it automatically be ran when the game loads so you don't need to manually set it up.

Next have an object named "parent_player" (which your player objects and goal objects inherits from), and give your player a variable player_id which is 0 for player 1 while the goal also has the same variable but it's 1 (this is what the control object uses to figure out where to put the views).

Then just place an obj_viewcontrol in the room (or better yet, have the player create one in its Room Start / Create event so you don't need to manually place one in every level) and it should hopefully handle everything on its own from there.