1964mod Private Build Bughunting

[Pokemaniacs]

but if you could include CRC32 naming sheme (and png support ) aswell, we could stay compatible with all frontends that are already using CRC32 sheme (I don't know if there are any frontends supporting N64, but the normal way of handle screenshots in frontends is the CRC32 system)...

I may be wrong but I thought the screenshot naming comes from the video plugin rather than the emu core. Glide64 supports png but I think 1964Video uses bmp or did I misunderstand your intention completely.

[MasterPhW]

I may be wrong but I thought the screenshot naming comes from the video plugin rather than the emu core. Glide64 supports png but I think 1964Video uses bmp or did I misunderstand your intention completely.

You are completely right there! The plugin "decides" which format and which name the screenshot has.
But if you are using frontends with screenshot-, boxart- and titlescreen-support, the shots are most likely named like ROMNAME_CRC32.png (or any other file format) and put into the corresponding folders.
The frontend or in this case the emulator already has a list of the most important roms with its crc32 values (ROM_Properties.ini), so it should be a great addition to use the CRC32 in the boxart feature aswell.

[Pokemaniacs]

But if you are using frontends with screenshot-, boxart- and titlescreen-support, the shots are most likely named like ROMNAME_CRC32.png (or any other file format) and put into the corresponding folders.
The frontend or in this case the emulator already has a list of the most important roms with its crc32 values (ROM_Properties.ini), so it should be a great addition to use the CRC32 in the boxart feature aswell.

My understanding is that emulator with GUI doesn't require frontends unless it is Mupenplus which lacks a window gui. Frontends that integrate different emulators should be capable of managing the underlying difference of various emulators. Emulator changes should not be made to suit frontends, rather it should be made to improve performance, playability etc of the emulator.

Does adding CRC32 in boxart make a difference?
Boxart image seem to be the same for U & E (not sure about other regions) rom.

[MasterPhW]

Boxart image seem to be the same for U & E (not sure about other regions) rom.

You checked my png test pack, didn't you? I included the different U/E/J covers every time I could find them for the games.
And the crc32 value is meant as an additonal way to rename boxarts, like CRC32.jpg or ROMNAME.jpg. That was my intension.

And a lot user still prefer a frontend on top of an emulator with GUI to manage all their emulators with just one click.
1964 should be command line capable, so I think, it is frontend compatible aswell.

[Pokemaniacs]

You checked my png test pack, didn't you? I included the different U/E/J covers every time I could find them for the games.
And the crc32 value is meant as an additonal way to rename boxarts, like CRC32.jpg or ROMNAME.jpg. That was my intension.

CRC32 is indeed another but it makes the name ugly looking and confusing. To differentiate between the different regions cover, it would be better to use the "Alternate Title" naming which is better.
But doing it means that we assume there is a different boxart cover for every region rom. If a user cannot find that cover, he will have to manually assign another cover for that region rom.
I would prefer to use the Rom filename / "Alternate Title" as the boxart image name and do internal check to assign boxart image to rom according to "Alternate Title" or crc32 value then the internal rom name for matchup of some sort.
Not sure if I am able to do it because I am still quite confuse with the existing codes.
The blog post on this topic is the reason why I seek user feedback.

And a lot user still prefer a frontend on top of an emulator with GUI to manage all their emulators with just one click.
1964 should be command line capable, so I think, it is frontend compatible aswell.

I have nothing against frontend but (personally) doesn't like another layer over an emu that has a window gui. If users like frontend, they can use it but they will have to manage it. It is just personal thing.

[Pokemaniacs]

It seems that MyGlide has a problem with texture dumping compared to the original Glide64WX for me. It only dumps a few textures and then stops.
That's the reason I switched back to Glide64 at my texture project. You can try it if you want.
MyGlide dumped 348 textures with F1 World Grand Prix II then stopped working, but Glide64 is already at 813 textures. I visited the same place, so the dumped textures should be nearly equal.
Probably MyGlide deactivated texture dumping while dumping. The problem is, you can't see it at all, because the only way to see whether texture dumping is enabled or not is a little flash screen after pressing "D" for a few seconds.

If your dump textures is less than expected using MyGlide64, read 1964mod "FAQ" section "Plugin & UI Specific" Q6

  Spoiler:

https://sites.google.com/site/1964mod/home/faq?pli=1