|
|
Is this with a release or a debug build? |
|
|
|
every build for some time |
|
|
|
Giving this one to Taylor. Dunno why, he posted in it. |
|
|
|
This has been around for ages. It seems to sit on that first bar for at least all texture and model preloading and index buffer (ibx) generation, which I guess indicates that it's processing everything but the CB's and maybe sound as a single step. I wouldn't consider this a very high priority, but it would be nice to let the new folks know that their game hasn't actually frozen. |
|
|
|
I'm wondering if you are just seeing the new caching stuff, Hippo. It doesn't unload anything until after it's finished loading. This is so that it doesn't have to unload something (models, bitmaps) and then load them right back. When you get this large jump does the mission load really fast or does it still sit there for a while? If it loads slow then something is really wrong and needs to be looked at in more detail. If it loads fast then it's just the caching and I curse you for complaining about it. :)
I am actually going to put a flashing "...creating IBX" in the lower right corner when it's creating the IBX files. This isn't going to happen real soon though, the loading proceedure needs to change a bit more first. The loading screen doesn't actually appear until after numerous parts of the loading process have already finished. That's about to change though with my next update but it still needs some work to spread out a few more of the game_busy() updates. It should be more accurate at that point as well. |
|
|
|
Yeah, as soon as it hits full, it goes to the breifings... |
|
|
|
@Hippo, if Goober's 04/23 release has a debug build in it then try that. If it's any better then great. If not then it should print out, in the upper left, where it is in the load process. Let me know where it seems to hang at and we'll go from there. If the text in the upper left never changes then it's not really a load problem but something with the update of the load screen graphics. |
|
|
|
I've seen this too. It doesn't really hang, it just spends a disproportionately long time on the first bar. In debug builds I can see all the stuff it loads, and it progresses just fine. The progress bar might need to be retimed. |
|
|
|
The only thing that I can think of is that the game_busy() calls are messed up but I don't understand why it's only affecting a few people. I'll have a run through all of that tonight/tomorrow. If it's working in debug builds then it's likely just some game_busy() screwup and so the loading screen doesn't realize that stuff is getting loaded. |
|
|
|
timer_get_milliseconds() returns a negative number on callback_init and game_busy() bails if it's not positive. That's why it works under Linux, different timer. It's always negative it would appear so I don't know if this is an ASM error or what, may be tied to computer speed. Looking for the reason and a fix. |
|
|
|
A few changes to timer.cpp gets this fixed. It also seemed that one Win2K and one WinXP computers I tested this with had wildly different behavior with the old code with values changing that shouldn't have ever changed. The modified code is working well with both platforms and with single and dual CPU configs. The downside of the new code is the increased risk of wrap around however it shouldn't be too much of a problem for this particular use, unless you leave the game running for really long periods of time.
Due to the tested values I'm unsure what other changes this code will show on the computers that exhibited this problem. Perhaps nothing but maybe something good or bad. A test build will be released shortly to find that out. |
|
|
|
Fixered. |
|
