.png.45cc82964cc5cee84f05914175cf71a3.png)
.png.6c4989b4177ae2440f13470070eb2c35.png)
SentaiBrad
-
Posts
6,988 -
Joined
-
Last visited
-
Days Won
7
Content Type
Profiles
Forums
Articles
Downloads
Gallery
Blogs
Posts posted by SentaiBrad
-
-
bd00 said
Let me try to explain further my thinking then. If we offer Icons, then there needs to be an option because not everyone is going to like Icons, they want their full image. This is fine but pointless, so take out the option. My original thought was to yes, resize the image when the Scrapper nabs the image from TheGamesDB. If we convert the images over to a smaller version, then what you would want is two version of the image, I already have close to 10GB of images with my library. If there were duplicates albeit smaller with a large library, that could get even bigger. So my next thought was to size them on the fly as to help with file size, but that would most likely require something like vectors which then also doesn't solve the size problem.SentaiBrad said
But thegamesdb only has one front cover per game, so if it is too large does LB just ignore it, leaving users without a cover? If not, then there is obviously some resizing going on on-the-fly. No need to convert images, just resize them to a standard resolution, like a max of 500x500 if required but leave the original as is for full screen viewing. I don't see why you need to convert images especially to vector, it doesn't make sense.bd00 said Brad, could you not just have LB create thumbnails on import? Limit the size and only load full size images when viewing the covers. Would that not solve your problem?
That could potentially, but I was trying to think of a method that wouldn't require another option. Not to mention I don't think we can scale the images on the fly, that would require them to be vectors and blow the ram usage out of the water. If you limit the size a bit at least you still get them and they can be capped on import. Unless we can come up with a RAM saving method with the slider we have now, but I still think that would require scaling on the fly.
My mind works oddly and I sometimes don't express everything. That said, if we only had the small version of the front and back covers but then kept fan art for Full screen game viewing then this could be achieved with the setup we currently have. Limit the most front facing images then use the fan art on full screen because I doubt a full screen image that has been resized to be smaller would look that good. There would also be the issue of how we do that since there is no standard and my thought is to reduce the image size by 50%-75% on import. It might make imports take longer too but in the long run should be a better option. We could also still show the front and back covers in their reduced form but make sure that the program doesn't expand them past their resolution.
-
bd00 said Brad, could you not just have LB create thumbnails on import? Limit the size and only load full size images when viewing the covers. Would that not solve your problem?
That could potentially, but I was trying to think of a method that wouldn't require another option. Not to mention I don't think we can scale the images on the fly, that would require them to be vectors and blow the ram usage out of the water. If you limit the size a bit at least you still get them and they can be capped on import. Unless we can come up with a RAM saving method with the slider we have now, but I still think that would require scaling on the fly. -
Also, anyone who needs to post an Error Message or they get a pop-up full of text, you don't need to post images if you don't want to. Click on the message box and press Ctrl + C. It should copy all of the relevant text from that window and you can paste it in to a reply message. You can still post images if you want, but if you don't want to, don't know how to or can't be bothered to, there's the alternative.
-
Steam Users
in Games
http://steamcommunity.com/id/SentaiBrad/ -
pogowolf said Issue: Keeping the meta data downloaded from 'somewhere' (in this case TheGamesDB.net) associated with the game itself. #1 - They way it's done currently is that all the meta data is downloaded and saved in one XML file. (mine is currently 78 meg) which is parsed on the fly for information, possibly partial saved on update, and re-read into LB after each edit. Pros: 1) Keeps the system 'clean' and it easy to access data 2) Keeps the data in once place, making the whole of LB more portable. Con: This process slows as the size of the XML file grows. Which effects the loading of LB to taking 30+ seconds per edit of a game and at 78 meg.. it's on longer portable anyway. Thoughts: Is portability really needed? yes, the INSTALL is.. but once you adding a few games, the idea of throwing everything to a USB drive and taking it to a friends becomes harder and somewhat impossible. so the question is: What is the why/reason for the need for the portability of the data? #2 - Use a seperate XML file to hold all the meta data Pros: 1) Would be easy(ish) to implement.. perhaps by GamesDb ID (so 8428.xml) which is Postal 3 2) Easy to update specific games (or re-update from the Gamesdb.net) 3) Possible to embed images into the games XML file. 4) Could be used for ISOs, DosBox Games, etc. Cons: 1) easy to de-associate game data from game image. Some sort of clean up system would be needed to sync the XML/image files no longer needed. 2) possible slow down on load due to loading multiple files at once (though, this could be threaded) 3) Makes Search and Filters much harder to implement and would slow the system down having 32k of files to search though in order to produce a search/filter list of games #3 - Embed the meta data of the game WITH with Game itself. Pretty much the same Pros and Cons as above.. except that the association of the meta data and game won't be lost and it would be easier to share this format than to share an image and force the user to download the meta data again. #4 - Hybrid of #2 I think this may be the best way to handle this issue. the PRIMARY meta data (Name, Release Date, Genre, Publisher, rating, etc) would be read from flat XML file as the game is being imported (and the XML file being created).. THis way all searchs and filters are fired agaist the database. If a user wants the additional information about the game.. then the XML file is read into the form. PROS: #1 - Fast access to any of the games, fast search, and filters. #2 - Opens the ability to create a virtual data grid so that a 78+ meg XML file isn't trying to be loaded all at once. #3 - Splits the data needed to RUN a game VS neat 'extras' that some users may not even care about. CONS: #1 - pretty much a total re-write of how the import system works, how the games are displayed, and how the import process works. #2 - Still pretty easy to de-associate the meta data from the game image. So the a tool would still be needed to clean up the XML files.. but now also the database as well. Also a tool to 'compress' the database would be a good idea to keep the database file size down. however if the import is split off.. you can speed up the import process by only downloading the primary meta data and download the 'extra' data later.. in the background.
Let me see If i can't answer some of this. 1. Yea, its all kept in one XML file for portability. Portability was the design philosophy Jason wanted to take. Since then we've discussed making a non-portable version of LB. This way we could use the registry and possibly get a voting system done within the program. We've since decided to probably go through the site on that though. Either way, the way its being done now was the way that was picked because the library counts weren't that large. The few of us have gigantic libraries but the average user does not. We've tested 10k items with little to no noticeable lag. The larger the XML file, the longer this can take. We have talked about multiple XML filing or changing the settings system all together, but we haven't decided on anything yet. 2. Most likely, the system of images in a folder is going to stay the way it is now. We could possibly further sort the images by Platform in the images folder but chances are it will stay this way. XML filing is a bit antiquated so adding in multiples and images is not desirable because of the massive lag it will cause. Right now its just looking in the XML for data, but data and images then multiple that by 10k, were back to where we started. The caching of images how ever is going to be improved. He is looking in to ways that will help the RAM issues. The filtering system was also the source of the lag before, but since that was taken care of it now seems that it is because of the sheer amount of data. Even if we change the system, nothing will fix that. At a certain point it is entirely dependent on each system, now that is not to say there can't be even more optimizations because of course there will be, but at a certain size there is nothing we can do. 3. I think its pretty safe to say that Jason does not want to create containers for anything. It will be a major headache for users of any level we think if we start putting rom's and data in to other files. It would essentially be scanning archives for data like a 7zip or rar archive. Even if no compressing is taking place that will cause more resources to be needed to parse that information. Boot times could get out of hand. 4. There is a compromise here, we know this. We just need to make sure we find the best compromise for the way the system is setup now. We want to stress, he wants to make the best possible program but if that means a complete rewrite of systems that needs to be carefully looked at and determined if it will be the best decision for the future. For him to rewrite entire systems would mean also partially rewriting other systems and could potentially take weeks; where as some optimizations can take a few days. Nothing is off the table but it also needs to make sense. Without changing how the system behaves now I believe we can try to get more cores to work for the program, even though I am certain it does use multiple cores right now... could be wrong. Also, the major problem isn't with CPU related tasks, its mostly RAM related tasks. The bigger the library, the bigger your RAM usage will be. I think we're going to look at how image caching works. Instead of retrieving the data at its fullest I believe dropping down the max resolution of images and how many are kept in the active cache will HELP this issue, im not sure it will resolve this issue. Lowering the image sizes will also mean that the max size in LB will probably be lowered. We could also limit how much else is downloaded with the import. Right now its defaulting to downloading all available images on the mass import, maybe changing how that works as options or just limiting it to just the Front and Back covers would help. Either way, it will be a decision on the users part. Also, keep the discussions coming, we do like reading them. -
pogowolf said
But there would be a "list all" option and by default it would do this unless you chose to save your filter selection when you close LB. The way it works wouldn't change, just how it looks.Vinicius256 said Hey Jason, I made a mock-up based on the OpenEmu style with the ''Charms bar'' idea from bd with a kinda ''Modern'' look, tell me what you guys think:
personally I like the first one better than anything.. however, even having the list of consoles.. you could have 30+ consoles.. listing like this (for large collections) I don't believe will work in the long run. my thoughts would be to have a fly out (kinda like the current filters) but filter the list of games by genre and/or keyword.. from my experance people don't tend to think "I'm going to play a PS2 game".. then think.. "I want a racing game".. or "I'm going to play mario" .. *shrug* but then I like to look though my list sometimes.. But that's why I like the current LB interface. it'll list everything.Spoiler -
Jason Carr said Ah, sure, that would make sense. Though I think I'd rather use a metadata file per previous discussion. Bd, you'll notice that the new export process does automatically arrange all the games for the zip file, so I'm not really far off from an option to "consolidate game files". At this point I didn't add the metadata files, but that wouldn't be too hard. Just didn't yet see that compelling of a reason to do it at this point. Could also move the images into the game folder, which would make it an isolated set. Think that's worth doing?
I personally think there is such a thing as over organizing. I'm not saying dump it all in a folder and go, but should it be complicated? I think an images folder and an XML file are fine enough. If you wanted to maybe split it all up by system? Though, I don't keep any of my games in the games folder, I just use LB as is in a folder and its points to everywhere else, so honestly I don't care how the data is stored. I just want to make sure there is no chance of it breaking, which the way it is now is hard to break unless you start deleting files. -
pogowolf said
Most of the portability you are talking about already exists though, its just not in a container or on OneDrive etc. You can already do all of that as is. The XML is holding the data of each rom like Publisher and its path on your system etc, and the images folder holds the images. The game is assigned an ID based on Hardware and setup, its given an entry in the XML then everything is assigned to that. Where as if it was based on names, that could be easily broken. It is the same result if its a container. If its based on ID we already have that system setup and if its based on name that can be easily broken and cause some headaches. The point of the program is to hopefully be stupid simple. If the power users like us want to mess around with it we can and if the general end user wants to just plug-in the roms and go they're also covered. Also, MESS is literally a mess. I tried it several times and did not like it at all. MAME barely gets there with a Frontend. The MESS cores are also not up to par from what I remember. A lot of emulators still being updated are generally better. Also, if we include emulators that have multiple systems tied to it, if someone wants to use another emulator I could see it being a hard time trying to change over the small portions, but with the UI rewite that would hopefully be a thing of the past. It only comes down to the right start up commands. I just personally don't like them.SentaiBrad said The only problem I see with changing file extensions is then Emulators issues. The fact still stands, we rely on other programs. Adding in layers of anything could have untold issues. It will also make the amount of user data a person has get to be out of hand and you are being forced to use LB so that the container is of any use. Also, after my last scan of TheGamesDB and going through a lot of my games manually, I don't have to do that again. When a new version comes out I just replace the exe and it automatically grabs all the data. If I need to change directories I put the new exe in the new directory, run LB, then place my old XML and Images folder in to the new structure. As long as the XML file corresponds correctly to the right images folder it will be all fine. That is because each game is generated a code based on hardware. Naming conventions can vary from person to person, so if each image set was tied to a specific name, once you edit that name it should break the link. Whereas its a generated code for each entry in the program so any value can change but you can't change the code it was assigned already. We also talked about playing around with an official list of Emulators. We would love to distribute emulators with LB for consoles with it already pre-setup so all you have to do is plug in the roms. Only problem is I can already imagine most Licenses and EULAs will prevent this from happening. The next step would to still pre configure all of the emulators, but each person has to plug in their own roms and the emulators, which we can link to from inside LB.
I don't really see it as a problem. Perhaps just a bit of PITA to set up.. LOL First, forget the extension. Look at the header of the file during import to verify the format. This way you KNOW it's a .nes vs a .fds ROM, etc. though, I'm not sure there really needs to be multiple formats.. so perhaps converting .fds to .nes would make things easier in the long run... the data a person needs to see really depends on the person and their filter preferences. We're as I like the auto-detect of the games from the gamesdb.com some of the information is lacking. Like there is a difference between UT3 and UT3:Black Editon, but Gamesdb.com doesn't make that distention. as for the container, true.. but then again, it's one of those things that as soon as other developers see that all the meta data for a game is located with that game.. it could make programming a lot easier. even better if an API was provided for the format to allow for auto updates of the information, etc. and would make changing aa folder structure (I personally, don't want my games under the LB folder, I want them in their own place. like E:/Games/Roms/Nintendo/Nes having a container that already has all your game information makes it as easy as coping a file. It would also remove the problem of the naming convention... the CART format would set it. Yes, having a built in set of EMU's would be pretty sweet. Though I believe you can embed MAME, MESS, and LibRetro.. which would take care 90% of the emulators, and since DosBox and ScrummVM are already there.. LB would be a fully featured launcher. at that point you could tack in like the VLC to add support for movies. Though, even if, the EULA for the software doesn't allow it to be embedded.. then support it anyway in the backend and provide a link to download it from the website. No reason why the download/install process couldn't be automated and it works around the whole embedding of the players. What I see as a need would be to separate the media manager from the launcher.. perhaps even separate out the configuration. If the media player software (EMus, VLC, etc) had there own configuration in let's say an XML file, that XML file could be placed on Google Drive, OneDrive, Dropbox.. what ever... updates to the configuration then wouldn't require a new build of LB. -
pogowolf said Good to see nice topics of conversation happening here!
The only problem I see with changing file extensions is then Emulators issues. The fact still stands, we rely on other programs. Adding in layers of anything could have untold issues. It will also make the amount of user data a person has get to be out of hand and you are being forced to use LB so that the container is of any use. Also, after my last scan of TheGamesDB and going through a lot of my games manually, I don't have to do that again. When a new version comes out I just replace the exe and it automatically grabs all the data. If I need to change directories I put the new exe in the new directory, run LB, then place my old XML and Images folder in to the new structure. As long as the XML file corresponds correctly to the right images folder it will be all fine. That is because each game is generated a code based on hardware. Naming conventions can vary from person to person, so if each image set was tied to a specific name, once you edit that name it should break the link. Whereas its a generated code for each entry in the program so any value can change but you can't change the code it was assigned already. We also talked about playing around with an official list of Emulators. We would love to distribute emulators with LB for consoles with it already pre-setup so all you have to do is plug in the roms. Only problem is I can already imagine most Licenses and EULAs will prevent this from happening. The next step would to still pre configure all of the emulators, but each person has to plug in their own roms and the emulators, which we can link to from inside LB. though there's a lot of information to read before knowing if you're just reposting something..
anyway...
my thoughts about the library is that perhaps the problem is being looked at from the wrong angle. Instead of looking at it like 'what media can this Util play", look at it from the angle of "ok, this is the media, what can play it" stance.
I know, for me, I could care less WHICH emulator plays what.. as long as it can play it quickly and within a tolerance for bugs.
Since such a library would pretty much be a database of meta data with a pointer to the media.
So NES games would be associated with the EMU's that play them.. perhaps with a crowd sourcing widget to know if X emu is horrible for this game, but Y is perfect.
this would also separate the Media Players (media.. roms.. pics.. isos.. music.. movies.. what ever) from the media itself..
what I really think is needed is a new ROM file format, I purpose calling it the .CART format. A container file that contains not only the image but also its meta data. Then, you'd only need to hit the GamesDB.com ONCE for the meta data and now that game has all the information association with with.. like Name, console, release date, etc.. the meta data could then be extracted and dumped into the database making importing a HECK of a lot faster..
and I've not had my coffee or mt. dew this morning, so if non of this makes any sense.. I'm going to blame it on the lack of caffeine. -
bd00 said
It also depends on how fast Jason can get the new system set up. Lol.
Like I said, I am making it all automated so anyone can set it up easily, within a few mins. It has navigation to get between instances too and it links to your main instance (All games) if you want to see everything together. -
bd and I also have the horrible coincidence... TO POST AT THE SAME TIME. xD You beat me by a few min. This time I directly referenced you. Now it goes down in the database that I am just a blind person who missed your post. xD
-
pogowolf said
bd, another forum user here, has LB open up to links of other instances of LB. Or he did at one point. That said, the XML and Library changes coming up may help fix Library lag. Like I said, we only got up to 10k, you tripled that. There is a will, and there will be a way, its just a slow going way because Jason is alone in coding, I have no code expertise so I am helping elsewhere. About using Filters. I thought the same thing, but some Emulators do keep multiple save files or misc items in where the rom is accessed, especially SNES emulators. zsnes and higan do this. So I would try to rescan your library or sort the folder by type and see what pops up. Some systems I have to do multiple scans but in the end it was worth it. Disc based systems needed multiple like *.iso, *.bin and *.img, but NES o0nly needed *.nes. *.fds is technically a different system but still technically falls under NES. Otherwise If you can't hold out there is the multiple instances of LB you can try. There isn't an easy way right now to fix that.SentaiBrad said [CyberSnipped] 1) Once I used the filters like *.nes, the out of control library was fixed. 2) [steam] I honestly don't use LB for Steam because there is no Steam API for that kind of importing function. 3) too big is too big. I would create instances for Sony, Nintendo, Sega, Steam, then DOS etc etc. Split it up how it makes sense for you, but that would be a quick solution right now.
Thank you for the reply! I'm pretty sure I'm not running into a dup thing because all my games are already broken down into separate folders. one for NES.. one for SNES, etc. and, so far, only 3 imports have been done, Steam, NES, and SNES. I understand not using LB for STEAM games, but I really like the 'all in one place' functionality let alone the extra meta data that comes with the GamesDB.com I'm not knocking the LB for not being perfect.. God knows I understand the programming process.
it was just an off-handed thought about how to handle the issue. I think one issue is that there really isn't an 'all in wonder' website / database for gaming information.
though I can't say the same thing about too big being too big. when there's a will there's a way. It's not like Google just stated nope.. Maps have too many points, too big is too big. However.. using an instance of LB for each platform type.. there is an idea.. but it does kinda defeat the purpose of having an 'all in one' front-end. -
When we had the initial lag I tested how long it took to start lagging and it was around 4k entries if I recall, maybe a little less. So now I sit at like 5.5 and Jason had almost double that with no over extended lag. By that, it wasn't taking for than a second or two which we thought would be normal once it got gigantically big. My imports were balooned hardcore because of a duplication problem as well as I didn't set filters when importing, so it imported the roms, then everything else. Once I used the filters like *.nes, the out of control library was fixed. As far as Steam game importing goes, it is kind of tricky. From what Jason explained to me and from what I saw, its depending on the acf files in each steam directory. So even if a game is uninstalled but some filing still remains, it will still add that game. I honestly don't use LB for Steam because there is no Steam API for that kind of importing function. So, its not perfect. He also understands that TheGamesDB is woefully incomplete as it relies on user input. I myself have added dozens of DOS games... lets not get started on there being no DOS system selection either. That is why he's trying to figure out the Wikipedia API, but that is going to take a while. It's not exactly easy to understand, not to mention he ones person also trying to add other new features and fix bugs, so we ask to give him time on that one. That's also another reason why im trying to take it upon my self to help out on the forums.
At a certain point, libraries can get so huge that it wont matter the revisions to the software, too big is too big. That said, he is working on a different way the program can handle things as well as a modified UI. If I understand correctly.. not even completely, each system you designate will have their own XML. Honestly, to solve your specific lag solution, I would use multiple LB instances. It is a portable program so its easily acheivable. I would create instances for Sony, Nintendo, Sega, Steam, then DOS etc etc. Split it up how it makes sense for you, but that would be a quick solution right now.
-
bd00 said Hmm, I seem to be mistaken. Just created a new instance of LB and the platform list in edit game has gone. There was a list in the other instance that I did not create. I remember seeing Ouya and I definitely did not put that there.
That's... odd. This was your existing LB config? Carried from beta or was it fresh with the new version? -
pogowolf said
Damn... we were pretty certain we got the lag issue taken care of... I have a 7000 count library and Jason bubbled his to 10k. Because sometimes there can be duplication issues in the cache, try this: Tools -> Clean Up Images It will find all of the images that are not currently assigned to any entries. From what I've been told, they're not saved per game they're saved to a generated code per setup based on hardware. So you import a game, it generates a code then assigns the data to that code including images. If you were to go to a different system and import that same game, or theoretically reimported and had the game twice in on library, the code would change then reassign new values to the entries. Since the images are cached, they're generally kept. There is a total clean up feature that should be coming at some point, but for now this is what we have. About the issue of certain things not being filtered correctly. My suggestion and what I have done, is when you import a section of games, name the Platform what TheGamesDB has them named. http://thegamesdb.net/platforms/ I say this because if you setup a custom Platform name like 'SNES' and import them all like that, when the GamesDB scrape happens it is going to rename the ones it finds to that specific platform. It will only rename the ones it finds on that initial import which is strict. So then you have 2 sections of Super Nintendo roms, 'SNES' and 'Super Nintendo (SNES)'. This should help in the filtering issue. That way when you select 'Super Nintendo (SNES)' It will list all of the games in your library, not just the ones it found on GDB.SentaiBrad said Hm, this issue has been solved for quite a while now. Which version of the program are you running? In LB Click Help at the top then About. Also, how much RAM do you have? Large libraries can't escape from the giant cache of images. It may not necessarily be LB just lagging but the system running out of proper resources. Idleing with my RAM recycler off I get about 1.2-1.5GB of ram usage. It is A LOT.
It's the current version, I just downloaded it like 2 days ago. so 3.2, and I have 16 gig RAM and a 6 core processor, so I don't beleive it's the hardware.
I kinda understand the cache setup from skimming ( ) the thread above.. to me it would make more sense to link the images to the display boxes that are on screen instead of cacheing the whole lot. was the 'load on demand' perfomance so bad it was changed to a cache?
still 8 seconds to save a change in the metadata which should have nothing to do with the cache is a bit strange to me. -
pogowolf said Evening all, I'm having the same problem. I have a rather large collection of games (steam and roms) and installed LaunchBox a few days ago while looking for a GOOD multi-emu frontend. All and all I like the interface and the the features.. but yeah.. it's slow with a large collection. Filtering down the imported games (steam, nes, and snes) for 'no platform' (since I want all the STEAM games listed.. and some didn't quite a few didn't (at 100 now) it takes 8 seconds to pull up the edit command. and 14 seconds to save it, then the system waits a few more to update the record. at this point it's my biggest issue with the system.. though filters on a large collection is also a bit of a PITA since the filters are set 'real-time', so on a large collection you set the filter then need to wait the 15+ seconds to filter the data and then wait again to add another,etc.
Hm, this issue has been solved for quite a while now. Which version of the program are you running? In LB Click Help at the top then About. Also, how much RAM do you have? Large libraries can't escape from the giant cache of images. It may not necessarily be LB just lagging but the system running out of proper resources. Idleing with my RAM recycler off I get about 1.2-1.5GB of ram usage. It is A LOT. -
bd00 said
It is going to take some time. There is a Wiki API but there needs to be a lot of arguments on each search. Like for the console, the game name and of course that it is a game all together and not a movie or something else.SentaiBrad said That's good then. My fear was that it did sound difficult with the wide range of options. There is really no standard. I was trying to think Ease of Use. Yea, setting up LB and scraping takes a while, but once you have that setup too, its as simple as carrying over images and config files. Web based games just happen to change a lot, that's the nature of web development I think. I'm all for it if it can be done easily and make sense for a majority of users who want to use this set of features.
It shouldn't be anymore difficult for the end user. If they are going to add browser games, they are going to add browser games, nothing will change except it will load full screen. If they use Xpadder, they already know that part. If they have set up a HTPC, this will be a breeze. Yeah, setting up is time consuming and scraping is a big problem at the min, which reminds me, are you any closer to adding that wiki scraper? -
bd00 said
That's good then. My fear was that it did sound difficult with the wide range of options. There is really no standard. I was trying to think Ease of Use. Yea, setting up LB and scraping takes a while, but once you have that setup too, its as simple as carrying over images and config files. Web based games just happen to change a lot, that's the nature of web development I think. I'm all for it if it can be done easily and make sense for a majority of users who want to use this set of features.SentaiBrad said Except that defeats the purpose of the controller. You can map opening and closing, then how do you map playing? Per each game? The point of an HTPC setup is to run setup once or import config files, then not having to touch it again unless something breaks. All I am saying is for the time you would have to spend doing this, you could have just loaded up Kongregate.com, looked through a few things you are thinking about playing then just clicking on the game. They're not suited for a controller. Edit: And I talked to Jason about being able to include button configuring in LB and it handeling config files and including emulators etc. But even if that happened, each flash game differs wildly. At least with consoles its the same button layout, that never changes.
I wasn't talking about adding button configs in LB, I use Xpadder for that. You can add keys to open and close AND play the games in the same config. I have not set up my controllers in most of the emu's I use, I just create a profile in Xpadder using the default keys provided. 9 times out of 10, that leaves me free controller buttons to map to things like closing the emu, adjusting the volume, saving/loading save states, etc. All I was asking Jason to do is add a timed keystroke (F11) when launching browser games, to save users who might add browser games the trouble of creating scripts or finding other workarounds. I thought it was a fair request and one that should be very easy to implement. As for the time it takes me to do this, I am unsure of what you are referring too? Launching a browser game from LB? Well I suppose it may be quicker not to use LB at all, go to your browser, and navigate to Kongregate.com and find the game you want to play. However, the same can be said for PC games, just create a shortcut on your desktop and double click it. Or ROMs, just open your emulator and load the rom, or better yet run it through RoM Jacket and create an exe or a .bat file and again just launch it from a folder on the desktop with a double click. But that is not what these frontends are about now is it? Or were you referring to Setting up Xpadder? It actually takes no longer than setting up the controllers within the emulators. Or do you mean because each browser game is different? This is true, but to be honest I very rarely play browser games so that is not a problem for me, but it may be to others and that is exactly why I am trying to think of ways to make this simpler for them. Since people seem to be adding browser games to LB, I tried to consider what would make this great for them and offered some suggestions. I was just trying to help. Also, a lot of browser games of similar genres often use the same keys, so a general configuration would work a lot of the time. I use X360 controllers and I map the mouse to the right thumbstick and the thumbstick button to the mouse click. This works fine for navigating menus. I was actually going to suggest people who use Xpadder, to start uploading profiles for browser games (and emulators) and we can try build a nice repository to save others time. For anyone interested, I have tried a couple of browser games and Xpadder works fine for both game controls and general keyboard/mouse actions, it could work with a HTPC setup without a keyboard and mouse with a lot of games. I can load a browser game from LB, have the browser load automatically to full screen, navigate the menu, play the game and exit back to LB all from the controller. So if anyone has a HTPC and some browser games they would like to set-up, all while avoiding having to use a keyboard and mouse, it can be done and is not very difficult. If anyone want's some assistance setting it up (Xpadder/full screen script/etc), just ask and I would be happy to help. -
bd00 said
Except that defeats the purpose of the controller. You can map opening and closing, then how do you map playing? Per each game? The point of an HTPC setup is to run setup once or import config files, then not having to touch it again unless something breaks. All I am saying is for the time you would have to spend doing this, you could have just loaded up Kongregate.com, looked through a few things you are thinking about playing then just clicking on the game. They're not suited for a controller. Edit: And I talked to Jason about being able to include button configuring in LB and it handeling config files and including emulators etc. But even if that happened, each flash game differs wildly. At least with consoles its the same button layout, that never changes.SentaiBrad said Honestly... It is a great idea, but for my purposes completely unneeded. I am glad people are finding ways to use LaunchBox to their desired effect. Considering right now it seems the direction is aimed at more Theater PC or HTPC setups, pointing back in to a browser completely defeats the purpose. However, regular laptop and desktop users could find that very handy. If you want to step up web integration Jason, I would suggest looking at Kongregate.com. Probably the best place for web based gaming. You may even find some rudimentary scraping options but I think it would be the same problem as MobyGames. So does this fit with the program in my opinion? Sure, anything can. Does it fit with ease of use? Not at all. Like I said though, im happy people are finding more awesome functions for LB.
That gave me a thought! If you want more of an HTPC experience, you can open the browser full screen. Then close with alt+f4 when finished (can be mapped to a controller button if using xpadder) and automatically return to LaunchBox. To open your browser games full screen you can press F11 (again, can be mapped to controller button with xpadder), or if you are using chrome I think you can use the command -start-maximized in your shortcut to automatically launch fullscreen. I don't think there is an option for Firefox, please correct me if I am wrong. If you do use Firefox, you could download Chrome Portable and save it to your emulators directory and only use it for browser games you launch from LB. Like an emulator.
*EDIT* It is probably possible to use the "additional applications" feature of LB and a small script that emulates the F11 keystroke shortly after launch of browser. Might do that this week sometime. Or maybe Jason could add the F11 keystroke emulation into LB when launching browser games so this wouldn't be necessary? -
Honestly... It is a great idea, but for my purposes completely unneeded. I am glad people are finding ways to use LaunchBox to their desired effect. Considering right now it seems the direction is aimed at more Theater PC or HTPC setups, pointing back in to a browser completely defeats the purpose. However, regular laptop and desktop users could find that very handy. If you want to step up web integration Jason, I would suggest looking at Kongregate.com. Probably the best place for web based gaming. You may even find some rudimentary scraping options but I think it would be the same problem as MobyGames. So does this fit with the program in my opinion? Sure, anything can. Does it fit with ease of use? Not at all. Like I said though, im happy people are finding more awesome functions for LB.
-
Jason Carr said
As far as marketing. You need to target specific groups. Target Lets Players, Completionists, Collectors. Go to Nerd sites, hell even some rom sites. Emuparadise is a great place, GBATemp (though not a rom site) is a great place to go. Twitter is too. Trying to have an out reach there. Not to mention various Emulator sites. It is literally compatible with every emulator. Though I think a Premium feature could be it being pre-shiped and pre-configured with the more popular emulators, obviously permitting permission or the respective licenses. So all you need to do, is provide the games and hit import, everything else is taken care for you. Emulators cant really be preconfigured because of differences in hardware for the most part, but LB its self could have them preset then on import you just specify an existing emulator or your own.bd00 said Yeah your right, not being able to disable it would be too much, forget I suggested that. I hate ads in apps too, but I do understand why devs need to do it. What we are talking about here, I don't really consider it as an ad but more of a notice. Seeing notices in free apps saying "If you like this app, please donate..." never bothers me like true ads do. I also think you should start encouraging your users to start spreading the word about LaunchBox, but that's just my opinion. I also think anyone who helps you in beta testing, should get a license too.
Good point about encouraging users to spread the word. I have zero marketing experience. Anyone have any ideas as to how best to encourage people to spread the word? Agreed about the licenses for beta testers; yes, that was the plan but obviously I do have to draw the line at some point. Everyone on this thread currently will get a license but I'd rather not hand out licenses to everyone who puts in a minimal amount of effort beta testing (otherwise we'll have people just hopping on to do the least amount of effort to grab a license). Significant contributors like all of you obviously are a different story. -
Conehead said
Well the plan was always to have a defined set of Premium Features. Jason and I talked about being very careful to not alienate the group his is unwilling or more importantly unable while still trying to make sure Premium is a good value. Donating helps Jason and should hopefully enhance your experience with the program. Trying to not make the previous version feel like an intentionally incomplete version. Also, I think the plan was to also still develop both concurrently, its just Premium has the added features which at this point are Themeing and some Power User functions, maybe even a little UI tweaking. LB will always be a free to use program at its core, with the same functionality you get now and a little bit more where it makes sense.SentaiBrad said
i too agree on this. but you must know that "the community decision " from here will be the view of just 10/20 people so for getting feedback on this from all the LB users you should use some other methods like a one time poll when the users open LB. also, not all are capable of donating even thought they would like using LB so i suggest that before releasing a premium version you should release an equivalent free version which would be stable like the Premium one but would have less features like Themes ,blocked Popup etc. and you could also release updates for the free version just like the Premium but with less features.Jason Carr said I've been thinking a bit. This is a pretty controversial topic I realize...but sooner or later, I'm gonna hit a wall with the project financially and probably eventually time-wise too. There's a million things to do yet with the project beyond what we already have, and I think it has HUGE potential. The issue is, the bigger it gets, the more money it will cost to maintain (web hosting, etc.) and the more time it will take to maintain and improve. I'm currently considering a freeware/premium model of sorts, where all of the current functionality is available for free, but you have the option to upgrade to an improved version with special features (like theming, more advanced customization options, etc.). I'm considering this mostly because I want this to be a long-term project, and I don't want to have to limit its features or not make it as good as it could be because I'm scrounging for funds. I also have to admit I would *love* for this project to be a full time focus (as opposed to the side project that it is currently). To be clear, anyone who's donated already would have the upgraded version free for life. I also hate DRM, so that would absolutely *NOT* be included, and the cost of the upgrade would be extremely inexpensive (probably $5 or $10 or similar). If everyone hates this idea, I won't go through with it. Straight up. I want this to be at least somewhat a community decision, as obviously it affects us all. So, to those of us on this thread, let me ask you a few questions: - Would you find it offensive or would it leave a bad taste in your mouth if LaunchBox went to this free/premium model? - Assuming you hadn't already donated, would you pay to upgrade to the better version with advanced features? - Specifically, what would you want to avoid doing if we did move to a free/premium model? Thanks everyone; please do speak up as we need as many people's feedback on this as possible. Obviously this isn't an easy decision to make (and trust me, it's not one that I had planned on making). Let me know.
I am torn on this. I agree with you, you want it to be full time. You would probably like to hire or recruit some extra help. But on the other hand, if the user feels like they have to pay for the program to any useful, then they just wont use it. They'll stick to current methods or find alternatives. I am not saying I am against it, I am saying the message needs to be clear that the program works just fine, and the same features that you've been used to since launch. Also make it clear you're not forgetting the general user base who doesn't want to donate, doesn't think its worth it, or simply can't - which is the camp I fall in to saddly. I want to donate, and will when I can, but can't just donate when ever. There needs to be a clear structure for the program. Usability, basic scraper functionality and maybe some other Features we can work out will be free. Always free, because if not then what is the point? But if you want some more advanced scrapper options, themeing support, maybe some forum incentives and priority support with the program, you can donate some money.
Thanks,
Jason -
Vinicius256 said
I was planning on donating several times when I can. So the first $10 I donate next Thursday will be on your behalf.Jason Carr said - Assuming you hadn't already donated, would you pay to upgrade to the better version with advanced features?
I would love to contribute by donating or buying the program, the problem is that I'm still 15 and to buy things on the internet is already terrible, because I have to ask my parents to buy stuff for me, and knowing my parents, they won't let me donate, sadly -
Yes, what bd said. It would most likely be $10 at max anyways.
My mind works oddly and I sometimes don't express everything. That said, if we only had the small version of the front and back covers but then kept fan art for Full screen game viewing then this could be achieved with the setup we currently have. Limit the most front facing images then use the fan art on full screen because I doubt a full screen image that has been resized to be smaller would look that good. There would also be the issue of how we do that since there is no standard and my thought is to reduce the image size by 50%-75% on import. It might make imports take longer too but in the long run should be a better option. We could also still show the front and back covers in their reduced form but make sure that the program doesn't expand them past their resolution.
though there's a lot of information to read before knowing if you're just reposting something..
anyway...
my thoughts about the library is that perhaps the problem is being looked at from the wrong angle. Instead of looking at it like 'what media can this Util play", look at it from the angle of "ok, this is the media, what can play it" stance.
I know, for me, I could care less WHICH emulator plays what.. as long as it can play it quickly and within a tolerance for bugs.
Since such a library would pretty much be a database of meta data with a pointer to the media.
So NES games would be associated with the EMU's that play them.. perhaps with a crowd sourcing widget to know if X emu is horrible for this game, but Y is perfect.
this would also separate the Media Players (media.. roms.. pics.. isos.. music.. movies.. what ever) from the media itself..
what I really think is needed is a new ROM file format, I purpose calling it the .CART format. A container file that contains not only the image but also its meta data. Then, you'd only need to hit the GamesDB.com ONCE for the meta data and now that game has all the information association with with.. like Name, console, release date, etc.. the meta data could then be extracted and dumped into the database making importing a HECK of a lot faster..
and I've not had my coffee or mt. dew this morning, so if non of this makes any sense.. I'm going to blame it on the lack of caffeine. 
Lol.
Like I said, I am making it all automated so anyone can set it up easily, within a few mins. It has navigation to get between instances too and it links to your main instance (All games) if you want to see everything together.
) the thread above.. to me it would make more sense to link the images to the display boxes that are on screen instead of cacheing the whole lot. was the 'load on demand' perfomance so bad it was changed to a cache?
still 8 seconds to save a change in the metadata which should have nothing to do with the cache is a bit strange to me. 
It would most likely be $10 at max anyways.
Library Brainstorming
in Features
Posted