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...
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...
I just had a look, it seems that it is:
System.ocg/Explode.c
etc.
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.
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?
>Do you want to do that?
Of course!
..but I can't, it's in the engine.
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.
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.
>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!
I had a look at the source.
So the thing you gotta do is to alter the two calculations those two fields are involved in in
Probably is is this, but you can try out yourself.
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;
>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
> 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)
Sorry for the wait, I tried it now with:
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)
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)
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.
I'd rather like this to be your contribution. Write what you don't understand and people can help you.
To summarize:
What you gotta do is to find at which places
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)
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.
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.
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!
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!
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.
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.
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.
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.
Powered by mwForum 2.29.7 © 1999-2015 Markus Wichitill