Zombeaver

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. 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.

Then the border=off function is literally just buggy. So what? That's true even without the zoom setting. That's literally what the bezel is there for in the first place. 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.

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. 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. 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

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. 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. 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. 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.

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.

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:

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 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. 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. 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. 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.

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 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. Knight Games is already in the collection. 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.

That's been available since the first page and referenced multiple times in the thread. 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. 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. 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.

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. 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. 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.

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.

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:

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).

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).

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.

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. Yep, I'm well aware. I still have mine (sitting in a closet gathering dust, but still). 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. Yeah, I understand that. How that actually turns out varies from game to game as you'd expect. Haha, yep, good way to put it Where possible and to my knowledge, yes. The two specifically NTSC games are Death Bringer and Masquerade.

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

Looks like for 1280x1024 you'd probably want to use this as a base: Aspect Ratio: Custom Integer Scaling: On Custom Aspect Ratio Width: 1536 (4x) Custom Aspect Ratio Height: 1088 (4x) Overlays should be turned off or the first image set to transparent (like is mentioned in this post). You'll have black/overscan space on the top and bottom because it's narrower than the C64 (16:10). Some games are still going to need to be customized because in some weird cases, like Frogger Arcade for example, the custom dimensions I setup also center the display. A few games make very weird/unorthodox use of the overscan space. The default settings: Adjusted: Not too many instances like this, of course, but some games do weird things.

The only way I know of to do something along these lines is via a sequence of two shader presets that are in one (separate) folder, one of which is your normal shader and the second of which is a duplicate but with altered vertical and horizontal overscan shader parameters (via the image adjustment pass), set that folder as the default shader folder in an override, and then using the "next shader" hotkey to swap between them. Kindof a big hassle and mostly overkill to be honest. Out of the 1800+ games currently, I've needed to make adjustments from my default for about 1.5% of them; and this shader sequence method wouldn't really work for them anyway because the adjusted dimensions aren't identical between them. No, changing from PAL to NTSC mode and vice versa requires a core restart (it does this automatically when you change it in the core options). That's assuming of course that you're talking about actual PAL vs NTSC mode and not just PAL vs NTSC dimensions which you could do via the method I mentioned above. One without the other wouldn't really make much sense though. You shouldn't need to do this anyway though. The very small number of instances of games that need NTSC are setup to use NTSC already and everything else is setup for PAL. It's literally just Death Bringer and Maquerade. A major point in this project in the first place is that you don't need to do this sort of thing. You don't have to set the joystick ports either - that's already set correctly for every game (barring a handful of mistakes here and there that I correct as I find them - brought on primarily by inadvertently changing the port with the asterisk key when setting them up originally ). Same for games that require true drive. The only thing that anybody should have to do is make manual window adjustments for the 25 games specified in the opening post if using something other than 1080p (which of course you are, in this case). I would do this myself if I had additional monitors for the relevant resolutions. I want people to have to do as little as possible, as it kindof defeats the original intent. I guess maybe I could look into changing my desktop resolution for testing purposes, I don't know how well that would work... I also couldn't do 4k or 1440p anyway since I'm limited to 1080p or less currently. I have base settings for those but nobody's volunteered to make them for the special cases. jophran's handled them for 1600x900 so far, but that's the only non-1080p resolution that's covered. If you'd like to do them for 1280x1024 I would certainly welcome it, and include them in future updates.

Welcome! Yep, that's intentional. That was changed a little while back as noted in this post because I realized after the fact that asterisk is the core's internal key for swapping joystick ports so it was causing a conflict, so I moved it. Some of the bindings were updated in the opening post (where they're in a big list) but a few other references I guess still need to be updated fixed. Not sure what to tell you there, those are the correct keys and they're working correctly here. The default is F... something. I want to say F11. You just press it twice. In the upcoming update it's going to be on the Y button (on a 360/XB1 controller).

I've never used it for 5200, but for what it's worth I've used Atari800 (standalone and in Retroarch) extensively for Atari 8-bit emulation (100+ games) and like it quite a bit. I use the Retroarch core in the majority of cases, the only exceptions being weird things like games that need to be set to NTSC mode for the correct colors (few and far between) which I never got to work quite right in Retroarch. I would assume that 5200 emulation is good with it as it would presumably be the simpler of the two. It's a bit on the weird side to setup (in Retroarch) though since the Atari800 menu (separate from Retroarch's internal core option menu) is still used for some things (kindof like the MAME core). Thankfully, the majority of the important stuff is accessible from core options though.

I pm'ed you guys.

Really? That's pretty bizarre. I don't think I've ever heard of that being an issue before. Cores not supporting save states is semi-common, but not supporting fast-forward is (I think) a first for me. The VICE core supports both the standard fast-forward and has its own internal warp hotkey. That's awesome! Looking forward to it. Good to hear from you!

You could just use RA's normal fast-forward function for that. You can set the max fast forward speed. I think the default is something like 3x but the max is 10x.

Oh? Well that's interesting. Will have to give that a go. That still won't give you a library of configs to pull from, but that's not necessarily a huge deal so long as it pulls the arguments that are specified in the .info file (which I would hope it would do). That's what FS-UAE does as a fallback at this point and even that's sufficient for the vast majority of stuff. If it doesn't, you're going to have problems unless you can specify them somewhere - the most important one being PRELOAD.