Diagonal Tearing Fix Support (Temper And Mame Questions)

[xexex]

I bought my wiz a couple months ago (and still have both my gp32 and gp2x). In terms of the overall design of the handheld I absolutely love the wiz and think it feels better to hold than the previous models and the oled screen looks beautiful. The only problem I have with it is the diagonal tearing. It is something that drives me crazy and so I prefer not to use emulators that don't have a tearing fix (I also can't stand console titles that have screen tearing and wish every game had a vsync option).

My favorite emulators on the wiz are mame and picodrive, which both support a tearing fix (although I did find that the tearing fix doesn't work with neo geo games on mame unless you also rotate the screen... is this something that may be fixed on a future update?). My question is how hard would it be to implement the fix found in pico drive in other emulators? Even if it does have a slight performance hit, it would be worth it to me and if it is simply an option than people who don't care could choose not to use it in order to avoid the performance hit. The emulator I most wish would offer a tearing fix is temper (for pc engine/turbografx16). I would think that this emulator could still work at full speed even with a slight performance hit, and the colors of the pc engine look great on the oled wiz screen. Is there any chance a screen fix option will be added to temper? Also, does anyone have a list of all the programs on the wiz that support a diagonal tearing fix? Thanks!

 

[EvilDragon]

GBA also does feature that fix (you can select that in the menu where you select scaling).

It don't think it's too hard to implement, but it does do a speed hit of about 10 - 20%.

 

[Yorper]

I could be wrong as i've been out of the scene for a very long time now and only just got back in.... But im pretty sure i read the tearing is to do with the SDK or there lack of an SDK?

Surely if GPH sorted out the SDK that should more or less resolve the tearing issues of new software using the fixed SDK? Removing the need for a fix to be a custom fix per software release?


Or did i just read something totally wrong on some other subject?

 

[notaz]

It don't think it's too hard to implement, but it does do a speed hit of about 10 - 20%.

That's if you implement it somewhat efficiently. With no effort it may be 2 times slower (or even more).

I could be wrong as i've been out of the scene for a very long time now and only just got back in.... But im pretty sure i read the tearing is to do with the SDK or there lack of an SDK?

No it's a hardware problem, that can be overcome if you draw the screen in portrait (240x320) mode.

 

[xexex]

It don't think it's too hard to implement, but it does do a speed hit of about 10 - 20%.

That's if you implement it somewhat efficiently. With no effort it may be 2 times slower (or even more).

Thanks for the information. Are you saying that a very rough fix that was around 2 times slower would take "no effort" to do? While I'd love the more efficient solution (I assume pico drive is using this better solution), if it was extremely easy to implement a "no effort" tearing fix then I would be happy to at least have that option in temper (considering how well it runs when my system is at 400 mhz and I can overclock it to 800, I would think that with frameskip even a rough implementation would be preferable to me than the tearing it has now). I asked about this issue here because although I understand the reason why the tearing occurs (i.e. drawing the screen in the wrong orientation) I am not at all a programmer so I wouldn't be able to implement a fix myself. However, if any of you could do even a rough fix I would be extremely grateful--and I assume I'm not the only one. Thanks!

 

[Exophase]

Right now no one can fix it because only I have the source for the Wiz version and my Wiz is bricked. I was investigating various methods when my Wiz was bricked. I'm still waiting for a good, easy way to unbrick it. EvilDragon - you said you could get images from GPH, is that still on the table?

 

[EvilDragon]

Right now no one can fix it because only I have the source for the Wiz version and my Wiz is bricked. I was investigating various methods when my Wiz was bricked. I'm still waiting for a good, easy way to unbrick it. EvilDragon - you said you could get images from GPH, is that still on the table?

It is, but you never know with GPH

 

[Exophase]

It is, but you never know with GPH

Okay, just so the situation is clear: as far as I know all of the non-volatile storage on my Wiz is toast. That includes U-Boot, so there's no first stage boot loader. That means that flashing from SD is not going to be possible. The only feasible boot option I'm aware of is over UART. I'm able to load MES's UART boot code giving me the menu, but loading the NAND flash module just freezes it. This could possibly mean that the NAND the flash module expects doesn't correspond with the one I actually have - U-Boot source has several commented out flash types so it wouldn't be that surprising if it changed at some point.

So what I need is a the right NAND flash loader, or something else that can accomplish this. It is possible for me to load U-Boot from the UART loader but that doesn't work for flashing since the memory map is non-standard (shadow swap mode to allow for UART boot). I thought about either writing my own flasher, modifying U-Boot so that its flash begins at a different place, or writing a program to use the MMU to accomplish that on standard U-Boot, but I was hoping there'd be an easier way since I'm too busy to dedicate a lot of time to trying to fix my Wiz.