MAMEWorld Forums - EmuChat - Another rom site down.

> 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!