FBA vs. MAME
-
Here's an "interesting" if not grueling read from one of the guys behind Atari vector games The Secret Life of Vector Generators.
It seems lower resolutions are a "safe" way to ignore orientation and higher resolutions become dependent on refresh rates.
The concept of resolution makes perfect sense in a raster game/monitor, but isn't directly applicable to a vector monitor/game. There are a finite number of start/end positions, but the lines between (in an analog VG) are essentially straight lines, not "pixel" representations of them.
In a Digital Vector Generator, each XY position comes from the output of a counter so the result is similar to what you would get by using a frame buffer. Since the Digital Vector Generator in Lunar Lander and Asteroids used 10-bit DACs we have a screen resolution of 1024 x 768. (We actually could use 1024 x 1024 but then the 4:3 aspect ratio of the CRT produces different X and Y scaling values.)
There's some interesting facts about vector games in the article toward the end.
In 1978 when the Digital Vector Generator was developed for Lunar Lander, memory was much too expensive for a frame buffer in a video game. The first game to use a frame buffer was several years in the future (Missile Command) and even then, it was low resolution. (It may have been 512 x 384, but I'm not sure.)
Quantum (November 1982) was not designed by Atari. It was one of the two games that came out of a legal settlement with General Computer Corporation of Cambridge, Mass. (The other game was Food Fight.) GCC got into the game business by reverse engineering the Missile Command program and coming out with a new and improved version. Unfortunately, their version still said 'Missile Command' and they got sued. (They were also accused of including some code from the original Missile Command in their ROMs.) Fortunately for them, Atari had an amazing habit of suing people, winning the lawsuit, and paying the (losing) defendants a bunch of money.
BattleZone was the first game to earn $500/week on field test. The company gave a party to commemorate this accomplishment. The game was hit of the Amusement and Music Operators Association (AMOA) show in the Fall of 1980 and was released in November 1980. (There was another game at the show that attracted very little attention at the time called Pac Man.) BattleZone sold about 25,000 units.
Red Baron was released in May 1981. It didn't do quite as well as BattleZone; it sold about 300 units. One of those units was in an airport when Wild Bill Stealey and Sid Meier played it and decided they could do better, so they went on to found Microprose.
There was also a rumor that U.S. Army Recruiters used to hang around arcades and when they saw a likely-looking candidate playing BattleZone, would go up to him and ask, "How would you like to drive a real one?"
The first 'video game' that I know of was developed in 1946. (U.S. Patent 2,455,992 Cathode-Ray Tube Amusement Device Thomas Goldsmith and Estle Mann). Although it used a sawtooth circuit it was essentially an XY game.
The first video game of the modern era (Computer Space) was invented in 1972 by Nolan Bushnell and Al Alcorn. Since the first microprocessor (Intel's 4004) was still in the process of being born, the game was a completely hardwired machine. Different operations were performed at different times according to the Counter used to produce Vertical Sync. The Motion Objects were stored in a diode matrix. The objects were created by stuffing the diodes in the appropriate holes in the PC board.
Computer Space was not very successful. The next game, Pong, was.
Tempest was the first color vector arcade game.
At some point in the early 1990s, the demand for PC graphics became hot. People wanted the games on their PCs to be as good as the ones in the arcades.
-
@riverstorm said in FBA vs. MAME:
In a Digital Vector Generator, each XY position comes from the output of a counter so the result is similar to what you would get by using a frame buffer. Since the Digital Vector Generator in Lunar Lander and Asteroids used 10-bit DACs we have a screen resolution of 1024 x 768. (We actually could use 1024 x 1024 but then the 4:3 aspect ratio of the CRT produces different X and Y scaling values.)
hmm i think this is talking about a slightly different thing - whilst the vectors may have 1024x1024 possible coordinates (or however you want to articulate it), the resultant output has effectively infinite resolution. ie there's no stair-case stepping or whatever on diagonal lines displayed on a real vector CRT.
i think the lower 'coordinate' resolution of the vectors would neccesarily already be handled in the emulation, so if you had, say, a 4k display, you would still see the vector lines judder across the screen slightly at the 1024x1024 'coordinate' resolution, rather than moving smoothly across the screen (although this would be mitigated and made more realistic by a CRT blur shader), but the lines should still be at crisp 4k.
it's kinda like how PSX emulators can run at super high resolution but if that's all you change, you see the polygons jitter around even at 60fps, because the vertex calculations are at a low resolution (there are emulation hacks that can fix this)
-
Yeah vector displays do not suffer from pixelation really, more so B&W vs color due to their nature.
I was thinking more along the lines of vector games and limitations of current day monitors; if you are using a real vector display then all this discussion would be non-applicable mostly.
Basically the endpoints of "infinite resolution" line segments are on a say a 1024x1024 "grid" or whatever your monitor display resolution is and there's pixels between those points. The pixels between point A and B are what makes that stepping apparent. It isn't present on vector displays because there's no pixels on vector displays.
The DACs that generated the signal back in the day were 10-bit, so 1024x1024 is possibly the native/original intended resolution, one could surmise, for Atari games like Lundar Lander, Asteroids and Asteroids Deluxe. After all a 10-bit binary number has a max value of 1024 (1111111111 = 1,024).
Vector displays are still bound by physics and need basic information like the coordinates of the ends of the segment line, even if the line itself is considered infinite resolution; the end points are finite and bound to some unit of measurement. In theory there's infinite resolution but in practice we're still bound by our monitors max resolution being completely different technology from a vector display.
I know there's some additional information on refresh rates calculated into the capable max resolution too. Well there's a whole lot of information in there. Just pick a reasonable resolution for today's monitors and go with it!
Anyway I think that article was incredibly technical, the math alone was fairly complex but it had some interesting tidbits. It looks like it required considerable effort to develop the technology of a "vector generator" and "XY monitor" due to the cost of memory alone being more than manufacturing the entire PCB is pretty interesting. They had to dump the idea of frame buffers. All that work for a cost effective solution in the name of vector gaming. :)
-
Some nice additions and fixes in FBA recently, including use of Taito C-Chip dumped code and vector games; check here.
@barbudreadmon Any date for releasing a new lr-fba version ... to get all this nice stuff in Retropie ?
-
@udb23 said in FBA vs. MAME:
@barbudreadmon Any date for releasing a new lr-fba version ... to get all this nice stuff in Retropie ?
lr-fbalpha will be updated when standalone will be released (generally the same day). Standalone will be released when it will be ready, dink mentioned it should be soon.
-
@barbudreadmon soon seems a good timing ;-)
-
@dudleydes this is an incredibly helpful spreadsheet, thank you for sharing. Not sure if there's an official title, author (tho I'd guess it's more of a shared project) or link for it (would be even better if this was saved as a Google sheet everyone could access w/a link), but I'm definitely going to be referencing/promoting it moving forward. Case in point, I myself wasn't even entirely aware just what a multifaceted emulator FBA was up until this point-- I was under the impression that it was mainly just for NeoGeo games-- but by referring to this, I finally today was able to get some 21 ROMs working that I hadn't been able to use on either mame2003 or libretro, including Alien Storm & Kid Niki, 2 that'd been eluding me for a few weeks now...
Still, as far as the "lr-mame" titles, I guess we have to do the digging to see if those work on something other than mame2003?? Because I do see Cruis'N World, DJ Boy, and Paperboy listed as compatible, and have the ROMs listed as much (unless I have the wrong ones?), and they still haven't been working.
But really, the only other main addition I would make (I'd certainly help w/it if I could) would be to spell out the games that the .zips are referring to (looks like that info was meant to be for column E), since in some cases I'm having to Google the zip name to see which game is being referred to.
Otherwise great, great work.
-
@mortalwombat said in FBA vs. MAME:
this is an incredibly helpful spreadsheet
this is just way too outdated (3 years old) to be useful, fbalpha became fbneo and dozens of games were added/fixed, other mame cores became available, new models of pi too (i believe this spreadsheet was done on rpi3 non-plus).
if you want a good compatibility list, i recommend @roslof 's : https://docs.google.com/spreadsheets/d/1Rq4shU1RUSdcc7cTVWeORMD-mcO6BwXwQ7TGw8f5_zw/edit#gid=0
-
@barbudreadmon oh man, this is even better, thank you!! May have to share it on here. Still, it begs a few questions:
*Am I still supposed to file games labeled as lr-fbneo in the FBA folder on my flashdrive etc?
*Is there a separate optional package/emulator I'm supposed to install to Retropie to play these MAME games labeled as lr-mame-2016, lr-mame-2015, lr-mame-2003-plus?
Because the only optional packages I see on Retropie 4.7.3 are lr-mame-2010, lr-mame2000, lr-fbalpha2012, and Advmame.
-
@mortalwombat check the experimental packages list :)
-
@dankcushions ah can't believe how many times I'd passed that by installing the Optional ones. :/
A couple of these look promising for the arcade games I'm trying to play, like the mame, lr-mame, lr-mame2003-plus, the others previously discussed and the lr-neocd one. Can I select most of them as emulators on a game-by-game basis without having to necessarily file the games themselves into separate folders on my flashdrive (and in turn, end up w/separate emulator menus on the main Retropie interface??
As is, I have some 255 arcade games spread btwn Final Burn Alpha, Arcade, MAME-Libretro, NeoGeo, and AdvMAME menus; for the time being I'm happy w/whatever it takes to get em working, but ultimately it might be nice being able to consolidate em/not have to hunt individual ones down...
And the packages themselves, they don't take up TOO much space, right? (otherwise, I figure I'd just install everything that looks useful and delete what I don't end up using...)
Also, do you guys generally recommend just installing these optional/experimental babies from Binary, or Source?
The one YouTube tutorial I first saw when I learned about this process suggested Binary then possibly Source later, I've just been trying to install from Source hoping to skip an extra step down the road...
-
@mortalwombat said in FBA vs. MAME:
@dankcushions ah can't believe how many times I'd passed that by installing the Optional ones. :/
A couple of these look promising for the arcade games I'm trying to play, like the mame, lr-mame, lr-mame2003-plus, the others previously discussed and the lr-neocd one. Can I select most of them as emulators on a game-by-game basis without having to necessarily file the games themselves into separate folders on my flashdrive (and in turn, end up w/separate emulator menus on the main Retropie interface??
sure - all arcade cores can be selected via the runcommand when launched from the arcade folder - the arcade folder is precisely to avoid this kind of arbitrary menu clutter.
And the packages themselves, they don't take up TOO much space, right? (otherwise, I figure I'd just install everything that looks useful and delete what I don't end up using...)
i think mame binaries can be quite large - into the 100s of MBs for the later ones. lr-fbneo is ~50MB
Also, do you guys generally recommend just installing these optional/experimental babies from Binary, or Source?
https://retropie.org.uk/docs/Updating-RetroPie/#binary-vs-source-updates
note that source updates will take hours for MAME. almost a day for current MAME. i would recommend binary every time unless there's some specific cutting-edge fix you want. -
@dankcushions yeah, shoot I guess a Source install is something you should only try installing overnight?? I defaulted to that for mame2016 shortly after making that last post, and it's STILL going all this time later (in comparison, when I did a Source install for the Vice package, it took 10mins tops; guess these experimental packages are a bit less streamlined??).
Not sure I wanna wait hours on end for this to finish when I could be testing ROMs or doing other things. Can I just stop the installation/turn off the Pi, delete the partial install and then try reinstalling the Binary (or Source) when I'm not planning on using it? Is there much risk of damage if I do so?!
-
@mortalwombat said in FBA vs. MAME:
@dankcushions yeah, shoot I guess a Source install is something you should only try installing overnight?? I defaulted to that for mame2016 shortly after making that last post, and it's STILL going all this time later (in comparison, when I did a Source install for the Vice package, it took 10mins tops; guess these experimental packages are a bit less streamlined??).
not really, it's more to do with how viable/tested/compatible they are on your current system. the length of the compile is typically dictated by the amount of source code. MAME supports over 7000 games on many systems, so as you can imagine that is a lot of source code to compile. earlier versions of MAME supported less so take less.
Not sure I wanna wait hours on end for this to finish when I could be testing ROMs or doing other things. Can I just stop the installation/turn off the Pi, delete the partial install and then try reinstalling the Binary (or Source) when I'm not planning on using it? Is there much risk of damage if I do so?!
it's best to never turn off your pi without a proper shutdown. ctrl+c will cancel a compile in progress, and then you should clean the build folder for the same package after via the package manager. note that some experimental packages may not have an option to install via binary.
-
@MortalWombat - I know some of the games you listed above work fine in mame2003-plus. They've also been doing a lot of game fixes and palette color tweaks.
They are starting to use the code to generate html pages for which games are fully working and which have issues. Like graphics, color or sound issues etc. I think they are still in the testing phase and working out details but here's an idea of what it will look like. It's actually quite useful for finding which games are working in mame2003-plus.
mame2003-plus working games status
I think the Libretro team is going to do something similar for other cores in the future so you can cross reference. Coming directly from the code bases it should be accurate and current at all times.
I only use a 32GB card and have pretty much all of the MAME cores loaded (minus the latest which doesn't really work well on the Pi) so space shouldn't be a big issue. I also use Arcade to consolidate ROMs under a single pane.
Once you figure out the core names I found it easier to manually modify the file
/opt/retropie/configs/all/emulators.cfgdirectly and add all the games vs. launching each game. That way each game will launch with your preferred core for the ROM right from the get go.The file looks something like this. The name is usually just arcade_ followed by the ROM name and the emulator.
arcade_gravitar = "advmame" arcade_astormu = "lr-fbneo" arcade_1943 = "lr-mame2000" arcade_1942 = "lr-mame2003" arcade_spacfury = "lr-mame2003-plus"Yeah, if you pull the plug you'll almost certainly have corruption on your card, I've done ctrl-c many times though. Even if it boots fine and seems fine it probably isn't. The Pi is very prone to card corruption and usually starts with something small and builds until the issues have to be dealt with.
I found a good way to test for corruption is to make an .img and use pishrink (search Github). It checks for corruption (and does try to fix it) before shrinking it. If none you'll get a clean compressed image when it's done.
If I show any corruption I always roll back to my last good image and start from there. I even seen vdroop cause corruption due to an extension cord being to long.
-
@MortalWombat - The cores that compile in a "reasonable" time frame (under 2 hours) are mame2000, mame2003, mame2003-plus, mame2010 and FBNeo. mame2003 (plus changes ported over), mame2003-plus and FBNeo seem to be under rolling development. I watch those cores as new games and fixes are being added all the time.
Contributions to the project are always appreciated, so if you would like to support us with a donation you can do so here.
Hosting provided by Mythic-Beasts. See the Hosting Information page for more information.