I'm developing a Block Breaker clone using c++ and Qt and I would like to know how to create infinite(or unbounded) animation for the movement of the ball.
Should i stick to the animation framework (by sub-classing QAbstractAnimation), or consider creating and managing new threads for handling animations?
Some experienced guidance would be very helpful, thank you.
So finally I figure it out: using the QPropertyAnimation::setLoopCount(-1) member function makes the animation run forever until stopped with the QPropertyAnimation::stop() signal...
Related
I'm working on an OpenGL project where there are many scenes. I have successfully implemented the functionality of switching scenes at runtime, so the user can change to another scene by choosing a scene name through the ImGui menu. When that happens, the current scene is deleted to clean up dirty OpenGL internal states, then the new scene will be loaded from a factory pattern. Everything works fine, except that the window will freeze for a few seconds during the transition because unloading/loading scenes takes quite a while to finish.
What I want to do now is to create a loading screen, which will be displayed in between. The task of unloading/loading scenes is scheduled asynchronously using std::async and std::future, so that the caller is non-blocking and my loading screen can show up. However, since I'm creating the new scene in background in another thread, that thread cannot see the OpenGL context in the main thread, as a result, any glxxxx() calls would cause access violation so the new scene cannot be created.
I know that OpenGL is a global state machine which does not support multithreading quite well. I've also read somewhere that it is driver-dependent. Most threads on this topic is old, I wonder if it is still difficult to use multithreading in OpenGL as of 2021. From what I see, loading screen and switching scenes are just very basic functionalities, many applications are able to do so, and I believe there're a bunch of them using OpenGL, why is this problem still not commonly addressed today?
Does anyone know of any external libraries in this regard? Or is there another workaround without using multiple threads?
I'm building Conway's game of life in MFC. I built it before using Allegro and want to try it out using MFC. So I start migrating the algorithms and stuff. It renders well using one core and it does the game of life algorithm rather beautiful just like in allegro. Conway's game of life is made up of little rectangle drawn using pDC->rectangle(x1, y1, x2, y2).
My problem is actually two, one of it is that everytime I call the pDC->rectangle(...) it draws it immideately, causing this chain reaction rendering style. I want it to display when it is done doing its job(i know you can do that in directx but I just want to do this using device context of MFC).
The other problem is the title, and probably my main problem. How do you using pDC with concurrency, I tried it and it did some weird stuff. I know I cant use pDC in OnDraw with concurrency because it is the same device context occupying the same memory but used in my 6 core. That's all, thanks in advance.
To avoid drawing immediately, you can draw in abitmap in memory and then blit on the real dc when you finished. Have a look here as a starting point, or at this article on CodeProject. For the multithreading part, you should be able to use the same in memory device Context from multiple threads, just ensure to properly coordinate the creattion of that sharted DC and the blitting/release.
Im in the middle of creating my first iPhone game - I have a background in OOP and in particular C++ so I had some questions with regards to how best to logically setup layers while maintaining functionality.
Currently I WANT for my game to have three main layers:
HUDLayer (All static objects on the screen are here - game controls, User score, pause button etc.)
PlayLayer (The Player, the main game loop and all of the game logic here)
Level Layer (The level images and the level physics objects that the player interacts with, and the background music specific to this level)
Notice I used the word WANT here - because for the life of me im constantly having to move logical objects around just to work within what appears to be Cocos2d's and spacemanagers structure.
Below are just some of the issues that I'm facing
I would like for my PlayLayer to be the scene thats loaded by the director - but if I do that then all of the HUDLayer objects get covered behind the PlayLayer, and dont stay in place like they should, hence the HUDLayer is my scene and I have had to do that just to make it work
I would like to play the background music (via simpleAudioEngine playBackgroundMusic) in the LEVEL layer because I want different levels to have different music. So far the ONLY way I have gotten background music to work is to have it in the TOP most layer i.e. in this case the HUDLayer
Because of the fact that I have to use an instance of the SpaceManagerCocos2d object to create physics bodies - it seems like my level layer has to be killed and just incorporated within my PlayLayer otherwise im having a nightmare of a time attempting to detect collisions between the player and the level.
Am I missing something very obvious here? is there a core understanding of layers that Im just not getting? More and more I feel like im being pushed by the framework to build the whole game inside of a single class and just to use layers as scenes.
Is anyone else having these problems? Am I approaching the architecture of the game wrong? Any help would really be appreciated.
Thanks in advance guys!
Well, each game is different. There are many good discussions on the cocos2d forums about architecture, some people prefer to use an MVC approach, some like using an Actor metaphor to contain physics objects, etc.
Here's my approach:
Use two CCLayer objects (GameLayer and HUDLayer) as child nodes of one CCScene (GameScene). These are the "view" objects.
Create a GameController singleton that can make changes to the game state (also stored in GameController, or in a separate file.) You could also subclass CCScene and call that your controller.
GameLayer is in charge of rendering the graphics of the game level and all actors in it; it also handles getting game input via touch events.
HUDLayer is placed at a higher z-index than the GameLayer and obviously has all of the CCSprite objects for the HUD and buttons.
Interaction between the HUDLayer and the GameLayer is managed via the GameController.
GameController does all of the state changing and game actions.
That's just my approach because it worked for my current game, and it by no means is the definitive answer.
I'd suggest that you look into using an Actor paradigm for your physics objects -- SpaceManager does a decent job, but you don't necessarily always want physics objects to extend CCSprite.
Hi guys
I am new to the cocos2D.In my game i have one scene and several layer to display Menu,pause,level finish,game over. now i want to find out the layer which is being used on top of the scene. i already tried and got the solution to solve it by using boolean variable for every layer. but this is not a good way to use i thought.
please provide some suggestions
Thanks
Riash
You can simply keep a pointer to the active layer. And it is better to have different scenes for every game state because in this case your management will become much simpler. That's because typically your game scene will have more then one layer. For example: background, level objects, controls and so on.
I have a problem about a simple mpi program.This program have some 3D points and these points are moving during the program. I created an simple code by implemented c++ and then I tried to add an simple gui. I used gnuplot library and I have a problem. When I call the gui function the gui is created and it is disappeared at the same time. I mean, point object have x,y,z coordinate and I have an array that includes point objects. I want to create them as gui. Can you help me about this problem?
Thanks for any help..
what about Qt? You could use the Qt Graphics View Framework to simulate the 3D-environment - it even supports coordinate transformation (ok, it was originally designed for 2d scope). It supports OpenGL and maybe you are able to simulate the 3D points by drawing dots and setting their positions using simple cosinus and tangens mathematics.
Don't get afraid of the many functions and classes Qt offers - it's very easy and fast to learn - just check out the simple tutorials and after that you right can start your gui!
...and if you are used to Qt, you'll never want to miss it :)
Could it be that the plot is up correctly but that then your program ends? Ie everything's correct, the window goes up, but the next thing that happens is that the program is done, and the window gets destroyed? Try putting in a couple lines that wait for a keypress right after you throw up the window. Then, the window will stay until you press a key (and then the program will end).