Hi Matt, welcome to the Uzebox community! Been offline for a couple day and just saw your thread. I also think the lack of cycles is what's causing the issue. Normally the game should gracefully slow down the main program without much other effects. Though, in this case it seems to also affect the kernel that is running at a fixed 60hz speed. I'll try to think why it could happens. If you can record an example with
camstudio ans PM it to me it could help understanding the issue (though no garantees it's fixable).
And wow this frees up a lot of RAM! I can use even more RAM tiles now!
This is great! I'm not exactly sure what:
-DSOUND_CHANNEL_4_ENABLE=0
The channel disabling switches are for the vsync mixer to lower the cpu cycles and does nothing for the inline mixer so you can safely remove it.
I'm a huge fan of the AVR microcontrollers, and I might end up doing some performance testing/tweaking using a logic analyzer on one of the GPIO pins. That's how I optimized the libraries that I've written for AVRs in the past: When I enter a function/ISR, have it set a pin high, and when i leave the function/ISR set the pin back low.
Have you tried using Atmel's simulator in AvrStudio and AtmelStudio? It has a cycle counter and I use it heavily when doing assembler stuff, specially video modes. Just put breakpoints in you code and calculate the elapsed cycles.
When I get more time tonight (time is precious and hard to come by) I'll verify the current behavior of the emulator. I haven't looked at the code for the emulator yet, but I wonder how hard it would be to fix that. I did notice that the behavior of the emulator is slightly different than the actual hardware, specifically in my physics calculations. Everything should be deterministic, since I'm using int16_t with fixed point math, but on the actual hardware I noticed that one of my flying entities took a pixel or two longer for friction to decelerate him when changing directions. I only noticed this because I had tweaked that entity's max velocity based on feedback using the emulator so he would fly up and down between two tiles (but skid past them when switching directions) and in the emulator it slides up through the bottom of the floor above it a few pixels, but not enough to cause its hitbox to overlap you if you're standing on the floor above it; whereas on the actual hardware it slides up through the bottom of the floor above it just enough to cause its hitbox to overlap you if you're standing on the floor above it.
I'm viewing the emulator as a tool to help speed up development, but periodically I'm testing it on the real hardware, just so I can discover, and work around these differences before they become hard to work around. If anything, I'll treat the actual hardware as the truth.
As you mentionne the emulator is really so speed up development and is far from perfect emulation. Perhaps less than 50% of peripherals are emulated and we patch it as requirements comes in (like timer1 overflow interrupt for Tornado2000). Also, the whole video is hacked on using the sound output to synchronize frames! So there's definitely things that could differ timing wise. But the AVR CPU core with memory and registers,peripherals are ok, but again I never tested it against running in AVR Simulator.
But now I'm confused about the actual FPS. I thought NTSC frame rate is 29.97 fps, so I've been using an FPS of 30 for my physics calculations (which I might end up changing to 32, just so I can do bit shifts rather than divides for the integration of acceleration and velocity), because I thought that NTSC is meant to be interlaced, but on the UZEBOX it just sends the same frame twice, so it acts more like progressive, so the perceived FPS is ~30. If I change the order of my sprites 60 times a second, how could that work? Wouldn't that just end up flipping them for only the "odd" scan lines, giving you a mis-mash of stripes from different sprites every other frame? Or is it because the UZEBOX is actually drawing each frame twice (for the even and odd scanlines), then you get exactly what is intended (full sprites that switch @ 30fps)?
NTSC is 29.97 frames per second, with each frames made of two interlaced fields. At the end of each fields there a vsync retrace and that's what the Uzebox internal interrupts is based on, the field rate that is about 60hz. So when you WaitVsync(1), you are really waiting until the next field retrace (up to 1/60 of a second). In reality the kernel will render (at least actually) each field independently at 60hz with whatever the vram,sprites, etc are setup at that time. So not a full sprites that switch @ 30fps.
For Ghosty Ghost the biggest problem is how fluid the scrolling looks. On hardware it's nice and smooth (on a CRT it's REALLY smooth) but on the emulator the stuttering is just enough that I think hardware players are at an advantage.I don't know much about the inner workings of the emulator but it would obviously be ideal to have it match hardware if at all possible regarding the frequency of the screen output. Otherwise it's just confusing and inaccurate. Maybe it needs to be 30hz for performance reasons but if not, it would be awesome to get this changed.
You can run uzem.exe -i yourgame.hex to enable interlacing. By default it just draws the even fields twice. Things are smoother, but there's obvious shearing artifacts between scanlines for moving objects. That's the reason why it's optional.
If the only way to solve the sustained note issue is to lower the cycle count, then I guess I can decrease the number of vertical tiles, and steal back some RAM and cycles, but I was hoping for as large of a screen as possible.
This is indeed a great way to at least test to see if it's a cycle thing. You can use the SetRenderingParameters() function to lower the number of vertical lines to be rendered.
On a related note regarding uzem, MAME will soon ship (if not already) with partial Uzebox emulation. Since they go for perfect emulation at the expense of speed I don't know if it will run full speed on current machines. Could be another way to tests things when uzem seems to act weird.
Looking forward to see your game!