+ T +

That's a driver file and needs to be compiled with the sourcecode. It won't be of any use to you unless you're compiling your own build. Keep in mind that FBL does not have any support for lightguns at all. All that's happening when you plug in your lightgun is it's replacing the analog stick which, in turn, is simulating mouse input which, in turn, is emulating an arcade lightgun. So really it's a wonder that it works at all. Regarding the sluggishness; in addition to altering the deadzone settings, you might also want to have a play with the Cursor Speed setting under Controller Options in the game menu. Increasing this speeds up the rate at which the analog stick moves the cursor so theoretically it should improve things. As for the centering, the analog input already defaults to the center of the screen so there's nothing to adjust there. It sounds like it would require some kind of gun calibration to work correctly, but since there's no provision whatsoever in the FBL code for that I'm afraid I wouldn't even know where to start.

Thanks for that. Runs amazingly well. Excellent stuff.

Just to clarify; the forum rules are that you cannot ask for ROMs whether you own the original game or not. Also FBL does not include any illegal bios files; the bios files neogeo.zip and pgm.zip are separate files that are a part of the ROM set. But, forum rules aside, this is intended as a development thread and it makes it harder for me to keep track of requests and reported bugs if it starts to get bogged down with people making and responding to ROM and/or emulator requests. I was aware that opwolf3 had calibration issues. But it's currently running at such a poor framerate I didn't think there'd be much interest in playing it this way. Now that I know differently I'll look into. Indeed.

Discussion of where to download emulators or ROMs is against the rules here and in any case I'd prefer it to not be discussed in this thread.

I'm sure some people do but, as you've already noticed, they're selling themselves short by doing so. And it's not just the filters either; the FBA core in CoinOPS doesn't allow configuration of any kind including access to DIP switches and service modes. As for the "bugs", the last I heard the author was not using FBL but an old version of the FBA core taken from nes6502's Final Burn port. He certainly shouldn't be using any code from FBL since I state in every release that this should not be done without releasing the source (and I've also made it clear that it's my personal wish and the previously expressed wish of nes6502 not to have FBL included in CoinOPS). But in any case, I've found it to be true in the past that the author will often use the term "bugs" extremely loosely to refer to things like tiny reconfigurations of options or controls. The fact is, it's ridiculously simple to keep track of fixes you make in the code, regardless of how small or how many. If these hundreds of "bugs" actually existed and were fixed in CoinOPS, I'm pretty sure they would be shouted about in the changelog. Any bugs that come to my attention, I will fix. Any "bugs" that don't come to my attention clearly aren't bothering people enough to notice them if they exist at all.

Just to revisit this topic; I don't want people to think I'm dismissive of these UI requests. In fact I've taken on board the suggestions in this thread and have come up with some possible ways of implementing them that I think will be more widely beneficial. Feel free to keep them coming.

NeoGeo savestates apparently caused problems in early builds of FBL and so nes6502 disabled them. Other than that I think there are some graphical effects in the driver that aren't emulated 100% correctly but my info could be way out of date there. Rest assured though I won't be updating any code in FBL if it's detrimental to the performance of existing games, in fact astute users may have noticed that I even added an additional xbe core to v1.666 specifically for the purpose of running older drivers that perform better than their newer counterparts. So you can update with confidence that existing games will always run as well as or better than in previous builds. EDIT: I just checked Alcon and it's flagged as not working in the driver. So there's your answer. Play the bootleg clones for now.

I'll look into the problem with Alcon. In the meantime though, the Slap Fight bootleg clones all work fine in 1.7. It's not so much the same ethos for FBA as it is the fact that FBA drivers are ported from MAME drivers so the "ethos" is carried over in a sense. But you're right that if the most recent version of MAME were ported to the Xbox, many games that ran perfectly well in older builds would run poorly due to increased accuracy in the drivers at the cost of performance. This is partly my thinking as to why these new FBA drivers for older games struggle to get a decent framerate on Xbox hardware. The new NeoGeo code has no performance issues at all. I compiled a working build of FBL with the updated driver and it runs just as well as the previous driver. The problem is that without VMM, only the smaller games load and anything that requires more RAM than the Xbox physically has won't work at all. It's beyond my ability to code new VMM routines for the updated driver and at the moment there's no real benefit to doing so since the only major additions are multi-slot support (which would be unsuitable for the Xbox anyway) and the NeoCD support (which should theoretically work without VMM).

My understanding is that it involves de-soldering the existing RAM chips from the mainboard and replacing them. On a personal note, I'm not keen on the idea of the RAM and CPU upgrades; for me the appeal of running emulators on a console is that everybody has the exact same hardware and the challenges are in optimising the code to get the best performance within those limitations. Something else I've been wondering about; drivers for older games from past builds of FBA always seemed to run well on the Xbox, however with this latest wave of updates the majority of newly added games don't perform too well (including the most recent Data East drivers from 0.2.97.13). Is this because they're ported from the latest MAME drivers which have become more resource intensive or is it that FBA is being coded with the current specs of modern PCs in mind, or is it simply that the drivers are new and there is room for optimisation? Just curious.

Wonderful news that you've been able to get some more FPS out of the M92 games. Is there any chance the optimisations could be applied to the M72 games as well? They perform slightly better so I'd think there'd be a greater chance of getting them up to full speed with just a little extra push. What's the current framerate of tkdensho? I ask because with VMM games it's possible to get a few more FPS by having them run in one of the separate xbe cores. The difference is not massive but every little helps. While you're perusing the source is there any chance you could take a look at Top Speed on the Taito Misc driver? I can't figure out why this one isn't working. It doesn't seem like it would be a memory issue considering the small size of the game.

This isn't an issue of legality or ethics or anything of the sort. What people choose to download is their own business, but when it comes to what is acceptable to discuss within the rules of a community it's a simple matter of respect for developers and the scene as a whole. I do not (and nor does any other developer I know of) consider it acceptable to distribute ROMs with emulators coded by others against their express wishes. I also do not consider it acceptable to distribute full pirated games and to discuss the same on an emulation forum. And I do not consider it acceptable to take the work of others, rebrand it as your own, and then not even have the decency to obey the license of currently active projects by releasing the source. ace9094, your attitude is typical of the selfish and short-sighted leeches that CoinOPS and other dubious projects like it depend on for their userbase. As long as you're getting your games to play you don't care whose work, whose wishes, or whose rules you have to take a dump on. With people such as yourself around it's a wonder there is any Xbox development left at all. Frankly it's my view that the emulation scene as whole would be the far better off without these 'projects' and without your sort. Call it what you like, but the above is my opinion and I'll express it wherever I see these sad and shameful practises surface.

I did plan on taking a look at the NeoCD stuff for Final Burn Consoles (I'd like to keep Legends as purely arcade games) and it's something I'd be very keen to try and get going. It seems pretty daunting with my limited coding knowledge and I think your latter suggestion would be the only way forward as I at least have some understanding of how that might be achieved. Any helpful input or advice you could provide would be most appreciated. Would FBA be able to load ISO+WAV files from in the same way as standard ROMs? Also I'd need to remove the elements of the NGCD code that currently rely on UI routines for selecting games; I'm not currently sure how tightly tied into the overall driver those routines are and whether the code will compile at all without them. Basically I anticipate a lot of obstacles so I've been putting off having a bash at it. But I guess it's about time I did.

I've finished merging in the updates from FB Alpha 0.2.97.13. The only reason I haven't released another build is because, in terms of FBL, the changes are minor and it sounds like you and Barry have some exciting stuff coming up in 0.2.97.14 so I figured I'd wait and have the next release incorporate both. The update doesn't include the new NeoGeo driver because obviously it has no Xbox VMM routines and has changed too much from the previous code to incorporate the existing ones. So in order to maintain support for the larger games I've left the NeoGeo component of FBL the same as in previous builds and have only updated the ROM sets in line with FBA 0.2.97.13. Anyway, I'll package up the current WIP source and PM you a link shortly.

This is also true of FB Alpha, since CoinOPS includes an FBA core. I don't know whether it's taken from FBL or not, but even so it is required that the source be released with any binaries. As for XBMC, as far as I know CoinOPS does not currently use any code from it but BP has been talking for years about making a some kind of CoinOPS/XBMC hybrid. If this happens he will also be required to release the source under the XBMC license.

You seem to be making a point that has nothing to do with anything I've stated. My personal opinion of CoinOPS has no bearing on the fact that this is not a warez forum. I haven't alerted anyone, I've simply stated my view that I personally don't welcome discussion of a downloadable package that includes blatantly pirated Xbox games. Feel free to ignore my comments and continue if you wish but I don't think this sort of thing is good for the forum or the scene as a whole so I'm not going to let it go unsaid.

There's a big difference. This is an emulation forum; discussing ROMs is a part of discussing emulation but even this does not extend to discussion of emulator packages that distribute ROMs along with binaries. However distributing pirated games for a system where no emulation is involved is a different matter altogether and has long been frowned upon in pretty much every emulation community of which I've ever been a part. I'd like to think that this forum is no exception. Unless of course you wish to make the claim that CoinOPS is the first emulator on the Xbox to emulate the Xbox!

Congrats on that. My point above is referring to the fact that the CoinOPS 3 package contains rips of the following commercial Xbox games; Marvel Vs. Capcom 2, Midway Arcade Treasures 2 & 3, Street Fighter III (from SF2 Anniversary Edition), and possibly others. My personal view is that this goes way beyond discussing ROMs within the context of emulation and is just outright game piracy, but I'll leave it to your discretion.

It's most likely memory related, yes. kenshiro has been doing some work on games that need VMM added but it isn't always easy to tell whether a game fails to load due to memory shortage or something else entirely. Well I'm definitely done messing with the screen sizes, so anything you do from now on should be future-proof.

CoinOPS was on shakey enough ground when it was being distributed with ROMs, now it seems to have sunk to the new low of having blatantly pirated Xbox games included in the package. I'm no mod but to my mind this falls way outside the rules of this forum and in my opinion undermines legitimate development.

Really? You seriously prefer to go without the infinitely more robust codebase, more polished interface, improved performance, faster loading times, and literally hundreds of extra games just to save yourself a few seconds of time configuring buttons? Each to their own I suppose.

The ROM set in 1.7 is exactly the same as in 1.666 which is based on MAME 0.143u8. I don't have any problems using the DATs with the latest Romcenter so I'm not sure what to suggest there.

Scrolling by holding down the D-pad buttons sounds easy enough and I can see the benefit; I'll look into it. As for adding favourites mid-game; that definitely falls under my point #4. Just add it to your favourites when you quit the game. Apologies if I've asked this before but could you explain how this would be more beneficial than just enabling/disabling clones in the menu?

I have no problem with it at all. It may even be more useful this way in that when/if I do eventually get round to adding more stuff to the UI, at least I won't have to trawl through old topics. There are however a few things I'll mention just so people don't get their hopes up with this sort of thing: 1) I'm not really interested in the UI. While I do have every intention of filling UI requests where possible, the fact is that it's the emulation side of things that interests me far more and as far as I'm personally concerned, the FBL UI is pretty much perfect as it is. So please keep in mind that any work on the emulation side of FBL will always take priority over UI changes. 2) I'm not much of a coder. Please don't assume this is any kind of modesty, it's absolutely true. So if a feature you're requesting involves coding anything new, as opposed to tweaking or updating existing code, then chances are it's beyond my ability to add. 3) With UI requests I always weigh up how much work would be involved in adding a feature against how many people it will potentially benefit. I can't afford to spend hours figuring out how to get something working if it's specific to the needs of just a single user. 4) I probably won't add features that boil down to user laziness. I don't believe a UI should hold your hand, be idiot-proof in any way, or do anything that you can easily do yourself. I hope that lot doesn't come across as too negative but I don't want anyone to feel I've misrepresented my intentions or made false promises about anything. At least this way, we're all on the same page.

Depends what needs fixing but generally, yes. FBL goes by the CRC of the individual ROMs not the name, so name fixes are less important. But the name of the zip is important to have right and there are other fixes that can affect whether a game will work or not. Basically you should have everything green if you can, because don't come to me for support with yellow ROMs!

If it's Genesis games you want then you should check out Neogenesis which is currently the best emulator for that system available on the Xbox. CoinOPS uses old outdated emulator cores, you're much better off with the latest versions of individual emulators.