Asynchronous wad loader
Closed this issue · 1 comments
I did an overhaul of the wad loader, see 878b051. Essentially before you read the wad into memory and looped over the contents. As a result, the progress bar only updated once because for loops are not "asychronous". This fixes that. The general process is:
-
Read the contents of the wad to check if it's a valid wad, get the initial number of lumps and pointer to the dictionary
-
Initiate the chain with a call to chunkReaderBlock. This function takes the offset (initially self.dictpos), chunkSize (16 as each lump is 16 bytes in size) as well as the file (named blob).
-
All chunkReaderBlock does is create a new FileReader that takes a 16 byte slice.
-
nextChunk is basically the main chunk of the original code except offsets were corrected for
-
Once we've reached the end of the file, we call onLoad, etc.
Subsequently I changed the logic of the progress bar. Right now it's actually kinda broken (it works but I have magic values) but the gist of it is:
There are two global counters now: progress and bar. The logic I'm trying to follow is that the width of the bar is 284 pixels and should be split into even sections (I picked a magic value of 284 divided by 14, which is the font pixel size, which approximately is 20). Then we want to normalize the total progress somehow so that a proportional amount of progress equates to some bars, resulting in a constant bar width for all filetypes. But it's morning here and I've been working on this all night, so I'm not going to fix it right now.
The other major issue is that my new code is actually a bit slower. It can be fixed by increasing the chunk size from something like 16 or 64 and looping inside nextChunk like done in the previous code. I'm not actually sure if this will create blocking, but hopefully not enough to disrupt the loading animation. Again, it's late and that's why I created this issue.
I've fixed the two issues but only a couple of issues remain:
- When increasing the chunk size I increment the progress variable by 4 accordingly. Maybe it can depend on data.byteLength / 16 if you really wanted it to be accurate, but it's pedantic
- There is a slight delay after it finishes loading because self.playpal.load has to load, making the loading look inaccurate.