Page 3 of 6

Re: Uzem ported to SDL2

Posted: Thu Oct 01, 2015 3:20 am
by kivan117
Artcfox wrote:BTW: What a challenging game! The best score I could manage was 7. :oops:

Yeah, it's pretty unforgiving. Honestly the guy who made it must hate people or something. :D
uze6666 wrote:Just to be sure can test with that game?
Artcfox wrote:I just tested Ghosty Ghost on both my 5 year old Linux laptop, and on a 3 year old Windows box, and it runs perfectly @ 28.636 MHz.
I haven't been on the boards here much lately because I'm in so far over my head at work, but the progress while I've been away is truly awesome. I think 2015 has been an amazing year for Uzebox progress all around. I'm happy to hear I can at least help by providing a game for testing use.

Re: Uzem ported to SDL2

Posted: Thu Oct 01, 2015 3:29 am
by Artcfox
kivan117 wrote:
Artcfox wrote:BTW: What a challenging game! The best score I could manage was 7. :oops:

Yeah, it's pretty unforgiving. Honestly the guy who made it must hate people or something. :D
uze6666 wrote:Just to be sure can test with that game?
Artcfox wrote:I just tested Ghosty Ghost on both my 5 year old Linux laptop, and on a 3 year old Windows box, and it runs perfectly @ 28.636 MHz.
I haven't been on the boards here much lately because I'm in so far over my head at work, but the progress while I've been away is truly awesome. I think 2015 has been an amazing year for Uzebox progress all around. I'm happy to hear I can at least help by providing a game for testing use.
Haha! It's a great game, thanks for making it! :)

I'm really looking forward to getting my game finished up so I can release it.

Re: Uzem ported to SDL2

Posted: Thu Oct 01, 2015 3:50 am
by kivan117
Thanks! I think we're all excited for your game to be released. I know I'm always glad to hear about another title joining the list.

To check coincidence I tried the 1.40 SDL2 version that uze posted a bit ago in the thread and ran my latest test version of Ghosty Ghost on it. Tried both .HEX and .UZE versions, not that it should matter but just in case. Everything ran really well as long as I wasn't actively resizing the window. Scaled from default size to as large as my screen would allow, then scaled it down to the minimum width allowed by Windows (it was very challenging to play this way, trust me) At all sizes, once in a while (every 10 to 15 seconds I'd say) I'd get a single pop in the music and corresponding stutter in the gameplay, and the title bar would indicate a drop from about 28.579 to 28.312 Mhz for one update.I'm using Windows 7 64 bit on a pretty high end desktop for reference.

Re: Uzem ported to SDL2

Posted: Thu Oct 01, 2015 4:24 am
by uze6666
There's definitely something different in the ways the audio works in SDL2, it was not dropping before. The emulation could slow down temporarily but the buffered samples seemed to be able to keep up. Or it's something with the video double buffering that's different. It's annoying because audio for me is extremely important. If we can't fix this, I reckon we stay on SDL1.

Re: Uzem ported to SDL2

Posted: Thu Oct 01, 2015 4:26 am
by Artcfox
kivan117 wrote:Thanks! I think we're all excited for your game to be released. I know I'm always glad to hear about another title joining the list.
Sweet! I'm hoping to at least get a beta build up soon. I have room for quite a few more levels, I'm just burned out creating and play testing them. So far I have 21, and that seems like a good number. I've been doing speed runs through them for a couple months now, and it still takes me ~25 minutes to actually pass all the levels in one sitting. My way of procrastination apparently was to switch over to debugging and improving Uzem. :lol:
kivan117 wrote:At all sizes, once in a while (every 10 to 15 seconds I'd say) I'd get a single pop in the music and corresponding stutter in the gameplay, and the title bar would indicate a drop from about 28.579 to 28.312 Mhz for one update.I'm using Windows 7 64 bit on a pretty high end desktop for reference.
I believe that's because that version posted will occasionally drop the entire first scanline. I created a patch that fixes that bug here, but the build you ran doesn't include that patch.

Uze, without that patch mode 3 games jitter up and down like crazy, and it makes my eyes go wonky. It wasn't just my game, Ghosty Ghost was doing it too. You said that the patch might screw up mode 13, but CunningFellow mentioned to me that Tornado2000 doesn't work at all with the SDL2 build you posted, so you might want to just go ahead and apply that patch. It definitely fixes mode 3, and it might also fix mode 13, but if you push that change, he (or anyone else with Tornado2000) should be able to test it again. I can probably submit a pull request for it if you would like, though I've made a bunch of other changes on that branch in my code so I'll have to figure out how to separate those out again, or you can just apply that diff as a patch.

Re: Uzem ported to SDL2

Posted: Thu Oct 01, 2015 4:29 am
by Artcfox
uze6666 wrote:There's definitely something different in the ways the audio works in SDL2, it was not dropping before. The emulation could slow down temporarily but the buffered samples seemed to be able to keep up. Or it's something with the video double buffering that's different. It's annoying because audio for me is extremely important. If we can't fix this, I reckon we stay on SDL1.
FYI: I'm running with that patch, and I haven't noticed anything different about the audio.

Re: Uzem ported to SDL2

Posted: Thu Oct 01, 2015 10:35 am
by Artcfox
In going from the master branch to the uzem140 branch, the number of SDL audio samples were decreased from 1024 to 512, but the size of the audioRing buffer is still set to 1024.

According to this page setting the buffer too small will result in audio crackles. I recommend bumping that parameter back up to 1024, and/or making it configurable from the command line, since that page also notes that the crackle threshold is something that's highly OS/hardware dependent. Setting it too high give you too much latency, but setting it too low gives you crackles.

Re: Uzem ported to SDL2

Posted: Thu Oct 01, 2015 2:47 pm
by uze6666
Ok, I will try and apply your patch to see if it improves things. My issue is that I don't seem to be able to reproduce your line drop issue. And I don't like to apply patch on something Iccan't see. I'm starting to wonder if it has somehow to do with the OS or GCC version. Btw, Y which version to you have? Can you send me a HEX file and capture that show the problem early?

I had lowered the buffer to reduce latency, but putting it back to 1024 didn't change anything.

Re: Uzem ported to SDL2

Posted: Thu Oct 01, 2015 7:16 pm
by Artcfox
uze6666 wrote:Ok, I will try and apply your patch to see if it improves things. My issue is that I don't seem to be able to reproduce your line drop issue. And I don't like to apply patch on something Iccan't see. I'm starting to wonder if it has somehow to do with the OS or GCC version. Btw, Y which version to you have? Can you send me a HEX file and capture that show the problem early?

I had lowered the buffer to reduce latency, but putting it back to 1024 didn't change anything.
The change from 512 samples to 1024 samples might not change anything for you, but that can make a difference depending on a person's hardware capabilities and configuration. For instance, on my desktop I was able to go down as low as 128 samples without crackling, but not on my old laptop. Changing it to 2048 or 4096 added too much latency.

In a previous PM, I sent you the .hex and a .cap file that can reproduce it. The hex hasn't changed since, but if that input capture file takes too long, then just run the .hex file manually and skip ahead to Level 10 (the dirt-themed level that has many lines of fire that you have to jump underneath without touching) and as soon as the level starts, hold right and then press and hold the jump button, and it should jitter a whole bunch right there in the beginning. I verified this using the Windows build that you posted the day you posted it, but I did not record an input capture, because it was something I can reproduce every time. Later tonight I can send you another input capture that will do that procedure, if you're willing to wait.

I've compiled Uzem with gcc 4.7, 4.8, and 4.9 with and without optimizations (-O3, -O2, -O1, -O0) and still got the same results (missing first scanline) without that patch applied on both Windows and Linux. I did not compile it myself in Windows, I just ran the build you posted.

As far as sound issues, the other difference between the master branch and the uzem140 branch is on the master branch SDL is configured with a sample rate is 15700, and on uzem140 branch it's configured with 15734. The documentation states that if your hardware isn't capable of setting it to what you request, then it may do a conversion internally to something the hardware can handle. I suspect that this is what might be happening, because I have bumped that number up to 15734 in both my master branch and my uzem140 branch and they sound exactly the same, but when I changed it back to 15700 there is noticeably less distortion. This happens independently of the version of SDL in use, it's just an inherent limitation of the underlying audio hardware. 48000 Hz is what most sound cards run at internally, and anything else is most likely going to require a conversion of some sort.

Edit: I'm not sure if SDL1.2 handles audio from a separate thread, but I know for sure that in SDL2 the audio callback you configure it to use runs in a separate audio thread. If the ring buffer isn't thread safe (a quick glance tells me it isn't), then that could also be causing audio issues.

Re: Uzem ported to SDL2

Posted: Fri Oct 02, 2015 3:34 am
by uze6666
Thanks for the rom and capture. I was able to reproduce the line skip issue. I will review you patch to fully understand what is going on.

I will do some audio tests with 15700 and various buffer sizes.