Thanks! I'm starting to think that's the case, because as I'm optimizing more stuff, it's getting harder and harder to reproduce. I actually don't have Windows installed at home, I've been doing all of my development and testing under Linux, but I can PM you the .hex file.uze6666 wrote: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).
Cool. I checked the size of the .hex with and without, and when there was no difference, I removed that flag.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've never actually used AVR/Atmel Studio, except once on a borrowed computer when I first got my AVRISP mkII in order to update its firmware. That does sound like a useful tool though! I mostly count cycles by hand looking at the generated assembly, or for the longer stuff, just use a logic analyzer that can automatically count cycles for me. I guess it's because I'm used to doing hardware stuff with the AVR microcontrollers. This is the first time where I actually feel like I'm writing software for one, rather than firmware.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.
Interesting, I think I'll have to do some experiments to solidify it in my head. I've read and re-read the documentation so many times, I think I'm going to need to poke it with a stick before I can fully understand it.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.
I'll give that a shot to see if it changes how it looks, though I'm not flickering my sprites, so I'm not sure it would show anything different.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.
I think I'd rather addThis 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.
Code: Select all
KERNEL_OPTIONS += -DSCREEN_TILES_V=XX
Sweet! I'm pretty pumped. I spent quite a few months looking at the documentation and design of the UZEBOX, trying to figure out if I wanted to build my own hardware from scratch, or just purchase a kit, but I have so little free time these days that I just bought the kit, and now it's hard for me to think about anything else other than this game I've been working on.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!