Screen Shake effect
BlitzMax Forums/BlitzMax Programming/Screen Shake effect
| ||
| Hi has anyone ever tried to make a screen shake effect? I can think of threww ways of doing this: 1) make sure that EVERYTHING you draw has offset x and y added on to their coordinates. these are normally 0 but change when the screen is shaking. Problem with this is it would slow down all drawing operations and be a pain to convert existing code. 2) Use some kinda DX or OpenGL calls to tell the videocard to start rendering at a different top left origin. 3) Use BMax to tell the video card to use a different top left origin, can this be done? thanks! |
| ||
Quick example:MaxOffset:float = 10 Repeat SetOrigin Rnd(0-MaxOffset,MaxOffset) MaxOffset:-0.1 Until MaxOffset <=0 |
| ||
| what and that works for all graphics drawn? Cool, I'll try it out. |
| ||
| Changing the origin manually seems more like a hack to me. If this is for a specific project, this may end up being the easiest solution. However I'm guessing you want this to be usable for many types of games. Something even better is a Camera based rendering system. Separate in your application World coordinates from Screen coordinates. Possibly handled by a camera type. All game logic operates on the world coordinates. When things are rendered their position and scale are translated into screen coordinates for the current view/camera. The current view/camera can be positioned to point at either a static position in the world or a game entity/player. Random velocities can then be given to the camera, which ease back to to the camera/views target position. You should find that setting up a system like this enables many other very useful things as well. I posted a demo of a very early version of my generic game engine a while back. |
| ||
| altitudems: Yeah that's basically my option 1. Most of the things on my screen can do that as they use an additional coord call ScrollX and ScrollY, even the particles. But a few things I've "manually" added on don't so for now the hack works great. Thanks GfK |
| ||
| Changing the origin manually seems more like a hack to me. Why? Its five lines of code that works perfectly. Something even better is a Camera based rendering system. <snip> You forgot to mention 'unnecessarily over-complicated'. |
| ||
| make sure that EVERYTHING you draw has offset x and y added on to their coordinates. these are normally 0 but change when the screen is shaking. Problem with this is it would slow down all drawing operations and be a pain to convert existing code. No.But as I see that GFK has answsed better than I would have. As to the "Hack" isuse, it depends on how you noramly draw things, I draw everything at/around origin, and simply move/rotate and scale as nessesary, so adding an "arbitary" wobble seems natral to me. Snippit, just to show Im not making it up. (ie its of no value) Method DM_Draw ()
SetOrigin (Self.F_Position.F_X*TLED.GF_ScreenMulti.F_X, Self.F_Position.F_Y*TLED.GF_ScreenMulti.F_Y)
SetRotation (F_Rotation)
SetScale (TLED.GF_ScreenMulti.F_X*Self.F_Size,TLED.GF_ScreenMulti.F_Y*Self.F_Size) |
| ||
| Essentially yes, it would be doing the same thing, except all you would have to change is the Render/Draw method of your entity/gameobject class. But yes sometimes it doesn't matter if its a hack or not. If it works, it works. Sounds like SetOrigin is easy solution to your problem. |
| ||
| I'm currently using the offsetx and offsety method and it just works. How would it make all draw commands slower? |
| ||
| An extra couple of mem lookups/calculations per draw |
| ||
| But it's already being added, although at a value of zero to everything, so how will it make it slower when it changes value? |
| ||
| I think the point is it will always make things slower by the same amount, whether it is 0 or not, compared to the same drawing instructions which do not perform this operation. After all how can the computer know the value to be added is 0, without reading the memory? |
| ||
| What Czar said. SetOrigin is the way forward for both speed and simplicity. |
| ||
Going like this:Draw Alien,x+xoffset,y+yoffset is bound to be slower than: [code]Draw Alien,x,y[code] That's what I meant. Calling SetOrigin is one call yet if you drew hundreds of particles using the xoffset method it would slow down the drawing due to all the additions. That's the way I viewed it anyway. |
| ||
| Use the projection matrix and offset that by a couple of pixels each time. In fact with the matrix you could scale and rotate. Since this is all done on the GFX card you don't get any slowdown. The projection matrix works with OGL and DirectX so it'll be compat on all platforms also. |
| ||
| sounds great but it's too late for this project (probably). |
| ||
| Hello. Put a rumble pack under the monitor? Move to LA/Japan? Goodbye. |
| ||
| "Well done, you have activated a bonus, please pack your PC carefully, fly to San Andreas, plug the PC in (you may need to purchase a power adapter) and wait for the next earth quake. When it occurs, press the space bar to resume play and to enjoy the special effect fully. Thank you." |
| ||
| Does the bonus pay the travel expenses? You may aswell just shake the moniter yourself. |
| ||
| I could just see that, a bomb goes off in the game and a prompt appears: "Please shake your monitor, press OK when done". |
| ||
| I would recommend that you shake the object, and not the screen with an offset. If your shaking the screen then everything rumbles, but what if you want to make your rumble more refined and only have objects say, within a blast range to shake, then you wouldnt be able to do it. What I would recommend is to build an offset system for each object that's draw, make it a common type and then just extend it to all new types your game uses. If your doing 3D, and want the full screen to shake then just shake the camera, if its 2D, just use the offset method. I am not sure if having to offset say 1000 particles would be any slower than drawing them without the offset, they still have to be drawn at a given x,y position, the only change is that the x,y changes slightly each time during the rumble. I might go test that. |
| ||
| trust me, arcade style screen shake is what I want :-) Although interesting I will be using the shake on one game object only in a different scenario. |
| ||
| Does the bonus pay the travel expenses? You may aswell just shake the moniter yourself. I could just see that, a bomb goes off in the game and a prompt appears: "Please shake your monitor, press OK when done". LOL, nice idea, what we need are some API like ShakeMonitor() or ShakeHouse() or ShakePlayer(). (If you're using methods like Shake.Monitor() would be nice and easy....) |
| ||
| how would achieve this if your using 2d, and setorigin is being called once already to distinguish world coords from screen coords and keep the "camera" focused on your entity. |
| ||
| By adding the values together before passing them to SetOrigin. |
| ||
| whatever you do not wish to be effected by the shake you could always just add or deduct the Maxoffset off/on too..You may need a flag to tell if shake is on or off to be able to tell when to do this... |
| ||
| question: if you pass them to set origin, you;d have to have something to bring it back down to 0, so it doesnt keep shaking. so if you add a bit of shaking like 0.5 on the x and y axis, to shake your viewable screen left/right up and down slightly, then it has to add subtract, add subtract to makethis happen. so your view has to move to the right slightly and also back left again before shaking to the left first. question2: is there any way like in my case, to keep your POV fixed on your entity in the centre of the screen? without using set original, but still have it move in "world" coordinates? |
| ||
| I don't do much 3d, but I would assume theres a code archive for rotating around an object, you could just do random increment/decrement's with boundaries so the camera doesn't spin all the way around. |
| ||
| Use SetOrigin. |
   |