Re: [crossfire] Trouble building Windows client
On 1/21/20 9:06 PM, Nathaniel Kipps wrote: > On a side note, has anyone devised any clever ways to do benchmark > tests of the client's rendering speed, or full end-to-end latency > testing of client-to-server communication? I think such was once > talked about on IRC, but it was some months ago. Nothing clever, but there is now: --profile-latency Log command acknowledgement latency to stdout --profile-redraw Print map redraw times to stdout This was used to measure the major server latency improvement committed not too long ago. -- Kevin Zheng kevinz5...@gmail.com | kev...@berkeley.edu XMPP: kev...@eecs.berkeley.edu ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Trouble building Windows client
On Tue, Jan 21, 2020 at 8:12 PM Kevin Zheng wrote: > > Are there any "partial debug" options I should try (since I notice a > > little stuttering with the main debug build)? > > Build "RelWithDebInfo" in CMake. Make sure to make clean. The build is here, for those who wish to try it: https://drive.google.com/file/d/1mmFb1zpB3OaWKXlwtJwd4YXY5ca41j4L/view It seems to have correct behavior with the Preferences window. I will do more tests to see if any other issues are apparent. On a side note, has anyone devised any clever ways to do benchmark tests of the client's rendering speed, or full end-to-end latency testing of client-to-server communication? I think such was once talked about on IRC, but it was some months ago. --DraugTheWhopper ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Trouble building Windows client
On 1/21/20 5:09 PM, Nathaniel Kipps wrote: > On Tue, Jan 21, 2020 at 7:21 PM Kevin Zheng wrote: >> >> That's interesting. That means there's definitely a bug somewhere. In >> the meantime, we can work around by providing a debug build! >> > > Are there any "partial debug" options I should try (since I notice a > little stuttering with the main debug build)? Build "RelWithDebInfo" in CMake. Make sure to make clean. > Any guidance on how it should be packaged for an "impromptu" release? > I suppose a zipfile is much easier to build than a full installer > package. A zip file with the binary and the runtime files is fine, like the previous release. -- Kevin Zheng kevinz5...@gmail.com | kev...@berkeley.edu XMPP: kev...@eecs.berkeley.edu ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Trouble building Windows client
On Tue, Jan 21, 2020 at 7:21 PM Kevin Zheng wrote: > > That's interesting. That means there's definitely a bug somewhere. In > the meantime, we can work around by providing a debug build! > Are there any "partial debug" options I should try (since I notice a little stuttering with the main debug build)? Any guidance on how it should be packaged for an "impromptu" release? I suppose a zipfile is much easier to build than a full installer package. --DraugTheWhopper ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Trouble building Windows client
On 1/16/20 8:39 PM, Nathaniel Kipps wrote: > In a bizarre twist, a debug build makes the issue vanish. I simply > cannot reproduce it once the CMAKE build type is set to "Debug". For > the adventurous, a copy of the debug build can be found here: > https://drive.google.com/file/d/1QobJhgkMLkBtq4uYhU8G72B2PEbWxYRR/ That's interesting. That means there's definitely a bug somewhere. In the meantime, we can work around by providing a debug build! -- Kevin Zheng kevinz5...@gmail.com | kev...@berkeley.edu XMPP: kev...@eecs.berkeley.edu ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Trouble building Windows client
In a bizarre twist, a debug build makes the issue vanish. I simply cannot reproduce it once the CMAKE build type is set to "Debug". For the adventurous, a copy of the debug build can be found here: https://drive.google.com/file/d/1QobJhgkMLkBtq4uYhU8G72B2PEbWxYRR/ > This, I don't know. What compiler did you use? If you used MinGW's gcc, > then gdb should be available as well. I do use gcc, or at least, whatever comes with MinGW. --DraugTheWhopper ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Trouble building Windows client
On 1/6/20 3:40 PM, Nathaniel Kipps wrote: > I find it most interesting that the issue only manifests once I remove > the binaries from the build environment, and execute them elsewhere. > This indicates to me that I'm missing something simple, and that it's > not just a regular bug. That is an interesting observation that I didn't realize before. >> try re-building with debugging symbols > > Some quick googling shows that this may be as simple as setting > "CMAKE_BUILD_TYPE" to equal "Debug". Shouldn't be to hard to try. That should be right. >> getting a backtrace from the crash > > Since the client doesn't actually crash, just behaves anomalously, is > there an alternate way to get a backtrace? Perhaps some function in > windbg that may help? This, I don't know. What compiler did you use? If you used MinGW's gcc, then gdb should be available as well. Regards, Kevin -- Kevin Zheng kevinz5...@gmail.com | kev...@berkeley.edu XMPP: kev...@eecs.berkeley.edu ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Trouble building Windows client
Hi Kevin, > On Mon, Jan 6, 2020 at 7:41 AM Kevin Zheng wrote: > There's no doubt there's a real issue somewhere. I find it most interesting that the issue only manifests once I remove the binaries from the build environment, and execute them elsewhere. This indicates to me that I'm missing something simple, and that it's not just a regular bug. > try re-building with debugging symbols Some quick googling shows that this may be as simple as setting "CMAKE_BUILD_TYPE" to equal "Debug". Shouldn't be to hard to try. > getting a backtrace from the crash Since the client doesn't actually crash, just behaves anomalously, is there an alternate way to get a backtrace? Perhaps some function in windbg that may help? --DraugTheWhopper ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Trouble building Windows client
Hi Nathaniel, On 1/6/20 3:47 AM, Nathaniel Kipps wrote: > When the built client is run in it's own development environment, > everything is fine. But, when I pull the binaries, DLLs, and > supporting files out into another environment, such as a test machine, > the Preferences window no longer opens. There's no error, or message > in the console, no indication of problems, just that the dialog does > not actually appear. > > If anyone has any input, that would be much appreciated. Also, if > anyone wants to try it for themselves, feel free to grab a rolled up > package here: > https://drive.google.com/open?id=14ej1Hw37mxABcd60ZD7ULL5AKNmelTU_ Rick has reported a similar issue, and I remember experiencing it before as well. There's no doubt there's a real issue somewhere. Unfortunately, it will be some time before I get around to getting my Windows build set up again. In the meantime, could you try re-building with debugging symbols and getting a backtrace from the crash? -- Kevin Zheng kevinz5...@gmail.com | kev...@berkeley.edu XMPP: kev...@eecs.berkeley.edu ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
