Jump to content
LaunchBox Community Forums

Sylwahan

Members
  • Posts

    10
  • Joined

  • Last visited

Everything posted by Sylwahan

  1. I see your point now, yes, that's easy, if perhaps a bit silly: I simply dislike the Mame interface and the menu-ception of the full Mame libretro core, so I'd rather run the FBNeo core for as many games as possible.
  2. Because the FinalBurn arcade romset is a subset of the Mame one to such a large extent that it seems a waste and hassle to deal with both. From a cursory glance it seems it's only the handful of CPS3 games using CHDs in Mame that are any different. Plus I also wanted to use Flycast in RetroArch for the Sega Naomi games in the same manner. Oh I see now, it's just for the that drop-down filter, I never change it from platform category so I didn't realize. Thanks! I saw that all of the arcade platforms I wanted were actually in the import rom list, so after importing the full Mame set I managed to do exactly what I was looking for by importing dummy roms just to get the platforms into the system and then reassigning the platforms for all the relevant games, after which those platforms could be used in the emulator management.
  3. I was wondering, is it somehow possible to treat a playlist as a separate platform for the purposes of launching emulators? In the properties of the playlists there's a checkbox called "Include this Playlist with Platforms" but it doesn't do what I hoped it would do—it still doesn't turn up in the list of available platforms in the emulator management. In fact I don't know what that option does at all. In this specific case I have imported a complete Mame romset, but I'd like to run the Neo Geo and Capcom CPS titles trough the FinalBurn Neo core in RetroArch instead of using Mame, but it seems once imported they all get assigned to the "Arcade" platform by default, with no way to to change it for specific games. So it's either assign everything to run with FBNeo (which will make a ton of games unplayable) or nothing. If it's not possible I suppose a workaround would be to delete everything but those playlists once imported, then import the entire romset again and call the platform something else, like "Arcade - Mame", or would that still silently assign it to the same "Arcade" platform under the hood?
  4. This particular cdifile tool seems to have been made for Philips CD-i images so maybe not surprising it doesn't work properly with Dreamcast. Been trying a bunch of different stuff but so far haven't found any way to make the resulting converted files playable. GDI or CUE/BIN is not an option with translated/patched games that are CDI, but they are pretty few so I guess one just has to live with those being different.
  5. The developer/publisher entities in the database seem to be little more than a unique name currently, but yes, if those were expanded you could add all the alternative naming variants under there if you wanted to. Right now we have all these separate database entries for the same developer, Square, for example: https://gamesdb.launchbox-app.com/developers/details/507 https://gamesdb.launchbox-app.com/developers/details/14 https://gamesdb.launchbox-app.com/developers/details/52 https://gamesdb.launchbox-app.com/developers/details/1042 Meaning if you wanted to sort or view games by this, you would only get a partial list of all the games depending on which naming variant you happened to check. It's just dumb and unhelpful, and all of the above should be merged under a common name. I propose "Square" for simplicity. "Square Co., Ltd." could work as well if you wanted to go that route, but then for consistency you'd have to go and add "Ltd."s and "Co."s and "Inc."s pretty much everywhere else in the database as well. It might all become a bit cluttered, and I don't really see the point in keeping that detailed information for a game collection front-end.
  6. I see that it was mentioned a couple of pages back but I made a case for unifying the developer/publisher metadata here: To me it seems completely insane to allow three or four different name variations for the same entity without having any guidelines to prevent this.
  7. Was about to make a thread about this but saw that there already was an older one. Put simply the developer/publisher entries in the database are a complete mess and some kind of standard or guideline needs to be set. A good example is Square where in the database you have: Square Co., Ltd. Square Squaresoft Square Soft Square Soft, Inc. And I see there's even an entry in the database named "Square,squaresoft". Yes, I know the US branch was officially called Square Soft instead of using it as a brand, but the way it's done now just makes it all very unclear and messy. While I 100% agree that official restructurings and mergers should be reflected, e.g. their older game entries should not be updated to Square Enix, I don't think it's a good idea to slavishly keep to what's on the box art or in the game menu for two reasons: 1) In the case of Japanese developers and publishers in particular, the English names are typically translated from the Japanese term kabushiki gaisha which may be done slightly differently at different times and probably depending on who did the translation. I've seen the same company alternately refer to itself with Co. Ltd. and Inc. endings. Likewise western companies may alternately drop their "Ltd." or even "Productions" or what have you. Then comes the question of capitalization and stylization, should it be "Square Soft, Inc." or "SQUARE SOFT, Inc."? In essence I don't think this information as it's typically displayed is always trustworthy enough to follow to the letter; they themselves often didn't seem to care enough to be consistent, so we shouldn't care about following whatever ended up on the box either. 2) The whole point of even having this information is to attribute credit to and group together different games that were developed or published by the same entity, and randomly showing different names completely defeats this purpose. Optimally you'd do it like IMDb where you would have one official name with a link to the database entry and then in parentheses (credited as...) so you could end up with something like "Square Co., Ltd. (as Squaresoft)" but obviously the database does not support something like that so you you would have to choose one name. Normally I'd go for the full official, legal name like "Square Co., Ltd." but since LaunchBox is not a preservation society or historical database, but a front-end meant to look nice, and these legal endings typically don't—and as mentioned can be difficult to find or reach a consensus on at times—I think it's better to just use the full official name but without any endings. So you would end up with simply "Square" as developer for almost all of these games, with "Square Soft", "Sony Computer Entertainment America" or "Square Electronic Arts" as the North American publisher depending on the game. I understand the idea of the title of the game being as it is on the box, but that's the outward-facing display name of the entire product and is always going to be unique anyway. On the other hand the developer/publisher information in the case of the LaunchBox database is metadata to be utilized by the user and it makes no sense to restrict it to whatever way it may have been transcribed on some little copyright section/blurb on the box. Insisting on keeping multiple name variations for the same entity because they happened to be that way on the box would be the same as insisting that the max players metadata for a game be kept at 4 because that's what the box said, even if it was originally a mistake and the game objectively only supports 2 players. In other words completely unhelpful and if you're going to do it that way you may as well remove the field entirely because it serves no purpose.
  8. I can see how the above wrestling image would make a nice background for the game, however I rejected it yesterday on the basis of it being upscaled and terrible quality yet still 1.56 MB PNG. I would like to urge people to use compression appropriate to the source image, and that one should have taken no more than maybe a 75 KB JPG to adequately reproduce. PNG should only be used for screenshots and very clean graphics and things that need transparency, not for photographic or scanned content or things that have already been compressed to JPG before. Likewise there's no need to scale up images or max out the JPG quality if the source was very poorly compressed or low-res to begin with. There's nothing to be gained there, and the application can scale the images on the fly. It might not matter for an image here and there, but when people may have thousands upon thousands of games in their collection it adds up.
  9. I agree the WonderSwans probably should have Bandai added, but the Coleco one seems redundant. I don't think it works to follow that naming standard to the letter, but it's better to do what seems natural. Otherwise the "Nintendo 64" platform should technically be renamed "Nintendo Nintendo 64" since the name of the console is "Nintendo 64" and not just "64", but that would be ridiculous. I do wonder about a couple of other platform things though, mainly why the name "Playstation" and not "PlayStation"? Especially since most of the other platforms (including the above three) follow the official camel case. Also should the SuFami Turbo be added as a separate platform considering other add-ons like 32X and 64DD are listed as separate? Or is it because the SuFami is third-party, even though it was officially approved by Nintendo?
  10. Screenshots for older 2D games, NES/SNES/Neo Geo etc. should always use PNG in native resolution or integer scaled. The pixel graphics both look and compress better than with JPG. It's only with 3D lighting and in particular texture filtering the images become complex enough that it's worth switching over to JPG at high quality, preferably without any color subsampling (which unfortunately not all image applications have the option for.) So for example for the dithered graphics of PSX it's still worth sticking with PNG even for 3D games for the most part—assuming the screenshots were taken with something like Mednafen without any additional texture/image filtering in the emulator— while for N64 which has texture filtering PNG starts to become a bit bloated. I'll attach some examples. First, Metal Slug at 304x224 native res. PNG is 29 KB, a very high quality, visually equivalent JPG is three times that at 101 KB. Second, Metal Gear Solid at 320x240 native res. PNG 41 KB, JPG still bigger at 69 KB. You could probably get away with lowering the quality a bit here, but there would still be no benefit or point to it over PNG. Third, Star Fox 64 at 320x240. PNG ends up a bit bigger here at 75 KB due to the texture filtering. Same quality JPG as before is now the significantly lighter option at 48 KB, though there may be some hints of compression noise if scaled up. Now if the issue is that the native res is too small or images get too blurry when scaled up, the good news is that for this kind of graphic PNG is quite forgiving of upscaling as long as it's integer scaled/unfiltered. The final set of images here is the same MGS screenshot but integer scaled four times to 1280x960. Despite a 400% increase in resolution the file size only increased by 70%. Meanwhile the JPG of that resolution at the same quality as before ends up at a whopping 400 KB! tl;dr PNG is pretty much always superior, regardless of resolution, as long as there's no filtering involved in the game rendering or in the image scaling. For more complex, smoother 3D graphics from about the N64 and forward, high quality JPG is likely going to be the better option.
×
×
  • Create New...