I did consider this might work, but not quite :/
https://i.imgur.com/YoyxWyR.png
For this particular instance, this is almost perfect:
https://i.imgur.com/fggFELt.png
But there must be a more scientific way to arrive at this? :D
Printable View
I did consider this might work, but not quite :/
https://i.imgur.com/YoyxWyR.png
For this particular instance, this is almost perfect:
https://i.imgur.com/fggFELt.png
But there must be a more scientific way to arrive at this? :D
I'll PM you the latest version. Please tell me if the Instant Teleport feature works as intended for you.
Thanks so much, I will do! I'm interested in why there's that extra -/+130 pixels needed adding to get the old VolCam to match positions, I'll try the brand new version too but it's become a kind of facination now :D I would have thought converting catchup to pixel positions would have worked but not quite, maybe I need to add jump/fall catchup onto it too; that would explain why if I hold still, the x-coordinates are instant?Quote:
Originally Posted by Volnaiskra
The new volCam is really awesome, teleport works perfectly! I'm not sure why I can't get it to see the full west edge of the frame, I even punched in 0 manually but it's still not going all the way to the edge?Quote:
Originally Posted by Volnaiskra
@Volnaiskra i pm'ed you an example with volcam 1.5, still having issues with perfect teleporting though and carrying over any catchup precisely.
I'm not sure what you mean. I've looked at your MFA, and I can't see any catchup lag. When I freeze-frame it, I can see that as soon as you teleport the player, both the target and the camera immediately move to the player. Both target and camera have the exact same X and Y coordinates, which shows that catchup was nullified successfully. (it takes a frame for the HUD to display this change, but that's just the HUD - you can see the updated coordinates on the camera/target objects themselves). I even took 60fps FRAPS footage of it and looked at it frame-by-frame in After Effects just to make sure. I definitely can't see the problem. You'll have to take some footage or something to help me understand what problem you're having.Quote:
Originally Posted by elvisish
_________________________________________
By the way, your MFA didn't work properly on my computer until I disabled the "Maximised on boot-up" setting. The top of the screen was cropped, with the red area and the player both off-screen. It took me a while to figure out why, but it's because that setting alters the data given by the Window Control Object, which volCAMERA uses to try and automatically determine your game's resolution. Although your game's internal resolution remains 640x360 even when maximised, the Window Control Object measures real physical pixels, so it suddenly reports your game as having a resolution of 2560x1440. And volCAMERA uses this (technically correct but misleading) resolution to determine where your game's camera edges are. This is probably the root of the problem you mentioned earlier about not being able to see the boundary of the screen properly.
To fix this, you'll need to hard-code your game's resolution by changing events 542 and 909 from this:
http://bit.ly/2XGj2hj
to this:
http://bit.ly/2XEZ72f
EDIT: Actually, there's a better way to automatically determine the internal resolution of the game, without using the Window Control Object at all. I'll employ it in the next version. It's this:
http://bit.ly/2XCmskO
There's a major new version of volCAMERA (1.51). I grew tired of waiting for it to come through the Clickstore backlog (it's been in there for a full month now), so you can now also get it over on itch.io. If you've previously bought volCAMERA on the Clickstore, you can either wait for the update to come online at the Clickstore, or PM me with your order number and I'll give you an itch.io key. Please note that because this is a fairly thorough overhaul of volCAMERA, it's not compatible with earlier versions. That means that you'll need to entirely remove all old volCAMERA objects and code from your MFA before you can import version 1.51.
New features:
--Look up/down feature with customisable timing, speed, distance, and springback.
https://gph.to/2Tt5FhP
--Camera "marshalls" that you can use to shepherd camera to/away from specific areas.
https://gph.to/2TUh537
--Cutscene mode (control camera independent of player) with two example cutscenes in demo
https://gph.to/2HV4OEi
--Camera tremble: 3 presets of ongoing camera vibration that can combine with Camera Shake
https://gph.to/2HQAaME
--Instant Teleport Mode: instantly snap to player after moving large distances
https://gph.to/2CASki2
--DrunkCam. Simulate inebriation/poisoning with a customisable effect that combines double-vision, sway, blur, and other goodies. (unfortunately I can't show a GIF because the double-vision effect is based on alternate frames, which would not only require a 60fps GIF but also annihilate the GIF compression algorithm)
--Effortless tweaking: all your camera settings are auto-saved and will auto-apply on subsequent launches.
Much better HUD:
https://gph.to/2CvbEx1
--Tweak camera settings in real-time, see how the camera engine works under the hood
--HUD now has more features, yet consumes fewer resources when on, and virtually no resources when off
--new HUD looks better and is just 19% of old HUD size
--New low-res HUD mode for pixelart games retains all major functionality at just 3% (!) of old HUD size
--All HUDs can be respositioned at runtime with numpad.
--New miniHUD mode shows various key camera info at just 1% of old HUD size
https://gph.to/2HOOYLt
Other improvements:
--Performance improvements. Up to 190% faster in both HUD-on and HUD-off modes (as measured by volPROFILER)
--Demo is more feature rich, informative, and user friendly
--Camera shake movement now more graceful and satisfying
--Improved clarity and helpfulness of many comments, including installation instructions
--Less clutter in your Frame Editor. Footprint of most objects is smaller, and you can now place all vC elements how and where you like in the Frame Editor.
--Arrow keys now work in the demo too, not just WASD
--All volCAMERA objects have a cohesive new visual style, to more easily differentiate them from the rest of your game's objects
--Added custom qualifier icons for volCAMERA's two qualifiers (icons will only display if 2.5+ DLC is present)
--No longer requires Window Control Object or File Object
Fixes:
--Fixed issue where camera boundaries could display incorrectly in the demo
--Fixed issue where left/right overshoot wouldn't work if jump overshoot was disabled
--Fixed (demo): player no longer gets stuck in wall
--Changed method of automatically determining internal game resolution, to prevent wrong calculations in certain fullscreen or maximised modes
--Various other fixes
You can buy it here: https://volnaiskra.itch.io/volcamera and (eventually) here: https://clickstore.clickteam.com/volcamera
It really is an awesome update, the look around is something I really wanted in the original volCam so this is a really welcome update!Quote:
Originally Posted by Volnaiskra
You could try making a 60fps webm clip, I tend to use those for example videos are they're a much more modern algorithm than gif (uses png, effectively), here's the tool I use if it helps: https://atomisystems.com/activepresenter/
This is repositioning me randomly along the x-axis and back to the still-centerable top of the level (*not* high enough so that the screen can't be centered still): https://imgur.com/XCXf2ZkQuote:
Originally Posted by Volnaiskra
This is the same with volCam 1.5: https://imgur.com/XCXf2Zk
Both don't take into account the catchup on the reposition, I'm trying to get it so that the object is still in exactly the same place relatively on the screen on teleport, so the relative visable position of the player is unchanged as far as the camera position is concerned. You can see the player moves up a bit and to the left/right a bit (depending on the direction moving) as the teleport is re-catching up to the players new position.
Dope update! Pm'd u my order number for itch :)
haaahhhhhhhouuuu la nouvelle version et incroyable qu elle travaille remarquable avec tout c est nouvelle foncions.
haaahhhhouuuu the new version and incredible that she works remarkable with all this is new funcions.
Longtime follower and finally decided to grab this after work today to play around with in my spare time, to find out that apparently it was created with a newer version of CTF2.5 and thus won't open.
I'm currently on R292.7 on Steam, is there an even newer update that I need to do?
If Volnaiskra saved this mfa in Fusion 2.5+ - even if he did not use any 2.5+ exclusive features - the .mfa can no longer be opened in standard 2.5. I believe Clickteam changed this because 2.5+ mfas were still causing crashes in base 2.5.
@Volnaiskra Not sure if you managed to check my post: https://community.clickteam.com/threads/101080-volCAMERA-a-powerful-camera-engine-for-Clickteam-Fusion-2-5?p=747706&viewfull=1#post747706 - I also sent a PM with some follow-up info detailing the issue I'm having.
@Volnaiskra quick bump in case you missed it?
The new version is finally available on the clickstore: https://clickstore.clickteam.com/plugins/tools/volcamera
@elvisish : oh, sorry, I'll take a look at that today.
Hi how do i download the update from the Clickstore. Only way i see the product is on my downloads list.
If i re-download that it gives me Version 1.02. Is there another way to get the updated download from the store.
download link has updated. now i get latest Version all good.
Wanted to ask, Why is the app set to run at 120fps? I used Fusion default to run 60fps. So far i am not pushing the engine at all with the Mfa's i made. If i copy camera into a 60 fps mfa iwill it run the same.
It's set to 120fps because it's originally made for Spryke, which runs at 120fps. It will probably behave differently at 60fps (ie. A setting that's fast in 120fps will be twice as slow in 60fps). All that matters is that you set it to your desired fps (which will happen naturally when you paste it into your game) before you start finalising your settings.
I can't remember if I posted in this thread or not, but I felt I should give it a bit of a shill - I'm using this in my project and I approve of this camera engine. Same for VACCiNE too.
@Volnaiskra thanks, i'd really appreciate it, it's stumped me completely!
@Volnaiskra
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!
https://youtu.be/bfcBOVBRpis
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)Quote:
Originally Posted by xhedgehogx
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:
http://bit.ly/2R4UI8P
Ah thank you for the clear explanation on that. I was looking at that event, for whatever reason it didn't even occur to me to manually enter the dimensions in there. DX11 fullscreen seems like its the culprit for me here.
Hey @Volnaiskra , 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.
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.
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?Quote:
Originally Posted by zip2kx
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.
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:
Originally Posted by vSv
Thanks for the answer!
If you're interested, I have a short .mp4 from the game I'm working on which has this effect: https://i.imgur.com/OZWUI7l.mp4
I will have to try and replicate it with your camera engine later.
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?
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).Quote:
Originally Posted by vSv
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):
https://bit.ly/38pCfeQ
Thanks! :D
I have never used or heard about the Round-function before, so that would probably have been impossible for me to solve on my own. The solution worked perfectly!
thx for the reply but sadly no :(Quote:
Originally Posted by Volnaiskra
Game might be too low res to handle small movements properly without some sort of smoothing between volcam and crosshairs following the mouse.
Hey, I was wondering if there was a zoom function or a way to zoom in on the sprites or on a specific region on the screen with the camera?
Hi, I don't know about this camera, but you can "zoom" if you change the scale of an object, that's a cool "trick" :)Quote:
Originally Posted by AshraldRails