The topic of a new stable release came up in the C++11 topic Moving to C++11
For core devs: please list here all the pending work you’d like to complete before it.
JSandusky has some upcoming PR work that would include large changes (RakNet, compute support) so it’d be better to get this release out before merging those.
For me: I’d like to complete the pending library updates (Assimp, libcpuid), nothing else at least at this point.
Would it be possible to have refactor-buildsystem merged in the main branch for the 1.7 release? I think the Android build-system improvements addressing these issues: https://github.com/urho3d/Urho3D/issues/1441 are working quite well.
Just a note: though my list is exceedingly small and practically completable within days, I don’t mean that the release would need to be imminent, at all, but that we start moving toward it.
I think this is mandatory per-condition of moving to C++11, according to
@weitjong Do you think refactor-buildsystem could make it in this time in some kind of timeframe? Or if it’s too much work total still, maybe a cherry-pick of the Android toolchain changes + CI changes (and anything else which is nice to have and doesn’t wreak havoc)
The commits that could be cherry-picked have already been picked in the last release. What left there have dependency on each other and should go in together. So, the question is, how much time it needs to get “completed”? That depends on how we define the complete. I have a few things in mind actually but have no time/commitment to carry them out. The good news is, that branch is always in compilable state. So, I could also say I don’t have any more plan and the branch is merge-ready after I have done a simple rebase tonight.
We should probably fix the keyboard problem on the RPI platform before making a new release.
Regarding the branch, that sounds good. I’ll let you be the final judge, but I’d vouch for merging it then.
I also hope to solve the constraint2D load/save issue.
One thing to note though. The new Android toolchain has Android NDK r12b as the minimum requirement and it uses Clang compiler toolchain by default. But I think we have waited long enough. It is not a bleeding edge version anymore.
Sounds reasonable. With NDKs, the worse problem is a new version appearing (while download of old is well hidden) and our build no longer working 
Can give a test-spin of a Windows/Android compile of the branch, hopefully tonight.
Current status for me on Windows: merging the buildsystem branch, installing NDK13b and running cmake_android resulted in the NDK’s Clang erroring on not finding various C++ headers, while it was building the Urho PCH.
In file included from D:/Lasse/Programs/urho3d-clean2/Source/Urho3D/Precompiled.
h:28:
In file included from D:/Lasse/Programs/urho3d-clean2/Source/Urho3D/Container/Ha
shMap.h:25:
In file included from D:/Lasse/Programs/urho3d-clean2/Source/Urho3D/Container/…
/Container/HashBase.h:32:
D:/Lasse/Programs/urho3d-clean2/Source/Urho3D/Container/…/Container/Hash.h:25:1
0: fatal error: ‘cstddef’ file not found
I have not tested it on a Windows host yet. I will try upgrade to 13b in one of the Linux VM to see if the error can be reproduced there. And if so, then it is caused by newer NDK, which I believe has dropped GCC compiler toolchain all together. Our CMake/Android toolchain file still relies on the legacy GCC bits to be around, although it uses Clang already. Will check later tonight and report back.
I had problem also with NDK 13b on Linux host system, although my build error was at an earlier stage. The problem was caused by NDK 13b changing the internal structure slightly for LLVM libC++ STL runtime. I will check in my tweak shortly. It builds fine afterwards on both NDK 12b and 13b. I didn’t test on Windows host though.
Thanks! Will be sure to re-check then.
The keyboard input problem on the RPI platform is now fixed in master branch. It was SDL bug all along.
I want to finish work on my PR before 1.7
I’m going to close this PR when I ensure that dynamic resource path changing works correctly.
https://github.com/urho3d/Urho3D/pull/1832
If there are no objections, by end of today or may be tomorrow the “refactoring-buildystem” will be merged into master branch.
Great! I compiled the refactor branch now successfully on Windows / Android after installing NDK14. On NDK13b I got the earlier discussed va_args error from Clang while compiling. But since the newest works, I have no objections.
Sorry for offtopic question but will latest NDK14 work on Android-4.0 ICS?
Ok… It’s been a while. IK is in, RaycastVehicle is in. The Nuklear PR is still ongoing and will take some weeks, but don’t think we have to wait for that, as it’s kind of outside the “norm” for Urho features anyway, ie. no script support, and not completely flexible regarding resources.
There is the Retina Sierra fullscreen issue ( https://github.com/urho3d/Urho3D/issues/1917 ) which is kind of a bummer, but I don’t foresee at least myself having time to properly investigate it until mid-summer. There’s also a smaller Retina UI bug which makes UI textures bleed from the adjacent shapes, since the UI spritesheet does not have padding, but that’s easily fixable either by adjusting the trouble shape UV’s, or switching to nearest filtering.
So, might as well move on with the release by starting to compile the changelog. Any objections?
I’d like to push few minor things today. No objections.
Also, just FYI - I was starting to create the PR for webGL compatible PBR. However, from what I can tell, the changes I made are actually already in the shader source. So, although I haven’t tested, I am pretty sure that webGL PBR should work with no further changes. (I generally work from a forked repo, so I’m not always up to date with the master branch).
I will try to verify this claim today.
Some notes:
Cool, make a PR if necessary, if there are minor shader changes needed they should be quick to verify.
I’d like to get some of the bugfixes I’ve made for IK support into master for 1.7 (there’s stack corruption being caused by the angelscript bindings [fixed], a segfault occurs when cutting and pasting a node with effectors in the editor [not fixed], a segfault occurs when changing the algorithm [fixed]).
I’ll work on getting a PR together for this.
Awesome. Just as I’m wrapping up with multi-channel audio and compute/API-hell.
Thanks, that sounds good to get in. Each platform manual tests & compiling the changelog will take some time (over the weekend, likely) in any case.
Hope to spend some time tonight to provide “glue” JS for the MODULE lib type so that the web samples with our default HTML shell run out of the box.
Are you going to investigate the bug that @Enhex discovered before the 1.7 release?
It was my fault, the reason was using too much GPU RAM.
I have more GPU RAM than the users that had the freezes so I couldn’t reproduce it, and couldn’t see it in the profiling tools because they don’t include GPU stuff.
Can anyone else confirming this bug: https://github.com/urho3d/Urho3D/issues/1860? It is super annoying as it wasn’t happening before. When the window opens if I press with the mouse I cannot get any events, If I loose focus and click on something else and then again on the Urho3D window I am getting events.
I encountered a blocker (a bug from Emscripten) and will submit a PR to fix the bug first. In other words, don’t wait for me for the release.
EDIT: after going through their change history, I now think the current Emscripten behavior is as per their design on how the main/side module should work. Thus, the problem is on our side.
I switched machine to another Sierra Mac in the meanwhile, I think I’ve seen the cursor staying visible for some time in the beginning, but not missed events. Will still retest before release. Is your application using visible cursor, or a locked invisible cursor (like NinjaSnowWar)?
I have mouse visible to true. I also have touch emulation enabled.
GetSubsystem<Input>()->SetMouseVisible(true);
GetSubsystem<Input>()->SetTouchEmulation(true);
These are the events I am using:
E_TOUCHMOVE, E_TOUCHBEGIN, E_TOUCHEND.
I only happens in window mode these are my settings:
engineParameters_["FullScreen"] = false; engineParameters_["WindowWidth"] = 1200/2; engineParameters_["WindowHeight"] = 1920/2;
@TheComet how is it going with the IK fixes, any ETA? I still need to compile the changelog and I’ve had minimal free time lately, so no absolute hurry.
It’s about 40% done. I’ve been super busy with exam hell lately, sorry it’s taking this long. I think I should be able to get it to you by next Weekend if that’s alright.
No problem, that sounds good.
I have solved my blocker issue. The web samples with MODULE lib type for Web platform now built and run out of the box on my test environment. Still not super happy about it because I have to disable the dead-code-elimination on the main module in order to preserve the “exported symbols”. Tomorrow will try to re-enable the DCE on the main module and passing the exported functions (with mangle names) explicitly to Emscripten, if it is even possible.
The EXPORTED_FUNCTIONS setting from Emscripten does not work with C++ mangled symbol names. Similarly, the EMSCRIPTEN_KEEPALIVE attribute only works for C functions and not for C++ type. If only we could tell Emscripten to automatically keep all the symbols that we have tagged with URHO3D_API attribute, that would solve the problem. Unfortunately for that, we have to go deeper into Emscripten itself. Perhaps another time then. I have just merged the feature branch into master and call it a day.
I want to investigate this one a bit before 1.7
Please note also issue #1960, for which I submitted a pull request.
I think I am done with AppleTV port, didn’t think I could make it in time for 1.7 release previously. Just need a confirmation or two whether the feature branch is worthy to be merged into master.
Don’t have the HW to test, though I can of course build on Mac just to see the branch runs OK for me on both Mac + iOS.
The physics 2D issues and other recent issues that can be easily solved are of course good to check, while waiting for the IK fixes.
Then it could be at last time
I would not expect any regression issue with iOS in the new branch, but no harm to double check that. In fact the tvOS platform is so similar to iOS platform, I am also almost certain that Urho3D game engine will render correctly on the actual device. It is the input subsystem that I have my doubt to get it right at first try.
Probably I should have created another thread for discussion about the MODULE lib type for Web platform. Anyway, I just want to update that I have some success today to build a working main module with DCE enabled, which tremendously reduce the size of the main module and the time to build it. However, the process requires manual exporting of the mangled symbol names and feed them to the Emscripten’s EXPORTED_FUNCTIONS setting during linking phase (finally I figure out how to pass that setting correctly via CMake to Emscripten). Perhaps it is time to revisit our Clang tool branch to auto-prepare the exported symbols list (easier to do); or as I commented before, hack into Fastcomp to auto-preserve URHO3D_API (harder to pull off).
EDIT: It is actually easier than I originally thought to hack into Fastcomp to auto-preserve the symbols with URHO3D_API attribute, however, by automatically including all the Urho exported public API symbols then the main module size increases back in size
Main module size:
In short, it does not worth it. So, the best way to do this is to disable the DCE; OR manually extract the required symbols for each individual project but with DCE enabled, which is unfortunate, cause I am not able to add that kind of logic in our build system for the latter. BTW, for those who still doesn’t get it why we need a new lib type. The use case of MODULE lib type is to link the main module to asm.js only once which takes relatively a long time, so that the side module (which contains only the application-specific code) can be linked to asm.js in a short time. Good for fast iteration during development.
Verified the AppleTV branch successful run on OSX / iOS.
8 posts were split to a new topic: New codestyle for C++ 11
IK work / fixes / docs are in, and I have nothing more on my list of waiting things, so I could go ahead and start compiling the final changelog.
Initial changelog is in. Feel free to amend where necessary.
You let go of shift too soon 
I am bit late to the party but maybe 3D UI would make it to release too? It is pretty much complete as far as i can tell, except for that OpenGL issue. If OpenGL fix isnt easy one then it can be left out. I really do not mind one way or the other.
Better to leave post release now, since the release was only waiting for IK fixes and a few smaller fixes, and there’s a bit of risk involved in UI / UIElement modifications.
news on russian site https://www.opennet.ru/opennews/art.shtml?num=47054
p.s. what about news on https://urho3d.github.io/latest-news.html ?
Site update and announcement is going online just now, it was just that the tag / builds came first.
Awesome! Congrats guys for the 1.7 release!