+ T +

The Final Fight hack is listed under it's correct MAME name which is 'Street Smart / Final Fight (Japan, hack)'.

FBL's scanline filter isn't coded in assembly as far as I'm aware. Maybe he'd have more luck with that. I believe the exact same filter code is used in NestopiaX.

I'm not saying composite is the way to get the best looking image. I just think it's interesting how developers intended for their games to be viewed through a composite connection and actually used these visual tricks to take advantage of the poor quality video and produce effects that would otherwise be impossible. It's just a testament to the inventiveness and resourcefulness of 90's games programmers.

Yes, you will have to enable hardware filtering and preferably the Simple2X filter to eliminate the blur that introduces. There is no way around this because, no matter what you do, the image must be upscaled. Since it cannot be stretched to an accurate size in the hardware, the stretching must be emulated in the software. The only way point filtering will be useful is if you intend to leave the screen at 512x448 which looks absolutely nothing like the output of the system and is therefore not viable. Yet again, I'm totally puzzled by this pixel-perfect stuff; it just looks silly to me. Hardware and software filtering is really the only option for anyone who wants their NES emulator to look as close as possible to an NES. EDIT: Just read your latest post. Obviously I'm talking about reproducing the look of the original system without having to purchase extra hardware.

Now this is good stuff. But could you ditch those ridiculous pixel-perfect values and post up some shots of the Xbox screen scaled to the same proportions as the NES display? Since most people don't have the extra hardware to produce the 240p output.

Apparently it's not as rubbish as previously thought. Take a look for yourself (scroll down to the Genesis shots): http://www.chrismcovell.com/gotRGB/screenshots.html#sms See how the line dithering in Vectorman shows up as a solid colour in composite? Well that's a colour that the Genesis would be incapable of displaying otherwise. Also the line dithering beneath the spotlights in the same shot actually show up as a blue glow in composite mode (as they are intended to) whereas in RGB and the emulator shot, all you see are the dithering lines. And look at how the waterfall in the Sonic shot actually looks like water whereas the clearer images show it as just a bunch of vertical lines. I'm sure there are other examples to be found of how programmers took advantage of composite blurring to achieve otherwise impossible effects in games, but these are great ones. I'm seriously tempted to hook my Xbox up with composite cables now just to see if these effects still work. And who knows? I may even leave it that way.

One thing I found really interesting on that website is how programmers deliberately designed graphical elements in games to take advantage of how they would appear when viewed through a composite output. Check out the waterfall in Sonic on the screenshots page. Very cool stuff and definitely lends weight to the argument that the only way to play old games is on an old crappy TV.

Yes, Cospefogo has hit the nail on the head. That's what I was referring to when I said to emulate the internal stretching would be impossible without altering the Xbox's video output. The 10x11 mode is a built-in function of the Xbox graphics adapter just like the flicker filter and display softening. An emulator can tap into these functions and make use of them, but it can't alter them unfortunately.

Stop you? I'd join you if I could.

You're right. The image is horizontally stretched somewhat in the hardware prior to reaching the screen. You'll see this if you plug an original system's video output into a capture card. But to emulate this would be almost impossible without altering the Xbox's video output. Also, no CRT display would display a game at the equivalent of 640 pixels wide, that's simply too big. If you want a close approximation of a system's outputted width in pixels then it will be somewhere between 570 and 600 for most displays. Wii VC seems to use around 576 which is a good horizontal value. With an Xbox emulator you will never escape the fact that the image needs to be upscaled. So the best and most practical method of achieving a display as close to accurate as possible is to use hardware filtering to eliminate those distortions and scale the screen to the appropriate vertical size and a fixed horizontal size. 256x224 becomes 576x448, 320x240 becomes 576x480, etc. Trying to set pixel-perfect horizontal sizes is just a waste of time since it won't get you anything like an accurate display. So this is the approach I'm taking with FBL to get the scanlines working properly across as many games as possible. For most games FBL will be sized to be double the native vertical resolution and all games will use the same horizontal size (probably around 576), thus creating as arcade-accurate an image as it's possible to achieve with this hardware.

To illustrate here are some images I put to together to break down roughly how CRT TVs display an image. Firstly this is the image as output by the console in its original native resolution (in this case 256x224): Now when you output this to a CRT display, it gets broken up into lines. The number of lines is the same as the original vertical resolution, except that there is a blank line every other line, hence we have what we refer to as scanlines. Note that the black bars at the top and bottom are because a CRT TV has 480 lines but this output is only utilising 448 of them (224 video and 224 blank): When it comes to the width, the original horizontal resolution is stretched to the length of the line. The internal horizontal resolution is entirely lost and irrelevant to the actual width of the final output, as shown in this half-and-half: When all that's done, what you end up with is this; and this is exactly how the image would appear on a CRT TV: The black borders would invisible on most displays due to overscan.

The thing is, when talking about CRT TVs, it's completely redundant to refer to horizontal resolution. These displays don't have a horizontal resolution since the display is not made up of pixels, it's made up of horizontal lines. Each line is approximately one pixel tall so the number of lines used vertically does conform to the native vertical resolution of the hardware (except every other line is blank hence the scanlines). However the native horizontal resolution of the hardware is irrelevant since, however many pixels there are, they will always be stretched to the full length of the line. So in order to replicate this with an emulator we need to set the vertical size to a multiple of the native vertical resolution of the system (hence giving the correct number of 'lines') and then we just need to decide how long our lines are going to be, since this is determined by the display and is different for every TV; there is no 'perfect' value. And in case you're wondering about rotated arcade games. The above still applies since it's just a regular monitor turned on its side, so the vertical lines now appear to the player to run horizontally across the screen. The 'height' of the lines is still determined by the display and will still always be the same size.

Entirely untrue. CRT displays, whether it's a home TV or an arcade monitor, can only display the native vertical resolution. It doesn't matter if a game's horizontal resolution is 320 or 256 or 512 or whatever; on a CRT screen the width will always, always be stretched or compressed to the same size. So to achieve an output that matches the original hardware (regardless of the system) you need a pixel-perfect vertical size and a fixed horizontal size. This is why I don't agree with the whole pixel-perfect philosophy, because varying the horizontal sizes is just plain inaccurate; no games were ever displayed on a CRT monitor in that way. Check any game you like on Wii VC and you'll see they all conform to this.

So basically, to get an emulator's output to look as close as possible to the original hardware output it would be viable to use Wii VC for comparison. That's an interesting fact, I wonder how close an Xbox emulator could get to that with some tweaking. Obviously the benefit of scanlines is that they disguise the blockiness of the graphics and games were designed with this in mind so some kind of scanline filter on top might be good. That's a great link though Phil, really interesting to see the various comparisons.

Interesting stuff for sure. Do you have access to a real SNES and CRT TV to compare with? For me, the pinnacle of an emulator's video settings would be to have it look identical to the original output on the originally intended display medium.

Yep, Cospefogo already called dibs on the new name when the final ultimate perfect version is released.

I'm sure iq_132 would be happy to share those driver updates. He's nice like that.

Do you mean the mouse code for analog input or do you mean controlling games with an actual mouse?

Any work I would have possibly done on MAMEoX128 Plus would have been for the original Xbox. The 360 doesn't interest me at all as a platform. I agree with exobuzz that it's extremely unfortunate that more sources to open-source projects ported to the Xbox have not been made available.

cba.gy is right. Unfortunately, HK$ never released his sources. If he had I would have been sorely tempted to do some work on MAMEoX128 Plus myself. I don't know if it's possible to contact him but he hasn't posted here for a long time.

Having a cabinet to play classic arcade games has always been something I've promised myself I'll do some day, but whether I'll ever actually get round to it or not is another story. I'd probably be more inclined to go the PC route if it wasn't for the boot time. MAME on even a half-decent spec PC will play so many more games than the Xbox will ever be able to handle. I wonder what the shortest achievable boot time is on a PC arcade cab.

For decency's sake I won't quote you, but that sort of verbal abuse has no place on or off the internet. You should seriously be ashamed of yourself if you think it's ever appropriate to address somebody in that manner, regardless of what you think they've said to or about you. That aside, a personal attack of that sort is a violation of the rules here and I certainly hope your post doesn't escape a moderator's attention. I don't want to see this sort of thing here and I'm sure nobody else does either. As far as I'm concerned, you owe cba.gy and everyone else here an apology.

I've just come back from a few days away (pretty shattered after the 400-mile ride home). I was hoping to get all the work on the FBL emulation side of things done before I left but it didn't happen. So I'll get back to it as soon as I can, and once that release is done I'll look into doing some work on the UI for the next one.

I'm not going to get into this in detail because of the potential for attracting nonsense that I don't have time for; but, to answer the question, FBL offers many options and settings that are not available in the FBA component of CoinOPS. I have no idea if it's now using the FBL core or not but the last thing I heard was that it uses a modified version of the old FBA core from nes6502's port of Final Burn.

I've never used FBANext but, from what I can tell, it's a fantastic port and it's hard to see what a 360 port of FBL would do that FBANext doesn't. The most notable games that play on the 360 port that don't play on FBL are the CPS3 games. As far as I'm aware there is also a perfectly good port of MAME currently available for the 360 as well.