Everybody! Help us test basic engine compability :)

#1

So I’ve got a quick public test here for everybody, regardless of whether you’re officially signed up as an alpha backer or a tester.

https://t.co/YQQT5gdJg9

Basically, we’ve had reports from a few testers that the HD build of Defender’s Quest crashes in recent builds, but I haven’t been able to reproduce this reliably, and it only happens to some people. I highly suspect the error is coming from our underlying engine somewhere, and I’ve put together a little test to help narrow down where the error was introduced.

As some of you may know, we are built on top of a technology stack:

  • Haxe (programming language)
  • OpenFL (multimedia framework)
  • HaxeFlixel (high level game engine/framework)

OpenFL recently underwent a change from its “legacy” version to a new version we’re calling “next”, and although it is better in many ways, it might still have some bugs/regressions. This test is designed to figure out where those rare crashes might be.

If you have some time and are running any version of Windows, you could really help us out (and speed the release of DQHD and DQII) by running this test :smile:

Thanks for your time!

#2

Done. Executive summary: On winXP legacy versions run fine, next versions of displaybitmap/shape run fine and everything else crashes immediately after creating the main window (outline only)

#3

Thanks :slight_smile: We’ve got some leads on what might be the source of crashes, and I’ll put out some new builds as soon as I can. Hopefully we get this nailed away real quick.

#4

@coyot:

Here’s a new build. This time I’m zooming in on PiratePig as that has the most crashes. We have two builds here, both using the “next” pathway. We’ve made one small tweak since last time, and in addition we’ve now also compiled with hardware rendering turned on and off.

https://drive.google.com/open?id=0B82nNNq_hucHdE1kQTlYT1dMS0U

Do both of these crash? Does one of them crash and not the other? If you run from the command line it will print out whether it’s hardware or not, but they’re also labeled in the folders.

EDIT:

https://drive.google.com/file/d/0B82nNNq_hucHYXdrczZaRnNDQzA

Added more info to the command line. It will output what hardware setting it’s trying to use (true for hardware, false for software), as well as what it’s actually using (OPENGL means hardware, CAIRO means software).

#5

Both crash the same way, I get a few seconds of music while the microsoft crash dialog is shown.
Commandline just confirms that hw true uses opengl and sw false uses cairo.

#6

Okay, that’s good, actually. So not only is the hardware version not falling back to software like it should, on XP even a force-it-to-use-software mode will still crash. I’ll report back when I have new test builds, thanks for helping.

#7

What is Cairo exactly?

#8

CAIRO is a software rendering library:
http://cairographics.org/

Basically, there’s two ways to draw things on a computer. Hardware, which uses the graphics card, and software, which uses the CPU. The former is fast and fancy and nice, but can be a pain to support consistently because of drivers and graphics cards and stuff. The latter is much slower, but doesn’t depend on a graphics card or graphics drivers and gives the same results on all platforms.

So we use OpenGL for our hardware rendering and CAIRO for our software rendering.

#9

That’s exactly the same result I got (also Windows XP with SP3).

EDIT:
Tested the new Testbuild.
First Test (Hardware) crashed and gave the following output:

Window Hardware Set to = true
Renderer in use is actually = OPENGL
AL lib: (EE) alc_cleanup: 1 device not closed

Second Test (Software) also crashed and gave the following output:

Window Hardware Set to = false
Renderer in use is actually = CAIRO
AL lib: (EE) alc_cleanup: 1 device not closed

#10

Good news!

I’ll be putting a fresh build out ASAP. Anyone who had the XP crash is invited to give it a test and see if it works. If it does, then the next nightly build of DQHD for alpha backers / testers should be expected to work too.

EDIT:
Here’s the new build, give it a shot everybody!
https://drive.google.com/file/d/0B82nNNq_hucHVVZCc2RUOFRWb1k

#11

Tested your new build.

Here are the results:

Hardware_next: Crash on start.

Window Hardware Set to = true
Renderer in use is actually = OPENGL
AL lib: (EE) alc_cleanup: 1 device not closed

Software_next: Crash on start

Window Hardware Set to = false
Renderer in use is actually = CAIRO
AL lib: (EE) alc_cleanup: 1 device not closed

Conclusion:
The fix didn’t help.

#12

Hmmm, I’ve had reports that it fixed XP for other people. Before I conclude the fix didn’t work, I need to rule out that I actually compiled with the new settings. I’ll add some new printfs to the output to verify.

EDIT: apparently I should have done a clean build rather than an incremental one, so I likely didn’t actually present the change in the new build.

New build incoming in ~30 mins.

#13

New Build:

https://drive.google.com/file/d/0B82nNNq_hucHVFdkNmNINWZoemM

Crosses fingers

#14

And here are the results:

Hardware_next: No crash.

Window Hardware Set to = true
Renderer in use is actually = OPENGL

Looks like there are less printf than before ^ ^

Software_next: No crash, but strange double execution.

Window Hardware Set to = false
Renderer in use is actually = CAIRO

Regarding the double execution:
First the Program starts, plays the music for like 3-4 seconds, then stops. As Score I see 1400, then a few seconds later, the window vanishes, leaving no console output whatsoever. Then the program starts again, this time with console output.

Don’t know if this is intended or not but that’s what is happening for me with the Software_next build.

#15

Great! I wasn’t able to put any new printf’s in as the define I was looking for is buried away in one of the dependencies and not easily accessed. While I was fiddling I probably deleted the Next/Legacy printout.

It’s weird to hear about the software issue, but software is just there for a fallback anyway and has known limitations, so I’m less concerned about that if hardware works as intended.

Eager to hear about whether tonight’s DQHD build actually works for XP users again!

#16

For me the latest pirate pig build works fine in both versions, no issues.

#17

Have you waited in the software-version for some time?
It occured to me roughly around 10-20 seconds after the music stopped playing that the program seemed to restart itself.

btw. where would I find the latest DQHD build? Haven’t been up to date with here for quite some time now but would like to test tonights new build.
Is it still in Google Drive (the “tdrpg-haxe-builds” folder there)?

#18

Yep, no problem on my side…

#19

Yes, check the DQ1 folder. :stuck_out_tongue:

#20

Hey everybody!

I’ve put up a new basic compatibility survey with fresh test builds:

This time I’m zeroing in on the “PiratePig” demo, which seemed to be the best test piece for crashes. I’m including just four builds this time, each using a different rendering method:

angle – uses Google’s ANGLE library to translate OpenGL calls to windows-friendly DirectX
opengl – uses desktop OpenGL (referred to as “hardware + next” in previous tests)
software – uses CAIRO software rendering (referred to as “software + next” in previous tests)
legacy – uses a much older OpenGL renderer with software fallback

Thanks for all your help in patience; these tests help us make sure that DQHD / DQII will run on as many computers as possible.