Yes, check the DQ1 folder. 
Everybody! Help us test basic engine compability :)
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.
OpenGL is the only one that crashes for me. Hooray! 
P.S.: Sorry for sorta wasting your time with the weird manifest issue @larsiusprime :V
Survey number 3!
I think I’m getting very close this time.
If AUTO wasn’t working for anyone (as in, it wasn’t launching anything), the download link in the survey has been updated.
Windows XP users!
I’ve got a quick test today. Can you test this and tell me if it runs?
https://drive.google.com/file/d/0B82nNNq_hucHSzRZVzlfd2REeWc/view?usp=sharing
Windows XP user at your service!
Indeed it does run. And it’s playable. But the score doesn’t go up 
^ ^
Here is the Output:
Next
Window Hardware Set to = true
Renderer in use is actually = OPENGL
PiratePig.hx:51: GL VERSION = 4.4.0 NVIDIA 344.11
Hope that helps!
Hmm, looks like that’s not testing what I want it to test. (it’s still using GL, not ANGLE)
How about this one?
https://drive.google.com/file/d/0B82nNNq_hucHa0ZycHlDdmh5U0k/view?usp=sharing
Window opened with some stuttering sound. Then it closed again and reopened again, without stuttering music.
Unfortunately, I only see white, so no graphics whatsoever.
Here is the output:
INFO: WARNING: Ingoring SDL_GL_SetSwapInterval call due to ANGLE bug
INFO: WARNING: Ignoring SDL_GL_SetSwapInterval call due to ANGLE bug
PiratePig.hx:35: Release
PiratePig.hx:41: Next
PiratePig.hx:45: Window Hardware Set to = true
PiratePig.hx:46: Renderer in use is actually = OPENGL
PiratePig.hx:52: GL VERSION = OpenGL ES 2.0 (ANGLE 2.1.0.faaa84ac1e86)
I think that the double first line is probably because of the reopening window. So the first window caused the first INFO: WARNING, then closed, than openened and the second INFO: WARNING came with the rest of the output.
FYI the funny thing is, that when I pipe the output to a log file, the “INFO: WARNING” messages are still on the console and not in the log file. Only the “PiratePix.hx:” messages get into the log file…
Okay, so I think ANGLE just doesn’t work on XP, though it solves our GL compatibility issues on all other versions of windows.
So now I have to find out how to get it to just fall back to OpenGL for XP, which won’t work on EVERY Xp machine, but better than a white screen.
https://drive.google.com/file/d/0B82nNNq_hucHNWwtZzFiS3NmdDg/view?usp=sharing
Okay, here we go. I couldn’t fall back to OpenGL, but I CAN fall back to software rendering, which will, hook or by crook, just work.
Didn’t work.
Now it’s black instead of white.
Here is the output:
INFO: WARNING: Ingoring SDL_GL_SetSwapInterval call due to ANGLE bug
INFO: WARNING: Ignoring SDL_GL_SetSwapInterval call due to ANGLE bug
os Version = 5.1
PiratePig.hx:35: Release
PiratePig.hx:41: Next
PiratePig.hx:45: Window Hardware Set to = true
PiratePig.hx:46: Renderer in use is actually = CAIRO
PiratePig.hx:52: GL VERSION = OpenGL ES 2.0 (ANGLE 2.1.0.faaa84ac1e86)
Also again the double start bug as described before.
Btw. couldn’t you detect if Win XP is used before starting any of the graphics? Then you wouldn’t have to “fall back” but simply use something different from the start.
That’s exactly what I’m trying to do here… one more test I guess.
What happens if you run it like this: “piratepig --window-hardware=false” ?
That forces software rendering. If that works, then it’s just a matter of enabling it early enough on XP detection.
That actually works. Even the score goes up by playing!
But still after like 7 seconds it started itself again for some reason…
Here is the output:
os Version = 5.1
PiratePig.hx:35: Release
PiratePig.hx:41: Next
PiratePig.hx:45: Window Hardware Set to = false
PiratePig.hx:46: Renderer in use is actually = CAIRO
Silly me!
Turns out the bug was simply that I was trying to do this in the application:
if (Lib.application.config.windows[0].hardware)
{
trace("GL VERSION = " + GL.getParameter(GL.VERSION));
}
Which won’t work if I’ve forced software because of the OS (instead of the command line), but if software is still enabled anyway, that means GL is not loaded, which means we’ll crash. So it was only my debug info that caused the issue!
If you’re still on, try this one:
https://drive.google.com/file/d/0B82nNNq_hucHU3JDY1VOaFpyaDg/view?usp=sharing
I’ve been getting good feedback on my latest build, so I went ahead and made a new form:
If results are positive, after Thanksgiving I’ll roll these improvements into the DQ nightly builds.
I wasn’t on anymore (was already around 2 am at my time zone… gotta sleep some time ^^ ), but I tried it out now.
Again I got the double start bug (i.e. game starting, after 4-5 seconds game closing and immediately starting again).
But overall, it worked. I could play it and even got score ^^
Here is the output:
NativeWindow.create()
PiratePig.hx:35: Release
PiratePig.hx:41: Next
PiratePig.hx:45: Window Hardware Set to = true
PiratePig.hx:46: Renderer in use is actually = CAIRO
Great to hear. Dunno what causes the restart, but hopefully that’s basically sorted.
I’ll be pushing these results to the next build of DQHD. DQHD is waaaay more complicated than PiratePig, so I have no idea if things are going to explode in XP mode or not, I guess we’ll see.