Software Support > controls.dat
Would anyone like to take over?
edekoning:
I think you and I are approaching this differently. You talk about searching in the file, implying that whenever some controls data is needed the file is accessed. I would just load the file once and keep it in memory in some kind of associative/hash container. Disk IO is magnitudes slower than Memory IO, so it should be avoided.
Binary will save lots of space, as you would only store values. All the data logging, keys, are all in the code, and not in the file. If you look at my example you see that the game struct has a variable with name numPlayers, whereas the file will only contain its value. So the XML attribute numPlayers="2" will be reduced to a single byte. Now binary has drawbacks: any format changes will most likely brake every bodies code, versioning is a ---smurfette---, so you should always provide a reader/writer sample code and clear documentation.
I've managed to stay away from all web related stuff in my work so far, not planning on changing that any time soon ;)
Howard_Casto:
But controls.dat viewers aren't a resident app. They are generally launched prior to the game and called via a hotkey. So you can't hold the file in memory... well you can, but you have to load it each time anyway, which takes just as long. Loading a 30+ mb file into memory, even on a modern machine, typically takes longer than searching the file by loading a bit at a time. Again, the massive file size of the dat throws typical approaches out the window.
Controls.dat is a flexible data file, so there can't be any hard-coded values. As you said, changes will break the compatability. Think about the nightmare it would be if I were to add a (just for generic example) "orientation" variable to the game structure. If it's plain text, any new additions to the format would simply be ignored by older viewers. As a binary file it would break them.
Rodent.Vienna:
i am interested to be part of whatever continuation this project may lead to.
I understand conceptually and structurally what contents are of different files supporting mame data, also such as controls.ini / controls.xml.
i would understand the direction to take this to as well, but i do not understand what the technical basis / starting pint is, in:
- what is consistent of the project currently?
- active people with which background participating
- technical requirements / existing solutions to promote crowdsourcing in a submitted / approved manner (2 lists to projectize)
- limits in resources (people / information), limits in technology (missing programs to aid the project)
- what is the complete "what we have" to start from as of now?
I am truly interested to participate from a strategic / "ideal scenario" point of view, and to support by finding the right people to fill gaps.
You need to pick me up with the "where are we at" :)
the where do we want to go is something not clear yet.
thanks
alex
Howard_Casto:
I can summarize.
We've got the website, we've got the old database and we've got all the tools needed to maintain the status quo.
The problem is the format needs changing a little to accommodate different control schemes and the database might not be the most optimized thing in the world. All the stuff on the backend needs to be reworked (the webpage and database) which somebody else needs to primarily handle. The stuff on the front end also needs a little work (xml/ini output and the viewers ect) which I will gladly handle.
Rodent.Vienna:
thank you for the insight.
i am currently focused on a different project, so all my input can be either handled as theoretical, or as "in preparation".
when you say "all tools to maintain status quo", what do you mean by that?
what is the potential to get an intermediate release out there, that covers the romfilename changes from 0.141.1 to e.g. 0.148?
when you say "we", and i asked about "active people with which background involved", can you put more light on this, or is it secret? :)
what i cannot see here, except actually the technical stuff around "backend needs reworking", is an outline if this is actually the single point of stallment currently,
or if there is indeed progress on the data entry / quality / data update side meantime, despite this technical problem.
when you say "somebody else needs to handle webpage & database", do you mean by that somebody needs to be found who can tackle this, or is this somebody identifies already?
thank you and kind regards
Alex
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version