2D Platformer from Qt 5.2 to Qt 5.4
Hi, Habr. This article should have been written in the winter, but for objective reasons I am writing it now.I decided once a year ago to take up GameDev. Late, of course, but the story is not about that. Immediately decided that you need to write for mobile devices. The direction is promising and for me it turned out to be very interesting.
Since I am a C ++ programmer, it means that I need to choose a cross-platform development environment. The choice fell on Qt. Now I will not say exactly why she is, but the choice was made, and the story is not about that.
')
He took out a book in Russian, Carefully read half, made a children's game "Bulls and Cows". There is nothing to talk about, it was a test project.
I read it again, I found out that Qt has very good documentation on its own site and it is easy to find in it a description of the necessary objects. And it can not be happy.
Now there is a question about how to make the project a bit more serious. Everywhere it is advised that beginners first take on something simple, try, so to speak, learn from their mistakes, etc. I have already begun to prepare to write the old and familiar Lines, but here it became necessary for one project to write something on Android. And so the idea was born to write a platformer. And so, strictly speaking, the story is just about that.
It was decided to write in C ++, I wanted to see how adequately it would then work on Android.
And I immediately decided that I would write with the use of the Qt graphic library, because there is quite a lot of good manual for it, as mentioned earlier. I'm not going to describe the process of creating a platformer, this good in the global network is sufficient in different languages.
I started writing this miracle at the end of September on Qt 5.2, I know that I already had 5.3, but I was too lazy to update myself. In early November, everything was ready, but for certain reasons, the event for which the game was written, did not take place and was moved to the spring. Laying out for the world project ahead of time can not be. There was enough time to work on minor modifications and transfer it to Qt 5.4.
Briefly described the implementation process, now, strictly speaking, what problems I encountered during development and the transition from one version to another.
Graphic Library:
Graphic library
Let's start with the jambs.
Native Qt library eats a lot of memory. Used component QImage. When a picture with the size of 780 bytes was loaded into memory, the amount of used memory did not increase by a couple of kilobytes, but by a couple of tens, and sometimes hundreds of kilobytes. This fact did not make me very happy, and sometimes I was annoyed.
In order to somehow reduce the amount of memory used, all graphic elements are placed in one file. But it was also connected with usability. The amount of memory used immediately decreased by 10M.
The second thing that caught my eye, This is how much the processor is loaded. Not 100%, but more than 50%. Maybe this is normal for games, but then it was more interesting.
When Qt 5.4 came out, the software company claimed that they had improved the graphics library.
I confirm that they have improved something :). When transferring to 5.4, the RAM was even less used and the processor was already loaded less than 50%. These parameters looked in Windows, how are things on the android - not in the know.
In the process revealed another interesting fact with the zoom.
The standard screen size for my game is 540x960. He is the only one. When reducing the picture, there were no problems, it even started to work a little more quickly. But with the increase revealed some problems.
First of all, smooth scaling did not work, the drawing process immediately increased 20-30 times. But this can be and refuse, not such a serious project, where you need to pay much attention to the schedule. But for myself, noted that it is necessary to prepare pictures for different screen resolutions.
The second problem was the following. As previously mentioned, all graphic elements were placed in one file. It was necessary to simply indicate the area that is redrawn on the game screen. When the area was increased, for some reason it was captured 1 pixel more than the specified one.
The solution to the problem is that between the elements you need to leave some free space of 1-2 pixels. Or do the elements themselves a little smaller than the area itself. I got the 2nd option.
And the last thing I did not like. This is the inability to work with pictures with a small color gamut (16 and 256). Allegedly, 256 bits are implemented in QIMage, but each bit must be preset.
The rest of the library pleased me. It is convenient to work with it, it supports different image formats, you can save the resulting image to disk. Diverse size of tools
Native Qt library eats a lot of memory. Used component QImage. When a picture with the size of 780 bytes was loaded into memory, the amount of used memory did not increase by a couple of kilobytes, but by a couple of tens, and sometimes hundreds of kilobytes. This fact did not make me very happy, and sometimes I was annoyed.
In order to somehow reduce the amount of memory used, all graphic elements are placed in one file. But it was also connected with usability. The amount of memory used immediately decreased by 10M.
The second thing that caught my eye, This is how much the processor is loaded. Not 100%, but more than 50%. Maybe this is normal for games, but then it was more interesting.
When Qt 5.4 came out, the software company claimed that they had improved the graphics library.
I confirm that they have improved something :). When transferring to 5.4, the RAM was even less used and the processor was already loaded less than 50%. These parameters looked in Windows, how are things on the android - not in the know.
In the process revealed another interesting fact with the zoom.
The standard screen size for my game is 540x960. He is the only one. When reducing the picture, there were no problems, it even started to work a little more quickly. But with the increase revealed some problems.
First of all, smooth scaling did not work, the drawing process immediately increased 20-30 times. But this can be and refuse, not such a serious project, where you need to pay much attention to the schedule. But for myself, noted that it is necessary to prepare pictures for different screen resolutions.
The second problem was the following. As previously mentioned, all graphic elements were placed in one file. It was necessary to simply indicate the area that is redrawn on the game screen. When the area was increased, for some reason it was captured 1 pixel more than the specified one.
The solution to the problem is that between the elements you need to leave some free space of 1-2 pixels. Or do the elements themselves a little smaller than the area itself. I got the 2nd option.
And the last thing I did not like. This is the inability to work with pictures with a small color gamut (16 and 256). Allegedly, 256 bits are implemented in QIMage, but each bit must be preset.
The rest of the library pleased me. It is convenient to work with it, it supports different image formats, you can save the resulting image to disk. Diverse size of tools
Working with sound
Working with sound
The book describes the work with multimedia for version 4.8. But since then everything has changed. And components, and work with them. A little googling and reading documentation led to success. In the end, it turned out not so difficult. I will not describe in detail, for today this information is sufficient on the forums and there is documentation. But if someone is too lazy to understand, write, I will answer.
In fact, what problems encountered. Large WAV files do not tolerate. Large - meaning longer than 3 seconds. MP3-files also do not really complain. Over 5MB failed to connect. I didn’t want to get together when the final size of the media was over 10MB. Maybe this restriction is somehow regulated, but I did not find how. I reduced the audio quality of MP3 files and everything went wrong.
The rest of the sound management components worked with dignity. You can control the volume level, mute sound without stopping the audio. Play music / sounds in the background without stopping the main stream of playback. Only if you launched a sound in a separate stream, will it sound until it ends, and it cannot be stopped forcibly.
I also encountered a problem in 5.2 - the external sound level control buttons did not work. I had to finish the Activity. About how I did it, I wrote an article on Habré. In version 5.4, everything already works, you do not need to finish anything.
In fact, what problems encountered. Large WAV files do not tolerate. Large - meaning longer than 3 seconds. MP3-files also do not really complain. Over 5MB failed to connect. I didn’t want to get together when the final size of the media was over 10MB. Maybe this restriction is somehow regulated, but I did not find how. I reduced the audio quality of MP3 files and everything went wrong.
The rest of the sound management components worked with dignity. You can control the volume level, mute sound without stopping the audio. Play music / sounds in the background without stopping the main stream of playback. Only if you launched a sound in a separate stream, will it sound until it ends, and it cannot be stopped forcibly.
I also encountered a problem in 5.2 - the external sound level control buttons did not work. I had to finish the Activity. About how I did it, I wrote an article on Habré. In version 5.4, everything already works, you do not need to finish anything.
Touchscreen
Touchscreen
Here I have the biggest misunderstanding happened. And the essence is as follows.
In version 5.2, I studied in detail the work with touchscreen events. There is a container that stores the coordinates and the status of all the "fingers" on the screen. There are events that react to the first touch (first “finger”), an event for a change (movement of “fingers” or a change in their number on the screen), and an event that signals the end of a tach (when all the “fingers” are removed from the screen).
In fact, if you use multitouch in your application, you can not even handle mouse events. Everything works fine on the events of Touchscreen. But for certain needs I had to handle mouse events as well. Subsequently, it helped me to understand the problems.
Everything has changed with version 5.4. When I put together a new Qt project and sat down to test the new functionality, what was my surprise when I found out that the control had flown. And the following happened.
For some reason, the developers of Q, changed the logic of the events of the touchscreen and mouse! Now it works like something odd. When you first touch the "finger", MouseButtonPress and TouchBegin events are generated. But then, when the MouseMove event is generated and TouchUpdate is not generated. But the point remains in the container of the wheelbarrow, but its coordinate and state does not change. And when the MouseButtonRelease event is generated , the TouchEnd event is not generated and it turns out that virtually you have one “finger” on the screen.
This problem is solved as follows: at the TouchBegin event , copy the status container to your own, and at MouseButtonRelease, clear it until the next TouchBegin .
After the second “finger” appears on the screen, the generation of mouse events is turned off. And after that, no matter how many fingers you put on the screen or no matter how many fingers are left, TouchUpdate events are always generated. When all the fingers are removed from the screen, a TouchEnd event is generated , and the MouseButtonRelease is not. Problems can be avoided by responding to the TouchEnd event as well as to the MouseButtonRelease . But the fact is that the next generation of the TouchBegin event, MouseButtonPress is not generated and you will continue to work with touchscreen events. This is where the biggest problem lies.
MouseButtonPress will not be generated until there is a MouseButtonRelease event. If the MouseButtonRelease is artificially called, it will still fail. It is necessary to put on the screen and remove only one “finger”, after that the MouseButtonRelease will be generated systematically .
This problem was solved as follows. Together with TouchBegin, it artificially raised the MouseButtonPress event. In the function of processing this event, we first checked the state of the global variable, if it is false , then it was assigned true and the function code was executed, if it means true , we just processed this event and just exit the function. When TouchEnd or MouseButtonRelease, this variable was set to false .
If in 5.4 nothing had changed in the work of the touchscreen, then this part of the text could not be here. And so I was very unhappy. Once in the "five-year plan," the bug pops up in the touchscreen, but I cannot reproduce it and, as a result, understand why it occurs. As soon as this happens, I will definitely write off here.
In version 5.2, I studied in detail the work with touchscreen events. There is a container that stores the coordinates and the status of all the "fingers" on the screen. There are events that react to the first touch (first “finger”), an event for a change (movement of “fingers” or a change in their number on the screen), and an event that signals the end of a tach (when all the “fingers” are removed from the screen).
In fact, if you use multitouch in your application, you can not even handle mouse events. Everything works fine on the events of Touchscreen. But for certain needs I had to handle mouse events as well. Subsequently, it helped me to understand the problems.
Everything has changed with version 5.4. When I put together a new Qt project and sat down to test the new functionality, what was my surprise when I found out that the control had flown. And the following happened.
For some reason, the developers of Q, changed the logic of the events of the touchscreen and mouse! Now it works like something odd. When you first touch the "finger", MouseButtonPress and TouchBegin events are generated. But then, when the MouseMove event is generated and TouchUpdate is not generated. But the point remains in the container of the wheelbarrow, but its coordinate and state does not change. And when the MouseButtonRelease event is generated , the TouchEnd event is not generated and it turns out that virtually you have one “finger” on the screen.
This problem is solved as follows: at the TouchBegin event , copy the status container to your own, and at MouseButtonRelease, clear it until the next TouchBegin .
After the second “finger” appears on the screen, the generation of mouse events is turned off. And after that, no matter how many fingers you put on the screen or no matter how many fingers are left, TouchUpdate events are always generated. When all the fingers are removed from the screen, a TouchEnd event is generated , and the MouseButtonRelease is not. Problems can be avoided by responding to the TouchEnd event as well as to the MouseButtonRelease . But the fact is that the next generation of the TouchBegin event, MouseButtonPress is not generated and you will continue to work with touchscreen events. This is where the biggest problem lies.
MouseButtonPress will not be generated until there is a MouseButtonRelease event. If the MouseButtonRelease is artificially called, it will still fail. It is necessary to put on the screen and remove only one “finger”, after that the MouseButtonRelease will be generated systematically .
This problem was solved as follows. Together with TouchBegin, it artificially raised the MouseButtonPress event. In the function of processing this event, we first checked the state of the global variable, if it is false , then it was assigned true and the function code was executed, if it means true , we just processed this event and just exit the function. When TouchEnd or MouseButtonRelease, this variable was set to false .
If in 5.4 nothing had changed in the work of the touchscreen, then this part of the text could not be here. And so I was very unhappy. Once in the "five-year plan," the bug pops up in the touchscreen, but I cannot reproduce it and, as a result, understand why it occurs. As soon as this happens, I will definitely write off here.
What else
I also added a translation into English, but there were no problems there, and there is enough information on the internationalization of applications in Qt.
Results
The game was written and successfully launched in the project. She fulfilled her initial missions - I gain experience in game devs and become one of the tasks in the city quest. Now she will fulfill her secondary mission - to be part of my portfolio.
Thank you for reading this.
Source: https://habr.com/ru/post/256879/
All Articles