Help building Defold?

Mathias_Westerdahl · September 30, 2020, 4:29pm

$ lein run

Epitaph64 · September 30, 2020, 4:30pm

Thanks! I now have the editor opening

Epitaph64 · September 30, 2020, 4:46pm

@Mathias_Westerdahl helped me build the engine/editor here: Help building Defold? and I have now swapped out the mobdebug.lua file to version 0.709. However, the error still presents. I tested debugging some known debuggable code and couldn’t tell any difference. I assume the editor is using the mobdebug.lua at /tmp/dynamo_home/content/builtins/scripts

britzl · September 30, 2020, 9:02pm

No, I think it is using https://github.com/defold/defold/tree/dev/editor/bundle-resources/_defold/debugger

Epitaph64 · September 30, 2020, 10:10pm

I now have a modified version of the mobdebug.lua code working in my Defold build. However, I had to diff the module with the existing and perform some similar commenting outs, and replace the socket require to use the builtin one. Also, I noticed that the newer version is using a newer dependency for “serpent.” I investigated the changes for mobdebug and it seems this could be perhaps the cause:

I’ll see if I can update serpent as well and see if it fixes the issue.

EDIT: Nevermind, the mobdebug.lua file embeds the updated serpent module internally, it doesn’t require an external dependency. That doesn’t fix the issue in this case though. I have print statements to verify I’m loading the modified mobdebug.lua code. It does still work seemingly for the areas of the code which were previously debuggable. I can send over the updated module if you want. Also I checked the terminal and no error is printed when the breakpoint fails to highlight in the editor.

Epitaph64 · October 5, 2020, 9:02am

I recently rebuilt the engine from source again to update and resolve an issue I created when messing around with LuaJIT :blush. I’ve noticed that Windows doesn’t properly migrate the engine for the editor when you use --platform=win32, only with --platform=x86_64-win32. Otherwise you have to copy the engine into that directory in the tmp/unpack/x86_64-win32 directory manually. Just thought I’d let you guys know in case you want to update the build docs

Mathias_Westerdahl · October 5, 2020, 9:06am

The editor only runs on 64 bit platforms.

Epitaph64 · October 10, 2020, 5:03pm

One last question for now I’m seeing a message in the console repeatedly while running the built version of Defold:

[28]: java.base/java.lang.Thread.run(Thread.java:834)
GLDebugEvent[ id 0x20052
    type Warning: implementation dependent performance
    severity Medium: Severe performance/deprecation/other warnings
    source GL API
    msg Pixel-path performance warning: Pixel transfer is synchronized with 3D rendering.
    when 1602349275784
    source 4.6 (Compat profile, arb, debug, compat[ES2, ES3, ES31, ES32], FBO, hardware) - 4.6.0 NVIDIA 456.55 - hash 0x71ce496f]

Does this mean anything other than I’m running a custom build? If not, then is there some way to disable this since it’s hard to see if there are any actual errors happening since it shows up so many times.

Erik_Angelin · October 11, 2020, 6:55am

Do you see this error immediately when you start the editor? Or does it appear after you’ve opened a .go or .collection for instance? You don’t get a stacktrace, right?

Epitaph64 · October 11, 2020, 1:54pm

It happens every time I move the mouse over an editor window (go or collection.) There is a stack trace:

GLDebugEvent[ id 0x20052
		type Warning: implementation dependent performance
		severity Medium: Severe performance/deprecation/other warnings
		source GL API
		msg Pixel-path performance warning: Pixel transfer is synchronized with 3D rendering.
		when 1602424407973
		source 4.6 (Compat profile, arb, debug, compat[ES2, ES3, ES31, ES32], FBO, hardware) - 4.6.0 NVIDIA 456.55 - hash 0x4056da11]
	[2]: jogamp.opengl.GLDebugMessageHandler$StdErrGLDebugListener.messageSent(GLDebugMessageHandler.java:347)
	[3]: jogamp.opengl.GLDebugMessageHandler.sendMessage(GLDebugMessageHandler.java:332)
	[4]: jogamp.opengl.GLDebugMessageHandler.glDebugMessageARB(GLDebugMessageHandler.java:358)
	[5]: jogamp.opengl.windows.wgl.WGL.dispatch_wglMakeCurrent0(Native Method)
	[6]: jogamp.opengl.windows.wgl.WGL.wglMakeCurrent(WGL.java:157)
	[7]: jogamp.opengl.windows.wgl.WindowsWGLContext.wglReleaseContext(WindowsWGLContext.java:167)
	[8]: jogamp.opengl.windows.wgl.WindowsWGLContext.releaseImpl(WindowsWGLContext.java:448)
	[9]: jogamp.opengl.GLContextImpl.release(GLContextImpl.java:417)
	[10]: jogamp.opengl.GLContextImpl.release(GLContextImpl.java:382)
	[11]: editor.scene$update_image_view_BANG_$fn__61854.invoke(scene.clj:1156)
	[12]: editor.scene$update_image_view_BANG_.invokeStatic(scene.clj:1155)
	[13]: editor.scene$update_image_view_BANG_.invoke(scene.clj:1127)
	[14]: editor.scene$refresh_scene_view_BANG_.invokeStatic(scene.clj:842)
	[15]: editor.scene$refresh_scene_view_BANG_.invoke(scene.clj:827)
	[16]: editor.app_view$refresh_scene_views_BANG_$fn__68909.invoke(app_view.clj:1367)
	[17]: editor.app_view$refresh_scene_views_BANG_.invokeStatic(app_view.clj:1366)
	[18]: editor.app_view$refresh_scene_views_BANG_.invoke(app_view.clj:1363)
	[19]: editor.app_view$make_app_view$fn__68940.invoke(app_view.clj:1461)
	[20]: editor.ui$__GT_timer$fn__19171$fn__19172.invoke(ui.clj:1923)
	[21]: clojure.lang.AFn.run(AFn.java:22)
	[22]: com.sun.javafx.application.PlatformImpl.lambda$runLater$10(PlatformImpl.java:428)
	[23]: java.base/java.security.AccessController.doPrivileged(Native Method)
	[24]: com.sun.javafx.application.PlatformImpl.lambda$runLater$11(PlatformImpl.java:427)
	[25]: com.sun.glass.ui.InvokeLaterDispatcher$Future.run(InvokeLaterDispatcher.java:96)
	[26]: com.sun.glass.ui.win.WinApplication._runLoop(Native Method)
	[27]: com.sun.glass.ui.win.WinApplication.lambda$runLoop$3(WinApplication.java:174)
	[28]: java.base/java.lang.Thread.run(Thread.java:834)