Bulk move misc/cave drivers to new cave folder

[angelosa]

No description provided.

[angelosa]

Necessary chore for Festival: Goldfish Scoop that don't fit in cavepc.cpp driver.

ETA: do I need to update plugins/hiscore/hiscore.dat or there's something that do it automatically?

[angelosa]

1. Sounds like "cave.cpp" actually belongs to atlus folder (has Atlus brands all scattered from the markings as per http://cave.buffis.com/#gen1 )
2. epic doesn't belong to devices/video, I believe that's confined to cv1k.cpp only.

[cuavas]

Remember to update any other #include guards, and move #include "epic12.h" right after #include "emu.h" now that it’s a local header.

What do other people think of this change?

[rb6502]

What do other people think of this change?

I think it's reasonable cleanup. epic12 isn't going to be used by anything else, and Cave certainly rates having its own folder.

[ajrhacker]

I think this is a good move, though the cave.cpp driver could probably use splitting in the future.

[galibert]

2. epic doesn't belong to `devices/video`, I believe that's confined to cv1k.cpp only.

The EP1C12 (not i, 1) is the Altera (now Intel) reference of the Cyclone 1 FPGA at the fourth size out of five, the others being EP1C3, EP1C4, EP1C6 and EP1C20. It has nothing to do with Cave specifically. Its behaviour as a blitter is only due to the bitstream that is uploaded. So even more than specific to Cave, it's specific to those boards.

[angelosa]

I think this is a good move, though the cave.cpp driver could probably use splitting in the future.

Been aware, not gonna touch that part here. It's pretty much settled that if anything driver itself shouldn't be named cave.cpp at all, but that also implies renaming/splitting states if not separate drivers, changing commentary in driver etc.
Also of note: Power Instinct 2 being released two months earlier than Cave actual foundation.

[cuavas]

ETA: do I need to update plugins/hiscore/hiscore.dat or there's something that do it automatically?

That file is on borrowed time. It’s never up-to-date anyway. It’s either going to the mame-goodies repository, or as an external data file to download like mameinfo.dat or history.xml.

No, you don’t need to update it. It isn’t really “supported” as such.

[happppp]

OT: IMO a hiscore plugin is fine, assuming there are still plenty people that use this feature. But I don't like the .dat file being included in MAME. Just let users download it from Leezer's.

[cuavas]

OT: IMO a hiscore plugin is fine, assuming there are still plenty people that use this feature. But I don't like the .dat file being included in MAME. Just let users download it from Leezer's.

There are multiple options:

1. Leave plugin in mame repository, remove history.dat altogether and let someone else host it.
2. Leave plugin in mame repository, move history.dat to mame-goodies repository.
3. Move plugin (including history.dat) to mame-goodies repository.
4. Move plugin to mame-goodies repository and remove history.dat altogether to make maintaining it someone else’s problem entirely.

The argument against keeping the plugin in the mame repository is that it’s a frequent source of breakage. All sorts of bug reports end up being traced back to it. If it’s something people have to add manually, it’s more clear they’re going off the beaten path.

If the plugin is moved to mame-goodies entirely, the history.dat file can remain with the plugin, making it just a single folder to add.

If the history.dat file is removed from the mame repository but the plugin isn’t, there’s the question of what folder it should be loaded from. Should the user add it to the plugin’s data folder, or to the plugin’s own folder? It’s kind of ugly either way.

[happppp]

It works fine the old way:
Move the hiscore.dat file somewhere, like your desktop.
Download https://highscore.mameworld.info/download.htm - add it to the same folder as mame.exe
Play pacman and observe it will save your high score.

Is the only reason the embedded hiscore.dat is sorted (and therefore different from the external one) for optimization?

[cuavas]

“Same folder as MAME” doesn’t work well if you’re using MAME in a Linux desktop environment. It only “works” on Windows because Explorer sets the working directory to the folder the executable reside in on double-click (for legacy reasons dating back to when DOS introduced subfolders which CP/M lacked).

With a Linux desktop environment, the working directory will be your home folder, and you really don’t want to have to put random files for MAME there. It needs to be relative to a configured path, and the two obvious ones are the plugins path (i.e. drop it inside the hiscore plugin) or the plugin data folder.

[happppp]

I don't know, put it wherever you place your dat files or cheat.7z and see if it works?

[cuavas]

I don't know, put it wherever you place your dat files or cheat.7z and see if it works?

Not really.

The cheatpath is a configured path, i.e. cheat.7z is treated like a folder. For example MAME looks for superx.xml in the cheat path, it doesn’t look for cheat.7z in some other configured path. To use the cheat path, hiscore.dat would have to go inside cheat.7z or inside a cheat folder alongside it. You could argue that it’s a “cheat” file of sorts, given it modifies game behaviour, but I doubt most people would consider it intuitive.

The history.xml, mameinfo.dat etc. location is the “history path”, which isn’t exactly an intuitive place for it either.

[happppp]

The plugins/hiscore folder will obviously work fine too if you dislike the homepath.

[cuavas]

homepath is the plugin data folder. It should never have been called homepath.