You are not logged in.

Read the FAQ and Knowledge Base before posting.
WiFi not emulated and not supported!!
We won't make a 3DS/2DS emulator.

#1 Re: General » Update Link in Build Guide to VS2015? » 2018-06-30 20:32:04

zeromus wrote:

this is why i hate documentation. more documentation is better? no, more documentation is out of date. it's technical debt. BLAHHHHHHHH

Probably doesn't matter but is there any reason to maintain that you can download the current source by selecting download snapshot on sourceforge?
Since you can link directly it could be changed from this:

wiki wrote:

Go to and select “Download Snapshot”. Due to sourceforge sucking, this may take 1 million years and never finish successfully.

to something like:

Download it here

That would make the "Download it and" part of the next line redundant so it can be removed.

wiki wrote:

Download it and open with your archive manager (if you haven’t one, I suggest 7zip at

And this line can be removed entirely.

wiki wrote:

Inside there is another one archive, open it and you’ll see the source code.

....And maybe change the last line to something more straightforward along the lines of:

The main advantage here is you don’t need the Git client, the disadvantage is that when changes are made to the project you have no way to download only those files which have been updated and must instead redownload the code in its entirety.

#2 Re: General » Update Link in Build Guide to VS2015? » 2018-06-30 10:20:02

zeromus wrote:


BTW, just noticed that it still tells you to grab the source off of sourceforge.

#3 General » Update Link in Build Guide to VS2015? » 2018-06-30 06:27:47

Replies: 5

I'm guessing the page linked in this guide

has since been updated as there doesn't appear to be any way to download VS2015 there. 
At the very bottom there is a link to this page

which does list VS2015 as an available download, however, AFAIK before you can download VS2015 from there you need to join their free Visual Studio Dev Essentials thing. 
Alternatively a user by the name of Nasreddine on stackoverflow seems to have found some direct links.

That's about it. Figure it might be helpful to either change the link to the vs/older-downloads page with some mention of this Dev Essentials thing or change it to the direct links on the stackoverflow page.

#5 Re: Technical » seamless AVI files for x64 builds » 2018-03-01 12:58:23

zeromus wrote:

Or find any opensource program whatsoever that can dump > 2GB avis.

What about PCSX2? *He asked nervously.*

#6 Re: Support » zeromus i am not using magnification filters nor do i intend to » 2017-10-17 19:02:08

zeromus wrote:

DeSmuME_git#73b5074_x64.exe on i7-4790K (but I just remembered, I have overclocked so it runs all cores at 4.7GHZ instead of 4.00GHZ with one core boost to 4.4GHZ... so my 75% figure earlier was not accurate.. should be more like 70% or something, I'm not sure).

Going by firestrike physics score it should be something like 55%, that is if you don't take your overclock into consideration; the 4790K gets ~12200 while the 7300HQ gets ~6800. It's probably closer to 50% with the overclock.

#7 Re: Support » Screen shots broken in 18 & 24 bit color mode » 2017-10-15 20:20:01

The quick screenshot feature works normally so unless there's some difference between them that I'm not aware of you should be able to use it instead.

#8 Re: Support » OpenGL rendering regressions in Mega Man ZX Advent » 2017-10-14 05:09:08

rogerman wrote:

Regression #1 has been fixed as of commit git#73b5074, which brings back support for transparent polygon IDs in the OpenGL renderer, thus bringing back order-independent transparency. This fixes those graphical glitches in Mega Man ZX Advent.

This fix will require quite a bit of testing, since OpenGL's transparent polygon ID support works differently than that of SoftRasterizer's. Specifically, SoftRasterizer uses two separate buffers for recording the opaque and transparent polygon IDs. However, OpenGL uses only a single buffer to record the polygon ID of the last polygon drawn, and then uses a single bit flag to designate whether the polygon ID of the drawn fragments should be treated as opaque or translucent.

But... of the many many many games I have tried so far, OpenGL does seem to produce the same results as SoftRasterizer... so far.

That's awesome!

#9 Re: Support » beyond x5 resolution might still need some work? » 2017-10-14 03:58:42

fintogive wrote:

just tried build and tried to run it at x6 res and it wont do any thing when ok is clicked  this is with a nvidia gtx 640 and an amd 8370 fx cpu on both open gl 3.2 and softraserizers. now when i go to anything higher it crashes.

i also tried it on my super computer with a 6900k intel cpu with a gtx 980 ti.  switching resolution in game works up to x6  any higher crashes the emulator again.

now if i change the resolution before i start a rom i can get it to work on x7 resolution's.

one other note if i try to dump avi wile on x6 the desmume screen freezes but i still have audio and the game is still running.

Try a 64-bit nightly build, they appear to be more stable at higher resolutions.

I can record at x16.

#10 Re: Support » Transparancey or layer error on openGL & Screenshot crash » 2017-10-06 18:33:47

zeromus wrote:

They have nothing to do with one another, except that they can both cause things to get rendered in the wrong order.

Got it, thanks.

#11 Re: Support » Transparancey or layer error on openGL & Screenshot crash » 2017-10-06 16:00:33

fintogive wrote:

Well could it be improved to be exact?  it works fine with softrasterizer but not open gl. but open gl is generally faster than softrasterizer I know im not a programmer but it looks like the layers just need to be reordered for the textures to look correct.  I know rogerman has been cranking out updates on improvements to the GFX engine. so could this be added to the list?

Error example.

I never saw the original image from your OP in 2016 which zeromus said was an issue with fine z ordering........
As for this new image where you showed the sea and floor being rendered incorrectly in MKDS, it was working fine up until r5372 as far as I can tell. That was the commit where order independent transparency broke.

Rogerman made a detailed reply in my thread about order independent transparency.

Interested to know if fine z ordering/sorting is the same thing as order independent transparency or if it's something sounds similar

#12 Re: Support » OpenGL rendering regressions in Mega Man ZX Advent » 2017-09-25 02:38:43

rogerman wrote:

As for the "comprehensive list of things that need to be fixed and/or features that need to be implemented before the next stable release", there is no actual list for this. But if I were to think of some things that HAVE to be done off the top of my head, it would be these things:

1. Core - As mentioned before, translucent polygon IDs really need to be supported in the OpenGL renderer. Testing and user reports are revealing that there are too many games affected by not supporting this.
2. Core - We need much additional testing on the effects of zeromus' matrix stack and geometry power register rework. In addition, there is currently a regression that needs to be fixed that is related to this rework.
3. Windows Port - In commit e6d5a8f, we increased the maximum GPU scaling factor from 5x to 16x. Much additional testing needs to be done to determine if we can keep 16x or if we have to revert back to 5x. This will be dependent on the number of difficult-to-fix bugs in relation to this.
4. Linux (GTK) Port - For some unknown reason, the GTK build crashes on startup. However, the Glade build works just fine. I haven't actually researched why the GTK port crashes, but it's probably due to some of the recent commits to the GTK port.
5. Cocoa Port - I want to rework Copy to Clipboard and Screenshot to File operations in the Cocoa port to take advantage of the newest tech that I've recently added. This is more of an icing-on-the-cake feature than anything else, but it is something I've really wanted to do for a while now, and I would feel bad if the v0.9.12 release didn't include the newest tech for these operations.

And that's it. I don't know if zeromus would want to add anything to this list, but these are the most important things I could think of that is blocking the v0.9.12 release.

Thanks, I actually expected the list to be a lot longer; not to make light of how difficult or time consuming it will probably be to work everything out but this makes it seem like 0.9.12 is actually happening.

Edit: I apologize for my sarcasm which brought on the weird troll, it was not my intent.
I've edited this post to remove the joke which was included below.

#13 Re: Support » OpenGL rendering regressions in Mega Man ZX Advent » 2017-09-24 04:55:30

I just tried 70c69a4 and can confirm that it fixed the issue during the first scene in Grey's story.

No new issues as far as I can tell.

#14 Re: Support » OpenGL rendering regressions in Mega Man ZX Advent » 2017-09-24 00:11:38

rogerman wrote:

mgitkun, thank you for your research and the efforts that you put into your bug reports. Good bug reports are quite rare from users, and I want you to know that your bug reports are very much appreciated!

With all that said, Regression #2 has been fixed in commit 1742114. Try that.

Glad to help.

I tried the new build and like you said it fixed regression #2.
Apart from that it also fixed a similar issue in an earlier part of the level where the windowpane appeared in the foreground and obscured sprites (enemies' upper bodies were entirely obscured while the sprite of the main character was visible through the window).
gif 1

There does seem to be a new issue though. The sprite of the main character (the guy in the pod), which should appear in the background, now appears in the foreground.
gif 2
This scene is at the very start of that same level.

rogerman wrote:

Regression #1 is related to issues #74 and #24. The NDS 3D renderer uses polygon IDs on transparent polygons in order to support a form of order-independent transparency. This is yet another case that demonstrates how DeSmuME's OpenGL 3D renderer doesn't support transparent polygon IDs. Coincidentally, this support was broken in r5372 when I made the decision to properly emulate shadow polygons, although this done by sacrificing an (at the time) imperfect transparent polygon ID implementation.

Of course, this is a very difficult problem to solve, and it really is the biggest regression that is holding up the entire v0.9.12 release. The problem is that the OpenGL renderer uses the stencil buffer to support shadow polygons or transparent polygon IDs. Unfortunately, the stencil buffer is incapable of emulating both features at the same time. Even worse, OpenGL can only use one stencil buffer at any given time. This situation creates a dilemma in which one must decide which feature do you emulate with OpenGL's single stencil buffer.


With the recent rework in the OpenGL renderer to separate opaque polygon rendering and transparent polygon rendering into two separate steps, there is now hope that transparent polygon IDs can be emulated without sacrificing proper shadow polygon support. In fact, I'm glad Regression #2 came up, because it is directly related to that rework.

I vaguely recall seeing those tickets at some point and with your explanation it makes sense how they're all related.
The funny part is that I searched for issues with 2f473cd but despite having included the previous naming scheme in the post it somehow didn't occur to me to search for it as r5372 on github, haha. Brainfart lol

Is there an actual comprehensive list of things that need to be fixed and/or features that need to be implemented before the next stable release?

#15 Support » OpenGL rendering regressions in Mega Man ZX Advent » 2017-09-22 04:04:49

Replies: 8

For both of the issues below I'll include a video and gif that show (from left to right) the last commit prior to the regression, the commit that introduced the regression, and the current master to show that the issue has not been fixed since then.

Regression 1:

I'll be referencing a number of old commits below, to prevent it from getting too confusing I've included the previous naming scheme so that you can see whether one commit came before or after another commit at a glance.

It seems that commit 2f473cd (r5372) caused certain sprites to be rendered at the wrong depth/order (I think) when using the OpenGL renderer.
The video below shows ZX Advent in 891fd01 (r5371), 2f473cd (r5372), and f521ab1 (master).
gif 1

Video (01:36)

Since every build from commit 760b5a6 (r5259) through 2f473cd (r5372) doesn't display any sprites at all because of an issue from 760b5a6 (r5259) I ended up building 2f473cd (r5372) and several commits leading up to it with the change to MMU.cpp from commit 34ec6bb (r5373) to figure out which commit caused the regression in OpenGL.

As you can see in both 2f473cd (r5372) and f521ab1 (master) the sprites for the robot's hands seem to be hidden behind the sprites for its wrists/arms (the thumbs poke out partially). I would assume that the animations for the eyes and mouth are also being displayed at the wrong depth/order.

Regression 2:

After recording the video for this post I noticed another regression, near the end of the video linked above (not the gif) you see the rays of light and the final explosion clip through the robot in the master build but not in the two older builds.

I checked a number of builds and I found that commit eea54a7 was the one that introduced the clipping issue.
Below is a video of that section in f8ab45f, eea54a7, and f521ab1 (master).

gif 2

Video (00:14)

Sprites are once again not displayed in builds 66b5da1 up until the fix in 759a039. Unlike the issue in the builds involved with regression 1, however, sprites appear once you enter a new stage/zone or die. The robot in the video above is at the end of the first level but has a separate stage/zone, once you load into this stage/zone the sprites appear.

Because the commits shown in the video for regression 1 (891fd01 and 2f473cd) had issues which prevented sprites from being shown altogether their videos had to be recorded on builds that utilized the fix/hack noted above.
The remaining builds shown (f8ab45f, eea54a7, and f521ab1 (master)) were downloaded off of appveyor.

Here are savestates you can use to get to this point in the game. I included two sets, one made on master and one made on 891fd01 (r5371). In each set there's two savestates, one right before the fight with the robot and one just as it's about to die.
There's also a similar DSM in each set that completes the first level entirely. There must be no save file present for it to work.
EDIT: Forgot to mention that I had Advanced Timing enabled and Recompiler disabled, not sure if any other options affect the sync for movies.

I used the NA release of ZX Advent and the area shown in the videos is at the end of the first level in Grey's (one of the two playable characters) story.

If there's any doubt as to what this scene should look like here's a video from GDQ.
The speedrun is on a different difficulty so you won't see a lot of the animations that you do in my gif/video but you do see the robot itself and its death animation.

#16 Re: Support » Sprites not being displayed in certain titles after commit 66b5da1c » 2017-09-22 03:57:32

zeromus wrote:

ok, got all 4 things working at once. thanks for your research.

Thanks for the fix.
With the sprites working I noticed some unrelated regressions with the OpenGL renderer in Mega Man ZX Advent, finishing the post for it now.

Oh, while looking into the OpenGL issues I noticed something about this issue that I hadn't before.
Just to be clear this is about the older builds, before the fix in 759a039e. It's not relevant to the master.

In both games the missing sprites show up after entering a new stage/zone or after reloading/resetting the current stage/zone (by dying).

Like I said it probably doesn't matter since sprites are now working in master but I felt this should be noted anyway.

#17 Support » Sprites not being displayed in certain titles after commit 66b5da1c » 2017-09-15 14:02:17

Replies: 2

Sprites aren't being displayed in certain titles regardless of settings used.
This issue is present in Mega Man ZX Advent (NA) and Doraemon: Nobita to Midori no Kyojinden (JP), there may or may not be other games with this issue but these were the only ones that I could confirm.
I tried these games on the most recent build from appveyor (d33faecd) and this issue is still present.

Went back and tested these games on random builds from appveyor starting with the first build made 7 months ago and found that sprites were working properly through commit 51163c33.
Commit 66b5da1c seems to have been the one that broke sprites for these games.

The screenshots below show sprites working in 51163c33 and then not working in 66b5da1c and d33faecd.

Skimmed through open issues to see if the commit had any other known problems and it seems there's one ticket for a rendering regression in Lack of Disco.

I tried building master with line 2356 changed to TRUE as zeromus said and doing so fixes sprites in both games.
Updated link to line 2356.

#18 Re: Support » Current State of MSAA? » 2017-08-28 21:14:28

rogerman wrote:

In the Cocoa port, if frameskip is disabled, then the overall execution rate will slow down in order to display every single frame. This is true, regardless of hardware used or GPU Scaling Factor used. For example, a Power Mac G5 running 16x will produce and show every single frame if frameskip is disabled, but the overall execution rate will become unbearably slow.

Ah, I think I see the issue on the Windows port now. If frameskip is disabled, then you would expect that every single frame would show, regardless of execution rate. But at the higher scaling factors, frames are still skipped, despite frameskip being disabled. This is clearly a bug in the Windows port.

Good to know that it doesn't happen at very high resolutions on the Cocoa port.

#19 Re: Support » Current State of MSAA? » 2017-08-28 01:41:58

rogerman wrote:

Try commit a05e03e.

Yeah, much better.
The difference is nearly indistinguishable at 3x and 4x now.

a05e03e2 3x
d2b25360 3x

a05e03e2 4x
d2b25360 4x

rogerman wrote:

16x GPU scaling works on all Macs, from the highest-spec iMac w/ Intel i7-7700K all the way down to a Power Mac w/ PowerPC G5. Obviously, the Power Mac will be completely unusable at 16x, but the iMac i7-7700K can run 16x at full speed, albeit with so much frame skip that games become unplayable. I haven't yet seen any PC that can run DeSmuME at 16x at full speed without dropping any frames, but I'm keeping the idea of running 16x at full speed without dropping frames as a sort of performance "holy grail" to reach in the future.

Yeah, that's why I said not at full speed; in other words if you have it set to "0 (never skip)" will it adhere to that setting and actually slow down game speed as it should, and as it does normally, or will it just randomly start skipping because of some shortcoming?

rogerman wrote:

A tip: Don't run magnification filters, like xBRZ or HQnx, while running any resolution above native. It's buggy, it doesn't produce the intended results, and is a complete waste of CPU cycles. In reality, magnification filters should be completely disabled on the Windows port when running non-native resolutions, until the time when the entire video system on Windows can be completely reworked.

Other than just trying every filter out to see what it does I haven't used anything but normal filter since GPU Scaling was introduced and I only use normal filter to smooth out any jagged edges that MSAA may have missed.

rogerman wrote:

Ideally, the two NDS screens should be processed separately. If an NDS screen comes in at the native resolution, then run the magnification filter on it. However, if the NDS screen comes in at a custom resolution, then use the screen as-is without magnification filters. The Cocoa port does this, and it looks something like this:
In this image, the main screen is at the native resolution, and was therefore upscaled using 4xBRZ. The touch screen is at a custom resolution, so 4xBRZ was not used on it.

That's interesting, seems like it'd be very useful for games that put 2d sprites or graphics that don't benefit much from scaling on one screen and 3d on the other.

#20 Re: Support » Current State of MSAA? » 2017-08-27 08:12:52

rogerman wrote:

You are misunderstanding a bunch of things here.
1. The MSAA sample size and the GPU Scaling Factor are two separate things and are completely independent of one another.
2. The MSAA sample size is automatically set, and is limited by both your GPU's capabilities and the internal limit that DeSmuME uses. For example, your Nvidia GeForce GTX 480 has a GL_MAX_SAMPLE_SIZE of 32. This means that DeSmuME's internal MSAA limit will limit you, not your GPU. However, if your GPU only supported 2xMSAA, then the GPU is what would limit you, not DeSmuME.
3. If the emulator hangs at 6x scaling, then that is most likely a problem with the Windows port and not the core graphics code. The Cocoa port can run with up to a 16x GPU Scaling Factor without any crashing.

1. I understand that.
2. I realize that it can't go higher magically because DeSmuME tells it to, I just didn't know that the maximum sample size was 32.
3. That's interesting, how does it run?
I mean in the sense that on the Windows port when running BRZ or HQ4x filters in combination with 3x+ GPU Scaling factor it starts frame skipping...with frame skipping disabled. But it technically runs.
That's just a comparison, I've read your replies about performance with filters and scaling being more so an issue for the Windows port , I'm just asking if anything funky happens when using 16x GPU Scaling on the Cocoa Port.
Does 16x GPU Scaling on the Cocoa port run like that or does it actually run without dropping frames (obviously not at full speed)

Oh and I tried 2379dc1e, oddly enough I can go up to 7x now with everything enabled whereas on e6d5a8fb I couldn't do 7x even with everything including MSAA disabled.

rogerman wrote:

Try commit 2379dc1. I've implemented the new limits I mentioned, except now they are as follows:
1x Native Resolution - 32xMSAA
2x Native Resolution - 16xMSAA
3x-8x Native Resolution - 8xMSAA
9x and greater Native Resolution - 4xMSAA

And no, I don't see any need to add a user-defined setting for the MSAA sample size. There is no need, especially now with the tiered MSAA limits. The performance problems from MSAA are due to MSAA consuming too much GPU memory bandwidth. At smaller resolutions, this is not a problem, since smaller resolutions consume less bandwidth. But higher resolutions consume more bandwidth, and MSAA multiplies this bandwidth cost. With the tiered MSAA limits, we keep the bandwidth usage more balanced.

Oh well.....that's a shame, either way this is definitely better than it was before for 2x.

Here's the same frame with the new build
2379dc1e 2x
d2b25360 2x

It still has very minor differences but nothing that should be noticeable when not comparing them side by side.

You might want to consider bumping 3-4x GPU Scaling to tier 2 as well, 5x scaling is probably fine at tier 3......
2379dc1e 3x
d2b25360 3x

2379dc1e 4x
d2b25360 4x

2379dc1e 5x
d2b25360 5x

#21 Re: Support » Current State of MSAA? » 2017-08-27 05:49:20

rogerman wrote:

8xMSAA is considered a lot of smoothing, so I'm frankly shocked to see such a massive difference.

What kind of GPU are you using? I have a feeling that your GPU supports something like 32xMSAA, so that would be a difference with 8xMSAA. Alright, I'll look at increasing the MSAA cap at the lower resolutions, which need MSAA the most. I'm thinking about capping MSAA at these values:

I'm using pretty dated hardware (2500K and GTX 480) relatively speaking, it shouldn't support MSAA higher than 8x.....unless you mean CSAA.

1x Native Resolution - 32xMSAA
2x Native Resolution - 16xMSAA
3x-4x Native Resolution - 8xMSAA
5x and greater Native Resolution - 4xMSAA

No warning/disclaimer needs to be provided. Gamers should know what MSAA does and the performance hit that will result from enabling it. And even if people don't know beforehand what MSAA does, the effects should be immediate and allow users to instantly make a judgement call whether to keep it enabled or not. Finally, MSAA only becomes a performance issue at the higher resolutions only. However, higher resolutions also mitigate the need for MSAA anyways.

Is there any chance of leaving some setting in some form, maybe not even exposed in the GUI, that lets you choose, just to have that option so that if you're recording gameplay from a DSM and not actually playing you can have it entirely smooth.
I can't go past 6x scaling without the emulator hanging and at 6x scaling there's still some minor aliasing with the current level of MSAA that wouldn't be there with the previous level of MSAA..... sad

#22 Re: Support » Current State of MSAA? » 2017-08-27 04:36:56

rogerman wrote:

Now that I look closer at the images you posted, it looks less like an MSAA difference, and more like you have Texture Smoothing enabled in the first image, and Texture Smoothing disabled in the second image.

Ensure that the Texture Smoothing option is exactly the same for your MSAA comparisons, and try again.

I thought so too and double checked before posting.
Here's MSAA + Texture Smoothing for both:

e6d5a8fb MSAA + Texture Smoothing
d2b25360 MSAA + Texture Smoothing

Texture Smoothing picks up most of the slack at lower resolutions, but there is still a difference...whatever it is.
To better illustrate that difference here's 2x gpu scaling with MSAA, Texture Smoothing, 24 bit color depth, Texture Deposterization enabled, 4x Texture Scaling, Display Method Filter Enabled, and Filter set to Normal.

e6d5a8fb 2x
d2b25360 2x

rogerman wrote:

MSAA was supposed to be limited to 8xMSAA as of commit f50f9d3, but there was a bug that caused MSAA to always be set to the max supported by the GPU. In commit 3b354a0, there was an undocumented bug fix that limited MSAA to 8xMSAA as originally intended. This may be the difference that you're seeing here.

Ah, okay; that seems like what I'm seeing.

rogerman wrote:

To note, there are no plans for supporting user-defined MSAA sample sizes. MSAA itself is kind of a hack as it, and setting MSAA to very high sample sizes causes massive slowdowns at higher resolutions. The 8x limit was chosen at the time as the best compromise between visual quality and performance.

Is there any particular reason that you couldn't just add a warning/disclaimer like you did with Advanced Bus Timing, JIT, and ROM Loading, or is it just that you would prefer not to?

#23 Support » Current State of MSAA? » 2017-08-27 01:07:29

Replies: 13

Since commit 3b354a00 MSAA no longer smooths out the scene as effectively as it previously did; it's still doing something...just not as much. I thought that it might be fixed by commit 6acf7818 but it wasn't.
As of commit e6d5a8fb there's been no change in this regard.

Just wondering whether this is a known issue that will be fixed eventually or if the previous behavior of MSAA was "incorrect" and it is now working as intended.

d2b25360 - MSAA ON
e6d5a8fb - MSAA ON

Here are the settings used, builds were downloaded off of the appveyor page.

#24 Re: Support » Flickering in 358/2 Days when rendering on both screens » 2017-08-15 09:38:03

rogerman wrote:

Fixed in commit 7487bf2.

Wow, that was fast...I guess when you said it would be the first step you meant it literally haha.
Thanks for the fix, I checked and it works as it should now.

Oh and thanks for the explanation on what was causing it, always appreciate some insight into what was actually going wrong.

#25 Support » Flickering in 358/2 Days when rendering on both screens » 2017-08-13 13:43:00

Replies: 3

I tested this on build 9a5e52a7 with these settings. I also tried other renderers, other display methods, and disabling game hacks, all of which had no notable impact.

In Kingdom Hearts 358/2 Days it seems that during scenes where the game is rendering 3D objects on both displays the top display will flicker.
The top display flickers during these scenes only when using 24 bit color depth (when using either 15 or 18 bit color there's no flickering) or when GPU scaling is greater than 1x.
I'm not sure that rendering on both screens is the reason for the flickering but I've yet to see this happen under any other conditions. 

I thought it was a little weird that the top screen continued to flicker even after the scene which was using the bottom display ended and the bottom screen no longer had anything on it, I tried hiding the Sub Layers to see if it did anything about the flickering. It didn't. Hiding Main BG 0 on the other hand showed that while the scene on the bottom screen was hidden it may not have ended, as far as I can tell it was still being rendered.....not sure if that's related or if it's supposed to remain, I just found it a bit strange so I thought I should include it here. It's entirely possible I misunderstood what was happening.

Recording of this scene with 18 bit, 24 bit, and 24 bit with main BG 0 disabled.       

Here's a savestate and save file for the US release of Days (NTR-YKGE-USA) so that you can reproduce the issue if needed.

Board footer

Powered by FluxBB