preload.pcx - am I using it right? Is there an alternative?

[EnterTheStory (aka tolworthy)]

I'm experimenting with large games, and some of them take 30 seconds between clicking the icon and seeing the game - there's not even a black screen until then.* Preload.PCX only appears in the last half second, which sort of defeats its purpose. Am I doing it wrong?

Is there some other way to load a pre-load screen? I don't want to launch the game from some pre-loader, because my whole reason for combining games is to simplify the launch as much as possible.** But is there some way to let the user know that something is happening?

* I'm planning ahead for 100 games in one file, based on the size of the first 4 games. I tested the worst case scenario: 250 MB of text modules that all have to load before anything is seen.

** I've had reports of game shortcuts not working in some configurations, and I can't find any reason for it. Mostly it works, but occasionally it doesn't: so I'm not taking ANY chances with shortcuts, non-standard loads, etc.

[Wyz]

Actually I should give RunAGSGame another shot. You're bound to run into loading time problems. Well you can also use a pre-loader, but that would be a separate program too. 

[EnterTheStory (aka tolworthy)]

Actually I should give RunAGSGame another shot.

I'll stick with it if I can't get the "all in one" idea to work, but I'm starting to fall out of love with it. Specifically:
(start RunAGSGame tangent)
1. It was never designed for what I'm doing with it.
2. I seem to be the only person using it on a large scale.
3. My "many games as one game" concept requires very complex code.
4. I am not a top class programmer.
Result: RunAGSGame (and its implications) take up about one quarter of my time, with no end in sight. The latest bugs, though minor, are incredibly hard to track. I think it's time to cut the Gordian knot.

Ironically, the problem has led to the solution. Earlier this year I moved from 2.72 to 3.x because RunAGSGame and translations files were incompatible. I've moaned about it plenty - it added at least two months of full time work - but 3.x can handle giant games whereas 2.72 could not. My other reason for not doing a giant game at first - the time needed to compile  is less of a problem, as with four games under my belt I'm able to do a lot more coding in-between compiles.
(end RunAGSGame tangent)

Really the only major problem I can see is loading time, and even that won't be a serious issue: loading times will grow slowly, and I can always warn people in the installation file. It's not the end of the world.

[Pumaman]

How large is your compiled game? It shouldn't take 30 seconds before the preload.pcx comes up, I'd be interested to see what exactly is making it take this long.

Are you using the Split Resource Files option? If not, try turning it on and see if that helps with the startup time.

[EnterTheStory (aka tolworthy)]

How large is your compiled game? It shouldn't take 30 seconds before the preload.pcx comes up, I'd be interested to see what exactly is making it take this long.

EDIT:
I created a new test game, of a more realistic size: 115 MB when compiled (includes 85 MB of code modules*). When starting the game for the first time, nothing happens for 20 seconds, then the preload screen appears  for 2 seconds, then the game starts.  My computer is a bog standard 1.6 GHz XP machine with 500 MB memory. I tried splitting media files into 10MB chunks. Curiously, this created
sandbox.001 10MB
sandbox.002 1MB
sandbox.exe 104MB
and took even longer to load than before.

NB this is using a 24 bit Preload.pcx in a 16 bit game. But according to the help file:

simply save the image as PRELOAD.PCX (must be the same resolution and colour depth as the game)

The PCX format normally only exists in 1, 4, 8, and 24 bit depths. Does this mean that preload.pcx should never be used in a 16 bit game?

*50 modules, each with 1000 functions in 10,000 lines (of 500 characters each). It took over 10 minutes to compile - perhaps the large number of functions is an issue?

[Pumaman]

Hmm, then it could be due to the sheer number and size of the scripts. The script loading and linking code in the engine has never really been optimised for speed, due to the fact that it has never caused a performance problem -- but your game might well be the exception.

I'll take a look at it at some point and see if I can speed it up.