> Ah, a batch of dishonesty. Lovely. > > A fraction of a second slower is not significant for anything I'm doing. The space > saving, especially if I'm storing stuff on USB so I can work on multiple machines, is > more beneficial. > > You went from saying, “I've never needed to perform any operations on them that are > noticeably slower,” which is just plain not true, to this. I already said, “You might > think the small space saving justifies it, but many others don’t.” > > Real performance issues in MAME, such as how dismal some of the Game & Watch stuff > has become are far more significant than if it takes 1/10th of a second longer to > load. The lower performance has cost more than the loading time within 10 seconds of > emulation. > > The Game & Watch stuff is no slower than it was previously if you use the old > artwork. The thing is, after I added additional artwork system functionality, various > Game & Watch artwork has been updated to use it in ways that make it prettier at the > cost of performance. Some of the artwork lets you toggle off more performance-hungry > stuff in the video options. > > If you’re not happy with the performance, either scale back your artwork, or find a > way to optimise the render path between MAME’s render targets, the OSD render > modules, and the graphics API. Yes, it needs a rewrite, but maybe you could make some > improvements with low impact. We might all be missing something obvious. With things > like Game & Watch, we’re pushing the rendering path harder than ever before, so the > the limitations and bottlenecks in the design are really bubbling to the surface. > > Still if you're going to go out of your way to be an asshole once more and say nobody > uses it for "real development work" I'm not just going to sit down and let you spew > such bullshit, because I guarantee that plenty of real development work has been done > with the ROMs stored that way. > > Way to put words in my mouth. Read the thread again – I never said that. What I said > is, “The format is slower to perform most operations on. You’re better off with split > zip if you’re doing any real development work.” Given the trade-offs of the format, I > believe that is true. > > I was responding to B2K24’s post about 7zip being better: “It is for MAME ROMs and > Software Lists ROMs it's just that very few people know how to deal with it, but > luckily, I know how.” Anyone can use 7zip archives from a user perspective – there’s > nothing inherently more complex about using 7zip tools than using PKzip tools. In > fact, many Windows users use the 7zip tools to handle PKzip archives. However, people > do choose to use PKzip over 7zip because of the trade-offs involved. > > 7zip trades performance for an improvement in compression ratio. Its benefits over > PKzip work best in situations where you’re going to extract the entire content of the > archive before using it. This is why the MAME source and binaries are distributed in > 7zip format – it saves download time/bandwidth costs, and you’ll extract it once > before using it. Solid compression formats (e.g. .tar.gz or .tar.bz2) have always > been popular in these kinds of applications. When you’re using the content directly > from the archive file (as is the case for ROM sets), 7zip’s disadvantages become a > whole lot more apparent (as do the disadvantages of .tar.bz2, for example). > > The performance impact of LZMA compression is causing issues for other users of the > CHD format as well, hence issue reports like #7402. I can definitely see the benefit > of adding options to chdman to blacklist particular compression algorithms when > creating a CHD file, either to improve read performance or for creating > backwards-compatibile CHDs when new codecs are added.
NEERRRRD FIIIIIGHT!
|