Always running in portrait mode, even when screen rotation is locked in landscape mode.
The dmengine.apk will always run in portrait mode since that is how it was bundled. I would recommend that you bundle a debug variant of your own application and use that instead since it will have the correct game.project settings. And if you have native extensions it will include those as well.
Thank you, I know.
If you watch the video carefully, there is no project, just start dmengine. The dmengine didn’t work like that before. Something has changed. I got back, the last well-functioning version is 1.2.150. This version still handles rotation. I’ll also add a video of this.
Note that the bundling time for my near completed project is 18 minutes 25 seconds
That’s quite a lot. how many assets do you have? How big is the .apk?
My guess is that it’s the textures that take the actual time. Do you use texture profiles (for compressing the textures)
What does the build report look like?
As a comparison, one of our commercial games takes just under 5 minutes to bundle, and becomes ~100mb (with texture compression).
Yes, it is really a lot of time. Earlier, it was fast, but the bundling process began to slow down from one version. I don’t remember exactly which version it happened, but last year it was.
The project is not big, the size of the apk is under 15 megabytes. Texture compression is on. I only use the default texture profile with the best webp-lossy compression option.
I’ll send you the report in a message. I started bundling at exactly 07:35:00 GMT.
I’m very sorry for my bad English.
And if you disable texture compression? How fast is the bundling process then?
Without texture compression, the bundling process takes 17 minutes 45 seconds. So the size of the apk is nearly 25 megabytes.
Wow, this is really way too much. Can you generate a build report and share it? Either here or directly to me (email@example.com).
Very strange things happen here. The report shows that texture compression is enabled, although I have turned it off in the editor. However, the size of the apk is larger by 10 megabytes.
I restart the editor and do another measurement without texture compression. I’ll send the existing 2 reports. Thanks!
One thing to note is that although we only put what’s needed in the bundle, bob.jar actually compiles all assets it finds in the project (which ofc is not optimal).
So if you have lots of resources that it finds in there (perhaps you’ve unzipped a lot of assets in your project?)
How large is your entire project folder? How many files are in there? and what is the most common file type?
(The editor only compiles what’s actually needed)
I’ve been testing the bundling process in the last few hours. The 10 megabyte size increase was due to the first time I built it in release mode and the second in debug mode. So this is not relevant, sorry.
As I realized this, I did 2 new tests:
1.) Release mode, texture compression turned off
2.) Release mode, texture compression turned on
The result is that both outputs are the same. The content of the two reports.html differs only at the time of generation. The contents of the assets folder in apk are the same. So, it seems like setting the compression option in the editor does not affect anything.
Only the required files are stored in the project folder. In addition, there is a .internal folder and a .git folder for git. Of course, there are lots of small files in the .git folder. Based on what you say, is it possible for this hidden folder to be processed by bob.jar?
I try to bundle the project without a git!
Unfortunately, without a git, the bundling time is around 18 minutes.
The project folder size is 16.4 megabytes, contains 1096 files and 81 folders.
Would you mind zipping the whole folder (excluding .internal, .git and build) and share that with me as well?
I’ve done some more tests on other platforms (Linux Mint, Mac OS). Each platform has the same result.
Then I tried not to change the texture compression settings, but the texture profile compression settings. And see a miracle, the problem is solved
Some bundling time values for different texture compression settings:
normal, compression_type_default -> 1:18
normal, compression_type_webp_lossy -> 1:28
best, compression_type_default -> 1:08
best, compression_type_webp_lossy -> 17:34
It is clear that each setting will result in an acceptable bundling time, except for one that I use. Probably the last combination requires a larger order of calculation.
Ok, good that you figured it out!
Returning to the original question, can I get a confirmation that this is not a bug? If you watch 2 videos at the beginning of this topic, dmengine 1.2.150 still handles the rotation, but those with a larger version are no longer. Thanks!
I tried dmengine.apk for 1.2.150 and 1.2.156 and 1.2.150 supports dynamic orientation while 1.2.156 does not. This is a regression on our end. I don’t see a reason why we’ve disabled dynamic orientation and I’ll try to make sure that it is enabled again in 1.2.157.