bsnes v0.035 released

[SmartOne]

Just "plop" an option into Advanced Configuration that can disable fullscreen menus for the rest of us. It happens to byuu too.

Probably not quite that easy, but it's an idea.

[AamirM]

Hi,

If you are not already doing this, using DirectDraw (system.video=directdraw) might remove this problem. I get one line tearing with D3D but not with DDraw.

stay safe,

AamirM

[SmartOne]

Thanks for the suggestion, but DirectDraw doesn't support a Point Scale2x filter (intead it's interpolated, like Linear.) I don't think there was any tearing though.

D3D has the one line of tearing near the top.

OpenGL is terrible... two or more lines of tearing near the bottom.

GDI isn't interpolated like DirectDraw but has a nice tear right through the middle.

Argh.

[_willow_]

So far i have bad luck with vsinc, it tearing everywhere no matter what i do.

1920 x 1200 x 60hz HDMI, OpenGL & Direct3D. Vista SP1

Need to to give DirectDraw a try..

[Verdauga Greeneyes]

GDI isn't interpolated like DirectDraw but has a nice tear right through the middle.

GDI cannot poll for VBlank like the others can, although obviously even they don't do a particularly good job of it (which is BS, since monitors are supposed to be capable of sending VBlank IRQs to the graphics card.. it just doesn't handle them in any sensible way).

[FitzRoy]

Here are some minor suggestions for the next wip:

1. In the "driver" config section, the spacing seems off from other sections. Notice how the first text line starts further down.

2. Paths section wording and order would look better as:

Default game file path:
Default save file path:
Default patch file path:
Default cheat file path:

3. The niche radio option atop input settings can be changed to only two options having to do with program behavior (misc.pause_when_unfocused, true/false) and moved to advanced settings. The middle setting seems pointless, anyone who didn't want input to register while inactive would simply use the pause setting because it effectively achieves that.

[Gil_Hamilton]

GDI isn't interpolated like DirectDraw but has a nice tear right through the middle.

GDI cannot poll for VBlank like the others can, although obviously even they don't do a particularly good job of it (which is BS, since monitors are supposed to be capable of sending VBlank IRQs to the graphics card.. it just doesn't handle them in any sensible way).

Graphics cards have never supported most of what's available.

Hell, the monitors have a full bidirectional communications bus, and video cards can't even properly query them for resolution and refresh rate in a lot of instances.

[odditude]

Hell, the monitors have a full bidirectional communications bus, and video cards can't even properly query them for resolution and refresh rate in a lot of instances.

To be fair, it's not uncommon for monitors to not provide all the correct information when queried. Both sides suck.

[henke37]

Yeah, it is something about people not bothering to do a good job since there is nobody that controls their pay that will check it.

And we have already discussed the difference between pause and ignoring input. One keeps the game running, the other not.

[Baron_Samedi]

hi

i found a small bug with star ocean and bsnes 0.035

when i close the dialog box the frames of the box flicker
and show some grafik errors
when the dialog box is on the bottom the complete frame flickers
when the box is on top only the bottom of the box flickers

the info box during a battle is ok when it closes


this happens with the j rom and the dejab version


i use vista 64 bit
i tried this with and without aero, vsync, d3d, opengl


but this error happens with all settings

[byuu]

Thank god for beta testing.

HDMA timing or CPU revision issue. I'm on hiatus at the moment, I'll work on it later. For now, you can minimize the impact by raising ppu.hack.render_scanline_position to 1110.

[Baron_Samedi]

oki thx

i'll try that


btw i have a question about bsnes
its 1 year ago since i made the snes emu test for aep
except bsnes there seems to be only little progress with snes emus



how about savestats for bsnes ?
i read that this is impossible hope this will change in the future
many games have build in save options but to save at anytime would be great

if u leave bsnes during play bsnes is paused, may be now its possible to save the memory bsnes uses to save the game...)


is there a progress about other hardware like mouse and other chips like sa-1 and fx ?


thx

[tetsuo55]

if u leave bsnes during play bsnes is paused, may be now its possible to save the memory bsnes uses to save the game...)

He actually has as point. A FULL memory dump during paused emulation. So the savestate is 40MB who cares.

[Baron_Samedi]

hmm i think that 40 mb would be ok

better than a full memory with 1, 2 or 4 GB


i remember that in the past there was a tool to save the complete memory
but this way of saving was very unstable for the os

the environment must be exaclty the same

means the same programms needs to be open and have to be on the same position even the mouse cursor
and system time etc.


if u save the complete memory on Thu Sep 04, 2008 6:52
and load it on
Thu Sep 04, 2008 6:57


for the system no time has gone but in reality 5 minutes are gone
and now the system "thinks"
"1 ms ago it was 6:52 now its 6:57
this is impossible" and the os will crash because it gets "dazed"



i mean save the complete memory and load it again will
cause major probs and unstability for the os
but save only the bsnes part in memory and load it again shouldn't make too many probs

[ZH/Franky]

if u leave bsnes during play bsnes is paused, may be now its possible to save the memory bsnes uses to save the game...)

He actually has as point. A FULL memory dump during paused emulation. So the savestate is 40MB who cares.

As much as 40MB is quite large (if you're talking about save states), at least it would maybe allow for savestates in the first place. Also, I imagine most people have at least an 80GB harddrive nowadays, so a few 40mb save states won't hurt.

[Verdauga Greeneyes]

I was wondering if you could perhaps have 'transient' save states that would be kept in RAM and hence only work until you close bsnes. Then a memory dump type thing for when you do need to close bsnes.

Of course neither would help if you want to keep your save states for a new version of bsnes, but that's only a minor loss in my opinion.

[Rhapsody]

As much as 40MB is quite large (if you're talking about save states), at least it would maybe allow for savestates in the first place. Also, I imagine most people have at least an 80GB harddrive nowadays, so a few 40mb save states won't hurt.

I've got bsnes on a 1TB drive here (that's only about 13% full), so that's not even slightly problematic to me.

However, it's been said that save states are impossible due to libco for a while, but why is this? I don't really understand what libco is or why it means save states are impossible. I've just taken for granted that this is true and tried to make my gaming skills better to compensate.

[I.S.T.]

libco is a library byuu developed to help him with bsnes. It's an unusual multi-threaded(Kinda...) library that makes it easier for him to emulate the timing in the SNES. Unfortunately, it has the side effect of making save states damn near impossible to do, if not 100% impossible.

Edit: Note that my explanation is more than a little over-simplified.

[byuu]

Thanks again for the bug report, I've fixed Star Ocean now.

Code: Select all

DMAstate legend:
0 = Inactive
1 = Run
2 = CPUsync

* HDMA run @  94,1120
* HDMA @  95,1106 - 4 [DMAstate=0]
* HDMA run @  95,1116
* HDMA @  96,1108 - 4 [DMAstate=0]
* HDMA run @  96,1120
* HDMA @  97,1108 - 4 [DMAstate=1]
* HDMA run @  97,1116
* HDMA @  98,1104 - 4 [DMAstate=2]
* HDMA @  99,1108 - 4 [DMAstate=2]
* HDMA @ 100,1104 - 4 [DMAstate=2]
* HDMA @ 101,1108 - 4 [DMAstate=2]
* HDMA run @ 101,1348
* HDMA @ 102,1104 - 4 [DMAstate=0]
* HDMA run @ 102,1112
* HDMA @ 103,1108 - 4 [DMAstate=0]
* HDMA run @ 103,1116
* HDMA @ 104,1104 - 4 [DMAstate=0]
* HDMA run @ 104,1120
* HDMA @ 105,1106 - 4 [DMAstate=0]
* HDMA run @ 105,1116

Code: Select all

if(status.dma_state == DMA_Run) {
  ...
  hdma_run();
}

You'll notice that lines 98-100 miss HDMA, because a DMA just ended before they began.

It seems this game is quite dangerous, very nearly hitting the CPU DMA<>HDMA conflict bug.

The fix is to change the code to:

Code: Select all

if(status.dma_state != DMA_Inactive) {

That way the HDMA will always occur.

is there a progress about other hardware like mouse and other chips like sa-1 and fx ?

Nope, same old story. Too complex and too resource intensive. Sorry.

----------

I'll make a post in the next few days explaining why I can't add savestates to the main bsnes thread FitzRoy is maintaining.

[Verdauga Greeneyes]

There have been long discussions about this, but let me see if I can remember the gist of it.

First of all, libco is the multithreading library bsnes uses to emulate all the components of the SNES as separate entities. By doing this he can easily switch between threads when needed to keep the components in sync with each other, rather than interweaving them all into a massive state machine, as this would be very hard to read and almost impossible to track bugs in (zsnes et al don't sync as often as bsnes does, so it's less of a problem for them, but accuracy suffers). You can find a better explanation on byuu's homepage.

Because of this, all the threads will be in various states of execution at all times with none of them 'finished', and there's no easy way to get them all to a point where you can just newly create them and start afresh (with the old variable values), as you would with savestates. There's also no real way to store the states of the threads so that they could continue where they left off.

Allthough various schemes have been suggested to implement savestates in some form they were all very hard to implement, with no guarantee of success, and they all had the disadvantage of the savestates being broken whenever a new version of bsnes comes out. For this reason, although it may not be impossible, byuu hasn't really had the time or motivation to work on implementing savestates.

Did I miss anything?

(wew, i was working on that post a long time )

[byuu]

Pretty much correct. I'll still address it more in time.

Okay, I found it hard to believe SO was hitting the CPU DMA<>HDMA bug, as it doesn't freeze on hardware, so I ran some more tests.

Code: Select all

* DMA begin @ 235, 152
* DMA end @ 235, 168
* DMA begin @  60,1216
* HDMA block @  62,1104
* HDMA block @  63,1108
* HDMA block @  64,1104
* HDMA block @  65,1108
* DMA end @  65,1316

Very interesting. I completely understand what's happening now.

Basically, DMA starts at V=60, and changes DMA state from 'Inactive' to 'Run'. HDMA then triggers on line 61, and when it completes it changes the state to 'CPUsync', and then DMA continues to run. The next time HDMA is triggered, it's still set to CPUsync, because it cannot transition back to Inactive until another CPU opcode cycle begins. So it then ignores all further HDMA transfers until after DMA completes.

Tricky stuff. The best course of action seems to be to have HDMA check to see if DMA is still active, and if so, stop it from setting DMA state to CPUsync.

I really dodged a bullet with this bug. I was afraid it was due to the HDMA timing changes, and I have no way of running tests on real hardware, due to the S-DD1.

Now, what to do about the bugfix? This edge case should not occur very frequently. Maybe in Bugs Buggy and/or Marko's Magic Football. But Star Ocean is a pretty big title. Should I release a new version with just this fix, after we test it?

[FitzRoy]

Did you test Mario Kart and see if it, by chance, fixed the map bug in that as well? I was actually going to PM you about that...

The screenshot as advertised on your website does not reflect what it looks like in the emulator right now.

[Verdauga Greeneyes]

Could the following change make it into the next WIP/release? We never really discussed this, as I was waiting for Fitzroy's suggestion thread, but this drop-in replacement makes it so that when a scaling factor is selected that's bigger than the window/screen resolution in the x or the y direction, it takes the largest floating point multiplier that preserves the correct aspect ratio instead (like using Stretch in my build).

in event.cpp's update_video_settings(), replace the video_settings.mode switch/case with:

Code: Select all

  switch(video_settings.mode) { default:
    case 0: { //windowed
      window_main.unfullscreen();
      //try and clamp windows larger than the screen to the screen size.
      //note that since APIs such as X11 lack the ability to get the full window size
      //(with border, etc), this can never be a perfect fit to the screen.
      int view_width  = hiro().screen_width();
      int view_height = hiro().screen_height();
      if(width > view_width || height > view_height)
      { double ratio = max((double)width  / (double)view_width,
                           (double)height / (double)view_height);
        width  = width  / ratio + 0.5;
        height = height / ratio + 0.5;
      }
      window_main.resize(width, height);
      window_main.move(window_main.view, 0, 0);
      window_main.view.resize(width, height);
    } break;

    case 1: { //fullscreen
      window_main.fullscreen();
      int view_width  = window_main.get_width();
      int view_height = window_main.get_height();
      if(width > view_width || height > view_height)
      { double ratio = max((double)width  / (double)view_width,
                           (double)height / (double)view_height);
        width  = width  / ratio + 0.5;
        height = height / ratio + 0.5;
      }
      window_main.move(window_main.view,
        //center view inside window
        (view_width  - width)  / 2,
        (view_height - height) / 2
      );
      window_main.view.resize(width, height);
    } break;
  }

Edit: added code for windowed mode, for consistency..

[Baron_Samedi]

"Should I release a new version with just this fix, after we test it?"


if u ask me

yes

star ocean is my fav. snes game
too bad that is was only released in japan
and developers had to hurry to finish it
hoped for a happy end between marvel and joshua....


hmm is it difficult to make a translation of a snes rom ?
i was thinking of making a german version of it....





is there a progress about other hardware like mouse and other chips like sa-1 and fx ?

"Nope, same old story. Too complex and too resource intensive. Sorry. "


hmmm and if u look at zsnes and snes9x how they handle these chips
even if they use tricks to make the roms playable



bsnes is the best snes emu but support of special chips/games/hardware is not the
big strength of it




btw on your hp there is a screen of SD Gundam GX
game is not playable
crashes when the red cpu moves its units
may be dsp-3 emulation is not 100% or there is no good rom dump out there....




i wonder if nintendo looked at your source code before programming there virtual console snes emulator



i dont have a wii
but are there fx or sa-1 games available for it ?
by disassemble wiis virtual console ......
just an idea

i mean not copy the code.... just look at it how big n emulates the games, may be this will bring new ideas.....

[mudlord]

"Should I release a new version with just this fix, after we test it?"


if u ask me

yes

Byuu's license prohibits that. I wanted to do a mod for BSNES that added HLSL/GLSL shaders, but the BRL prohibits forking....

So, all you can really do is let byuu review the code.