volCAMERA: a powerful camera engine for Clickteam Fusion 2.5

Quote from Fenris

Hello [MENTION=15682]Volnaiskra[/MENTION], I just have a quick question abut this camera as I can't get it to work properly. I copied VolCamera engine and all essentials to my game. I also replaced all references of demo player. When I start the game camera works, but I just can't get xOvershoot to work. I set it to yes but no matter what values I put in, the camera stays at default. I know I'm probably doing something wrong or missing something, but I just can't figure it out. Any ideas? Thanks

Sorry, but without seeing your game, I can't really tell what the problem might be. Unfortunately, the best advice I have is to try importing everything again, and hopefully whatever you did wrong last time (if indeed you did anything wrong) will be fixed this time around

[MENTION=5748]Chaos[/MENTION] Thanks very much

Quote from Fenris

[MENTION=15682]Volnaiskra[/MENTION] Thanks for answering. I tried importing the engine again and plug my player in and I still have the same problem. I even tried using default camera demo object instead of my player. I deleted my object and just plugged Demo object in PMO, as it is already set to engine. But the problem is still the same, I only get default camera movements. I'm certain that I'm doing something wrong, but I just can't figure it out, and it's driving me crazy Here's my example if you maybe have the time to look at it :Please login to see this attachment.

Hey Fenris. volCAMERA needs to know data about your player (movement speed, whether player is on the ground, in the air, etc,). So you need to populate the Connect volCAMERA with game group with up-to-date information about your player, by giving that information to the volCAMplayerStates object. The comments in that group outline what values you need to provide and where.

Please login to see this picture.

For example, you've linked Xspeed of volCAMplayerStates to an alterable value of your player called Xspeed. That's a good start. But Xspeed of your player doesn't actually do anything at the moment; it just stays at zero. So even when the player is moving on the X axis, the alterable value of Xspeed just remains 0, as you can see in the debugger on the right side of this screenshot:

Please login to see this picture.

So, you need to get information about your player's x speed, and tell that information to volCAMplayerStates. For example, this would do it:

Please login to see this picture.

Or, an even simpler way:

Please login to see this picture.

So now, volCAMplayerStates knows what your player's xspeed is, and can operate properly.

......well, not quite. As I was looking through the code, I noticed a bug that was my fault, which also prevents overshoot from working properly - doubling your problems! Sorry about that! You also need to make the following change, please:

Please login to see this picture.

Once you've done all that, overshoot should work:

Please login to see this picture.

Quote from elvisish

[MENTION=15682]Volnaiskra[/MENTION] As I mentioned in Please login to see this link. I'd love to be able to use VolCam with PMO. I understand PMO's float coords get clamped internally which would make it difficult to accurately match the position with VolCam, but a lot of people rely on PMO's simplicity, including me. Is there any workaround you could think of that would allow VolCam to track correctly with PMO? I'd really appreciate it as I didn't expect PMO to have any issues like this and I'm relying quite heavily on it's functionality.

I don't mean to sound like I'm just being defensive, but I don't think volCAMERA has anything to do with your problem. When I completely disable volCAMERA in your MFA, I can see the same type of stuttering on the character.

Please login to see this picture.

If I disable volCAMERA and set the mfa to always centre on the player as below, then the player of course becomes smooth (since he's no longer actually moving on the screen). But now, everything else (the trees, the rocks, poor Santa...) stutters in just the same way as the character did previously. It's just less noticeable because one doesn't look at them as intently.

Please login to see this picture.

I guess it's just how PMO works. You could try fiddling with some of the physics values and/or the MFA's framerate (acceleration, speed, etc.) and see if you can find a combination that feels smoother. I got considerably less stuttering when I tried Max Y velocity = 400 and gravity = 6. The demo that comes with volCAMERA uses PMO and actually moves very smoothly. I think that's partly because the movement is faster, and partly because the MFA is high-resolution (see below)

The "maximise on bootup" setting also has a lot to do with it. Please login to see this picture. If you turn it off, the stuttering isn't too bad, but when it's on it amplifies those 1-pixel jumps since each pixel is now so huge. I guess you could try using a higher resolution in your game and 'simulating' the pixelart look instead, by making each 'pixel' actually comprised of 4, or 9, or 16 pixels. This would make the graphics just as blocky as before, but would allow things to move at finer increments.

Hey Julian I've been purposefully avoiding the forum, just like I've been purposefully avoiding a lot of other things, like social media. (Though I've missed the forum, unlike social media, which I don't miss in the slightest). I've had less time and head-space to work on Spryke this year than in previous years (two children is way more exhausting than one!), so I've tried to cut down on as many different distractions as I can to maximise the time I do have. The last time I actually played a single minute of a computer game (other than Spryke) was January! I'm back this week because I needed to come here to get some help, and ended up sticking around a bit, but don't be surprised if I soon disappear again into my Spryke cave. I hope Outbuddies is going great!

Hi volCAMERA users, there's a volCAMERA update in the works, but it's likely still a way off. I've made a few improvements here and there over the past few months to the volCAMERA code that I use in my game Spryke, but it always requires some work to get those kinds of improvements into the generic version of a product without breaking stuff. I know I'll make more improvements in the near-mid future, so I'll hold off on official updates till after then. So for now, I want to highlight a couple of bugs that have come up in this forum. They'll be fixed in the next update, whenever that arrives, but until then you can fix them yourselves as shown below.

BUG 1, found by PBarwick (could make the camera boundaries not display properly in the demo - actual camera engine is unaffected):

Quote from PBarwick

Line 317 reads:
- Start loop "place volCAMERA X boundaries" Ceil(Frame Width / 1000) + 1 times
- Start loop "place volCAMERA Y boundaries" Ceil(Frame Height/ 1000) + 1 times

and it should read:
- Start loop "place volCAMERA X boundaries" Ceil(Frame Height/ 1000) + 1 times
- Start loop "place volCAMERA Y boundaries" Ceil(Frame Width/ 1000) + 1 times

BUG 2, could prevent left/right camera overshoot from working properly. Make this change to fix it:

Please login to see this picture.

Yeah, my work approach has evolved in a similar direction. I've been spending most of this year working on...not necessarily code, but ....I guess I'd call it systems. So much of the game was comprised of disparate parts that were stuck together for this demo or that conference. And, like you, I was jumping from art to code to marketing to animation etc. I've taken a step back from that approach and am working on making everything as solid as I can, and the workflows as efficient and automated as possible. Some of that's code, some of it's photoshop.

For example, by combining Photoshop's artboards and image generator features with Fusion's PNG import feature, I've now got it set up where I can make a change to any graphic in Photoshop, then immediately hit run in Fusion (mapped to one of the 15 buttons on my mouse - no time-wasting keyboard shortcuts for me ), and the graphic will appear in the game runtime - no save dialogs, no import dialogs, no locating the files, nothing - you just work on the graphics whenever you want, then see them automatically updated in-game. It takes a little planning and setup to get this workflow happening, but once it is, it's such a breath of fresh air to work this way!

Once the workflows (graphics generation, level generation, NPC scripting, etc.) are all solid and streamlined, it'll hopefully let me dive into the purely creative side (graphics and level design etc.) and crank out the game content without much other friction getting in the way.

Haha. Yes, I'm often totally guilty of that. The problem with perfectionism is that it's sometimes your worst enemy, but it's also sometimes your best friend. My perfectionism is responsible for both my best work and my biggest time-wasters. The trick is to try and catch which is which - easier said than done of course.

I'm sure I fall in love with my tools too much sometimes. But other times I know they greatly reduce friction and confusion in my workflow, which saves me time and, even more importantly, sanity.

Answer: use the new "instant teleport mode."! X) It, along with lots of new features like camera marshalls, cutscene mode, drunkcam and new HUD modes, are in the latest version. But you'll have to wait for it to appear at the clickstore. I submitted it a few weeks ago, but there's a backlog.

In the meantime, setting x and y catchup to 1 whenever you want the camera to instantly snap should do the trick.