Kaleidoscope

If you ever see the code for ABC-Pop (not if I can help it). You would soon became rationally angry at my design choices. And then, very soon - irrationally angry. In my previous post I wrote about camera-pan movement and render to texture functions in which I rendered entire level to a texture and then just rendered the camera view to the screen. Well, when I was developing ABC-Pop, I never knew about SDL_SetRenderTarget function (in hindsight, it's obvious) and I soon encountered the problem of handling my UI and game rendering for multiple resolutions. A sane mind would go on the net and search about handling UI rendering and game rendering against unknown target resolutions. Not me. I like to invent and discover stuff for my self. But sometimes instead of discovering hot water, you end up discovering piss. And that was what I did for ABC-Pop. So instead of heating water to boil, I pissed in the pan and called it hot. Okay, enough metaphors. I made my entire game work

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 bo