I can’t find _crash file, but I found more info in console:
I sent a build in PM.
Videocards:
1 Like
Unfortunately publisher won’t take our game to publishing with this bug =(
He turned a blind eye for lack of support Win XP, but this bug is a blocker =(
1 Like
Hopefully it can be fixed. But I don’t understand using a publisher for PC… I can give you the most important tip to release on Steam and that is to have your game in coming soon long enough to gather as many wishlists as possible 10k + would be ideal. Once you get enough wishlists Steam will organically begin to help you get more. If you do a decent launch you get put into the popular release list, and this is much easier to do if many people have it on their wishlist as they get e-mail by Steam when it releases.
The casual portals are kind of dead. Mobile ate their lunch. They can still make some money but not like they used to.
3 Likes
Thank’s for your advice, but publisher not for Steam.
After a lot of experiments and downloading dmengines one by one from d.defold.com, I found that dmengine_release works fine on this PC.
Looks like problem only with debug version of the engine.
BmC - old project, and we have freezed it before new appmanifest features was relesed. And project had no appmanifest (unfortenetly we have released few updates to mobile without appmanifest too =(( ). That mean that we use debug version of the engine in all our builds (even with Release checkbox, yes it’s still debug dmengine).
Like result: after adding game_release.appmanifest to the project, it works fine on this old PC.
It still can be issue in future for some developers, but not an issue for me anymore.
P.S.: like a conclusion - Defold needs more convinient way to build release bundle. I already used appmanifest few times in other projects, but even I forgot about it. For guys who new with the engine it will be a problem.
2 Likes
Well, the debug builds make checks that all the OpenGL calls behave correctly. This is disabled in the release builds. We still need to find this issue, since you cannot work on a machine that has this issue (BuIld and run launches the debug build)
And yes, making the workflow easier for the native extensions is also on our roadmap.
3 Likes
Ok, if I can help with it, just give me know. I leave this PC in office for a some time then.
2 Likes
That would be super great! I’m currently building a new exe for you to test 
2 Likes
Why not have appmanifest as a dropdown option on the dialog when bundling? Then include a few of the appmanifest files which have been prepared by you and community in builtins or elsewhere the dialog can access.
1 Like
It’s a good idea. We are closing in on the more UX related aspect of native extensions. Previously, we’ve focused mainly on making it work, and making it reliable (and there are still a few more things to do there as well), but we’re getting to it soon.
5 Likes
I just ran into the same issue. I’m currently sitting at the place where I work, wasting time with a crappy old laptop we have here (Sony VAIO VPCEB1E1E running Windows 7). I’ve decided to kill some time uninstalling old crap to make it run a little faster, which was a success - seems like the only thing I broke is Defold, which used to run “fine”.
As I was getting rid of some of the ballast, I uninstalled the graphics driver which presumably came with the laptop ages ago and after a while found a working replacement, which seems to be the same as the one shown by OP in the screenshot (ATI Mobility Radeon HD 5470).
What happens now is that when I try to build the project, it crashes on startup and the console says:
ERROR:GRAPHICS: gl error 1280: neplatn� vy��slen� (mangled Czech for “invalid enumeration”)
Assertion failed: 0, file …\src\opengl\graphics_opengl.cpp, line 594
The line number is different, but it’s probably the same issue.
Bundled debug version crashes, bundled release version is fine. “Build HTML5” works too.
This is not a big issue for me (on the contrary, I have other stuff to do than mess around with Defold), but if there’s more info I can give or stuff I can try that you’d find helpful, just let me know.
3 Likes
We updated the our game from 161 up to 166 version and got the same error (gl error 1280) on several devices with MALI-400 GPU
On game loading in debug mode I got crash:
E/defold ( 2944): ERROR:GRAPHICS: DrawElements(1284): gl error 1280
E/defold ( 2944):
F/libc ( 2944): ../src/opengl/graphics_opengl.cpp:1284: void dmGraphics::DrawElements(dmGraphics::HContext, dmGraphics::PrimitiveType, uint32_t, uint32_t, dmGraphics::Type, dmGraphics::HIndexBuffer): assertion "0" failed
On release build game starts, but game objects is not rendering (almost all):
On 161 defold the game runs correctly
Any idea?
Seems related to this issue: Android build on older device not rendering game objects (SOLVED)
What is your sprite max count?
2 Likes
For now this is 16384 sprite max count
I checking now related topic and will experiment around it
See if you can halve it to 8192.
Yea, if I halved the sprite max count, the game is running withour gl error 1280.
But what we can do, if we need this sprite amount? 
What happened from 161 defold?
You can of course set it to something just slightly smaller, e.g. 16380.
The key part is that as long as we don’t need 32 bit indices for the index buffers.
I wouldn’t have thought that we actually changed this, but I’ll double check the code to see what could cause this.
EDIT: Looking at the code, it was the introduction of the sprite trimming that increased the number of (possible) vertices for a sprite from 4 to 8, hence the change in behavior. It was not intentional, and I’ll look into a fix tomorrow, for the beta.
3 Likes
I added issue 4718 for this, and I’m working on a fix for the beta right now.
2 Likes
I have now release a new version of the BETA with a fix for this.
Please try it out to see if it works for you.
4 Likes
At first look all seems ok, as before sprite trimming
We will test more, seems all working, thank you!
2 Likes