View Single Post
  #212 (permalink)  
Old 05-11-2010, 06:31 PM
bitbank's Avatar
bitbank
PPCGeeks Regular
Offline
Location: Redmond, WA
 
Join Date: Oct 2009
Posts: 79
Reputation: 95
bitbank is becoming a great contributor
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Send a message via AIM to bitbank
Re: Smartgear works great on Touch Pro 2! NES! Genesis!

Quote:
Originally Posted by THE-COPS View Post
Smooth scaling would be a nice addition. But doesn't that stretch the image? Also, woud it be possible to add an adjustable sound buffer, for latency? I am noticing that some have lag or static issues while others do not. Perhaps having a slider to adjust it would even it out for all. I kinda miss this option as most PPC/Smartphone emulators don't have such an option. Not all devices are universal, so the emulator I think should have some sort of compensation for each. Does that make any sence to you?

And as far as the differences in why there are gfx glitches in some roms while other users such as yourself aren't experiencing them.. I'm thinking, could it be the gx.dl file? Is that the correct file I'm thinking of? The driver for gfx . I forget the file name. But in any case, could it be that since the T-mobile TP2 came out wel before the VZ & Sprint versions, that there coud have been some minor code changes done to it after the TMO unit came out? If this is the file, then perhaps I could send you a copy of said file and you could somehow compare them? I noticed it's a very small file at 6.83KB. That can't be the gfx driver? Confused here.
I'm already stretching the images to fill the display. GBC = 160x144 and Genesis = 320x224, so in order to fill a 800x480 display, the image needs to be stretched.. The idea would be to make the stretched image look less blocky.

I'm not sure about some of the sound differences you're seeing, but I do see the Genesis graphics problems and will eventually have a fix for them. GX.dll is not used by SmartGear and there is no real "driver" involved. SmartGear asks the system for the address of the display VRAM and then writes directly to that memory. I don't think a variable sound buffer scheme is necessary; all WinCE devices work pretty much the same, so once I get things working well it will work well on all devices.
L.B.
Reply With Quote
This post has been thanked 2 times.