Nestopia 1.39
Moderator: General Mods
1.33c-WIP3 (Part 2)
More bugs,this time for real
1. When Auto monitor refresh is enabled and VSync enabled,the emulator switches to 100Hz or 120Hz,but unlike 1.32 this version al NEStopia runs at double speed (100/120fps!) instead of 50/60.
2. When in fullscreen mode,and going to the Video settings,if you change the resolution from the drop-down box and then press 'Cancel',instead of just closing the options window,it also switches the resolution to the canceled selection and then quickly goes back to the one that was before.
?. Shouldn't the emulator pause emulation when the menubar (in fullscreen mode) is called with the ESC key?
I noticed that behavior only in 1.33c WIP2 Shouldn't this be added as an option?
"Auto-pause emulation when menubar is shown"
I would prefer emulation to be paused,but I also like to set it the way it is now (useful just for speed/bug testing,since it slows down performance significantly in some cases)
*. OK,VSync works and correctly locks at 60fps (or lowers performance further if fps <60,as expected),but the 'fishy' part is switching from double buffer to triple buffer and vice versa has no effect on performance at all in any combination/mode I tested.
You said you made the CPU/GPU sync activate only when triple buffering is off.I don't notice any performance drop when switching to Double Buffering as you said before.
Also,when in Double Buffering mode without VSync,60fps at 60Hz monitor refresh,I get bad tearing especially with no video filter.Switching to triple buffering doesn't change anything.Still bad tearing.
On the other hand,when I enable Triple Buffering in ZSNES,for example,I see a big difference.It's almost like VSync.As I said VSync works fine in NEStopia (no tearing at all),just the triple buffer...
**. Input lag? Tested again and double-checked for the latency 'issue',and I see there's no such thing as I previously thought. Not a bug.
Yes,I always set sound latency to 1,With filters off,everything's OK.
***. In the NEStopia log file,I get a list of supported refresh rates ranging from 56Hz to 120Hz,but in the video card control panel I get a range from 43Hz to 200Hz supported by the video card,
of which 56 - 160 (selectable) supported by the monitor. Indeed,DX9 doesn't support anything lower than 56Hz. Or maybe it does,but only if a TV is connected as a secondary display,
I have to check this now.
As for 200Hz,DX9 does support it.I can select it anytime with a 200Hz-capable display.
More bugs,this time for real
1. When Auto monitor refresh is enabled and VSync enabled,the emulator switches to 100Hz or 120Hz,but unlike 1.32 this version al NEStopia runs at double speed (100/120fps!) instead of 50/60.
2. When in fullscreen mode,and going to the Video settings,if you change the resolution from the drop-down box and then press 'Cancel',instead of just closing the options window,it also switches the resolution to the canceled selection and then quickly goes back to the one that was before.
?. Shouldn't the emulator pause emulation when the menubar (in fullscreen mode) is called with the ESC key?
I noticed that behavior only in 1.33c WIP2 Shouldn't this be added as an option?
"Auto-pause emulation when menubar is shown"
I would prefer emulation to be paused,but I also like to set it the way it is now (useful just for speed/bug testing,since it slows down performance significantly in some cases)
*. OK,VSync works and correctly locks at 60fps (or lowers performance further if fps <60,as expected),but the 'fishy' part is switching from double buffer to triple buffer and vice versa has no effect on performance at all in any combination/mode I tested.
You said you made the CPU/GPU sync activate only when triple buffering is off.I don't notice any performance drop when switching to Double Buffering as you said before.
Also,when in Double Buffering mode without VSync,60fps at 60Hz monitor refresh,I get bad tearing especially with no video filter.Switching to triple buffering doesn't change anything.Still bad tearing.
On the other hand,when I enable Triple Buffering in ZSNES,for example,I see a big difference.It's almost like VSync.As I said VSync works fine in NEStopia (no tearing at all),just the triple buffer...
**. Input lag? Tested again and double-checked for the latency 'issue',and I see there's no such thing as I previously thought. Not a bug.
Yes,I always set sound latency to 1,With filters off,everything's OK.
***. In the NEStopia log file,I get a list of supported refresh rates ranging from 56Hz to 120Hz,but in the video card control panel I get a range from 43Hz to 200Hz supported by the video card,
of which 56 - 160 (selectable) supported by the monitor. Indeed,DX9 doesn't support anything lower than 56Hz. Or maybe it does,but only if a TV is connected as a secondary display,
I have to check this now.
As for 200Hz,DX9 does support it.I can select it anytime with a 200Hz-capable display.
Thanks again for your report. Here's the update (finally the last?):
http://s22.quicksharing.com/v/5126866/N ... 4.zip.html
I had a quick look at the ZSNES source and saw that there are no DDFLIP_NOVSYNC flags in any of the IDirectDrawSurface7::Flip function calls. Therefore, enabling triple buffering in ZSNES will enable vsync as well.
http://s22.quicksharing.com/v/5126866/N ... 4.zip.html
Heh, one of those what the f*ck did I smoke bugs. Fixed now, but you'll unfortunately not be able to enjoy vsync on the higher rates since your driver appears to lack the D3DPRESENT_INTERVAL_TWO cap bit. Check for driver updates.1. When Auto monitor refresh is enabled and VSync enabled,the emulator switches to 100Hz or 120Hz,but unlike 1.32 this version al NEStopia runs at double speed (100/120fps!) instead of 50/60.
Yeah, it's due to design limitation. Since it's just a minor quirk, I'll look at it later when I have nothing else to do.2. When in fullscreen mode,and going to the Video settings,if you change the resolution from the drop-down box and then press 'Cancel',instead of just closing the options window,it also switches the resolution to the canceled selection and then quickly goes back to the one that was before.
Yes, always, except for when netplaying or when the 'run in background' option in the preferences dialog is enabled. Did you enable it by misstake??. Shouldn't the emulator pause emulation when the menubar (in fullscreen mode) is called with the ESC key?
Ah.. no, the major speed drop earlier was because of an unrelated bug. The sync-locker sorta made it worse, but since that bug was fixed and I've found others ways to reduce lag, there shouldn't be any major speed difference now. A few FPS at most maybe, but it all depends on your card and driver.You said you made the CPU/GPU sync activate only when triple buffering is off.I don't notice any performance drop when switching to Double Buffering as you said before.
Yup, that's to be expected.Also,when in Double Buffering mode without VSync,60fps at 60Hz monitor refresh,I get bad tearing especially with no video filter.Switching to triple buffering doesn't change anything.Still bad tearing.
No, it IS vsync.On the other hand,when I enable Triple Buffering in ZSNES,for example,I see a big difference.It's almost like VSync.
I had a quick look at the ZSNES source and saw that there are no DDFLIP_NOVSYNC flags in any of the IDirectDrawSurface7::Flip function calls. Therefore, enabling triple buffering in ZSNES will enable vsync as well.
Maybe, maybe not. It's up to the display mode enumerator to give me the rates. I've set my limit on 120Hz though since I feel it's unsafe to go higher because of potentional driver/monitor bugs/oddities.Indeed,DX9 doesn't support anything lower than 56Hz. Or maybe it does,but only if a TV is connected as a secondary display,
I have to check this now.
-
- ZSNES Developer
- Posts: 6747
- Joined: Tue Dec 28, 2004 6:47 am
Marty is correct.Marty wrote:No, it IS vsync.On the other hand,when I enable Triple Buffering in ZSNES,for example,I see a big difference.It's almost like VSync.
I had a quick look at the ZSNES source and saw that there are no DDFLIP_NOVSYNC flags in any of the IDirectDrawSurface7::Flip function calls. Therefore, enabling triple buffering in ZSNES will enable vsync as well.
Continuing [url=http://slickproductions.org/forum/index.php?board=13.0]FF4[/url] Research...
-
- Seen it all
- Posts: 2302
- Joined: Mon Jan 03, 2005 5:04 pm
- Location: Germany
- Contact:
kick wrote:Having a 200Hz PAL mode will also be a great addition
vSNES | Delphi 10 BPLs
bsnes launcher with recent files list
bsnes launcher with recent files list
1.33c-WIP4:
Only one little bug to fix:
In fullscreen mode with VSync ON,when running an NTSC game,if alternate speed is set to 240fps,holding the Alt. speed key reaches only 120fps.
When running a PAL rom,on the other hand it goes to 240.I see a regression here,kinda deja vu?
With VSync OFF,this doesn't happen.
The double-speed bug at 120Hz is gone now.
As for the >120Hz refresh rates,you can add this (advanced) feature by making it available only by editing the .cfg file (not available in the GUI)
Nearly release-ready
Only one little bug to fix:
In fullscreen mode with VSync ON,when running an NTSC game,if alternate speed is set to 240fps,holding the Alt. speed key reaches only 120fps.
When running a PAL rom,on the other hand it goes to 240.I see a regression here,kinda deja vu?
With VSync OFF,this doesn't happen.
The double-speed bug at 120Hz is gone now.
As for the >120Hz refresh rates,you can add this (advanced) feature by making it available only by editing the .cfg file (not available in the GUI)
Nearly release-ready
Alternative speed mode enables auto frame skipping internally and may not always keep up the speed when vsync is enabled. Try increasing the number of max. frames to skip in the timing options dialog.In fullscreen mode with VSync ON,when running an NTSC game,if alternate speed is set to 240fps,holding the Alt. speed key reaches only 120fps.
-
- Rookie
- Posts: 11
- Joined: Tue Aug 29, 2006 9:01 pm
I haven't play nes games in a few years on my pc. This program blown me away. I like it alot. This is alot better than the last program that I try a few years ago. Legend of Zelda have nice colors. I may start playing nes games again.
I have acouple of my GameGenie codes books somewhere. I going to look for those books. I don't remember where I put those last time.
I have acouple of my GameGenie codes books somewhere. I going to look for those books. I don't remember where I put those last time.
My Radeon 9800 Pro with Catalyst 6.5 installed (yeah, 3 releases behind) only supports INTERVAL_IMMEDIATE and INTERVAL_ONE. I suspect updating won't change this.Marty wrote:Heh, one of those what the f*ck did I smoke bugs. Fixed now, but you'll unfortunately not be able to enjoy vsync on the higher rates since your driver appears to lack the D3DPRESENT_INTERVAL_TWO cap bit. Check for driver updates.1. When Auto monitor refresh is enabled and VSync enabled,the emulator switches to 100Hz or 120Hz,but unlike 1.32 this version al NEStopia runs at double speed (100/120fps!) instead of 50/60.
Release is readykick wrote:Nearly release-ready
http://nestopia.sourceforge.net/
September 10 2006
Version 1.34 released. What's new:
Shell Changes:
Better method for CPU/GPU frame synchronization. Disabled when triple buffering is enabled.
Suitable default settings for auto frame skip, triple buffering and clock source based on system info.
Blargg's nes_ntsc back again with new version 0.2.1.
AVISTREAMINFO::szName no longer used since its presence seem to cause loading failures in some AVI file editors.
Shell Fixes:
Frame timing bug. Could cause severe slowdown on some systems.
Wrong speed at higher refresh rates.
Non-blocking input key commands.
Core Fixes:
"Quattro Sports: BMX Simulator" now responds to input again.
Language pack has also been updated with Chinese translations by nhlay (traditional) and Yoyo (simplified).
-Trebor
Updated NES NTSC filter and Chinese translation. Nice stuff
Hmmm...seems ATi's (AMD) drivers are way behind nVidia's when it comes to this.Not only that,but they also cut the hardware support for nPatches (TruForm) a year ago.Way to go,ATi (bah!)
And if you think nVidia is better,they offer more features and modes,but their drivers now suck even more.
Hmmm...seems ATi's (AMD) drivers are way behind nVidia's when it comes to this.Not only that,but they also cut the hardware support for nPatches (TruForm) a year ago.Way to go,ATi (bah!)
And if you think nVidia is better,they offer more features and modes,but their drivers now suck even more.
-
- ZSNES Developer
- Posts: 6747
- Joined: Tue Dec 28, 2004 6:47 am
Incorrect. There is no more software Truform support for non-8500/90xx/91xx/92xx (there is still hardware support for the 8500/90xx/91xx/92xx series). Then again, Trueform didn't really go that far with developers.kick wrote:Hmmm...seems ATi's (AMD) drivers are way behind nVidia's when it comes to this.Not only that,but they also cut the hardware support for nPatches (TruForm) a year ago.Way to go,ATi (bah!)
It could be worse, like Intel.And if you think nVidia is better,they offer more features and modes,but their drivers now suck even more.
Continuing [url=http://slickproductions.org/forum/index.php?board=13.0]FF4[/url] Research...
Deathlike2 wrote:Incorrect. There is no more software Truform support for non-8500/90xx/91xx/92xx (there is still hardware support for the 8500/90xx/91xx/92xx series). Then again, Trueform didn't really go that far with developers.kick wrote:Hmmm...seems ATi's (AMD) drivers are way behind nVidia's when it comes to this.Not only that,but they also cut the hardware support for nPatches (TruForm) a year ago.Way to go,ATi (bah!)
It could be worse, like Intel.And if you think nVidia is better,they offer more features and modes,but their drivers now suck even more.
There's no hardware support for Truform for the older cards as well.It's been removed from the drivers since last year.
It's sad to see it didn't go well.It was amazing for beefing-up lower-poly games,and could've been very useful for enhancing 3D system emulators,like PS1,N64 and even in some cases Dreamcast and PS2.
Yeah,forgot about Intel...LOL
-
- ZSNES Developer
- Posts: 6747
- Joined: Tue Dec 28, 2004 6:47 am
You do realize that software acceleration wasn't really ideal? Software acceleration wasn't really good for this. Some things are better off being hardware accelerated. Whether or not this was removed in the drivers that had hardware support.. software (games) support matters more. IIRC, adding truform support for games was easy, on the other hand, you had to tweak Truform quite a bit for it to matter (this was needed to be done for performance reasons).kick wrote:Deathlike2 wrote:Incorrect. There is no more software Truform support for non-8500/90xx/91xx/92xx (there is still hardware support for the 8500/90xx/91xx/92xx series). Then again, Trueform didn't really go that far with developers.kick wrote:Hmmm...seems ATi's (AMD) drivers are way behind nVidia's when it comes to this.Not only that,but they also cut the hardware support for nPatches (TruForm) a year ago.Way to go,ATi (bah!)
It could be worse, like Intel.And if you think nVidia is better,they offer more features and modes,but their drivers now suck even more.
There's no hardware support for Truform for the older cards as well.It's been removed from the drivers since last year.
It's sad to see it didn't go well.It was amazing for beefing-up lower-poly games,and could've been very useful for enhancing 3D system emulators,like PS1,N64 and even in some cases Dreamcast and PS2.
Yeah,forgot about Intel...LOL
Seriously, it was a nifty feature, but only good in a limited situation, plus the fact that it was only hardware accelerated to one product generation. Besides, adding Truform support to games that did not originally had it in mind is not a good idea, and is only limited to one vender and is not something any emu author would bother doing in this case.
Continuing [url=http://slickproductions.org/forum/index.php?board=13.0]FF4[/url] Research...
-
- Rookie
- Posts: 11
- Joined: Tue Aug 29, 2006 9:01 pm
Thanks for the release.
Btw: Does anyone know how I can copy all these codes and then turn all those into Codebook.exe? Is there one already so that I can download it? I never could find one.
I found whole shit load of codes here - http://www.consoledatabase.com/cheats/nes/index.html
Btw: Does anyone know how I can copy all these codes and then turn all those into Codebook.exe? Is there one already so that I can download it? I never could find one.
I found whole shit load of codes here - http://www.consoledatabase.com/cheats/nes/index.html
-
- Rookie
- Posts: 11
- Joined: Tue Aug 29, 2006 9:01 pm
What is Pro Action Rocky? I searches it on google and no codes list or a website been found. So I'm thinking it a Pro Action Replay instead.
Another thing is that Pro Action Replay codes can't be added because of something like this. The codes uses a space after 4 numbers.
Pro Action Replay Codes
Infinite Lives for Player 1: 0000 2E99
Infinite Lives for Player 2: 0000 4299
Not invincible after dying: 0000 3F00
No Sound FX: 0000 D100
So I have no idea what this about. Very confusing.
Another thing is that Pro Action Replay codes can't be added because of something like this. The codes uses a space after 4 numbers.
Pro Action Replay Codes
Infinite Lives for Player 1: 0000 2E99
Infinite Lives for Player 2: 0000 4299
Not invincible after dying: 0000 3F00
No Sound FX: 0000 D100
So I have no idea what this about. Very confusing.
Guys, question...
See, the original version of DBZ3 works with Nestopia, however, the English patch doesn't: http://www.romhacking.net/trans/898/
Said patch works with FCE Ultra though... Can you guys confirm the problem lies within the patch and not Nestopia ?
See, the original version of DBZ3 works with Nestopia, however, the English patch doesn't: http://www.romhacking.net/trans/898/
Said patch works with FCE Ultra though... Can you guys confirm the problem lies within the patch and not Nestopia ?
They're not the same. Here's a link Google gave me: http://disgruntleddesigner.com/chrisc/NewRockyCodes.htmT-Doomdays wrote:What is Pro Action Rocky? I searches it on google and no codes list or a website been found. So I'm thinking it a Pro Action Replay instead.
You could say the fault lies within .nes file format. You see, some mapper 16 carts contains different EEPROMs which may vary in units and size. DBZ3 uses a 24C02 (256 bytes) while other games, such as "Dragon Ball - Dai Maou Fukkatsu", uses a 24C01 (128 bytes). Since the .nes file format can't hold this information, I have to do CRC checks to detect what EEPROMs a cart contains. So, how can this be solved for homebrews and patched images?Stifu wrote:Guys, question...
See, the original version of DBZ3 works with Nestopia, however, the English patch doesn't: http://www.romhacking.net/trans/898/
Said patch works with FCE Ultra though... Can you guys confirm the problem lies within the patch and not Nestopia ?
Here are a few solutions I can think of:
(1). Split mapper into several new mappers based on EEPROM setup, e.g mapper x for 24C01, mapper y for 24C02, mapper z for 24C01+24C02 etc.
(2). Ignore EEPROMs for unknown carts. Game may run but save games won't work.
(3). Provide a user interface for overriding EEPROM setup (similar style to the DIP switch dialog).
I'm thinking about doing (3), but haven't decided yet because I'm not sure the casual user is attentive enough to try it before filling a bug report.
-
- Trooper
- Posts: 376
- Joined: Tue Apr 19, 2005 11:08 pm
- Location: DFW area, TX USA
- Contact:
Incidentally, either through ATI's WDDM drivers, or through Vista itself, dxcapsviewer reports that the device supports presentation intervals of two, three, and four.kode54 wrote:My Radeon 9800 Pro with Catalyst 6.5 installed (yeah, 3 releases behind) only supports INTERVAL_IMMEDIATE and INTERVAL_ONE. I suspect updating won't change this.Marty wrote:Heh, one of those what the f*ck did I smoke bugs. Fixed now, but you'll unfortunately not be able to enjoy vsync on the higher rates since your driver appears to lack the D3DPRESENT_INTERVAL_TWO cap bit. Check for driver updates.1. When Auto monitor refresh is enabled and VSync enabled,the emulator switches to 100Hz or 120Hz,but unlike 1.32 this version al NEStopia runs at double speed (100/120fps!) instead of 50/60.
-
- ZSNES Developer
- Posts: 6747
- Joined: Tue Dec 28, 2004 6:47 am
Marty.. I was reading this thread in your forum... http://www.bannister.org/ubb/ultimatebb ... 6;t=000135
I'm not exactly clear on this, but why is 288 used for the TV aspect ? Shouldn't it be 298 instead? (298x224 is closest to 4:3 as possible).. unless I'm missing something here...
I'm not exactly clear on this, but why is 288 used for the TV aspect ? Shouldn't it be 298 instead? (298x224 is closest to 4:3 as possible).. unless I'm missing something here...
Continuing [url=http://slickproductions.org/forum/index.php?board=13.0]FF4[/url] Research...
Looks like a typo to me.
I've been having the same problems trying to think of a sane way to do aspect ratio correction for all monitors and resolutions.
Essentially, the formula is rather simple: width=height*4/3. Turns square pixels into pixels that match the width to height ratio of (S)NES pixels on a traditional CRT TV (4:3). The problem is with all these new 16:9, 16:10, 4:3 but 5:4 video modes, etc... you basically need to apply two math formulas, one to account for the pixel x:y aspect of the host machine, and another to correct for the pixel x:y aspect of your target machine. Problem is that the host machine's x:y is dependant on both current resolution (only a problem for more flexible CRTs, 4:3 monitors are 5:4 in 1280x1024 mode) and physical size. The latter of which there is no simple API to determine, and you can't expect users to exercise common sense and enter this information into the emulator before complaining. Not really sure how much the latter is a problem, are there PC monitors (such as 1280x1024 LCDs) where pixels are non-square due to the actual dimensions of the monitor being a true 4:3, or do they intentionally always make these LCDs taller to account for this?
I've been having the same problems trying to think of a sane way to do aspect ratio correction for all monitors and resolutions.
Essentially, the formula is rather simple: width=height*4/3. Turns square pixels into pixels that match the width to height ratio of (S)NES pixels on a traditional CRT TV (4:3). The problem is with all these new 16:9, 16:10, 4:3 but 5:4 video modes, etc... you basically need to apply two math formulas, one to account for the pixel x:y aspect of the host machine, and another to correct for the pixel x:y aspect of your target machine. Problem is that the host machine's x:y is dependant on both current resolution (only a problem for more flexible CRTs, 4:3 monitors are 5:4 in 1280x1024 mode) and physical size. The latter of which there is no simple API to determine, and you can't expect users to exercise common sense and enter this information into the emulator before complaining. Not really sure how much the latter is a problem, are there PC monitors (such as 1280x1024 LCDs) where pixels are non-square due to the actual dimensions of the monitor being a true 4:3, or do they intentionally always make these LCDs taller to account for this?