Jason Carr

SentaiBrad said Lets start what with what I meant about PS1 default, I was typing and thinking so much I think I left things out in some places. Because the names share similarities, when I was adding them in I forgot to specify a default emulator for PS2 and it automatically used ePSXe which is for PS1. The same could happen for Game Boy. That said, as long as someone checks their settings before hitting ok on import, it should be fine. So that was a personal bug, but it can happen. Ah, I see what's happening. I didn't even think about the fact that it did that. If you don't specify an emulator, but search TheGamesDB, it'll grab whatever game it can find in TheGamesDB with that title, and assign that platform. Interesting. Not sure if that's ideal or not; maybe I should just require you to specify a platform.

bd00 said Yeah sure: Tools > Install DOS Game Type name No, I have the installation files... Inside a CD Image ISO File ISO path entered Choose destination path (left at default) Yes, automatically mount the CD Yes, copy to the destination folder (copies fine) Ready to perform the installation in DOSBox ERROR! Hope this helps, if you need anymore info just ask. Thanks for that, stupid error on my part. I changed something at the last minute that broke it apparently. I'll have that fixed for the next release.

Hehehehe...I could use some therapy...

Ha, okay, from here on out let's just assume that neither of us are ever offended. No kidding on the text form of communication; it's a complete fail. Misunderstanding is so easy. For what it's worth, I feel like your communication skills have been top notch. I just sensed (probably falsely) a bit of irritation in the last message (empathy is one of my personal strengths), and I feared that you would back off a bit, which I do not want in the slightest. That was the only source of my concern. Let's just assume we're both positive from here on out; doesn't do either of us any good to worry about the other, lol. I've been busy unnecessarily worrying about not offending you, and you've been busy unnecessarily worrying about not offending me, when in reality, neither of us are ever really offended. Such is forum life.

Yeah, who knows if VMware would be more compatible with Daemon Tools or not. Personally I've never tried Daemon Tools with Virtual PC or VMware. I think I'm out of ideas...hope you can figure out something.

Cool, Ed. A couple of things. As you probably know, "Windows XP Mode" is basically just Virtual PC, which is a similar technology to Hyper-V on Windows 8. So once you have the Windows XP image, you can copy it over to any Windows 8 or 8.1 machine without issues, and you can run it inside of Hyper-V, which is Microsoft's latest virtualization technology. Just throwing that out there. As per the "missing CD" issue, unfortunately I think if the game did employ an anti-copying mechanism on the game disc, nothing is going to work sans for maybe using something like Daemon Tools to emulate it (it can mount an ISO a fake the copyright protection). In all honesty, though, NoCD cracks are almost always easier. It's ridiculous to have to use them when you own the CD, agreed, but sometimes you run out of other options. Also worth noting is that .bin/.cue files provide slightly better representation of an actual game disc, so it's possible that some of it was lost during the conversion, which is causing the problem. I kind of doubt it though. Last thing; VMware I believe does have a free version out now as well, and traditionally they've handled games much better in their virtual environments than MS has, so that might be worth a shot. Sounds like you've made pretty good progress though. Thanks for sharing it all with us.

SentaiBrad said Starting to add dos games... oh god this sucks doing it one by one. xD So I thought of ways to import DOS games. Instead of doing it the way you do it for ROMs, have it be very specific unless installing from source material or selecting a folder one by one. Have it be a strict rule set. LB can look for .exe's, then .bat's, then .com's.... etc etc. There are a few different types it can be. Some games do have more than one exe, bat and com file. You can have it blanket search for a few different names as well. "Install" .exe, .bat, .com. "Setup" .exe, .bat, .com. An alternative would be to read the folder names and if an exe, bat or com file match the folder name it can pick that file and if it cant find one at all it can default to looking for install or setup. Obviously it wont be perfect, and as a 3rd backup it can just make an entry named what the folder is called. To denote that it doesn't have an exe or something else selected you can put a red X on the image, or what would be the image, or when you try to launch the game a prompt saying that it couldn't find am applicable file. Honestly, I don't know how D-Fend does it, but I would assume its something along those lines. Just look at the programs behavior when you do import something. That's not perfect either, and we obviously need to make it work in this instance, but holy crap I do not want to add ~1200 DOS games by hand. Fixing them after the fact is a bit different. Also, whether or not you are importing or installing a DOS game from source or a folder, can it automatically fill in the platform as DOS? I keep thinking, so forgive me if some of this isn't possible, I am just trying to come up with solutions to the issues we have. That said, the major lag issue only happens when a library gets to a certain point, right? You also stated you use XML filing. Well what if you split up XML files? Instead of one XML file being in the root of the program you create a 'Configure' folder. In there you have XML files split up by System. So NES, SNES, N64, all have separate XML filing. This could potentially split up the work so instead of combing one gigantic file, it combs several smaller files. When an XML file reaches X amount of game entries, lets say 1000 for our purposes now, then it just creates a second XML file continuing on for that system. That would most likely be needed for DOS and PC system sorting. That is assuming you wanted to also stick with XML filing. Otherwise, maybe we have to look at optimizing the programs performance more? I notice that it doesn't take too much processing power, which is a good thing for a lot of people, or for smaller libraries. Clearly though, the bigger the library the slower it gets. What about allowing the program to use multiple cores of a CPU? What about using GPU capabilities in helping to process the imagery? What about increasing the RAM that the program has access to? All of this could be check boxes in an options folder. Some, like the multi-core utilization could get greyed out if the program detects a one core or dual core CPU? All random thoughts. I do think a DOS import would work decently similarly to the way you described, assuming that the folder you import from only contains DOS games (and not Windows EXEs), and has a folder per game. Yeah, wouldn't be perfect, but it's certainly doable, and yes, we can auto-fill the platform. I still haven't found a batch import in D-Fend though. I must be blind. I see the import options under the file menu, but they seem to be one by one imports. I'm not sure if splitting up the XML files would help performance or not, but I'll do some experimentation with all of that shortly. Same with optimizing performance (which I intend to do first before anything else). I am curious to know what the RAM usage is for the app on your system after scrolling through your entire library.

SentaiBrad said DOS importing is what I want to work on next. I have DOS Discs (not Disks, aka Floppies) and them in folders. You also asked for ways to import DOS and ScummVM games. Well I know ScummVM is open source...? Or at least a license that will let you use code? Worth a check, and if so maybe you can look at their code and see if its usable, if not then maybe you can just see how its done and reverse engineer a method for LB. Same goes with D-Fend, or ask the developer how he did. Sure, didn't think about using the ScummVM list to import from; I wonder how many people actually use that to make an import worthwhile. I don't see a batch import in D-Fend; am I just missing it? For what it's worth, though, there is a batch import to import all games from D-Fend.

SentaiBrad said Ok, I am currently reimporting all my items. I want to try and document when the horrible program lag starts in and picture importing. I also can tell the lag right away because when it populates the list of games after the import it lags, even when adding 1 or 2 games, but I'll make sure to test it with editing too. Also..... holy crap it sucks to have to specify each filter when importing. Before I started each import, I did go through and try to look for duplicates to fix a horrible duplication error I had. I also used the import filters properly this time. I doubt I got ALL of the duplicates, but were talking about maybe roughly 100 I could have missed over all my rom sets. At a certain point as you'll see, it wont matter anyways, holy crap I did free up a lot of space though. So here we go! PS1 Import: 261 Games --No Lag during game population after import. PS2 Import: 433 Games --No lag after import. --No lag when changing filters. --No lag when editing and importing data. Pictures show up right away. N64 Import: 600 Games --No lag after import, changing filters, editing data or importing pictures. Pictures show up right away. PSP Import 802 Games --No lag after import, changing filters, editing data or importing pictures. Pictures show up right away. PC Engine Import / TurboGrafx 16 1102 Games --I could be wrong, but it seemed to lag initially after the import as it was populating the list. Not the massive lag I was getting (a few seconds to 15+ seconds and the program not responding) but... that said. I edited a game just fine and the picture showed up just fine afterwards. Seems a tad of lag after populating the new list of games. Nintendo DS 1379 Games --No noticeable lag after the import and population of games this time. May have just been a fluke on the last import. Back to no lag on all fronts again. Importing, editing, pictures. There was a tad of lag when deleting an item because I had a duplicate issue. There was a bit of lag there, but 3-5 seconds, nothing I wouldn't have honestly expected. GBA 2016 Games --No lag after importing, editing and pictures showed up right away. GBC 2437 Games --Didn't seem to be any lag after import. Editing the a game entry now lags, but slightly longer than expected. I am getting mixed signals with this a bit though. When importing and editing just text data, it lags more then before. When I am just importing images, though it depends on how many it downloaded, it didn't lag too bad. Data can show me "Not responding" where the image portion did not. Doing both data and images together it did lag as well. So far, this all supports that data is the lag culprit, possibly. Images also showed up instantly still, no re-editing after download still. Game Boy 2882 Games -- I finally got (Not Responding) at the top but it didn't take too much longer after import. Imported Data and pictures, not responding. Tried it again with no "Not Responding" this time actually. Tried importing just data again, Not Responding lag. Same entry 1 image import and got not responding lag, still showed up just fine afterwards. Lag during deleting an entry. SNES 3203 -- Starting to lag in everything now. Importing, editing / importing data and pictures. Getting (Not Responding). I can keep going documenting the rest of my importing, and there is a bit still left but you can start to see where it starts to change a bit then where its a certain fact. So image bug is fixed but the larger the library gets the more laggy it gets. I did notice that importing data is inherently more laggy early on ironically. There REALLY need to be a way to have multiple import filters, I honestly think that is a prudent update. Same with a box check saying [ ] Use the folder name as the game title. This is assuming that you have one game per folder. For multiple disc games maybe it can still detect if there are multiple files in there and just still apply the folder name. Otherwise for example I have most of my roms for other games in one giant folder. So its situational. If anyone has any questions or needs clarification anywhere, let me know. Also side note: downloaded your album. I'll be honest, was not expecting it to be religious in the slightest, but I listened to it and it sounded FANTASTIC. You have a good voice, and the woman you have sing too sounds awesome as well. It sounds crisp and the actual music from the instruments sounds good. That's interesting that there seems to be a hard line where it starts to lag badly. LaunchBox does cache all of the images in RAM; I wonder if maybe that's the problem. Have you checked the RAM usage? It could be exhausting RAM and resorting to using the swap disk. I do have an item on my to do list to reduce the RAM usage. You and bd both have pushed for multiple filters, so I'll add that to my list as well. Many thanks for the compliments on the tunes. My wife does the female vocals.

bd00 said Ok, I did a little testing this morning with beta1 (have not yet started beta2) and I encountered a problem. So, I tried installing a DOS game using the wizard, everything was going great, it really is clear and super easy to use Jason, excellent work with that by the way. Anyway, part way through the installation i got this error: It states: System.ArgumentException: The path is not of a legal form. at System.IO.Path.NormalizePathFast(String path, Boolean fullCheck) at System.IO.Path.GetFullPath(String path) at LaunchBox.InstallDosGameWizardForm.readyToInstallWizardPage_Commit(Object sender, WizardPageConfirmEventArgs e) at AeroWizard.WizardPage.OnCommit() at AeroWizard.WizardPageContainer.NextPage(WizardPage nextPage, Boolean skipCommit) at System.Windows.Forms.Control.OnClick(EventArgs e) at System.Windows.Forms.Button.OnMouseUp(MouseEventArgs mevent) at System.Windows.Forms.Control.WmMouseUp(Message& m, MouseButtons button, Int32 clicks) at System.Windows.Forms.Control.WndProc(Message& m) at System.Windows.Forms.ButtonBase.WndProc(Message& m) at System.Windows.Forms.Button.WndProc(Message& m) at System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message& m) at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam) I was installing from an ISO. EDIT . My bad, I forgot to unzip CDRDAO Please just ignore me, it is one of those days. EDIT 2 . Hmm, ok, maybe I was a little hasty with my last edit. I have unzipped CDRDAO and ran the installation again and got the same error: System.ArgumentException: The path is not of a legal form. at System.IO.Path.NormalizePathFast(String path, Boolean fullCheck) at System.IO.Path.GetFullPath(String path) at LaunchBox.InstallDosGameWizardForm.readyToInstallWizardPage_Commit(Object sender, WizardPageConfirmEventArgs e) at AeroWizard.WizardPage.OnCommit() at AeroWizard.WizardPageContainer.NextPage(WizardPage nextPage, Boolean skipCommit) at System.Windows.Forms.Control.OnClick(EventArgs e) at System.Windows.Forms.Button.OnMouseUp(MouseEventArgs mevent) at System.Windows.Forms.Control.WmMouseUp(Message& m, MouseButtons button, Int32 clicks) at System.Windows.Forms.Control.WndProc(Message& m) at System.Windows.Forms.ButtonBase.WndProc(Message& m) at System.Windows.Forms.Button.WndProc(Message& m) at System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message& m) at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam) EDIT 3 . Same thing is happening on Beta 2. Also, it tells me that the CD will be mounted to drive D: however that slot is already occupied. Might that be related? That's interesting...definitely need to work through that issue and get it figured out. D: shouldn't be the issue as that's what it's mounted to in DOSBox, not on the system. I'll look at the code and see if I can figure anything out. Can you tell me what values you're putting in all the fields? Thanks, bd.

SentaiBrad said So I have an odd problem that I am just now running in to, but it has to do with file structure and not so much the program. So, I have a softmodded Wii. I have an external with Gamecube abd Wii Games. They're all in separate folders but the Gamecube files are ALL named game.iso and the Wii games use their ID code I.e. SBLE5G for A Boy and His Blob. Is there a way when importing to have a check box for how LaunchBox gets the names for its entries? Obviously its using the Iso files in this case, but the check box could say to use the Folder name? I also need to test wbfs files, but since this isn't an emulator its self it should be fine. Also, I am now using 3.1 Beta 2. Also, a note about filtering with similar names like Sony Playstation. When trying to set a default emulator for PS2 it did try using the default emulator for PS1, depending on the order you do that in. Though that's a small issue that can be fixed by just making sure you go over all your settings on import. Sure, I'll add a note to add that checkbox. Can you explain the default emulator thing? I don't really understand "it did try using the default emulator for PS1".

Absolutely, bd. I know that, for sure. Sorry if I came off brash, just needed to respond quickly because I was at work. For one thing, I very much appreciate *everything* you do to help out on the forums, and with LaunchBox in general. It is *hugely* appreciated. I've never been at all offended by anything you've contributed; it is always constructive, and I'd be very disappointed to see you move on. Just wanted to share that because I was afraid I came off too harsh and rubbed you the wrong way.

Wow, looks awesome, Ed. I'll take a look in detail tonight.

Awesome guys...thanks a ton. I'll take a look at everything in detail tonight.

Awesome Brad. Bd, I would, but that feels more like a workaround than a decent fix. The are a few issues: - Searching for "PlayStation" would return PlayStation and PlayStation 2, etc. It's arguable whether that's a flaw or not, but I can see the confusion. - It'd be nice to be able to specify any common name for the platform (such as PS or PSone, etc.). I think in order to make that effective I'd have to use a relatively exhaustive list of platform names (which I actually do already have started, I use it for the search on TheGamesDB). Anyways, just some stuff to think about. We have some more pressing things to tackle first, of course.

Alright, here's beta 2. Remember that you'll still need the CDRDAO.zip file referenced above in the previous post. I'm still looking for some help testing the MS-DOS installation wizard. I worked on the game images not updating issues, and I'm hoping that the issues are fixed. It is hard to replicate though, so I really need help testing that to confirm that the issue is truly fixed. Also new with this beta is the requested "launch a random game" option under the tools menu, and I revamped the About dialog to allow more room for third party credits. Do test as much as you can and let me know how it goes.

Thanks, Brad. Unfortunately the Program Files test doesn't really test whether an app is truly 64 bit. However, the app is already 64-bit when available, I am sure of that. Of course, I'd love it if you did a LaunchBox video. That'd be really great. Whether it gets a few hundred views or 10,000, it's a win. The filters just work off of a standard search, so yes, filtering to "Sony Playstation" picks up anything that has "Sony Playstation" in the title. It's just a simple text search for the moment. I worked on a number of things tonight; specifically the images bug. I'll have a beta up on the beta testing thread (https://www.launchbox-app.com/forum/features/launchbox-beta-testing/page-4) shortly. I also added you into the beta testing group. Thanks, Jason

Hi Zeciorrr, thought I responded to this already, but I guess I must have never submitted...or something. I do plan to add language support, but of course I need help with the translations. I'll see if I can get a language file of some sort going in the near future.

So, back to performance. There are things I can do in the code to speed it up, for sure. So I'll attempt to tackle that first to see how much I can speed up the populating after filtering/sorting. There are a bunch of other things to look into performance-wise, plenty to do there, for sure. For instance, I'm using XML for all the data. I chose to do it this way for flexibility (easy to write your own import, etc.), but it's obviously not the fastest way to do things; a database would be faster. It's all about spending the time to address the slow points in the code and thinking about how to speed them up. I'll devote some time to this soon. Imports for DOS and ScummVM games might be tough. I'm open to hearing ideas on how to implement these. Let's start a new thread for that though (would be better to discuss individual things on individual threads I think). Emulators, yeah, I can see the benefits of all that. I still have a main goal of keeping it all as simple as possible, but there should be a way to apply an emulator to a group of games, etc. Noted. That said, if you update the command line settings for a particular emulator, it will apply to every game assigned to that emulator. Even though you access the emulators from within the games (which I will be changing, btw), they are still separate in and of themselves, and not specific to each and every game.

Woah, big conversation here! I do appreciate all the feedback, Brad and bd. Regarding filters, yes, you'll need to do multiple imports to cover multiple extensions for the moment. With the pictures, the issue is somehow with the caching. I have a cache in place in order to make the games view performant, and it sounds like in large libraries the timing causes problems somehow. It's good to know that it happens mainly with larger libraries. This is the biggest glitch I know about right now, so I'll focus on it for this next release. As per 64-bit, the app is written for the .NET framework, and targets both 32-bit and 64-bit platforms, individually. This is hard to explain, but depending on which version of the .NET framework you're running (32-bit or 64-bit), the app should run under that model. It's not really that simple, and I don't really understand all the aspects of it, but the .NET framework does do a good job of handling it all behind the scenes. So, unfortunately, I think we're already seeing the benefits of 64-bit (or any that we could see in using the .NET framework). Gonna go through the rest of the feedback as well, but I'll divide it up into more posts. I'll say this first though: I'm glad to have you on board here, Brad. Honestly the best thing you can do for LaunchBox right now is to advertise for it however you can; I'm still working on getting it out to as many people as possible. Also, we should get you in on the beta testing thread.

Hey everyone; I need some *serious* testing on this. I've spent 4-5 days developing a wizard that makes it as easy as possible to install DOS games from a CD, folder, CD image, etc. I've even implemented a way to rip CDs to .bin/.cue files to make them run without the CD. Obviously this is a tough undertaking. I've wracked my brain to make it as easy as possible, but I'm sure there are things I haven't thought of, and I'm sure there will be issues with certain games. The new wizard is available under Tools | Install DOS Game. Here's what I really need help with: - Please run through the wizard, pay attention to/read everything, and let me know if anything is confusing (if you have any questions about how to answer any of the steps). I want to make the wizard as easy to use as possible. - Please pull out any DOS games you have (especially if you have the original game media or CD images of the original game media) and run them through the process to test it. I'd like to test the wizard with as many games as possible. The more games we test, the more stable we can make it. - Please try and test every aspect (every page, select every option, etc.) of the wizard as best you can. Try and make it crash. Put it through hell. It's tough to maintain state with such a complicated wizard so I want to make sure I didn't miss any problems that might come from going back and changing options, etc. As always, thank you all for all your help. The new 3.2-beta-1 version is attached. Also attached is a zip file that contains CDRDAO; this is an open source application that I've integrated that provides the CD ripping functionality. I'll include it in the new setup, but for this beta test you'll need to manually extract it to your LaunchBox folder. The folder structure should be LaunchBox\CDRDAO\cdrdao.exe. Happy testing! Whatever details you can give me as to what you tested, what works, and what doesn't is greatly appreciated. Thanks, Jason

bd, yeah, that is certainly a current priority. I'm thinking just a simple one-field at a time thing. Select the games to update, select the field, select the value. Simple and effective (and probably relatively easy to implement). Vinicius, welcome to the forums. I'm currently looking for more help beta testing, so you're in. You can now download the beta releases from this thread.

Also a good idea. Added to the list.

Good idea, shinra, added to my list.

Hey Brad, thanks for those details. Yes, I expect performance when editing games mostly has to do with having such a large library. There's always performance improvements I can make; I'll add a to do to see if I can speed that stuff up. I've seen the picture issue before as well, but I've had trouble replicating it. It seems to pop up randomly out of the blue. If you can see any kind of pattern behind it, let me know. I'll add a to do item to add an option to remove games with missing application files as well. Thanks, Jason