Not logged inOpenClonk Forum
Up Topic Development / Developer's Corner / Screenshake bug
- - Date 2014-04-19 07:15
Parent - - By Andriel Date 2013-09-14 12:46
I've been following this game for a while now, I hope it will be good! :)
But yeah, explosions in OC should be much "juicier", they need better sounds and screenshake! Currently, both is completely missing: sounds are missing due to a bug (btw, I stumbled over this, too), and screenshake is missing because of ... another bug? At least my viewport doesn't even perform a slight tremble when blasting something...
Reply
Parent - - By Newton [vn] Date 2013-09-14 13:36

>screenshake


I think it is just not implemented.
Parent - - By Andriel Date 2013-09-14 14:11
I just had a look, it seems that it is:

System.ocg/Explode.c

global func Explode(int level, bool silent)
{
  if(!this) FatalError("Function Explode must be called from object context");

  // Shake the viewport.
  ShakeViewPort(level, GetX(), GetY());

  
etc.
Reply
Parent - - By Newton [vn] Date 2013-09-14 15:33 Edited 2013-09-14 15:39
ShakeViewPort is also defined in the same file along with the ShakeEffect. You could try if the function SetViewOffset is working in script.

Also, SetViewOffset should probably be changed to that the offset is not given in landscape-pixels but screen-pixels so it is independent on the zoom level. Or perhaps even not in pixels at all but in promille of the screen width or something so it is even independent of the viewport size - this was already the problem with the viewport shake in Clonk Rage: Players with a huge resolution would only see a light vibration.

Do you want to do that?
Parent - - By Andriel Date 2014-04-18 14:23

>Do you want to do that?


Of course!

..but I can't, it's in the engine.
Reply
Parent - - By Newton [th] Date 2014-04-18 19:14
Wow, that's a late reply.

Well, you could try. You can only learn something in the process. If you are new and unsure how to go about in the engine source, search for and have a look at other functions that use screen pixels as input (as SetPlayerZoomByViewRange) and copy that behaviour. I myself wouldn't do otherwise.
Parent - - By Andriel Date 2014-04-18 21:53

>Wow, that's a late reply.


Yeah sorry, I forgot about it until I saw it in my watch list recently.

>Well, you could try.


I spent this afternoon trying to get into the source code, it got me as far as finding what looks like a function declaration of SetViewOffset inside C4GameScript.cpp, but I have no idea what the difference between .cpp and .h files or where and what the relations between different files, operations or tasks are.
I'll most likely start another attempt soon, but I find it really hard to even get an overview of some of the things happening there.

>If you are new and unsure how to go about in the engine source, search for and have a look at other functions that use screen pixels as input (as SetPlayerZoomByViewRange) and copy that behaviour.


That's what I thought too, but I couldn't understand that function. Doesn't help that I kind of suck at maths.

Well, I might accomplish something tomorrow!
Reply
Parent - - By Newton [th] Date 2014-04-19 07:15
I had a look at the source. SetPlayerZoomByViewRange is not really helpful. Instead, search for all occurances of ViewOffsX and ViewOffsY in the source. These fields of the C4Viewport class are set via the script function SetViewOffset.

So the thing you gotta do is to alter the two calculations those two fields are involved in in C4Viewport::AdjustPosition() and perhaps add a comment to their declaration that they are in viewport coordinates (now). (Also, change the documentation.)

Probably is is this, but you can try out yourself.
    // apply offset
    ViewX -= ViewWdt / (Zoom * 2) - ViewOffsX / Zoom;
    ViewY -= ViewHgt / (Zoom * 2) - ViewOffsY / Zoom;
Parent - - By Andriel Date 2014-04-21 12:17 Edited 2014-04-21 12:46

>Probably is is this,


Hm, so by adding "/ Zoom" you make the outcome independent of the zoom? Wasn't the plan to make it in promille of the screen size? Maybe we can use something I found in C4Viewport.h, like GetOutputRect() or
// "display" coordinates
  int32_t ViewWdt,ViewHgt;
  int32_t BorderLeft, BorderTop, BorderRight, BorderBottom;
  int32_t DrawX,DrawY;

?

or this?

ViewportArea.X, ViewportArea.Y, ViewportArea.Wdt, ViewportArea.Hgt

GetScreenWdt(), GetScreenHgt() ?

or its this GBackWdt and GBackHgt, as in C4Viewport::CenterPosition()

EDIT:
If ViewWdt is the width of the screen (I don't know if it is), and ViewOffsX is the promille of the screen, how about this:

ViewX += (ViewWdt / 1000) * ViewOffsX;

?
Trying this out now
Reply
Parent - - By Newton [th] Date 2014-04-21 12:48

> Hm, so by adding "/ Zoom" you make the outcome independent of the zoom? Wasn't the plan to make it in promille of the screen size?


I'd say so. Did you try it? To make it in % of viewport size, add * ViewWdt / 100 (and ViewHgt respectively)
Parent - - By Andriel Date 2014-04-27 12:09
Sorry for the wait, I tried it now with:

ViewX -= ViewWdt / (Zoom * 2) - ViewOffsX / Zoom;
ViewY -= ViewHgt / (Zoom * 2) - ViewOffsY / Zoom;


And it seems to have the wanted effect, but everything is reversed: SetViewOffset(0, 100, -100) with the old code has the same outcome as SetViewOffset(0, -100, 100) with the new code. Also, when zooming in on the set offset, the camera goes farther away from the clonk, when it actually should come closer, shouldn't it?

how to fix plz (I just tried lots of variations, changing - to +, / to * and so on, but I can't seem to get it right)
Reply
Parent - - By Newton [th] Date 2014-04-27 15:16
You can use crucible to allow us to review your patch.
Parent - - By Andriel Date 2014-04-27 18:39
Well, but it isn't even my patch. There's just this one change by you and I neither understand how it (almost) works, nor do I know how to fix it.
Reply
Parent - - By Newton [th] Date 2014-04-27 21:09
I'd rather like this to be your contribution. Write what you don't understand and people can help you.

To summarize: ViewOffsX and ViewOffsY are set by the C4Script function SetViewOffset(). ViewX and ViewY is the upper left corner of the player's viewport in landscape pixels. Zoom will be 3 if zoomed in 3x, 0.5 if zoomed out 2x etc.
What you gotta do is to find at which places ViewOffsX and ViewOffsY is used in the code (Ctrl+F) and adapt the calculation like we discussed everywhere. (It is used in more than one place)
Parent - - By Andriel Date 2014-04-27 21:22
Ok, thank you for the explanation. I will experiment a bit.
Is there a quicker way to test minimal changes than compiling every time?
Reply
Parent - By Newton [th] Date 2014-04-28 06:08
No
Parent - By Sven2 Date 2014-04-22 12:29

> ViewX += (ViewWdt / 1000) * ViewOffsX;


ViewWdt is int, so multiply before dividing.
Parent - - By Nachtschatten Date 2013-09-24 09:52
Interesting. I was glad the shaking was gone and assumed it was removed on purpose for being far too disruptive. (Just like the lightning made the whole screen flash white...) Seriously, "visual" effects that basically send you to a forced break from the game are just annoying.
Reply
Parent - - By Newton [la] Date 2013-09-24 11:56
In which resolution did you normally play?
Parent - By Nachtschatten Date 2013-09-24 12:29
800x600 mostly, sometimes one above that (1024x768?).
Reply
Parent - - By Andriel Date 2013-09-24 12:24
How is half a second of screenshaking interrupting the gameplay? You would at least wait so long until the smoke from the explosion and the casted materials have settled anyway.
Reply
Parent - - By Nachtschatten Date 2013-09-24 12:48
You don't see what's going on on your screen. This may not be that critical when mining, but in hectic melee situations it is. That is also why I'm not a fan of overdone explosion effects (aside from screen shaking). Even more annoying were the earthquakes, which lasted several seconds.
What I also found irritating for the eyes was the randomness of the shaking. There were some games that did it differently by just giving the screen a fluid up-and-down motion. Red Alert on the PlayStation did it that way if my memory serves right. Trying that alternative effect may be worth a try.
Well, to be clear: I don't want such "juicy" effects for small explosions like those of flints. This is small stuff that happens all the time. About massive explosions with nice effects and a shaking screen: Yes, please!
Reply
Parent - By Andriel Date 2013-09-24 13:29
I agree with you on the earthquakes. But flint explosions do not happen "all the time", they are a special and also somewhat dangerous event which should be carefully executed. It may happen more often in a game like Clonk but it's not like permanently raining flints after all.

And for the melee situation: The screenshake (and therefore resulting confusion) is part of a flint attack. In OC, there are plenty of other weapons, so explosives are by far not used as often as in CR, where they were almost the only choice for an attack (besides the passive Clonk to Clonk fight).
You should be disoriented when hit by an explosion.
And as Sven alrady said, the screen should of course only shake when you are directly affected.
Reply
Parent - By Sven2 [de] Date 2013-09-24 12:39
For Flints I find it OK, because flint explosions are special events and you usually control it yourself. If an enemy does it against you, it may be annoying but then it's a strategical element and part of the attack (like smoke grenades, etc.).

What I found really annoying was constant screenshaking in maps that have earthquakes. You could never know when the next earthquake would come and disrupt your vision mouse controls.

I think if screenshaking is reintroduced, it should happen only when the event is happening really close to you. I.e. explosions or earthquakes that affect your Clonk directly.
Up Topic Development / Developer's Corner / Screenshake bug

Powered by mwForum 2.29.7 © 1999-2015 Markus Wichitill