I’m not sure but I think that’s not enough.
My assumption is that if it was this simple some emulators would have done it. 
I don’t know how it works on a TV and I just see what people say in that thread I mentioned (which seems a bit confusing between resolution and overscan).
1 thing I noticed concerning overscan is a Mednafen “issue” (or choice? idk). Games in 336x224 like r-type (hope that’s the real resolution, I see different informations) are cropped in their width if you compare them with Magic Engine.
I tried to confirm it with Chris Covell’s screen dimension test: it gives me 341 pixels width in Mednafen/Retroarch vs 352 on Magic Engine.
Don’t know if you saw it but what I pulled has been merged. Here the details.
Some differences with what you’ve done in your fork: I pushed the scanline end to 242 I made 3 the default scanline start (and reordered the slend choices, more intuitive in RGUI) that’s related to the revert in vdc.cpp (changed VDS -4 to 0 as it was from mednafen, while you keep -1)
Your use of FB_HEIGHT is cleaner than my “243” (line 1327 in my commit) but you kept FB_HEIGHT - 1 because of the VDS -1 above I guess. I did many trials and chose 242 slend in mednafen settings for 243 FB_HEIGHT to get the maximal lines range, hope that’s good. (I think it’s an issue from mednafen, they lose 1 pixel at the top in addition to the 3 black lines. That’s why I used FB 243 and they use 242 but in the end all lines are displayed. But I decided to leave it like it is on the mednafen side and change the libretro.cpp part. Should have mentioned it in comment near the FB code as a reminder in case they fix it later)
So perhaps you can just change my commit around to make it cleaner with the FB_HEIGHT and anything I missed, starting from a new fork?
(sorry for the waste of time 
)
FB_HEIGHT - 1 is the last line of the buffer, it has nothing to do with VDS - 1.
The VDS - 1 (I finally saw what you were getting at with you earlier post) , shifts everything up 1 scanline. Now you can see line 239 and no extra line at top.
I don’t like messing with the internals in vdc.cpp but it “works for me”. If you get rid of the VDS - 1 it should duplicate Mednafens output exactly. (At the same scanline starts/ends.)
As far as the making more changes, I don’t want to redo anything at this point.
It would have been better to wait for my rewrite. (why the hurry?)
I had to revert these changes because certain people voiced their disapproval over these changes. And it will be impossible and undesirable to keep making these changes whenever Mednafen’s core updates. And I already have to get around to doing that soon.
We should come up with a proper solution for these usecases where certain emulators decide which scanline to begin rendering and which scanline to end rendering on a canvas/surface - and still do scaling without a full context reset or surface teardown/reinit (which is obviously not acceptable or desired).
I want Themaister at least to address this since it’s currently the source of much consternation and if it is something that can be addressed I’d rather we put in the necessary amount of work to get it out of the way.
Sorry I misunderstood, thought you forked from my changes as I gave the address just before you said you’ll begin your work.
As I tested mine OK I submitted it thinking your changes will go after that.
Alright, you guys know better how to maintain the whole line.
Sorry for hijacking this thread, but what about those two changes?
https://github.com/libretro/mednafen-li … l/52/files https://github.com/libretro/mednafen-li … a5a0e81322
They both only affect libretro.cpp, shouldn’t they be fine to keep?
Sorry for hijacking this thread, but what about those two changes?
https://github.com/libretro/mednafen-li … l/52/files https://github.com/libretro/mednafen-li … a5a0e81322
They both only affect libretro.cpp, shouldn’t they be fine to keep?[/quote]
You can recommit the Core Volume fixes commit.
The latter commit I’m wary of since it affects framebuffer width/height changes.
Done =D
Updated my repo, should be cleaner only 2 files are changed libretro.cpp and mednafen/settings.cpp.
Output should match Mednafen pce_fast.
I found a way to display the full 352 pixels width instead of 341 pce_fast is limited to (in stand-alone mednafen as well). It’s here for anyone who wants that.
[quote=“Tatsuya79”]
I’m not sure but I think that’s not enough.
My assumption is that if it was this simple some emulators would have done it.
I don’t know how it works on a TV and I just see what people say in that thread I mentioned (which seems a bit confusing between resolution and overscan).[/quote]
To come back on this subject, I’ve been trying a lot of games and did some comparison with real hardware on TVs (thanks youtube).
You have the 3 resolution modes and then something indicates the starting and ending lines displayed on a TV.
Some games start a bit up (Dracula X at the extreme top with a huge black bar on bottom, but not on TV), some a bit down, a lot do center their display in the resolution range.
This thread is interesting about the various modes.
So yeah, that’s not just about resolution. Mednafen pce standalone (the most precise one) don’t handle this like a TV, the overscan is the same for every game. I don’t know if any emulator do that? (display exactly like the real hardware on a TV)
And just as a reminder, the Turbo GT didn’t care and displayed the full 240 pixels (or close to that, watching youtube, don’t have mine anymore) vertical overscan. (in a different ratio then)
Tested this on a Wii build but I had to add 352x240/352x480 to the list of resolutions to get it to show right, can this be added to the main source? Even if they stick with 341 there’s no resolution for it. The official Virtual Console version of R-Type just uses 640 wide pixels and filters it btw.
I see at least 1 game (Asuka 120%) that gets black borders on each sides though. This would be better to make it an option but I failed at it!
I tested that game on the Wii and found that it changes resolutions:
The menu uses 352 while the title screen/gameplay is 256, quite annoying. I injected this game into a VC and it ignores 352 and always uses 512x480, so the menu has scrolling artifacts. Perhaps the black bars you see are from forcing the gameplay into 352 wide?
Yes that’s the problem here. But this game is a particular case though. You can see they made a hack just for it in mednafen code.
I tried to tweak it but I’m just a beginner who learned a bit of Java… so I even failed at making a core option for 341/352 switching in libretro, not sure how it works!
And I don’t think it will get pushed to github atm, they want a better dynamic resolution handling first.
Shooters like Final Soldier really take advantage of the full 240 pixels range. Just need to select the 16:15 ratio in retroarch menu. They were stretched horizontally on the pc-engine, some even had an option to put black bars on each side.
Final Soldier
Gunhed
I wonder if the settings are actually working. Something seems strange to me, I could be wrong, if anyone could check:
in mednafen/settings.cpp you have this bool MDFN_GetSettingB function at line 157 From what I understand it should return true/false and not 0/1?