Any reason why r13 starts a bit slower than other versions?

[Enjay]

I'm not reporting this as a bug because I don't think it is one. It isn't noticable with Doom2.wad but with my own IWAD the little progress bar moves across the bottom of the small startup window at a similar speed to before but when it gets to the second last division, it pauses there for about 7-10 seconds before going to the titlepic (unless you have played very recently and the IWAD is cached). Then, when I start a game from the menu, the first level takes a few seconds to load before you see it.

Once things have started, it all works at normal speed - even transferring to new levels.

It's not a huge problem. In fact it's not really a problem at all. I was just wondering if this is an expected side effect of recent changes or not?

[Graf Zahl]

No. r13 only contains rather small changes.
Which revision did you compare this to?

[Enjay]

Unfortunately I'm losing track of the revision numbers. Certainly it's a difference versus 1.0.32. I'll try and track it down but I'm not always keeping all the SVNs on my HD so to do it I'll have to DL a few and then try them, but do so making sure that the IWAD isn't already cached. I'm just waiting to find a mirror with r16 on it now that RazTK has uploaded it so that'll be the first one to try anyway.

But this reminds me of something else I've been meaning to ask about. I know it's already long but could you tag the r* numbers on to the version number so that it is easy to check which version you are running just by dropping down the console? I'd certainly find it useful.

[Graf Zahl]

My plan is to use ZDoom's svnrevision tool. But I simply haven't found the time to set it up, Over the last few days all I did was quick fixes that took no time.

Hopefully tomorrow things are a bit less hectic for me.

[Enjay]

OK, from what I can check, r2 does not pause on the last division of the progress bar, r4 does. r3 is not available on sourceforge.

Looking at the executables using a hex editor, there is certainly a change that I can see. Years ago, I used to hack the exe to cycle through a different set of pictures to the usual titlepic/demo/credit/demo/credit/titlepic cycle. That was easy to do, just find where they were mentioned in the exe and change the two entries for credit to 2 new graphic names. However, with one version of Zdoom, it became a little more complex. The full screen graphics (titlepic, credit, help etc etc) started getting an early mention in the exe (again viewed with a hex editor) whereas previously they were only mentioned in the area of the exe that used them to cycle through them at game startup. I used to refer to these additional early mentions of the graphics as "primers" and guess that it was something Zdoom was doing to check their availability or maybe load them in before using them. Obviously, however, I really don't have a clue what they were for. All I know is that unless I added the names of my additional graphics (by changing the unused Strife HELP graphic names in the "primer" to match my lumps) changing the word CREDIT later in the exe no longer worked.

That extra mention of these graphics had been in the exe (Zdoom and GZdoom) for years but between r2 and r4 it has disappeared and the graphics now only get mentioned (from what I can see) in the areas such as the startup cycling of images/demos/images etc. Pretty much as it was before the "primers" appeared.

Now I'm not saying that particular change has anything what so ever to do with the pause during game loading (because I don't know). All I'm saying is that it's an indication that there is something easily visibly different in the structure of r2 and subsequent exes.

For information, although you may have already worked it out from the position of the status bar that I described, the message in the startup window whilst the pause is taking place is "R_Init : Init Doom refresh subsystem"

As I said, it's not a huge problem and not a bug, as far as I am aware, but it's there.

[Graf Zahl]

Between these revisions I changed the texture loader.

Before, it initialized everything just by type, i.e all sprites first, then wall textures, than flats etc. which caused problems with name collisions. Now textures are loaded per WAD. This *will* slightly increase texture initialization time if you have an extremely high amount of textures in your WAD because the code has to scan through the WAD directory multiple times.
It also has to get all normal graphics lumps in the initialization phase. This means that every lump has to be opened and looked at. Again, with normal sized WADs this poses no problem because aside from the data that has to be loaded anyway and the levels there isn't that much left. However, if you have huge amount of graphics in your WAD it may take a little longer.

But this is initialization time only. Once the game has started it shouldn't matter anymore. Level loading should not be slower than before. Can it be that you altered the texture precaching option? If that is on level loading may take a little longer depending on the textures being used.

[Enjay]

Between these revisions I changed the texture loader.

Before, it initialized everything just by type, i.e all sprites first, then wall textures, than flats etc. which caused problems with name collisions. Now textures are loaded per WAD. This *will* slightly increase texture initialization time if you have an extremely high amount of textures in your WAD because the code has to scan through the WAD directory multiple times.
It also has to get all normal graphics lumps in the initialization phase. This means that every lump has to be opened and looked at. Again, with normal sized WADs this poses no problem because aside from the data that has to be loaded anyway and the levels there isn't that much left. However, if you have huge amount of graphics in your WAD it may take a little longer.

That'll be it then. 3917 texture1s, 3731 patches, 9765 sprites, 550 flats and 164 skybox TXs. Not sure how many miscellaneous graphics, but quite a few.

I thought I'd seen you mention that you'd worked on the texture loading and guessed that it might be related. For info, I just did the first start-up of the day (so the WAD was definitely not cached) and timed it. 22 seconds between double clicking and getting the title screen. about 15 of those seconds were spent sitting paused on the last division of the progress bar.

But this is initialization time only. Once the game has started it shouldn't matter anymore. Level loading should not be slower than before. Can it be that you altered the texture precaching option? If that is on level loading may take a little longer depending on the textures being used.

It does seem to take a bit longer to start the first level (ie when you start a new game) but it isn't much and it could be my imagination. Once that's done though, subsequent levels load as quickly as they ever did. Texture precaching is certainly switched off.



Like I said, it's certainly not a problem and isn't noticeable in the standard games at all. I was just curious about it and seeing as how it is an expected side effect of an improvement, well, it's all fine.

[Enjay]

Once that's done though, subsequent levels load as quickly as they ever did.

After quite a bit of checking and going backwards between versions I can definitely confirm that, although initial startup is longer (as already described) the loading of subsequent levels, where it counts: during a game, is noticeably quicker. Whether that is an expected result of this or not, I don't know bit it is certainly there.

[Graf Zahl]

The startup time is rather long. How large is the WAD you are loading. Since most of the time is spending accessing the HD it might be interesting to know how much it has to load.

In any case, even with the old version it had to scan all lumps in the patches/sprites/flats parts for texture initialization. Are there by any chance some large graphics in the WAD that are loaded as images? Especially JPGs are a bit inefficient to read so if all of them have to be scanned at startup some time may accumulate.

[Enjay]

The 164 skybox TXs (actually, 162, I counted the control lumps by accident) that I mentioned are all "true colour" but most are only 256x256. I have replaced a number of full screen graphics at 640x480 rather than the original 320x200, but none bigger than that. There are a few additional 640x480 graphics in the WAD that are occasionally used for full-screen hudmessages.

There are a lot of model skins that get loaded. There are just shy of 300 models with 376 model skin images. I try to keep the skins smallish (most are 256x256) but some are bigger. 70 are 512 wide and one is 512x768.

Sizes of stuff getting loaded:

Main IWAD 149MB (17676 lumps of which the textures, patches and sprites are as detailed above)
Music WAD 412MB (156 MP3s)
Skyboxes WAD 10MB (162 images)
Models Zip 18MB (Am I right in saying model related stuff gets loaded when a game/level is actually started rather than game/engine initialisation?)
About 8 MB of additional lumps - mainly sounds but some skins and a few more misc graphics (25 mainly 640x480 graphics)

So I guess relatively long loading times are not a huge surprise. In fact, given all that, GZdoom is probably doing pretty well.

[Graf Zahl]

156 MP3's? Ok, that explains it. Unfortunately it is necessary to open every lump in the global namespace to check whether it's a texture or not so the entire 412 MB get loaded.
The code was never meant to load such extreme amounts of data.

Of course that also means that the music files are cached after that so starting the levels is a little faster. If you want to so something about it you can copy them into a Zip/PK3 which has a dedicated namespace for music so they don't get processed upon game startup.

[Enjay]

That certainly does make a difference to the startup time. Thanks. On initial testing it does seem to make the slight jolt when music changes during a level a bit more noticable. I guess it just depends on which I consider to be preferable.

Would the same technique work for sounds - ie are they in the same situation: no dedicated name space in a WAD and so having to be checked? Although, obviously, sound lumps are a lot smaller so perhaps they have less of an impact?

[Skunk]

What the hell do you need 156 mp3s and 164 skyboxes for? Commerical games don't have near as many of either.

[Enjay]

Commercial games don't have almost 120 levels.

It's not 164 skyboxes BTW. It's 162 skybox images (my mistake): each skybox uses 6 images so that's "only" 27 skyboxes.

[Skunk]

Let me rephrase, then. WHY THE HELL DO YOU HAVE 120 LEVELS? Isn't that OVER KILL?