DcSteve wrote:As for Emu performance, i think it has improved since the last post BA made about it, because FAME has signifacntly improved.. I could be wrong.
Dunno, I haven't tried it yet. I had a really terrible day yesterday. A combination of lack of sleep (caused by hayfever and dust allergies, I think), sharing a train with two classes of school childeren both to Uni and back, general hell all day, my phone's batteries died, I couldn't call home on the payphone because it was engaged, having to walk half an hour in direct sunlight (30 degrees, high humidity, no shade) to a nearby bus stop, and all sorts of other stuff. I finished the day with a severe headache caused by a combination of tiredness, hayfever, screaming childeren, heat and dehydration, moderate sunburn on my forearms and neck, a rash (probably cause by the heat) on my right arm, and generally feeling like hell.
I eventually got up at 11AM this morning, and I still don't feel right. So I'm probably not going to do much work today. If the new version of FAME requires nothing more than a recompile, I might plug it in later on and try it.
From what Fox68k has told me, it should run bloody quickly.
Christuserloeser wrote: One thing that came to me (I think Skyhawk came with it first) would be maybe to use single archive files like Beats of Rage or Quake use to store the data (maybe use ZIPs with zero compression or similar) to allow faster access to the screenshot / package / database loading.
Yeah, that'd probably be a good idea. The easiest format to use would probably be a KOS romdisk. They aren't normally compressed, and KOS can simply mount them directly. You can also compress them using gzip to save some space, and that's what Feet of Fury uses.
The only catch is that a compressed image of multiple screenshots, a box scan, and all kinds of other stuff is going to be larger (and take longer to load) than the box scan alone would. I also don't think it would be a great idea to store
all of the available media files in the romdisk image, because you won't need quick access to them.
Something like this would probably be a good idea:
Code: Select all
/cd
genplus
games
gamename.zip (compressed game ROM)
media
gamename (directory)
art0.jpg (and so on)
music0.gym
text0.txt
zmedia
gamename.rdz (compressed romdisk image, containing)
boxscan_{us,eu,jp}.kmg (VQ compressed 512x512 box art, 66KB each)
title_{us,eu,jp}.pcx (Title screen, at most 70KB each)
shot0_{us,eu,jp}.pcx (In game shots)
logo_{us,eu,jp}.kmg (logo, likely 256x128 ARGB1555, 64KB)
icon.kmg (VMU icon, 32x32, probably 1KB or so)
artinfo (Info about all the artwork files)
musicinfo (List of track names for music)
textinfo (Info about all the text files)
At least, that's one way to do it. I'm not actually certain that it's the best way though. If you have a lot of games on the disc, it'll probably start to slow down significantly. I'm not totally sure though - it depends on exactly how KOS caches directory entries. Each of the three main directories there (games, media, zmedia) will have as many entries as you have games (and the games directory might have more, if you have multiple ROMs for some games), and if you have a lot of games (say, 1000 on one disc) that might be too much for KOS to keep cached. Using a single flat file for each one, something like a ZIP file, might actually turn out to be more efficient.
Oh, and the "zmedia" directory is similar in principle to a dummy file. Rather than name something starting with 0 to make sure it's near the beginning of the disc, we name it starting with Z so it's as close to the end of the disc as possible. Loading times are quite critical for the compressed romdisk images, because they're being loaded on the fly from the menus. The ROMs are going to be quite large, so the more of those you have the closer to the outside of the disc you're going to push the zmedia directory. The media files that are loaded on demand, such as music, could be placed absolutely anywhere on the disc. Doesn't much matter.
The romdisk image would be well over 200KB, even with compression. VQ images don't really compress at all, nor do things like JPG, or PCX. Only the icon and info files, which are very small anyway, will compress noticable. If I used JPG format box scans, I could probably get that down to between 100KB and 200KB. Of course, decoding a JPG takes some time, so it may not actually be any faster than using the VQ compressed versions. Although, on the plus side, the disc builder program doesn't need to spend 15 seconds re-encoding each box scan.
It depends on exactly how all that information gets used. If the only thing that you see from the game select menus is the box shot, it doesn't make sense to package all the rest of it up with it. It would be better in that case to have the box art images stored separately. Maybe have one copy in the game's romdisk image, and another copy stored as plain files elsewhere.
I'm not too sure. I really need to think about it some more, and maybe do some experiments with it. But not right now.
v1: '88-'93; v2: '93-'97
Should we consider that to be authoritative? It certainly sounds about right. Sonic 2 used a v1 box, but Sonic 3 used a v2 box.
In that case, anything prior to '93 is v1, and anything after '93 is v2. How about games released in '93? I don't think we're going to get a more exact release date than "1993" for most games, so how d'ya think we should handle it?
Of course, if we can get some more exact dates, that'd be even better.
WaCk0 wrote:Now only the v1 and v2 JAP are missing, and maybe the v2 BR (the black ones/v1 are on page 3)
There's not really a lot I think we can do for the Jap templates. Aside from the v2's blue/yellow strip on the left hand side of the front cover, they don't seem to have much (anything) in common at all. That's the point, I suppose. Have a look at Christuserloeser's templates, and remove the picture of Sonic and the game titles. That's about it. The v2 boxes are similar, but have the blue/yellow strip on the left hand side of the front cover.
Compare Puyo Puyo (v1) with Puyo Puyo 2 (Jap v2)