Not even MAMEDev. Haze.MAMEdev angry at a fork. News at 11.
Not even MAMEDev. Haze.MAMEdev angry at a fork. News at 11.
No it's not...
I don't mind people using other emulators but coming over to say "hey your stuff is broken gonna use something else"
I find this particularly annoying, we try our best to keep features working and stable, and I personally try to help everyone I can manage to help.
Edit: https://wiki.libretro.com/index.php?title=Beetle/Mednafen_PSX
https://github.com/libretro/RetroArch/issues/5254
Also, I'm not going to be making a m3u of what I'm trying to play. It's the beatmania games and you have to do different disc swapping paths to reach different songs on the discs. Creating a m3u for each specific game and each song selection process would be a nightmare rather than just being able to swap the discs easily.
Update to the latest nightly
I'm really hoping the issue with multidisc PBPs in Beetle-PSX gets fixed. Currently, you can't load a save state from Disc 2+ in a PBP, as Beetle loses track of what disc the game is on and softlocks the next time it tries to load data. PBPs are cool (FF8 goes from 9 files, including the M3U, to one PBP) but they are also useless for multidisc games, currently.
I wonder if the recent CHD support for Saturn-PSX will help.
m3u method it working fine for me, I just tested, I made a m3u for mgs with the discs swapped for testing purposes (2 first 1 last), started new game, it asked me to swap disc, swapped fine.
Also made a savestate on the title screen and when I finally had control of snake, tried to load those once in the other disk and it changes the disk index properly so it shouldn't have issues with save states.
Not sure about pbp, I don't like lossy compression.
What's lossy about pbp? I was under the impression that it's just using gzip to compress sectors...Not sure about pbp, I don't like lossy compression.
Yeah, I thought PSX2PSP PBP conversions were lossless. I've only heard that official PBPs from PSN could be lossy.What's lossy about pbp? I was under the impression that it's just using gzip to compress sectors...
Mesen is supposed to be the most accurate NES emu right now, but I've never used it, so I'm not sure what's noticeably different from something like Nestopia. Supposedly it's not easy to port to libretro because it's coded in C#. I messed around with the Sameboy core when it first came out. It had worse sound than Gambatte, but was on par graphically. The author updated the sound code when I made an issue report about it, but while it sounded better in the stand alone port, the libretro version didn't seem to change. Sameboy is also much slower than Gambatte, so I don't think it's worth using over that for general use. The code is supposedly very clean, so I guess it's a good documentation project.What's the differences between them? I feel like every week there is a new Gameboy or NES/SNES emulator... it's getting really confusing, and seems more and more like they are not really doing all that much differences other than "Its more accurate" but there doesn't seem to be any info on how exactly it is more accurate or examples of how it is more accurate
this is because somebody has to update the libretro core if there are changes to the stand alone emulator - it's not automatic.I messed around with the Sameboy core when it first came out. It had worse sound than Gambatte, but was on par graphically. The author updated the sound code when I made an issue report about it, but while it sounded better in the stand alone port, the libretro version didn't seem to change.
It's this issue here, I even put a bounty on it a while ago.
What's lossy about pbp? I was under the impression that it's just using gzip to compress sectors...
Yeah, I thought PSX2PSP PBP conversions were lossless. I've only heard that official PBPs from PSN could be lossy.
I tried it after this commit was merged though: https://github.com/libretro/SameBoy/commit/00623d4eea49eb3d8e1e69bf9774b691e9bcd349this is because somebody has to update the libretro core if there are changes to the stand alone emulator - it's not automatic.
Did you build from source or use a release?I tried it after this commit was merged though: https://github.com/libretro/SameBoy/commit/00623d4eea49eb3d8e1e69bf9774b691e9bcd349
Yes but as I said, the M3U method is working fine
.
I probably just grabbed a nightly off the buildbot. I generally make sure the build time stamp is after a commit I'm looking to try out, but I could have missed it.Did you build from source or use a release?
Try the shaders inside 'crt' and 'denoisers' folders (the latter is particularly good for 32bit games). In 'crt' folder, the most known are: geom, easymode, hyllian, hyllian-glow, aperture, lottes and royale. Royale shines in 4K.
Unfortunately I don't use Royale, so I don't know its parameters to help you. The other crt shaders are brighter than Royale at not so high resolutions. Try them and tell what you think.Yeah I'm using Royale right now and it looks great already at 1080p, any way to get it a tiny bit brighter though? And alright thanks, I'll play around with the others.
CRT-Easymode-Halation is the best for maintaining brightness. It was designed for 1080p as well, whereas Royal is supposed to shine more at 4k.Yeah I'm using Royale right now and it looks great already at 1080p, any way to get it a tiny bit brighter though? And alright thanks, I'll play around with the others.
Unfortunately I don't use Royale, so I don't know its parameters to help you. The other crt shaders are brighter than Royale at not so high resolutions. Try them and tell what you think.
There's not much you can do about the image darkening when you add scanlines other than turn up your display's backlight/contrast control.
Some shaders adjust the gamma to "brighten" the image but that just messes up the colors. Even the default settings for Royale do that.
CRT-Easymode-Halation is the best for maintaining brightness. It was designed for 1080p as well, whereas Royal is supposed to shine more at 4k.
CRT-Easymode-Halation was a bit too bright and bloomy for me.
Just FYI, there are options for both reducing the bloom and scanline strength.
I've only noticed the morph ball in Metroid looking squished at 1:1, so I just use that. Everything else has perfect squares and circles at pixel aspect. Well, I'm sure there are other examples of NES stuff corrected for 4:3, but none I can think of. Funny that the morph ball looks round at pixel aspect in Super Metroid.1:1 often times results in things looking "squished" vertically and circles aren't circles.
The problem is a lot of old systems (NES, SNES, Master System, Game Gear, GBA all jump to mind) had rectangular pixels and these days we have square pixels. So CRT or original device is the best way to go.Is there any sensible article discussing what the correct aspect ratio to display various systems is?
I guess my main focus is the NES. 256x240
https://www.gamasutra.com/blogs/Fel...idescreen_Tips_on_correcting_aspect_ratio.phpIs there any sensible article discussing what the correct aspect ratio to display various systems is?
I guess my main focus is the NES. 256x240
So we can integer scale to:
1:1 often times results in things looking "squished" vertically and circles aren't circles.
(3:3 768x720)
4:3 is what I understand CRT to be so you would think everything is intended to display at that ratio but I don't think that is right either. Seems wide.
(1024x720)
These are based on my observations with the NES Classic and the two modes provided.
If we go the retroarch route on my 1080p display:
My options:
4.5:4.5 (1152x1080) (non-integer, skinny look, shimmering effects)
6:4.5 (1536x1080) (non-integer, fat look, shimmering effects)
5:4 (1280x960) (integer boxed resolution)
6:5 (1536x1200) (integer full screen! but note the 24 vertical pixels lost)
I think this is because a CRT doesn't really have fixed pixels and using a fixed pixel display forces a perfect square. CRT didn't use perfect squares, but using the fuzzy upscale results in some rounding issues causing uneven pixel sizes.
What is the magic bullet to get razor sharp pixels and round circles?
If you're trying on a modern LCD you're best sticking with slightly squished, as running it at the correct aspect ratio will introduce scaling which will mean blurring and the picture will still be less then perfect but in a different way.
I've found that running RA with 4K output on my 4K TV really helps make scaling issues less noticeable. When I was on 1080p I always had to use integer scaling because the artifacts were just too ugly but at 4K I will fill screen while maintaining aspect ratio and it usually doesn't bother me. Scanlines work better too.
Depending on how the art is drawn, you either use 1:1 pixel aspect ratio or 4:3. Whichever looks correct.Is there any sensible article discussing what the correct aspect ratio to display various systems is?
I guess my main focus is the NES. 256x240
[...]
I think this is because a CRT doesn't really have fixed pixels and using a fixed pixel display forces a perfect square. CRT didn't use perfect squares, but using the fuzzy upscale results in some rounding issues causing uneven pixel sizes.
What is the magic bullet to get razor sharp pixels and round circles?