+ T +

For all the major supported cores (CPS, NeoGeo, Cave, Psikyo, Konami, Toaplan, others...) FBL will outperform CoinOPS' MAME core every time. Obviously if CoinOPS uses the FBL core for certain games then these will run just equally well however as far as I know you have no filters or other options to choose from and no possibility for 1080i, all of which FBL handles and maintains full speed on pretty much all games. ESPrade runs full speed in FBL. Any slowdown you experience was most likely present in the original arcade machine. However, FBL does include an option to overclock the emulated CPU which will reduce or eliminate these slowdowns (it can cause problems in some though so use with care). If CoinOPS doesn't exhibit these internal slowdowns then it's probably using a similar feature by default. You can find this feature under General Options in the in-game menu.

Well ideally not downloadable extras. I'd like to include it all in one package but I'll have to see how the filesize stacks up. The screenshots alone are coming in at about 40Mb rar'd and while I know that isn't a lot these days I don't want the size to be restrictive to anyone. I won't be doing anything with videos since I don't think they're worth the space they take up. But video preview support in FBL remains intact and works fine with marquees so anyone is free to create a video pack. Is the cheat.dat for FBA the same as the one used in MAME? If so, I don't see a problem including the latest one which would support pretty much all the new games. More info on this would be appreciated. The only UI changes in 1.4 will be the new global screen sizing, the marquee feature, and one or two fixes. The focus on this release really has been the emulation side of things and getting as many games added/working/fixed as possible. Once this release is out the door I'll look at all these requests and give an honest idea of how viable I think they're going to be. Thank you all for your patience.

Just a couple of tidbits about the upcoming release; Firstly there will be a new default skin (by Neil222) with an arcade-cabinet style. And secondly, to complement this, I've added marquee support. So as well as your screenshot or video preview the game's unique marquee image will appear at the top of the cabinet for an authentic look. I'm also planning to include a full set of screenshot AND marquee images either as part of the 1.4 package or as downloadable extras (depending on size) so you will get what is in my opinion the best and most slick looking GUI on the Xbox straight out-of-the-box.

The Pacman games aren't vertical games in the sense that they don't rotate the display the way most vertical games in FBA do. FBL 1.4 will include preconfigured inis for games like this with unusual display properties (Pacman, Darius, Ninja Warriors) which should make them look right. I'll look into the rotation setting not saving though.

The short answer is yes, there is a file you can edit and input the values directly. The long answer is; FBL's true default screen size values are hardcoded into the emulator and cannot be changed. What you are doing when you resize the screen in the UI is defining a set of values that act as modifiers. The sum of the base value + the modifier determines the screen size. The modifiers are represented by long decimal values that are relative to the base values and therefore cannot be translated into standard pixel dimensions. So how useful the ability to directly edit them will be I'm not sure, but it does make it easier to share your screen size with other users.

Unfortunately, due to the way FBL handles video, it's extremely difficult to determine how many pixels or what ratio a given screen size is. Anyone who has ever tried to achieve a specific size on Zsnexbox will understand exactly what I mean. In terms of visually filling a screen the system works great but it's simply not intended for use of specific values. As far as I know Raiden Fighters runs on a CPU that isn't emulated under FBA so it would require some serious dev work of the sort that is way beyond my capabilities. I can change existing code and add code from other sources but if you ask me to code anything from scratch then I'm afraid you're asking too much.

The new screen resizing code is done and it works pretty much as you describe. There is a default screen size setting which can now be adjusted in the main video options. You can also adjust the screen size for an individual game using the in-game video options. So this should keep everybody happy. With vertical games the screen values are simply rotated so the default horizontal width will become the default vertical height when rotated (and the same for the other axis). This isn't as problematic as it might sound and is even desireable to those who like to keep their ratios consistent as, if you set your horizontal default to a perfect 4:3 ratio then your vertical default will automatically be perfect 3:4. It just means some playing with the settings until you find a happy medium that fills your screen in both standard and rotated modes. I've got no problem with changing FBL's preset default values if that's what everybody wants. The existing values are geared primarily towards SD users since they allow for overscan, but nes6502 clearly saw it as better to have black borders on an HD setup than to lose parts of the screen on an SD setup and I agree with this. If I was going to set new defaults I would probably be more inclined to set the screen to reflect how an actual arcade board's video output would look (most games in FBL use a vertical resolution of 224 so it would be 448 vertical and an arbitrary stretched horizontal value as would be displayed by a CRT monitor). The ROMs in FBL aren't based on any particular version of MAME, most will be between 0.139 and 0.141. I'd like to update them all in future to match the latest MAME dumps, but that's further down the road. But as I said, full DATs will be included.

Quite a few ROMs will need updating in this release (not to mention all the new ones that are added). Obviously I won't be making any packages available complete with ROMs as I consider this to be an extremely dubious practice, but full DATs will be included. (TIP: If you have an FBANext set and an up-to-date MAME set then you should be able to put an FBL1.4 set together easily)

Well I was more thinking of releasing in the next couple of days but if you'd rather I waited til September then I couldn't refuse the wish of a condemned man. (j/k, congratulations ) Speaking of skins, I wanted to swap the default skin for one of Neil222's since they really are excellent. I've tried emailing him through the forum to ask his permission to do so but I'm unsure if he's able to receive messages since he's sadly no longer active here. If anybody here is registered on any other forum he frequents could they possibly pass on my request? Many thanks. Finally I just want to say that I certainly have no interest in being 'first' to release a build with iq_132's drivers. I'm sure everyone here knows the quality of the emulation experience provided by FBL and I promise you won't find that anywhere else. The real deal is coming. Accept no substitutes.

What makes you think so? If there's one thing you can be sure with iq_132 it's that, just when you think it can't get any better, he manages to pull something else out of his box of tricks . Plus, even though the PGM drivers would be enough of an update on their own, there's still plenty more in this release and I want to make sure it's all good before making it available. How other 'developers' are handling their projects has no bearing whatsoever on this one. Should be soon though.

Quoted for clarity. I'd like to have a go with MAMEoX as I'm sure there are many drivers that could be added from subsequent versions of MAME. Unfortunately the source to MAMEoX128Plus which I consider to be the most solid version of the MAME core on the Xbox was never made available so I'd be going back to the same old version that CoinOPS is based on. Plus there's the issue of time as well, I'd like to make a go of keeping FBL alive and I won't be able to devote the kind of time I have over the last couple of weeks to it on a continuous basis, so it'll be a case of doing what I can when I can which doesn't really allow for a second concurrent project.

While we're discussing screen sizes, can I just ask everyone a question? Currently FBL uses separate screen size settings for every single game and I've always found it inconvenient having to adjust each game individually to fit my screen, and even more inconvenient having to use approximate values meaning that no two games are ever exactly the same size. I've also never come across a situation where I need a particular game to have it's own separate screen settings. So my question is this; would it be better to just use a single global screen size setting for all games similar to the system MAMEoX and it's derivatives use? So any changes you make to the screen size are carried over to all games or do people actually use the individual sizes for some purpose? Clearly it would be great to have the option for both but right now I'm interested in which people would prefer if it could be either one way or the other.

That's correct. Arcade games run at a huge variety of different resolutions, but when output, the display device will stretch the video horizontally to fill the screen. The amount of stretching would vary slightly from screen to screen so there is no way to have one single value that is arcade perfect, but 4:3 is a great all-round ratio that gives a visually accurate representation of how the game would look on an arcade monitor. All 'pixel perfect' does is take the game's internal resolution and doubles/triples it which means you end up with all kinds of crazy shapes and sizes which you would never see on a genuine arcade machine since all standard arcade monitors are 4:3 or 3:4. EDIT: As to your question about how to set the screen in FBL. By default FBL displays horizontal games in 4:3 and vertical games in 3:4 which is exactly how they should be so really you shouldn't need to adjust anything at all. Unless of course you have an HDTV in which case you would need to switch it to 4:3 mode (I don't have one personally so I'm assuming that's possible) to get a visually accurate display.

Something I would like everybody to keep in mind; I'm really not much of a coder. I understand enough to be able to tweak existing code or add new code from other sources even troubleshoot problems but when it comes to coding something from scratch I just wouldn't know where to begin. It's important to me to be open about my limitations from the get-go as (while I do surprise myself occasionally at what I am actually able to do) I wouldn't want anyone to have any false expectations and certainly wouldn't want to be seen as someone that implies I'm capable of things on which I can never deliver. Also, my primary interest is in the emulation side of things. Drivers, performance, and compatibility updates will always take priority over interface-related changes and certainly in this initial 1.4 release I haven't touched the frontend code at all. That isn't to say I won't in future of course, again I just want to keep everyone up to speed with how things are. All that being said, for my side of things I will take every request into consideration. I would stress again though that any requests are best saved until after the 1.4 release since they are in danger of being lost here.

Well yes, if are actually going to take a proportional resolution and use an external device to stretch it to 4:3 then you are indeed achieving an accurate reproduction of the original display. But I'm sure you'll agree that most users don't have the benefit of such additional equipment and therefore won't achieve anything resembling the original hardware using these 'pixel perfect' settings. I understand that a lot of people see using proportional resolutions as improving on the original video by not stretching it to full screen as the original output would have done. I guess this is the same as graphics filters, some like the 'enhanced' look and others prefer a more accurate representation of original system. Each to their own I suppose, it just irks me whenever I hear anyone describing 'pixel perfect' as being more true to the original system. This simply isn't so unless you're using a setup such as yours to achieve 'pixel perfect 4:3'.

Never understood the appeal of 'pixel perfect' myself. Just seems like an inventive way of making arcade games look completely different to how they actually looked in the arcade. All these crazy numbers may be 'pixel' perfect but good old 4:3 is arcade perfect.

Counter Run uses a driver that isn't currently part of FBA so you'd effectively be asking for a whole new driver to be ported. However the MAME driver should be easy enough to add to CoinOPS, it may not even require any changes I'm not sure it's been a long time since I did any work with MAMEoX drivers.

FBL was ported by nes6502 and these are his words taken directly from the release notes which I believe sum up the feelings of everyone concerned: So yes, it is my intention to make a full source release along with any binaries and I would expect anyone who uses the code for their own project to do the same. As for 'permission', nes6502 made it very clear on these forums that he did not wish to have any of his work 'rebranded' as part of CoinOPS and since I can't lay claim to any of the code in this release I can only remind everyone of that. The source will be available though so BP can do as he wishes with it, I don't personally follow CoinOPS development so I doubt I'll be aware of it anyway and for my part I'll certainly continue to work on FBL regardless.

I think that the term 'added games' as CoinOPS uses it is (deliberately?) rather misleading. CoinOPS is intended to be a package complete with roms so when arcade games are described as 'added' it simply means that roms have been added to package, not that support for any new games has been coded into the emulators.

Correct. Well I may as well let everyone here know that recently I've been working away on an update to Final Burn Legends. I've updated many core components to the latest PC version of FBA and am also using code from FBANext and from the truly skilled community over at the Neosource forums to try and add/fix as many games as possible. There's already a nice list games that are now working or had issues which are now fixed. And I've just added iq's PGM code which is running extremely well. There are a few more fixes I want to implement before release, but it shouldn't be much longer now. Please don't request anything just now, when v1.4 is released I'll start a thread. Hopefully this will breathe some much needed life back into these forums.

Good news indeed for all of us. Many many thanks iq. And to those expressing concern that it's FBA-XXX shown in the video, don't worry. I can assure you all that the code works wonderfully in FBL as well.

My understanding is that it isn't just the fact that protections are improving to prevent the running of homebrew code, but also that console architectures are becoming less and less similar to the conventional PC architectures. The reason the original Xbox was such a gem for homebrew was the fact that it effectively was a PC in console form (with some minor differences of course). But the motivation for development on new platforms isn't about getting things running better or playing more games, it's about seeing how much can be achieved within the limitations and challenges of the hardware. Even though one system may well be the greatest homebrew console platform ever, it will inevitably die out in favour of new platforms regardless of how much more difficult they are to modify or develop software for since those difficulties are the things that tend to hold the appeal for developers.

I remember a while back there used to be a Sierra SGI adventure game interpreter for the GBA. It was great to run on Xboyadvance since you chose the action commands from a menu rather than having to type them.

The only way you'll see a Saturn emu from BP is if someone else releases it first.

bb2020; bb2020a; bb2020h; countb3; 4play; sonicwi2; sonicwi3; aodk; alpham2; androdun; aof; aof2; aof2a; aof3k; aof3; bakatono; bangbead; bangbedp; bangbedn; bstars2; bstars; bstarsh; flipshot; blazstar; bjourney; breakers; breakrev; burningf; burningfh; ctomaday; neodemo; marukodq; cnbe; columnsn; crsword; cthd2003; Cthd2k3a; cthd2k3d; ct2k3sp; ct2k3spd; ct2k3sa; cyberlip; diggerma; doubledr; eightman; kabukikl; fatfury1; fatfury2; fatfury3; fatfursp; fatfursa; fightfev; fightfeva; fswords; fbfrenzy; ngfrog; galaxyfg; ganryu; ganryun; garoubl; garoup; garou; garoun; garouo; garouon; gpilots; gpilotsh; ghostlop; goalx3; gururin; fr2ch; ironclad; irrmaze; jockeygp; jockeygpd; ltorb1; janshin; karnovr; kof94; kof95; kof95h; kof95a; kof96ep; kof96; kof96h; kof97; kof97h; kof97pls; Kof97pla; kof98k; kof98n; kof98; kof99e; kof99nd; kof99n; kof99p; kof99; kof99a; kof10th; kof10thd; kf2k5uni; kf10thep; kof2knd; kof2000n; kof2000; kof2001; kof2k1nd; kof2001h; kf2k1hnd; kf2k1pls; Kf2k1pla; kof2002b; kof2k2nd; kf2k2mp; kf2k2mp2; kf2k2pls; kf2k2pla; kf2k2plb; Kf2k2plc; kof2002; kf2k3pcb; kf2k3pcd; Kf2k3bd; kf2k3bl; kf2k3bla; kof2003; kof2k3nd; kof2003h; kf2k3hnd; kf2k3pl; Kf2k3pd; kf2k3upl; Kf2k3upd; kof2k4se; Kf2k4pls; kog; kotm; kotmh; kotm2; kizuna; lans2004; lastblad; lastbladh; lastbld2; lresort; lastsold; lbowling; legendos; magdrop2; magdrop3; maglord; maglordh; mahretsu; matrim; matrimbl; matrimnd; mslug; mslug2; mslug3; mslug3nd; mslug3h; mslug4; mslug4nd; mslug4h; ms4hnd; ms4plus; ms5pcb; mslug5d; mslug5n; mslug5; mslug5nd; mslug5h; ms5hnd; ms5plus; Ms5plusd; mslug3b6; mslugx; minasan; miexchng; mutnat; nam1975; ngem2k; neo2500; neobombe; neodrift; NeoGeo; neomrdo; neonopon; neopong; syscheck; turfmast; neocup98; nitd; nitdbl; nitdn; ncombat; ncombath; ncommand; ninjamas; overtop; samsho4k; panicbom; pgoal; pnyaa; pnyaan; poknight; popbounc; pspikes2; preisle2; preisl2n; pulstar; pbobblenb; pbobblen; pbobbl2n; puzzledp; puzzldpr; joyjoy; quizdais; quizkof; quizdai2; rotd; rotdnd; ragnagrd; rbff1; rbff1a; rbff2k; rbff2; rbff2h; rbffspec; ridhero; ridheroh; roboarmy; samsho; samshoh; samsho2; samsho3; samsho3h; samsho4; samsho5b; Samsh5bd; samsho5; samsh5nd; samsho5h; Sams5hnd; sam5spnd; samsh5sp; samsh5sph; sam5shnd; sam5snnd; samsh5spn; samsho2k; samsho2k2; savagere; sengoku; sengokh; sengoku2; sengoku3; sengok3n; beast; shocktro; shocktra; shocktr2; socbrawl; socbrawla; spinmast; stakwin; stakwin2; strhoop; s1945p; s1945pn; sdodgeb; ssideki; ssideki2; ssideki3; superspy; svc; svcpcb; svcpcba; svcboot; svcnd; svcplus; svcplusa; svcplusb; svcsplus; mosyougi; tws96; trally; tophuntr; tophuntrh; tpgolf; twinspri; ssideki4; vliner; vlinero; viewpoin; gowcaizr; wakuwak7; wjammers; wh1; wh1h; wh1ha; wh2; wh2j; wh2jh; whp; zedblade; zintrckb; zintrkcd; zupapa; zupapan; zupapad;