I have a side scrolling platformer that uses Chipmunk and Cocos2d for iPhone. The player moves from one side of the level to the other side of the level to complete the level. The player actually moves from one side to the other; the background is not repeated to create the illusion of scrolling.
However, I have been befuddled as to how I could do this with a parallax background. The level goes to about 3000 on the x coordinate.I cannot use an image that large. I also cannot make the image repeat itself after the player reaches a certain point because the player is not standing in one location.
Any suggestions?
You can split the background image into 3 images, each 1024 pixels in width. Simply offset the 2nd and 3rd image sprite's position by 1024 times 2 respectively times 3.
Related
i have a LOGO image and i want to dissolve it into small square pixels images from down to top of the Logo image with fade in action and Logo remove completely then my game start. how can i do it in cocos2d-x v3 using C++ coding or any other way?Thanks in advance.
There's nothing in this code just to have permission to ask question i made it just like that.
CCAction *fadeIn = [CCFadeTo actionWithDuration:0.5 opacity:0.5];
CCAction *fadeOut = [CCFadeTo actionWithDuration:0.5 opacity:1.0];
CCSequence *pulseSequence = [CCSequence actions:[fadeIn copy],[fadeOut copy], nil];
I think your only method here to TRULY have the logo dissolve into pixels, will be brute force, which will mean rebuilding the logo one pixel at a time by adding single pixels sprites onto a layer, so instead of logo.png you have a ton of whitepixel.png redpixel.png etc, then send them into action. Depending on how fast it dissolves, this would work (although rebuilding the logo with pixel art will take a long time, i'd recommend doing it with a pixel matrix and write a function to place the sprites).
Alternatively, you can fake it by simply slowly covering/obscuring/fading the sprite top to bottom and spitting particles out along the wipe line. If you want it to un-print slowly one line at a time, you'd need 2 obscuring images, one to cover vertically as you go line by line, one to be wiping the next line horizontally. This would be much easier to demonstrate via video, add my Skype reduxde if you want and I can show you with some construction paper.
I'm bad with particles, but as long as you're picking particles that match the colors in the logo, most peoples eyes won't be able to track it to realize the pixels aren't a 1:1 match up.
For a logo that's say 160 by 100 pixels though, you're talking 16,000 sprites by the brute force method, which will undoubtedly lag out your devices (I've managed to get about 700-800 sprites in motion before until the engine chugs).
Probably your best bet would be to hire a graphic artist and do this as an animation using a sequence of photos (which would be choppy compared to a true dissolve).
I have a video sequence of which one frame is shown below as shown below.
I was trying to use corner detection to find the edges of the rectangle on the sheet of paper.
I am using the Shi-Tomasi corner detector for the same. However it detects a number of other things that I don't need from the background of the image. How can I narrow down my ROI to only the sheet of paper.
Second Question:
In the video sequence upon detecting The corners I need to play another video inside the rectangle. I was trying to do this using a single thread but it lead to a lot of lag and jerks. What can I possibly do to improve my processing speed. Do I need to use multiple threads for each video. One video is from the webcam while the other is from the hard-drive.
Here is what I did for one of previous projects.
Find all contours in your picture and approximate each with 4 corner shape
Find right rectangle with your own condition such as rectangle with area > 1000000
(optional) you will notice that your rectangle is not real rectangle because of 3D world. You might want to do perspective transformation to get correct rectangle
Paint green or whatever texture on the found rectangle since you already have 4 corners from above
As for jerky playing, you might want to use not only multithreading with GPU but also encryption to improve speed.
I have a problem and I saw it also in the game Candy Crush Saga, where they successfully dealt with it. I would like the sprite to show only when it is in the board (see image link below). The board can be of different shapes, like the levels in the mentioned game.
Has anyone some ideas how can this be achieved with Cocos2d?
I will be very glad if someone has some tips.
Thank you in advance.
image link: http://www.android-games.fr/public/Candy-Crush-Saga/candy-crush-saga-bonus.jpg
In Cocos2d you can render sprites at different z levels. Images at a lower z-level will be drawn first by the graphic card and the images (sprites) with a higher z-value will be drawn later. Hence if an image (say A) is at the same position of the other but has a higher z-value you will see only the pixels of image A where the two images intersect.
Cocos2d uses also layers so you can decide to add Sprites to a layer and set the layer to a specific z value. I expect that they used a layer for the board (say at z=1) with a PNG image containing transparent bits in the area where you can see the sprites, and a second layer at z=0 for the sprites. In this way you can only see the sprites when they are in the transparent area.
Does this help?
I found out Cocos2d has a class CCClippingNode which does exatclly what I wanted. First I thought it can clip only rectangular areas, but after some research I found it can clip also paths.
I just want to do a simple animation (for example in C++ using OpenGL) of some moving object - let's say simple horizontal movement of a square from left to right.
In OpenGL, I can use "double-buffering" method and let's say a user (running my application with the animation) have turned "vertical sync" on - so I can call some function every time when a monitor refreshes itself (I can achieve that for example using Qt toolkit and its function "swapBuffers").
So, I think, the "smoothest" animation that I can achieve, is to "move the square by for example 1 pixel (can be other values) every time monitor refreshes", so at each "frame" the square is 1 pixel further - "I HAVE TESTED THIS, AND IT SURELY WORKS SMOOTHLY".
But the problem arises when I want to have "separate" thread for "game logic" (moving the square by 1 pixel to the right) and for "animation" (displaying current position of the square on the screen). Because let's say the game logic thread is a while loop where I move the square by 1 pixel and then "sleep" the thread for some time, for example 10 milliseconds, and my monitor refreshes for example every 16 milliseconds - the movement of the square "won't be 100% smooth" because sometimes the monitor will refresh two times where the square moves by only by 1 pixel and not by 2 pixels (because there two "different" frequencies of monitor and game logic thread) - and the movement will look "little jerky".
So, logically, I could stay with the first super smooth method, but, it cannot be used in for example "multiplayer" (for example "server-client") games - because different computers have different monitor frequencies (so I should use different threads for game logic (on the server) and for animation (on the clients) ).
So my question is:
Is there some method, using different threads for game logic and animation, which do "100% smooth" animation of some moving object and if some exists, please describe it here, or when I just had some "more complex scene to render", I just would not see that "little jerky movement" which I see now, when I move some simple square horizontally, and I deeply concentrate on it :) ?
Well, this is actually typical separate game-loop behavior. You manage all you physics (movement) related actions in one thread, letting the render thread to do its work. This is actually desirable.
Don´t forget this way of implementation of game loop is to have maximum available frame rate while preserving constant physics speed. At higher FPS, you can not see this effect by any chance, if there is not any other code related problem. Some hooking between framerate and physics for example.
If you want to achieve what you describe as perfect smoothness, you could synchronize your physics engine with VSync. Simply do all your physics BEFORE refresh kicks in, than wait for another.
But this all applies to constant speed objects. If you have object with dynamic speed, you can never know when to draw it to be "in sync". Same problem arises then you want multiple object with different constant speeds.
Also, this is NOT what you want in complex scenes. The whole idea of V-sync is to limit screen tearing effect. You should definitely NOT hook your physics or rendering code to display refresh rate. You want you physics code to run independent of users display refresh rate. This could be REAL pain in multiplayer games for example. For start, look at this page: How A Game Loop Works
EDIT:
I say your vision of perfect smoothness is unrealistic. You can mask it using techniques Kevin wrote. But you will always struggle with HW limits as refresh rate, or display pixelation. For example, you have window of 640x480 px. Now, you want your object to move horizontally. You can move your object by vector heading towards bottom right corner, BUT you must increment object coordinates by float number (640/480). But in rendering, you go to integers. So your object moves jagged. No way around this. In small speed, you can notice it. You can blur it, or make it move faster, but never get rid of it...
Allow your object to move by fractions of a pixel. In OpenGL, this can be done for your example of a square by drawing the square onto a texture (i.e. a one-pixel or larger border), rather than letting it be just the polygon edge. If you are rendering 2D sprite graphics, then you get this pretty much automatically (but if you have 1:1 pixel art it will be blurred/sharp/blurred as it crosses pixel boundaries).
Smooth (antialias) the polygon edge (GL_POLYGON_SMOOTH). The problem with this technique is that it does not work with Z-buffer-based rendering since it causes transparency, but if you are doing a 2D scene you can make sure to always draw back-to-front.
Enable multisample/supersample antialiasing, which is more expensive but doesn't have the above problem.
Make your object have a sufficiently animated appearance that the pixel shifts aren't easy to notice because there's much more going on at that edge (i.e. it is itself moving in place at much more than 1 pixel/frame).
Make your game sufficiently complex and engrossing that players are distracted from looking at the pixels. :)
How would you store game level for a Dizzy-like adventure game? How would you specify walkable areas and graphics? Is it tile-based, pixel-based or walkable surfaces can be described by vectors?
Very old adventure games (like Sierra's quests from the 80s) used to actually maintain a separate bitmap of the entire screen that represented z-depth and materials to determine where your character could go and where it would be hidden. They would use pixel sampling to check where their small sprites would go.
Though current machines are faster, long side scrolling levels make this sort of approach impractical, IMHO. You have to go with more sparse representations.
One option is to "reduce" your game into invisible tiles, which are easier to represent. The main problem with this is that it can constrain your design (e.g., difficult to do diagonal platforms), and it can make the animations very shoddy (e.g., your characters' feet not actually touching the platform). This option can work IMHO for zelda-like adventure games, but not for action games.
A second option is to represent the game world via some vector representation and implement some collision detection. I would personally go with the second solution, especially if you can be smart about how you organize your data structures to minimize access time (e.g., have faster access to a subset of world elements close to your characters current position).
I wouldn't be surprised if there are available 2D game engines that provide this sort of capability, as there are definitely 3D engines that do it. In fact, you may find it easier to use an existing 3D game engine and use it to render 2D.
The Dizzy game is probably using a tile-based system. The game world is made up of a palette of tiles that are repeated throughout the level. Each tile would have three elements - the image drawn to the screen, the z-buffer to allow the main character to walk behind parts of the image and a collision map. The latter two would be implemented as monochrome images such that:
colour | z map | collision
-------|--------------------|---------------
black | draw dizzy infront | collide
white | draw dizzy behind | don't collide
Storing these are monochrome images save a lot of ram too.
You would have an editor to build level that would display a grid where tiles can be dragged and dropped.
That specific game is a tile-based game, with pixel perfect collision. The collision was controlled by a single bit in the colour byte of the tile (the brightness) and you could also mirror the tile by setting the flashing bit of the colour.
The tiles, however, could only be placed at even x,y coordinates (I suspect this was done to help the collision system a bit.)
The collision system involved a persistent check around the hero. The rules were roughly:
- If it finds a non-collision pixel row below the hero, it dropped the hero by 1 pixel.
- If there is a collision intersection with the hero, it raised the hero by 1 pixel.
- When moving left or right, it checks in that direction and if:
- if finds a wall (collision height more than 4 pixels), deny movement in that direction;
- if it finds a climbable box (collision height up to 4 pixels), allow movement in that direction.
- If there is enough headroom allow jumping, else, stop at the last possible free position.
When combining these simple rules, you obtained a very smooth collision negotiation able to walk even arbitrary slopes without extra taxing.
In creating such a game, I would use individual tiles, I would assemble them on layers (background, foreground etc...) and render them. I would assemble a separate collision map from the tiles attributes that indicate a collision tile, and I would use that separate map to negotiate the hero's collision and movement.
Similar to this demo: http://games.catevaclickuri.ro/