Development of OpenGL games for the Android platform
Some time ago I finished porting an iDracula game - Undead Awakening, which Moregames Entertainment developed from the iPhone platform to the Android platform.
I am ready to share with you my thoughts and problems that I have encountered.
I want to warn you that I have worked much more with the Android platform (based on the specifics of the task :), but I also have experience in developing more “smaller” games for the iPhone platform. I also developed iPhone games on cpp, not ObjectC.
')
Difficult topic, given the difference between languages ​​and operating systems. Therefore, short and IMHO.
xCode unfortunately in my opinion it is difficult to call a modern IDE, especially when you have to work a lot and refactor someone else's code. In this regard, the advantage of IntelliJ IDEA, or Eclipse (a plug-in for developing for Android is under both IDEs) is felt very strongly. In some cases it was easier for me to transfer the code as is, and then to do a certain code refactoring already in the java version. Debugging under xCode also requires much more skill and knowledge of certain specifics. The disadvantages of the Android platform tools include some instability of plug-ins (especially eclipse) - they periodically forget adb.exe in memory, which makes profiling impossible via DDMS. It is necessary to follow a clear order, first run ddms, then debug. The essential disadvantage is also the heavy weight of the emulator - it starts a long time, it works slowly. At 35 fps on the device, I have 15 fsd on the emulator on my MacBook Pro, and even less in debug mode, which makes it impossible to fully test many things. The simulator for the iPhone starts almost instantly, and is not inferior in speed to the device.
The only problem I encountered when developing for an iphone is the lack of ogg support. The problem was solved by simply porting the corresponding library.
Unfortunately, the Android SDK is not so simple.
The most serious problem is memory leakage when using the OpenGL functions glXXXPointer. In fact, for every function call we have a memory leak of dimensions into the array that we set. Those. what not to do when using these functions, we will sooner or later receive a call to gc, and this is from 200 to 1500 ms lag. Here are the details. Also, the cost of calling functions glXXXPointer is much higher, which, incidentally, is expected.
The high cost of touchscreen processing - i.e. Stupidly you have 50 fps, put your finger on the screen you have 30 fps. For MotionEvent breeds and load the system. The decision to do sleep after receiving MotionEvent solves the problem is not complete.
Lack of multitouch support. And at the SDK level, i.e. even if you have a firmware that supports multitouch, or HTC Hero, which also has multitouch support - you currently cannot use it in your application.
Unfortunately at the moment we have quite different devices. The main problems associated with the HTC Dream (G1). G1 has a much worse trackball sensitivity than Magic and Hero. Where the player will be comfortable playing using the Magic Trackball on the player, he may have problems on the Dream.
There are problems and data acquisition from position sensors with music turned on. If you play a music track with a volume of 0.5 of the maximum, then even in a stationary state you will receive bounce sensors from -40 to +40 from the possible range from -90 to +90 (-180 / + 180). In fact, with this bounce, it is not possible to use position sensors to control the game. Only when the volume is reduced to 0.2 of the maximum bounce decreases to the range of -4 / + 4, which is already acceptable.
On G1, there are also problems with a small amount of memory, they are aggravated by the fact that widgets that the user places on his desktop can consume memory (up to 15 megabytes), but it’s not obvious to the user that they are running programs. Therefore, you can receive different reviews from users with the same devices. From "wow the game flies" to "it is impossible to play, only lags" (see the paragraph above about memorials).
Problems with G1 with a small amount of space for installing programs, on average on a zero system, the user has about 30 megabytes. After installing applications less. If the application is large (the full version of iDracula is 13 megabytes), then there may be problems with the installation. I will write below in more detail.
Unfortunately, the Android Market in all respects loses the AppStore.
Currently, there is no possibility on the market to indicate the devices for which your application is developed.
Those. if your application needs a hardware keyboard, or multitouch (when it is entered), then the application will be visible to device owners without these options and you will receive a negative rating from them.
Problems installing large apps. After about five years on all cell phones, after installing the application, the user, after downloading the application if there is not enough space to install, in addition to the warning, receives a dialog with the ability to remove current applications and fight to continue the installation. On android, he is forced to call a variety of menus for this action. Moreover, if your application is 10 megabytes, then to install it requires a minimum of 20 megabytes (the downloaded file, and installation space).
One solution is to install the application without resources, and download the resources by the application itself, saving them to the USB flash drive.
I would like to see this as the standard feature of the SDK - the ability to mark part of the files for placement on a flash drive.
It also lacks the ability to get information about the device on which the user leaves a review in addition to a review (for example, about the crash of the application), and ideally the log of the application as done in the iphone.
There is not enough section Entertaiment - games are forced to compete in tops with applications like "Beautiful fire on your screen."
Well, the lack of screenshots leads to the fact that the game is largely chosen based on the name (as no one reads descriptions), such a problem was, by the way, in the BREW market. Plus there is a limit on the size of the description.
If to summarize, you need to develop applications up to 3 megabytes in size, using, preferably, no more than 15 megabytes of memory and making a reserve for the brakes when working with touchscreen.
Initially, there was a desire to write a more structured review and spend more time on the iphone, but I feel that this way the article would have lain in drafts for another month. I hope the folded will be useful in this form. I am ready to answer questions in the comments.
PS If you have a ready-made game for iphone or another mobile platform and you want its port for Android with the condition of shared revenu or a fixed payment, then I will be happy to talk with you. :) For example on Skype - youngskipper. Ready to talk with other developers as well - discuss the platform.
I am ready to share with you my thoughts and problems that I have encountered.
I want to warn you that I have worked much more with the Android platform (based on the specifics of the task :), but I also have experience in developing more “smaller” games for the iPhone platform. I also developed iPhone games on cpp, not ObjectC.
')
Environment and development tools
Difficult topic, given the difference between languages ​​and operating systems. Therefore, short and IMHO.
xCode unfortunately in my opinion it is difficult to call a modern IDE, especially when you have to work a lot and refactor someone else's code. In this regard, the advantage of IntelliJ IDEA, or Eclipse (a plug-in for developing for Android is under both IDEs) is felt very strongly. In some cases it was easier for me to transfer the code as is, and then to do a certain code refactoring already in the java version. Debugging under xCode also requires much more skill and knowledge of certain specifics. The disadvantages of the Android platform tools include some instability of plug-ins (especially eclipse) - they periodically forget adb.exe in memory, which makes profiling impossible via DDMS. It is necessary to follow a clear order, first run ddms, then debug. The essential disadvantage is also the heavy weight of the emulator - it starts a long time, it works slowly. At 35 fps on the device, I have 15 fsd on the emulator on my MacBook Pro, and even less in debug mode, which makes it impossible to fully test many things. The simulator for the iPhone starts almost instantly, and is not inferior in speed to the device.
Sdk
The only problem I encountered when developing for an iphone is the lack of ogg support. The problem was solved by simply porting the corresponding library.
Unfortunately, the Android SDK is not so simple.
The most serious problem is memory leakage when using the OpenGL functions glXXXPointer. In fact, for every function call we have a memory leak of dimensions into the array that we set. Those. what not to do when using these functions, we will sooner or later receive a call to gc, and this is from 200 to 1500 ms lag. Here are the details. Also, the cost of calling functions glXXXPointer is much higher, which, incidentally, is expected.
The high cost of touchscreen processing - i.e. Stupidly you have 50 fps, put your finger on the screen you have 30 fps. For MotionEvent breeds and load the system. The decision to do sleep after receiving MotionEvent solves the problem is not complete.
Lack of multitouch support. And at the SDK level, i.e. even if you have a firmware that supports multitouch, or HTC Hero, which also has multitouch support - you currently cannot use it in your application.
Devices
Unfortunately at the moment we have quite different devices. The main problems associated with the HTC Dream (G1). G1 has a much worse trackball sensitivity than Magic and Hero. Where the player will be comfortable playing using the Magic Trackball on the player, he may have problems on the Dream.
There are problems and data acquisition from position sensors with music turned on. If you play a music track with a volume of 0.5 of the maximum, then even in a stationary state you will receive bounce sensors from -40 to +40 from the possible range from -90 to +90 (-180 / + 180). In fact, with this bounce, it is not possible to use position sensors to control the game. Only when the volume is reduced to 0.2 of the maximum bounce decreases to the range of -4 / + 4, which is already acceptable.
On G1, there are also problems with a small amount of memory, they are aggravated by the fact that widgets that the user places on his desktop can consume memory (up to 15 megabytes), but it’s not obvious to the user that they are running programs. Therefore, you can receive different reviews from users with the same devices. From "wow the game flies" to "it is impossible to play, only lags" (see the paragraph above about memorials).
Problems with G1 with a small amount of space for installing programs, on average on a zero system, the user has about 30 megabytes. After installing applications less. If the application is large (the full version of iDracula is 13 megabytes), then there may be problems with the installation. I will write below in more detail.
Delivery of content to the user
Unfortunately, the Android Market in all respects loses the AppStore.
Currently, there is no possibility on the market to indicate the devices for which your application is developed.
Those. if your application needs a hardware keyboard, or multitouch (when it is entered), then the application will be visible to device owners without these options and you will receive a negative rating from them.
Problems installing large apps. After about five years on all cell phones, after installing the application, the user, after downloading the application if there is not enough space to install, in addition to the warning, receives a dialog with the ability to remove current applications and fight to continue the installation. On android, he is forced to call a variety of menus for this action. Moreover, if your application is 10 megabytes, then to install it requires a minimum of 20 megabytes (the downloaded file, and installation space).
One solution is to install the application without resources, and download the resources by the application itself, saving them to the USB flash drive.
I would like to see this as the standard feature of the SDK - the ability to mark part of the files for placement on a flash drive.
It also lacks the ability to get information about the device on which the user leaves a review in addition to a review (for example, about the crash of the application), and ideally the log of the application as done in the iphone.
There is not enough section Entertaiment - games are forced to compete in tops with applications like "Beautiful fire on your screen."
Well, the lack of screenshots leads to the fact that the game is largely chosen based on the name (as no one reads descriptions), such a problem was, by the way, in the BREW market. Plus there is a limit on the size of the description.
If to summarize, you need to develop applications up to 3 megabytes in size, using, preferably, no more than 15 megabytes of memory and making a reserve for the brakes when working with touchscreen.
Initially, there was a desire to write a more structured review and spend more time on the iphone, but I feel that this way the article would have lain in drafts for another month. I hope the folded will be useful in this form. I am ready to answer questions in the comments.
PS If you have a ready-made game for iphone or another mobile platform and you want its port for Android with the condition of shared revenu or a fixed payment, then I will be happy to talk with you. :) For example on Skype - youngskipper. Ready to talk with other developers as well - discuss the platform.
Source: https://habr.com/ru/post/67231/
All Articles