I'm using a particles, slightly modified CCParticleFlower with positionVar to be in form of vertical line, from top to bottom. In CCNode update I constantly change the position of the particles from left to right across the whole screen, when it reaches the right side I set x to 0 and start scrolling to the right.
The problem is when I reset the X value to 0, all particles blinks, they disappear for about one frame and appear in the next frame, it causes a nasty flickering effect.
It does not happen when I increment X values by small numbers but when the particle position is reset to its beginning position it flickers, on win32, android and ios. I’m using most recent 1.1 version (master branch)
I recently had something of a similar problem where the particles would jump around whenever their parent changed direction. I'm not sure if it's exactly the same problem, but here's the thread I found that helped with my problem:
http://www.cocos2d-iphone.org/forum/topic/17167
The relevant post:
I just encountered the same problem and it took me a while to get to the bottom of it, >here's the low down: do not use
[self schedule:#selector(NextFrame:)];
Instead, use
[self scheduleUpdate];
and rename NextFrame: to update:
Using a custom selector schedules your update at the very end of the CCScheduler queue, in other words, it will cause your NextFrame: method to be called AFTER the particle system's update: method, because the particle system schedules its own update method with a priority of 1.
This is not good because the position of the quads for the particles are updated using the current position of the emitter, and then the emitter is moved in your NextFrame: method, which causes all the particles to be moved again because the position of the emitter is really the position of the CCNode that draws the particles.
By using scheduleUpdate, you really schedule your update: method with a priority of 0, which means it will be called before the particle system's update: method and all will be well.
So basically, add an update method to your class and call scheduleUpdate instead of manually scheduling it.
Related
I am currently working on a new RPG game using Pygame (my aim here is really to learn how to use object oriented programming). I started a few days ago and developed a movement system where the player clicks a location and the character sprite goes to that location and stops when it get's there by checking if the sprite 'collides' with the mouse position.
I quickly found however that this greatly limited the world size (to the app window size).
I started having a look into making a movement system where the background would move with respect to the player, hence providing the illusion of movement.
I managed to achieve this by creating a variable keeping track of my background map position. The map is much bigger than the app window. And each time I want my player to move I offset the background by the speed of the player in the opposite direction.
My next problem now is that I can't get my character to stop moving... because the character sprite never actually reaches the last position clicked by the mouse, since it is the background that is moving, not the character sprite.
I was thinking of spending some time coding in a variable that would keep track of how many displacements it would take the character sprite to reach the mouse clicked position if it was to move. Since the background moves at the character sprite's speed it would take as many displacement of the background in the x and y directions to center the clicked position on the background to the character sprite at the center of the screen.
It would be something like that:
If MOUSEBUTTON clicked:
NM = set number of moves needed to reach the clicked position based on character sprite distance to click and character sprite speed.
If NM != 0:
Move background image
Else:
pass
This would mean that when my background has moved enough for the character sprite to now be just over the area of the background that was originally clicked by the player, the movement would stop since NM == 0.
I guess that my question is: Does that sound like a good idea or will it be a nightmare to handle the movement of other sprites and collisions ? And are there better tools in Pygame to achieve this movement system ?
I could also maybe use a clock and work out how many seconds the movements would take.
I guess that ultimately the whole challenge is dealing with a fixed reference point and make everything move around it, both with respect to this fixed reference, but also to their own. e.g. If two other sprites move toward one another, and the character of the player also "moves" then the movement of the other two sprites will have to depend both on the position of the other sprite and also on the offset of the background caused by the movement of the player's character.
An interesting topic which has been frying my brain for a few nights !
Thank you for your suggestions !
You actually asking for an opinion on game design. The way I look at it, nothing is impossible so go ahead and try your coding. Also it would be wise to look around at similar projects scattered around the net. You may be able to pick up a lot of tips without re inventing the wheel. Here is a good place to start.
scrolling mini map
I am currently working on a simple CAD-like drawing program using Qt and openGL.
What I am doing is that I maintain a list of objects which is on the canvas. The paintGL() function is just loop through the list and render the objects one by one.
objects are fed to the list via slot drawObject(Object obj), in which there is an update() function to schedule an update event to update the scene.
Now, I want to do some rubberband drawing of lines:
After pick one endpoint of the line, whenever I move the cursor, a mouseMoveEvent() is triggered and it will generate an object for the line and emit a signal to drawObject(Object) slot. what the slot does is to erase the old line by doing xor drawing, and draw the new line in xor mode as well.
What I expect to happen is that every time the mouse is Moved, a new object is rendered to the scene. However, it is not. For example, if I move the mouse
fast, then before the update() function actually update the scene, multiple mouseMove events has been triggered and it seems that these events are never been handled, i.e., the correspondence objects never goes to screen. What the program actually does is that a lot of random artifacts is left on the screen after a fast rubberband dragging.
It seems that this is due to the fact that what update() function of QOpenGLWidget does is that it generate an event to inform the widget to redraw later for performance purpose.
During the course of me writing this question, I discovered the repaint() function which do an immediate update. However, the lagging is quite significant: when I move the mouse fast, the rubberband line is not following.
So, my question is, how to implement the rubberband drawing so that it could take advantage of the update() machanism to boost the performance while not having those glitches on the screen?
I have searching around on this but I could find a single article talking about this fast-moving mouse stuff.
Thank you in advance!
I am working on a window which displays a number of objects (a graph) (C++/Win32API). This is in GDI+ and I have written a test piece of code with Direct2d as I want to improve the performance when dragging objects in the window. The best approach I have found (to date) is the following (using a graph of 1000 nodes and 999 edges).
(bascially buffer static content to a bitmap buffer and only draw whats moving)
When dragging starts (e.g lbuttondown state), create a base rendertarget with the full graph excluding the node being dragged and the attached edges, call GetBitmap and store for later use. When I need to draw (due to mousemove event and lbuttondown state true), then clear the current hwndrendertarget (background wash white), then draw the edges that are connected to the node being moved into the hwndrendertarget, then copy the save bitmap to the hwndrendertarget, then copy the node bitmap (created when the node is first created in the DB, saves actually drawing it) being moved to the hwndrendertarget, then call EndDraw.
Now this works ok (ish), what I don't like it that, when the node is dragged quickly the mouse cursor moves ahead of the node being dragged (distance depending on speed of drag/mousemove bu worst case up to about 1/2 inch). My reference app is MS Visio, dragging a single object on this shows the cursor staying in the same position over the object being dragged maybe +/- 1/2 pixels.
What I have not tried yet is moving all the (and only) the drawing operations to a separate thread, but before I try this I would like to research other methods if other single threaded approaches would trump this way.
Update:
I have optimized this a bit more with improvement, I found I was allocating and de-allocating the edge brush in the draw function which I have moved out to a class wide object and initialize for the life of the class as with other brushes etc. The cursor now only gets a little way (2 pixels or so) outside of the object being dragged when being dragged quickly, the object is a 15px radius circle. so the cursor is able to move up to 17px away from the middle of the object (the point the cursor should stick to) when being dragged. In testing I found an interesting thing, on my main monitor the drag is worse in that the cursor can get ahead of the object being dragged by more than 17px, say up to maybe 25px from the center point of the object where the cursor should be fixed. On the second monitor for the extended desktop (i.e. no taskbar) the drag is better in that described previously. If I hide the taskbar on the main monitor and run the app on that monitor and drag, the performance is the same as the second monitor.
I am doing a simulation using MFC application (its a robot moving in a field) what happens is that the process behind calculates the position to quick where as drawing takes time so what I see ultimately is the robot at the end position no intermediate positions . But when I put AFXMessageBox then I can see all the position its been going through , Can you help me figure this out
Hina, What you need to do is move the complex calculation that calculates the position of the robot to a thread and keep the drawing of robot in your main thread. Then you need to communicate your current positions to the main thread and after the drawing invalidate your surface. This way you can see the positions updated frequently.
What happens when you display a message box is you are able to repaint the surface after the calculation.
You can fasten the drawing my using memory device context. In a nutshell you would do all the drawing on a bitmap in memory which will be fast. When it is all ready, you will print the final drawing on your display. This will be very fast and smooth.
I have designed a small tutorial named "Stacker", As the name suggests, The game involves stacking blocks on each other. I have a large number of blocks to be stacked and hence all cant be accomodated in the screen itself... I m new to cocos2d and box2d but have managed to create a body with its adjoining sprite wen a user clicks on the screen. I have used MouseJoint to give movement to the body till the user performs the drag action that is till the user takes his finger off the screen.
The problem is that i need to follow the sprite (actually need the camera to follow the sprite) when the user drags it above the screen space, i referred the following links with no success... i guess wat i need is to move the body to a virtual coordinates which m not getting coz even if the screen does shift using the camera methods, but the sprite doesnt move with respect to the screen...
cocos2d forum link
flash concept but box2d
Can some1 guide me in case i need to have some pre-requisites before following camera in the manner i specified.. Thanx!
Ok Guys!
Got it guys! Had to take a global variable which records the increments per frame, The increments were equal to the layer movement which i did by setting the position of the layer to a unit less in every frame! Then set the Mouse join to the target which is (ScreenCoordinates + increment) dis too has to be done in every frame!
Done!
Cool method but needed a bit of brainstorming!!