Implementing Camera Pan in Critters



Camera Pan




Speaking about another thing I never paid attention to in my 2D game prototypes, camera movement and camera view ranks just around the top. Next to the UI. They're friends in fact.

When implementing parallax scrolling and even when playing with the top down tiled based programs I coded, the idea of camera control was always there, but as my prototypes never did move above, well the prototypes phase, I never really needed a true camera view and control.
Until I started playing with the Critters Level design that is. And the first design decision was:
Levels will be larger than device max resolution. So no more cheating and moving level layers at different speeds, It's time for a serious 2D Camera implementation.

So what does camera object needs to properly function? Not much as it turns out. It needs CameraView rectangle, UpdateCamera function, x and y relative to mouse motion and current level's width and height to make sure camera view stays in bound of the level and that's it.

In our main loop, we now listen to the  SDL_MOUSEMOTION and update out global variables based on the received event. For camera, we are especially interested in the sdlEvent_.motion.xrel and sdlEvent_.motion.yrel variables because they track the relative motion in their respective directions. We need these values because in our case the Camera is moved by holding the right mouse button. Or in Android case a multi touch gesture.
We also, call Camera's UpdateCamera from this event.

Our UpdateCamera function is simple.

If right click is pressed / multi touch 
  If we are moving camera right  (-xrel)
    subtract xrel from camera.x
 else we are moving camera left (xrel)
     subtract xrel from camera.x

Do the same when moving camera up and down and in the end do the checks to not let the camera leave the level rectangle.

Sample code:


Example Camera Movement

  
The other thing that needed work was my Level drawing function.

Until now, the level just drew all its elements directly on screen, but with camera, this changes a little. So instead of the screen, we now render to texture and then clip the camera_view to the screen.
To do that we must first create a blank SDL_Texture the size of the level with the SDL_TEXTUREACCESS_TARGET parameter set. Once this is done we can now use this new texture as a giant screen and just draw the entire level as we would normally but this time using  SDL_SetRenderTarget.

At this point we have entire level drawn on the specified texture and now we just need to show the specified camera rectangle on screen and that's it.
Camera Panning complete.

Example SDL_SetRenderTarget




 If you're interested in Critters or find this blog moderately interesting,
You can follow me on Twitter for news and updates
https://twitter.com/CrittersDev






Comments

Post a Comment

Popular posts from this blog

Trouble in Qt Paradise

Image
I've spent more than a decade making professional commercial programs in Windows and MFC. Before that, I was working in now extinct Borland C++ Builder and VCL (I miss you old friend). Way back when, around year 2000, I had Linux as my primary OS installed (Mandrake - I don't miss you) and was testing different APIs to get a feel of programming GUI for Linux. At the time I had access to KDE and Qt. KDE was OK, but when I tested Qt, something clicked. Their entire programming paradigm just resonated with my programming style. And while KDE had more of the Win32 API approach, Qt was entirely different. And while KDE and Win32 at the time made me code message loops, in Qt, all was provided on more or less few lines of code. I think I made Tetris clone in Qt before ditching Mandrake for Windows. Fast forward a few years and I got my first job as a C++ programmer. Me being a self taught programmer I walked to work every morning with an ear to ear wide grin every day. After my tr
Read more

Programming UI for Critters

Image
I never really thought about how UI is coded for games. For me, mostly working with OS level APIs UI was something that's handled by the OS and I just mostly put my controls on the provided IDE's canvas and code away - mostly. Even for fun, when making mechanical prototypes at home, UI was almost an afterthought. The most I ever made was maybe a start screen with a few buttons to start game or quit game. It worked fine for my needs and even when I started seriously working on ABC-Pop , UI was the last thing I started to work on.  Pretty much all the mechanics for the game was finished at that time. I mean, how hard can it be? Put buttons on the window, and when clicked, change something. Well, as it turns out it can be pretty fucking hard. I soon found myself entangled in 3 separate execution loops all firing different type events toward the main loop all juggling in my head and me trying to keep it all under control. And if you've seen the trailer for ABC-Pop you can a
Read more

Of Loot Bombs and Sticky Walls

Image
While you program, you create and form a thought and visualize it through a programming language. It's a beautiful and interesting process that is its own reward. But inevitably, this process will also create nasty little buggers called  bugs.  A flaws in thought, programming logic or simply an error while writing code. In the early Critters development, back in the dawn of time (few weeks ago). I implemented a Toolbar HUD element with a few Critters-Murder tools I wanted to test and play around with, with one of them being a grenade type weapon that player can drop on the little bastards. After timer is complete, the bomb grenade explodes with the satisfying destruction inside its radius. Critters die and spawn gems and ammo. Player collects loot and continues the destruction. All in all, often used but a proven little concept of blowing stuff up. Until loot pickup started spawning their own grenades - that is.  Now, I'm the first one in line for more Critter destruction,
Read more