Codechange: refactor File I/O slot functions to be object oriented and pass references instead of indices #9039
Conversation
|
Would it maybe be a good idea, as it is a rewrite anyway, that one could use |
Support for |
In theory yes; using C++ file IO would arguably be better, however it is not a full rewrite but only a rewrite of a small sub part of the whole file I/O, so using C++ file IO does not seem feasible without reimplementing the base this depends on. But then this patch's size would spiral out of control. Here I just wanted to accomplish that the "slotted" file I/O got removed with something more maintainable. |
| * @param palette_remap Whether a palette remap needs to be performed for this file. | ||
| * @return The reference to the SpriteCache. | ||
| */ | ||
| SpriteFile &OpenCachedSpriteFile(const std::string &filename, Subdirectory subdir, bool palette_remap) |
There was a problem hiding this comment.
This is (almost) the only function that doesn't return a pointer. Any particular reason why?
There was a problem hiding this comment.
My reasoning has been: if it can be nullptr, then make it a pointer. If it cannot be nullptr make it reference. Though that is my C++03? brain talking; I have no real clue about the nuances of all the new pointer types.
rubidium42
force-pushed
the
fio_rewrite
branch
2 times, most recently
from
90eba82
to
473b8d0
Compare
rubidium42
changed the title
… the FIO slot functions
…ead of the global FIO slot functionality
…FIO slot functions
|
Since fdc11a9 I get a message that I am missing 10 sprites in the baseset (using original_windows) |
Motivation / Problem
Technically the idea comes from #8870, although the bug part of it has been solved. Looking into it, it became clear to me that the code could definitely use some help. Especially when there are global bool arrays that use the number of a slot a file was loaded in, which makes it look like something that was added on later. Similarly the GRF Container version is passed around in many places, even though it is something that is part of the file so if you have a reference to that which add a second parameter?
Functionally there should be no change at all, except that the number of fopens/fcloses should be smaller now as the caching checks for the same file already being opened and reusing that instead of the old logic that closed that file and then reopened it.
Description
A RandomAccessFile class is created with the functionality of the old Fio functions, i.e. read a byte, word and dword, an seeking around in the file with some caching. Contrary to the Fio functions this caches 512 bytes per file, instead switching the "used" file and re-reading those 512 bytes the next time something is read.
This class is used for Sound and Music.
A SpriteFile subclass of RandomAccessFile is created which contains the palette_remap state and the GRF container version. The former is passed in the constructor, and the latter is determined in the constructor.
This class is used for sprites (gfxinit, newgrf, spriteloader and sprite cache). The sprite cache, since it already has references to the files it has to to load the sprites from, has been given a vector with the SpriteFiles used for the current game. Upon reinitializing the sprite cache these files are also closed. For the security/static scan of NewGRFs a temporary instance of SpriteFile is created which releases everything as soon as feasible.
Limitations
First and foremost, it is not finished yet. At the moment I am primarily looking for suggestions/comments regarding the structure of the classes and whether things should be in a different location, and whether we would rather use references, pointer or something like unique_ptr to pass the RandomAccess/SpriteFiles around.
As it is not finished, I have not checked for missing documentation myself, and some commits should be done in a different order and some should be squashed with each other. That will be done once I know the more generic preferences.
Likewise I have done some preliminary testing with some NewGRFs and that seems to work, however I am fairly certain there are many code paths that I have not tested yet.
Furthermore there is a ByteReader in newgrf.cpp that effectively reads a block of data from the SpriteFile and then provides similar functionality, and in the functions where it is used we often have to access the SpriteFile via _cur.file. I think a light weight variant of the ByteReader can be made on top of the SpriteFile which could reduce some of the unneeded copying of data, and might mean we can get rid of _cur.file. However, this is a big undertaking and will be considered future work and not part of this pull request.
Checklist for review
Some things are not automated, and forgotten often. This list is a reminder for the reviewers.