Windows 7, GTX 660, i5 3570: 62 fps
Seems were all stuck on it!
1 Like
Macbook Air 2013
OSX 10.11.6
cpu: 1.7Ghz i7
integrated gfx: Intel HD 5000
ram: 8GB RAM
FPS: 20-22
Alright this is interesting, initially I experienced graphical errors, like shown in the image below, no labels and a lot of black artifacts, this happened twice. I tried running it a third time and now it looks normal. I also experienced a crash on launch at one point.
http://pastebin.com/cJZnYKw6
Oh and yes the package is corrupted if extracted with the standard unpacking tool, use KEKA instead.
1 Like
Just to note, it’s (currently) locked to 62fps max. 
2 Likes
Unfortunately for me it’s been blurry. Is this expected, or is it rendering wrong?
I have a Surface Pro 4, which has a pretty high resolution.
Hm, maybe the depth of field is acting weird, or Krom/Windows is somehow upscaling the output (the window should be quite small - 1280:720 vs 2736x1824 total on SP4). Getting back to this as soon as the new builds are out.
Updated binaries with disabled sound, should fix some of the crashes especially on startup. Project sources are also out. More fixes soon.
GTX 1060
i5 6500
Windows 10
Runs at 62 FPS too, but is it normal that when you toggel your flahlight often, the room lights go off and after some times you teleport to a 360 degree image of a museum or something like that where your Battery HUD turns off?
Testing new builds!
- Runs on upcoming Armory Build 9
- Slightly faster load times due to improved material building
- Enabled light attenuation, creates a better sense of depth but has a bit darker vibe
-
Runs 20-40% faster. Creating the benchmark scene paid off and the first round of speed-ups is there. Each part of the renderer has been shaved down to perform better. I tested on a Mac with Intel HD5100 - went from 20-22fps to 27-30fps.
@Simonrazer: It’s not normal, but should be fixed now.
1 Like
Nice improvements! I ran the newest benchmark just now and got between 28-32 fps. Initially it ran 31-32 but the more I moved around and went back and forth, it started to fluctuate between 28-30.
Macbook Air 2013
OSX 10.11.6
cpu: 1.7Ghz i7
integrated gfx: Intel HD 5000
ram: 8GB RAM
1 Like
No problems under Linux: Solus 2017.01.01.0 64-bit NVidia GTX 1060 - Everything looks ok and keeping the 62 fps limit.
Under macOS 10.12 I have a problem running the app. I’m having the famous error: “App is damaged and can’t be opened. You should move it to the Trash."
I know that this was solved on previous system versions changing the security option to allow running software from anywhere. But this options seems to be gone in macOS 10.12. The problem here is that the app is not working just right clicking on it + open (like I do with other unsigned apps). To solve this problem under 10.12, I see some solutions that require the terminal to change permissions to the file or disabling main security options through terminal. This is something I don’t have a problem doing, but I think armory builds should, at least, build to the point that just right clicking + open should work (if not signed, of course).
I will try to investigate what makes this difference; how macOS says the app is damaged instead of just complaining about security things and forcing the right click + open workaround as usual. Maybe some problems with the bundle structure or Info.plist?
Edited: uhm… maybe a signature is needed for the right click + open to work. So the last option is to execute this on the terminal:
sudo spctl --master-disable
You will need to
sudo spctl --master-enable
to revert this action.
This does the same than selecting to run apps downloaded form anywhere.
Edited 2:
With all this I forgot to mention that after this, the first execution crashed, and the next ones worked. With my Intel HD Graphics 6000 we are around 30-32 fps. Trying to replicate the crash to get log message without success now (every time is working now…).
1 Like
Having to fiddle with terminal is of course unacceptable. We could try signing the Krom binary in Armory SDK - however I am not sure if you can stuff additional files into the .app folder (that is all Krom needs) once it is signed without breaking anything and what is the legal side of it. Maybe it just won’t do without signing anymore. In that case Armory would generate XCode project for builds to be distributed, user configures required signing and builds (same like using the native/c++ target right now).
There is one report on the first-run crash. What I gathered so far - it always happens only once, it is MacOS only, and it seems to crash because paths are somewhat modified (just a guess) and Krom is unable to load files. Curiously, it starts up the second time.
Happy to see the fps boost!
…I’m still getting 62fps…
No issue whatsoever as before.
Yes @lubos , you are right. If when signing any hash/checksum with the bundle size is created you wont be able to inject the content after signing. I tried to look if there was a way to partially sign or use other mechanism… and seems something was allowed in the past, but not anymore.
Extract from https://developer.apple.com/library/content/technotes/tn2206/_index.html#//apple_ref/doc/uid/DTS40007919-CH1-TNTAG401
I store data in or otherwise modify my bundle after I sign it.
- This is no longer allowed. You will need to locate this data elsewhere.
- It won’t work to write the data before your app runs for the first time. Gatekeeper will reject your app because the signature will be invalid.
- It also won’t work to write that data after your app first runs. That still breaks the signature. Gatekeeper will check your app again if your app is copied to another computer such that the new copy is quarantined. And on macOS Sierra and later, Gatekeeper will check your app every time it’s launched if it is run from the location where it was downloaded.
- macOS APIs that rely on a valid identity will fail.
- In general, you should plan for future stricter runtime checks of code validity.
Maybe doing the same than armory is doing on the other platforms? In linux and windows the content is distributed alongside the run.exe and _run.sh. So, in macOS, the Krom binary could be unique/signed and provided alongside the resources. Armory.app will need to look for the content outside the bundle, alongside the signed Armory.app. Maybe this adds other complications or is also not possible.
And of course, leave the need to construct the signed bundle with resources inside only when generating xcode projects targeting native/c++.
It looks like MacOS 10.12 introduced a feature which makes that harder too - App Translocation. Basically there is a chance .app folder gets mounted onto randomized location at startup, preventing to easily locate files distributed with it.
Edit: Can probably integrate something similar:
is any update on window size?
I added a browser version at:
http://armory3d.org/demo/bench1/
@nictaylr: Is it the same in the browser? I am starting to think that Depth of Field effect is just too strong, disabling it completely may do the trick. 
3 Likes
Only ~9 MB, very nice! I may be busy with my thesis but I’m keeping a very close eye around here hehe 
1 Like
Browser version works well here, is my impression or it’s faster than Krom Version?
Happy to hear! Should be possible to get it down to 7 MB soon - using bullet/ammo physics module through webassembly saves some space + Armory now optionally computes tangents on the gpu, can shave down model data sizes a bit.
@AndreaMonzini Yes, it’s indeed faster but the reason is reduced resolution. For the Krom version I did not want to go below 1280x720, while the browser version is at 960x500 if I recall.
Otherwise the browser penalty seems to be up to 25% slower. We might get rid of that penalty though - new graphic APIs are starting to appear in browsers.
1 Like
The Browser freezes unfortunatly when it finished downloading, but the offline version works at 30fps on a gt620m. The use of the integrated graphics of the i3 2328M result in a white screen (i waited 10min). 6gb drr3, gt 620m, i3 2328m, win 8.1