c64 C64 Dreams (massive curated C64 collection)

[Zombeaver]

Mind you, this also depends on whether or not you want to treat pixels as square. I know that they are not on a C64, but the settings I use are based on the premise/executive decision that I think circles should, in fact, be round, regardless of accuracy to original hardware. It just looks better imho. I know this is a source of a great deal of nerd contention lol

[Zombeaver]

28 minutes ago, Pixelpiper said:

Maybe not enough visible overscan though.

You shouldn't need any additional with the exception of (some) of those 25 games, since in the case of a 16:9 display I'm showing even less without issue (again, minus those 25). To be fair, there are some additional instances where something is displayed in the extra overscan space that I've made the executive decision to ignore, like some games have a huge portion of the overscan dedicated to nothing more than the name of the game or some such, but I felt like it wasn't worth losing the extra real estate just to show that. I made adjustments in cases of actually pertinent information for gameplay.

28 minutes ago, Pixelpiper said:

All C64 displays (back in the day) had the overscan border visible

Yep, I'm well aware. I still have mine  (sitting in a closet gathering dust, but still).

28 minutes ago, Pixelpiper said:

every developer used at the very least the entirety of the 320x200 display within it for content

That's not exactly true. There are some instances of games like Ballblazer that do not.

Default (cropped to 320x200 area):

Additional custom cropping:

These instances are, of course, few and far between.

24 minutes ago, Pixelpiper said:

I know a lot of others (including in artwork for games) designed in such a way that the non-square pixels produced the intended results.

Yeah, I understand that. How that actually turns out varies from game to game as you'd expect.

24 minutes ago, Pixelpiper said:

So your very point can come to light when displaying pixels as squares - you'll get Ernie instead of Bert.

Haha, yep, good way to put it

28 minutes ago, Pixelpiper said:

Did you fill the collection with mostly PAL versions of the games?

Where possible and to my knowledge, yes. The two specifically NTSC games are Death Bringer and Masquerade.

[Zombeaver]

59 minutes ago, Pixelpiper said:

Your Donkey Kong (Atari) should also be NTSC.  The Ocean version is PAL.  One of the ones I plan to test out as the NTSC version should run about 20% slower on a PAL system.  Nice to see you grabbed both plus the more recent remake.

Alright, thanks. I changed it, adjusted the crop (for 1080p), and changed the joystick port to 1 (fix).

If you run across any others that you know to specifically need NTSC let me know. I know that all of them work on PAL (other than Death Bringer and Masquerade), but there might be some instances of others like this one that should be set to it for speed reasons (or bugs that I haven't encountered) but I'm not necessarily going to know that beforehand.

EDIT: And just as a heads up the Ocean version is getting replaced by the Remember version in the next update.

[Zombeaver]

18 minutes ago, Pixelpiper said:

Have you found any notable issues running/testing original releases of any/many games?

No, not really, but I don't prioritize those to begin with either to be fair. As you rightly notice I generally prefer the newer groups. As I mentioned in the opening post I have a sortof mental priority chart of groups that I prefer and follow that unless I run into something that forces me to move to something else like TrueDrive requirement which can vary in some cases - Nostalgia is often particularly problematic because they usually use the "NosDOS" system which doesn't play nicely without truedrive emulation. They tend to make some otherwise really good releases but that's kindof a turnoff.

Generally speaking my priority list is something like Remember > Triad > Hokuto Force > Genesis Project > Laxity > Fantastic 4 Cracking Group > Derbyshire Ram > Pugsy > Lurid & Tricycle > Onslaught > Hotline > Nostalgia > Excess > Ikari > whatever else.

So to answer your question, no I haven't, but those aren't where I usually start either. In the cases where I do go with something older they don't typically present any more problems than anything newer (less in the case of Nostalgia).

[Zombeaver]

This morning I updated the core to the newest version after looking through the commit log on github (the previous version used was from 11/20/19). There are a few nice new additions, the most exciting of which (for me) is the addition of a new SID engine - ReSid-3.3. It brings some noticeable audio improvements in certain cases. It's not always a huge difference but in scenarios that make more advanced use of the SID, like in some demos and newer music tracks, it's a pretty nice improvement. I updated all the per-game option files as necessary.

They also fiddled with the palette values quite a bit which makes the default a lot better than it was in the past (though still not quite right without some additional manual intervention imo) but this also made my altered (C64-specific) version of CRT-Easymode-Halation look quite wrong, so I spent some time getting it back to mostly the same final appearance as the previous version. I doubt anyone's really going to notice a difference (but that's the idea).

[Zombeaver]

You might want to check out my shader pack, there may be something in there you like.

I've actually been doing a bit of work today on making adjustments to one of the presets from that called Esper for use with these. Not quite done with it yet but it's getting there.

No shader + new default palette:

crt-Easymode-Halation-C64:

Esper-C64:

No shader + new default palette:

crt-Easymode-Halation-C64:

Esper-C64:

No shader + new default palette:

crt-Easymode-Halation-C64:

Esper-C64:

No shader + new default palette:

crt-Easymode-Halation-C64:

Esper-C64:

No shader + new default palette:

crt-Easymode-Halation-C64:

Esper-C64:

No shader + new default palette:

crt-Easymode-Halation-C64:

Esper-C64:

No shader + new default palette:

crt-Easymode-Halation-C64:

Esper-C64:

[Zombeaver]

Yeah, I've got that on my to-do list for the next update. I did change my password after the last one when someone else mentioned it.

[Zombeaver]

2 hours ago, Pixelpiper said:

Can you offer any advice on getting default-style keyboard navigation working in Retroarch (cursor keys, enter, backspace, esc, etc.) without screwing up the key bindings during emulation? At the moment I can move around with 4568, but have no idea how to use the keyboard to enter nor escape tabs/menus and it's doing my head in trying to use the mouse at the same time.

Disable unified menu controls and then you can navigate with arrow keys, accept/enter with enter and back with left alt. This is already going to be implemented in the next version.

2 hours ago, Pixelpiper said:

If I could make one overarching suggestion for the entire collection, it would be to try and keep the Retroarch file/folder hierarchy as close to stock as possible and organize any custom files, such as compiled ahk scripts and custom controller setups, into their own sub-folders outside of the Retroarch structure.

It already basically is. The only external elements that are within the Retroarch structure are the ahk scripts (converted to .exes) which start alternate Antimicro profiles for some game-specific mappings. All the configs, opt files, etc. are Retroarch's own files. Things like Antimicro is already in its own separate folder. Additional utlities are in their own separate folder.

Retroarch is never going to remain completely static from one version to the next anyway. Cores get updated, Retroarch itself gets updated which means new dependency files, new configs get added, new overlays get added, new option files get added, it goes on... whether those .exes are in there or not isn't going to change any of that.

2 hours ago, Pixelpiper said:

An installer script to put everything in the right place within an existing Launchbox setup would be sublime.  But I fully understand if that's beyond the scope and time you'd prefer to put into this.

Time isn't an issue, but the technical know how to make that happen is. I'm competent with ahk and bat scripts but that's a rather complex and delicate procedure you're talking about, given how it would need to interact with existing files. If it were a simple "drag and drop these files" it would be no problem, but it's not. If someone would like to try to come up with something, it'd be welcome, but I don't anticipate that happening from my end; not anytime soon at the very least.

[Z3R0B4NG]

23 hours ago, Zombeaver said:

Time isn't an issue, but the technical know how to make that happen is. I'm competent with ahk and bat scripts but that's a rather complex and delicate procedure you're talking about, given how it would need to interact with existing files. If it were a simple "drag and drop these files" it would be no problem, but it's not. If someone would like to try to come up with something, it'd be welcome, but I don't anticipate that happening from my end; not anytime soon at the very least.

I'm fine if there is a readme file how to import it into my existing launchbox.
I already did so with eXoDOS 4.0.  

The thread here said a explanation how to import would come with the next version so i've been waiting for that instead of fiddling around myself.  

The big iffy point for me with eXoDOS was that i wanted to have the paths for the actual files on my unRAID server ( mounted as drive X: ) and everything else be on my local drives, i ended up needing to do some manual editing with notepad in the LaunchBox\Data\Platforms\MS-DOS.xml ...opening a 30MB xml file takes a while but the find and replace all function is worth gold to change those paths.  
Everything else was just copy&paste.  

With C64 dreams personally the sticky point is more that i don't want to touch the Emulator managing window (i already have like 4 different installs of Retroarch for my own stuff, so the C64 Dreams Retroarch install would need to have its own name and path).  

----  

One little bonus feedback i'd like to give: i'm not a big fan of your choice of border (or bezel or what its called)... the thing on the side with the Aliens stuff ....why Aliens? Why not something C64 themed? And with how thin the border is i can't just use one of the default retro arch borders to replace it because you opted to zoom in further than 4:3 ... which makes sense for C64 i guess but its an odd format for borders (the empty space in that big blue border is just never used by the C64 is it? ... i wonder why i do not remember that from when i was 8? i had a hand-me-down-from-dad-C64 next to my SNES! )  

----  

So uhm, i just started using this since 0.18.7 a month or two ago ... i don't have a feel yet what your update release cycle is like, so i'm wondering when or in what intervals should i be looking for updates?
I've been checking irregularly every few days/weeks. ...just wondering if i check too many times and if there is some strategy to it ?

[Zombeaver]

5 hours ago, Z3R0B4NG said:

The thread here said a explanation how to import would come with the next version so i've been waiting for that instead of fiddling around myself.

That's been available since the first page and referenced multiple times in the thread.

5 hours ago, Z3R0B4NG said:

With C64 dreams personally the sticky point is more that i don't want to touch the Emulator managing window

You don't have to do that at all. Emulators aren't set/used in Launchbox at all for this. That's entirely handled through the .bats. That's why this project isn't even Launchbox dependent.

5 hours ago, Z3R0B4NG said:

One little bonus feedback i'd like to give: i'm not a big fan of your choice of border (or bezel or what its called)... the thing on the side with the Aliens stuff ....why Aliens? Why not something C64 themed?

It's Project Firestart. One of the more well-known games for the platform. 

I made multiple bezels if you want to use something else by going to C64 Dreams\C64 Dreams\Utilities\Overlays and starting any of the .bats.

5 hours ago, Z3R0B4NG said:

So uhm, i just started using this since 0.18.7 a month or two ago ... i don't have a feel yet what your update release cycle is like, so i'm wondering when or in what intervals should i be looking for updates?
I've been checking irregularly every few days/weeks. ...just wondering if i check too many times and if there is some strategy to it ?

Every couple months, but there is no set schedule. The next one is probably a couple weeks away. It's at 1902 games currently with 2000 planned for the update (and the remaining 98 are already picked out). There's always lots of testing, cleanup, documentation, smaller changes, etc. involved though.

[Zombeaver]

1 hour ago, Pixelpiper said:

I'd never heard of Project Firestart until the post above.

Be that as it may, it's a well-known title. At least among C64 devotees. "Iconic" is a hard thing to pin down with a library the size of the C64's, but it's currently ranked #33 on Lemon64 for the best C64 games of all time, and is generally considered the first survival horror game ever made. It would be unusual for it not to be mentioned in any serious conversation about the best games for the platform. Being a "late" title by mainstream standards however meant it wasn't particularly successful commercially, unfortunately. Way ahead of its time, but it came out in a weird transition period 

1 hour ago, Pixelpiper said:

By 1989 I was already neck deep in the Amiga and C-64 gaming was a distant memory.

Then you missed out on some great stuff. Bad Blood, Dan Dare 3, Deliverance: Stormlord 2, Dominator, Kendo Warrior, Ninja Spirit, North and South, Hellhole, Rainbow Islands, Supremacy... in some cases they were cross-platform with the Amiga, but the Amiga version wasn't necessarily the best. I'd argue that Dominator is significantly better on C64 than it is on Amiga. I prefer the C64 Ninja Spirit as well. There are a number of instances of games that are higher resolution with more detailed sprites that run at... significantly lower framerates, to their detriment.

This is of course not to mention the modern renaissance of C64 games over the last ten years, but that's a different conversation.

1 hour ago, Pixelpiper said:

If you get the chance before the next update, Knight Games. Just saying. Not a top-5, but fond memories.

Knight Games is already in the collection.

1 hour ago, Pixelpiper said:

If you'd consider splitting Maniac Mansion and Zack McKrackin into solo releases, I'd appreciate that too. Not a fan of combos or making gaming selections after the selection in Launchbox/BigBox.

I'm not either, but I'm even less a fan of disk swapping and loading times. The inconvenience of selecting the game is less than the alternative. In the case of most other Easyflash collections, they're setup to load a state right after picking the specific game, but that breaks in-game saving for Easyflash so in cases where that exists (like Maniac Mansion and Zack McKracken) it's not used.

[Zombeaver]

1 hour ago, Pixelpiper said:

I don't agree whatsoever with the order, but I really appreciate the recollection

I don't either, but that's part of the appeal of the C64 to begin with, and why I think this project is worthwhile - there's just so much out there. You're never gonna find two people that agree on that list 

1 hour ago, Pixelpiper said:

I don't recall anyone I knew (of) paying much attention the C64 after 1988 and that might be anywhere up to a few hundred people who were active on the platform.

Personally I started with the C64 (and all games for that matter) when I was about 4, which would have been 1990. At that point what I had at my disposal was three large boxes full of disks (I'd guess several hundred), often with multiple games per disk. The games ranged from the early 80s up until 91ish (one of my favorite games as a kid was Supremacy, which came out in early 91), though I had no concept of that at the time. As I've said before, I didn't even understand what a cracktro was. I just thought that was part of the games. We had an Epyx Fastload cart and I knew the C= + Runstop combo so Dad could sit me down in front of the C64 and just let me go to town digging through stuff.

I got into the emulation scene in the late 90s and that ended up taking me back to where I started. And here we are.

1 hour ago, Pixelpiper said:

I see some great looking examples published well into the 90's that I'll make a point to check out. I really had no idea most of those even existed.

There are actually a lot. C64 titles were still being made and sold well into the mid 90s. Zzap!64 which later became Commodore Force (which still covered C64) was published until 1994.

And as I mentioned, the scene is very very much alive today. New games are being released all the time through outfits like Psytronik, RGCD, Protovision, and others. I check CSDb.dk for new stuff multiple times a week and you'd be amazed how active the scene still is.

Some of the really oldschool groups are still around too. Triad, Genesis Project, Fairlight, Fantastic 4 Cracking Group, etc. are still around and active today. In some cases that of course involves a passing of the proverbial torch, but some of the guys from the 80s are still in the scene today.

1 hour ago, Pixelpiper said:

So WRT splitting the Lucasfilm titles, all the other releases suffer from the issues you mentioned? Shame if that's the case.

Well all other releases are standard disk images so 2-3 disks that have loading times yes (and may or may not require TrueDrive, I don't remember). There is Maniac Mansion "Mercury" (has some extras) which has a standalone Easyflash but based on some of the comments it's kinda buggy and multiple people mention it crashing at times, so I'm not too inclined to use that. There's no standalone Easyflash for Zak McKracken.

People are certainly welcome to replace the version I'm using with whatever they want, using something like Hitchiker's Guide to the Galaxy or The Bard's Tale II as examples for how to do multi-disk stuff. I wouldn't recommend that though. The version I'm using is used because it's, essentially, the best version available. That's ostensibly my goal with all of these, though of course not everyone will agree with my choices. It's easy enough to swap them out though for those that are so inclined.

1 hour ago, Pixelpiper said:

As an aside, I think I'm also going to look into getting a 1541-II or 1571 drive and some adapter to connect it to USB so I can read or attempt to recover a stack of old floppies I have here. It'll be interesting to see if they're still viable after all these years.

There are a few different options for that. They're basically all little made-to-order indie devices. I'd probably go with something like this.

Just prepare yourself for, in all likelihood, lots of demagnetized disks

It'd be awesome if not though.

[Zombeaver]

As a bit of a status update:

All of the 300 new games are done, bringing the count to 2000.
All version updates are complete (69 games updated). EDIT: Actually I can't say this definitively yet because I haven't completed version info for everything yet. Everything's updated that I've gone through. A few more will probably end up updated before it's all said and done.
I've added Blast From The Past volumes 16-25.
I've updated the controller mapping image to reflect the addition of the virtual keyboard function, as well as note some special keyboard keys (Esc = Runstop, Tab = Ctrl, etc.)
I've added 45 new custom notes overlays bringing the total to 70. I want that to be 100 for the release.
I've added 5 new demos bringing the total to 39. I want that to be 50 for the release.
I've added 1 new SID track bringing the total to 51. I want that to be 60 for the release.
I'm in the process of converting Zzap!64 issues 36-50 for the magazine module, the web versions will be included in the standard version.
I need to add custom controls to 1 game.
PRG/Group/Version info is currently complete for 1850 of the 2000 games (92.5%). I intend for that to be 100% for the release.

Once this stuff is done I need to import everything into LB, clean up media/metadata, do final testing, and then some final housekeeping.

I intended to do a release-candidate version here before I put it on my site, the reason being is that there are a few key changes that have been made that I'd like to have some external testing on first. One of the features in the updated core is a "zoom" setting. Previously I had tried the core's "Display Borders=Off" option and I can tell you that you do not want to use that - over the course of testing only about 50 games I ran into problems created by that in several of them. Flickering sprites, flickering portions of the screen, other bugs, it just isn't a good option. I think the problem is that it's trying to dynamically detect where the border is per game, and it just doesn't work correctly in a number of cases. The zoom setting functions a bit differently - it's essentially a couple pre-defined crop levels for a number of different common use scenarios. Options are "none", "small", "medium", and "maximum". "Maximum" is basically the equivalent of what I used as a base video setting previously. The benefit here is that this way shouldn't require any custom adjustment based on your resolution so long as one of the zoom settings is appropriate for a game. This also meant that I was able to eliminate custom cropping settings for 20 games as I was able to replace them with various zoom settings. I still have custom cropping for 14 games after going through all the custom ones. Still, that's more than half of them taken care of across the board. My intention is to have custom settings for 1080p for those games and then make alternate settings that use pre-defined zoom settings that are "close enough" for other resolutions. If people want to make custom values for those games for other resolutions to be used in future releases, that will still be welcome, but this way they'll be mostly close for everyone even if that doesn't happen.

One interesting ramification of doing this is that the aspect ratio of the resultant image from using the zoom settings isn't quite the same as what I was getting from just adjusting the base numbers proportionally as I had done in the past. It's slightly narrower. But after looking at a lot of games and a lot of different images, I think what it's yielding is correct. Proportions generally seem more appropriate to me so I'm going to trust that it's correct. This of course also means that I had to make new bezels because the previous ones were no longer correct. Only Project Firestart is done so far, but I'll be remaking the others, and hopefully a few new ones as well.

Previous:

New:

Previous:

New:

[Zombeaver]

9 hours ago, Pixelpiper said:

Are there any methods to scale the display window while locking a specific aspect ratio?  With more than 3 zoom settings? Or aspect ratio correction to core provided based on a multiplier?  Or scale/fill/fit settings with locked aspect?

In general, yes. That's what setting a specific aspect ratio in the output settings does.

The problem is with C64, specifically, because here it's applying that aspect ratio to the entire usable space including all of the overscan. For most platforms the aspect ratio setting functions the way you'd expect, but because of the way the overscan space is used (or often not used) for C64 it becomes a problem. The zoom settings work pretty well, because it'll maintain the aspect ratio correctly (you leave the aspect ratio as "core provided" when using them) and scale to the screen, while cropping as little or as much as you specify (within the 4-step range of "none" to "maximum"). That covers a lot of ground but some games situate visual elements in weird ways that don't quite fall into one of those, that's where the 14 remaining custom cropped games come in. And for those I can still find a zoom setting that's pretty close. The zoom setting does not seem to work correctly when using NTSC, however, and ends up squashing it horizontally, so the three of those (Death Bringer, Donkey Kong (Atari), and Masquerade) have to be adjusted manually.

[Zombeaver]

4 hours ago, Pixelpiper said:

Sorry, I should have said manual/custom aspect ratio setting without specifying a specific resolution.

Nope. Pre-defined fixed aspect ratios, core-provided, or custom which requires manual adjustment. You can do custom + integer scaling=on but that just locks the horizontal and vertical sizes to integer steps (4x, 5x, etc.) rather than per-pixel adjustment. Custom + integer scaling=on does have the added benefit of locking it to the center though, so you don't have to adjust the X and Y position.

4 hours ago, Pixelpiper said:

I'd love to have a float / % setting for zoom instead of some fixed min-max range. With the current monitor resolution as the base.

You can, with the image-adjustment shader. That's not ideal though because in my experience it ends up distorting the image somewhat depending on how much you zoom (I'm assuming this is because it's happening post/on top of internal scaling). It's also not really any less work-intensive than using the traditional method of resolution adjustment because then you're saving different shader presets for specific games. And even then you're still adjusting zoom for horizontal and vertical separately (by percentage, but still).

Again, for most platforms this isn't an issue because the aspect ratio is applied to the content which occupies the entire space that's going to be adjusted. That isn't the case for C64 because of the overscan. It doesn't work ideally with PSX and Saturn either because they use a number of different resolution modes from one game to the next. Things like NES, SNES, Genesis, etc. you can basically set it once and be done.

While the options afforded by RA aren't perfect, to be frank they are miles better than most other emulators; if you're as nitpicky about this stuff as I am anyway. Most emulators are going to give you a handful of scaling options and just tell you to hope for the best, regardless of whether that's ideal for your specific monitor or not. There is no per-pixel adjustment in any standalone C64 emulator (other than maybe micro64 which is kindof a nightmare to use for other reasons). I'll take whatever small nuisance is hoisted upon me in its current state. It means that despite the wide range of weirdness implemented by various C64 devs over the years, I have a way to deal with it - I have no such option elsewhere. You get out of it what you put into it, but for most alternatives you're stuck with whatever you can get, regardless of whether or not it's what you want.

In an ideal world we'd have a custom aspect ratio "lock" where you could basically dial in numbers as a base and then just increase both horizontal and vertical proportionately (and preferably with an option to do this in higher than single-pixel values) + locking it to the center. Alas... until then I'm left adjusting the vertical resolution and Y position until it touches the top and bottom, then calculating the horizontal resolution proportionally to the adjusted vertical resolution, then centering it horizontally.

4 hours ago, Pixelpiper said:

With your tests on NTSC, were all properties in line. In other words, real NTSC release, core set to NTSC, etc.

The core was set to NTSC. The games in the case of Death Bringer and Masquerade don't work correctly or at all when it's set to PAL, and Donkey Kong works but runs at the wrong speed when set to PAL, so they should be NTSC releases. I don't believe it has anything to do with the loaded content. The core itself alters the dimensions when switching between PAL and NTSC, regardless of what's loaded or even if nothing is loaded.

4 hours ago, Pixelpiper said:

Quick post...  On Retoarch 184 I dont see the zoom ranges you mentioned.  Can you let me know where they are.

It's not a Retroarch video setting, it's a core option setting. Quick Menu > Options > Zoom. Retroarch's aspect ratio needs to be set to core-provided. You have to update the core to the newest version. It's not in the version provided with v0.18.

[Zombeaver]

33 minutes ago, Pixelpiper said:

Try toggling between 4:3 and Core Provided in the NTSC case.  If they look the same (like they do in PAL) then you know the core is setting 4:3.

They're not the same.

Set to NTSC. Zoom: Off. Core provided:

Set to NTSC. Zoom: Off. 4:3:

Set to NTSC. Zoom: Small. Core provided:

Set to NTSC. Zoom: Maximum. Core provided:

Set to NTSC. Zoom: Off. Custom:

I cropped and overlayed the 4:3 one on top of the custom one in Photoshop and it's a little bit narrower (inside the white line):

It's slightly wider than what you would have for a traditional 4:3 bezel on a 16:9 image. I could make one specifically for NTSC games I suppose.

35 minutes ago, Pixelpiper said:

The adjustments allow maximizing the play area of the display, even though that's not how anyone ever had their displays adjusted in the 80's.

I know. I have a JVC CRT that I still use daily for retro stuff. The way it scales is certainly not identical to what you'll see on an HDTV with an emulator. Although in most cases that actually entails the CRT cropping more of the image rather than less, in the case of things like Playstation anyway. I just make it a point to try to crop specifically to the content as much as possible, because I'm anal.

39 minutes ago, Pixelpiper said:

While the border around the C64's "screen memory" area (40x25 character blocks) includes overscan, it's not entirely overscan - most of it would have always been visible - that's the way the display/output was designed to look as there was no guarantee of how much border would be visible from one customer's display to another's. The inset 40x25 (action safe area)  guaranteed that anything displayed in it was visible even on the non-existent "perfect" display.

Yes, I remember this being the case on our 1702. I just don't feel like that's something that necessarily needs to be preserved just for its own sake

[Zombeaver]

20 minutes ago, Pixelpiper said:

There's no detection needed to figure out where the border is, it can''t be changed in software. You can write to the border area in a fashion, but you can't change what is and isn't part of the border nor where it starts. That's a part of the C64's internal architecture as the screen ram starts at a specific memory address.

Then the border=off function is literally just buggy.

20 minutes ago, Pixelpiper said:

When applied, the resultant image will fill the display but it looks like the side borders define the maximal expansion and remain fully visible (covered by the overlay for you).

So what? That's true even without the zoom setting. That's literally what the bezel is there for in the first place.

20 minutes ago, Pixelpiper said:

The feature also still has an effect when aspect is set to custom or otherwise. Setting it to 4:3 when zoom is used doesn't produce the same result as "Core Provided" - something wrong is happening here.

I didn't say it didn't. I said you need to use core provided for the scaling to be correct. It literally says to do so in the option's tooltip. Zoom=Maximum + Aspect Ratio=Core Provided is the equivalent of what I had in the past (albeit slightly narrower, I think correctly), and that's what's going to be on 99% of the games.

 

[Zombeaver]

5 minutes ago, Pixelpiper said:

It means on anything but a wide screen monitor you end up with exactly the same display as no zooming whatsoever,

Oh? That... doesn't seem right. Send a screenshot of something with Zoom=Off + Aspect Ratio=Core Provided and then Zoom=Maximum + Aspect Ratio=Core Provided.

5 minutes ago, Pixelpiper said:

If it's reliant on that, then they need to check for it before activating the feature, so it's broken.

There's no way to do that, to my knowledge. I'm not aware of any core that has that sort of interaction, short of literally crashing when something is set wrong (like a feature being say Vulkan-dependant when you're using GL as the video driver). I'm not a Retroarch dev though, so I can't say for sure.

[Zombeaver]

Interestingly enough, set to NTSC + Zoom: Maximum + Aspect Ratio: 19:12 puts it right on the dot with a normal 4:3 overlay for a 16:9 display, so I'll probably go with that for the NTSC titles.

My SNES overlay, as an example:

[Zombeaver]

Go to Input and turn off "Unified Menu Controls"