volCAMERA: a powerful camera engine for Clickteam Fusion 2.5

Quote from xhedgehogx

[MENTION=15682]Volnaiskra[/MENTION]
Apologies for the bump. But, I'm having a little bit of trouble with volCAMERA and can't pinpoint exactly how to resolve the issue.

The scrolling is fine if I don't switch to full screen. You can see the character will go all the way to the left wall (same with the right wall, floor, ceiling). If I switch to full screen at the title screen and then go to the next frame, there's an issue where the camera won't scroll all the way to the edge as it should. And finally, in the last example, if I switch to full screen while already in the level, the camera scrolling works as expected. How do I fix this problem? Thanks!

Please login to see this link.

Edit: It looks like disabling the 'vC - Boundaries: LERP' group fixed it.

I think you need to manually tell volCAMERA what dimensions your game is running at (see below)

What's probably happening is that the camera boundaries are being incorrectly placed. Where they must be placed depends on your game's resolution, but since I had no way of knowing what your resolution would be, I had write some code that would try and figure it out for itself. So vC tries to read your game's resolution when you first run it, and calculate where the boundaries should be based on that. But it's an imperfect system, and fails if you use a fake fullscreen method (eg. Ultimate Fullscreen, or :cf25+: DX11 mode fullsreen). Because in a 'fake fullscreen' mode, your game (which is, let's say, 640x480) gets scaled up but your monitor's resolution (which is, let's say 2560x1440) remains unchanged.

So, volCAMERA sees that your game is using 2560x1440, so it thinks that your gameworld is 2560x1440. But really, even though your game is now displayed using all 2560x1440 physical pixels of your monitor, your gameworld is still just 640x480, but scaled up. if were to tell your code to move an enemy 640 pixels to the right, it would of course move it all the way across the screen, yet it would traverse 2560 physical pixels to get there. So this confuses volCAMERA, and it places the boundaries in the wrong spot.

;TLDR
Manually enter the dimensions of your game's north, south, east and west edges here:

Please login to see this picture.

Quote from zip2kx

Hey [MENTION=15682]Volnaiskra[/MENTION] , dont know if you are still around but i was curious if you ever made VolCamera work with mouse aiming? For 360 aiming for e.g. a shooter.
I can get it of to kind of work but it has some small jitters making the cursor/crosshair look like its flicking that i cant get rid of.

Hey. Sorry for the late reply. I'm sure there's a way, but I've never tried this myself. I guess you'd want to turn off as many irrelevant features as possible (overshoots, jump lock, etc.), and lock the grey target object to xmouse and ymouse, as close as possible to the final execution group. Does that not work without jitters?

Though thinking about it, it might not be adequate to just point the camera at the mouse. You might want to point it only a certain distance away from the player, so the player remains close to the centre of the screen. In that case, I guess you'd need to use trigonometry (or perhaps the Adv Direction object) to figure out where to place the grey target so that it's always X pixels away from the player, at the same angle from the player as is the mouse.

Quote from vSv

Hi Volnaiskra !

I purchased your camera engine and it's fantastic. I was thinking about using since it leagues better than my current camera engine. But I'm wondering, is it possible to make the camera auto scroll a full screens height or width when reaching the visible end of the frame? Just like in the old Mega Man games when entering a boss room on the NES or when switching rooms in games like The Binding of Isaac.

I never played Mega Man (I was a Commodore 64 kid) and it's been a long time since I played Binding of Isaac, so I might not know exactly what you have in mind. But it sounds like volCAMERA's "cutscene mode" might do what you need (you can see examples of it in the demo frame). You could place a trigger at the end of the level that forces vC into cutscene mode, and creates a cutscene object that slowly moves a screen width up to where you want it. While in cutscene mode, vC will follow this cutscene object rather than the player. To prevent the player from seeing this extra space until the correct time, you could perhaps use vC's camera marshals to fence the camera in (I can't remember if those camera marshals would also impede the camera in cutscene mode - if so, you might need to then destroy or move those camera marshals once the cutscene mode starts so that it's free to move beyond the previously fenced in area).

Quote from vSv

Hi again Volnaiskra!

I have a very small problem with your engine. I thought it was due to my implementation of the camera into my engine, but it seems that even in your file this problem exists.

If I understand it correctly, the vCcamera should always aim to get the exact same X and Y position as the vCtarget?

The problem for me is that the X position (and calculated Alterable Value for the X position) of the vCcamera is slightly off by a pixel depending on what direction the player faces. In your demo file, the calculated X is off by a pixel when the player faces left, and in my game its off by a pixel when I'm facing right.

The same goes for the Y position and its calculated AV. Whenever I jump and land, its off by a pixel.

It might not sound like a big deal, but as I'm working with relatively low resolution in my game (426x240), that pixel calculation is clearly visible at times and it makes things not pixel perfect anymore.

Do you know any solution for this?

Display More

I'm sure I noticed this, but I never thought it would matter to anyone (I guess I never properly thought about how it might look at very low resolutions).

It's caused by a rounding error in the bit that says set X("vCcamera") to Alterable Value X("vCcamera"). By default, I think Fusion 'floors' pixel values, so it will set the camera object to X=49 whether Alterable Value X is 49.01 or 49.99. This tends to bias the numbers by 1 pixel this way or that when going in a certain direction.

It's an easy fix. Just add Round() to the final positioning actions, as shown below (now 49.01 will become 49, while 49.99 will become 50):

Please login to see this picture.

Can't you just deactivate the volCAMERA group whenever you want the camera to freeze?

Quote from vSv

Hi Volnaiskra!

I've encountered a problem with the Marshalls and the Overshoot mechanic and/or the X Bias mechanic. I was hoping I could get some solution from you regarding this.

My problem is that the Overshooting mechanic forces the vCtarget beyond a Marshall even though the player object is already inside a Marshall.

I understand that one "solution" to this problem is to make the Marshalls wider, but this doesn't really solve my problem as I use Marshalls that pushes Left adjacent to Marshalls that pushes Right as a way to stop the player from seeing through a wall.

So basically, if I'm using the X Overshoot mechanic and/or the X Bias mechanic and I'm running to the right, I will activate the first Marshall that pushes the camera left (so far so good), but once I'm close to the adjacent Marshall the vCtarget will "jump over" to the adjacent Marshall that pushes the camera Right.
This causes an issue as I'm now able to see what's on the other side of the wall (or whatever else I used the first Marshall for) for a brief second.
This is sadly also an issue even if I don't use another Marshall as the vCtarget will just jump to where the first Marshall ends.

Would love to know if you have any idea for preventing this from happening?

Display More

Hey vSv! Thanks for pointing out the problem, and for posting your solution. If it works with your setup, then I think you're good to go. I tried it with my setup, and it solved some of the problem, but not all of it (things still got jittery under certain conditions).

This will potentially affect my game too, so I've spent the past few days looking deeper into this problem, and I think I've finally solved it. There may still be issues with extreme levels of Xovershoot lock, but that's probably a very rare use case anyway. From what I can tell, my changes solve the problem for Xovershoot, JumpOvershoot, FallOvershoot. and X and Y Bias.

It's a bit hard for me to separate the changes out from my game and package them into a stand-alone MFA that I can upload. And I'm reluctant to update volCAMERA on the clickstore itself because the last time I did that, it got removed from the store for 4 months or so while it waited in the update queue. So I'm just going to post screenshots of the changes here for anyone who would like to implement them into their own game.