SE 4: Disabling Splash Screens?

[Fyron]

Will said:
"Nothing wrong with using C++ Win32/COM."

By nothing, I assume you mean everything. Its a horrible mess.

"In fact, you can do all the features you listed for your modlauncher with that "decade old" technology."

Never implied you couldn't. It would just involve a lot of headaches dealing with the win32 API.

"As a bonus, it doesn't require users to download a 280MB VM framework (and that's just the x86 version!"

Uhh... Its a 22.4 MB download. Where do you see downloading 280 MB??

"Takes less memory, too."

14 MB instead of 5 MB ram. Oh noes. If 11 MB of ram is a real concern when you are playing SE4, you have some serious hardware issues.

[Will]

If you don't understand what the parts of the Win32 API are for, then yes, it may seem like a mess. And yes, there are some parts that are unnecessarily hairy. But the same thing can be said about parts of dotNET.

The 22.4MB download is not the entire download. That's the part that checks for previously installed versions, hardware profiles, etc. and then queues up the rest of the framework for download and integration/compilation. So if you're upgrading from 1.0 to 2.0, it doesn't need to re-download all the backwards compatible stuff. The framework itself is 280MB for the x86 version. And those 280MB need to come from somewhere.

And less memory usage is a good thing. Even 11MB is worth quibbling over, especially for a rather trivial application like a modlauncher. Because there are lots of those trivial little applications, and if all of them begin using triple the RAM they needed, you very quickly run into performance issues.

Anyway, you should probably give Win32 another shot, it seems like you've had bad experiences. Especially for an app like this, the difference between coding with .NET and with "old technology" is practically zero. Any decent visual editor will take care of all the messy GUI bits, and you can just fill in the actual logic. Which really only consists of overwriting a text file with a given relative path, and calling a run() method that optionally includes a saved file in the command switches. And doing that is virtually identical between the COM and .NET interfaces.

Unless your major complaint is making the GUIs, which means you aren't using visual editors, and also that you're masochistic enough to hand-code that stuff. To which I have to say, "Good God man, you have better uses of your time!" Let the machines handle that mundane stuff.

[Fyron]

"But the same thing can be said about parts of dotNET."

Indeed. However, those tend to be arcane issues with very specific parts of the language set, rather than right up front at the basic starting point.

Visual Studio doesn't seem very good at taking care of the messy bits when dealing with COM guis... It doesn't even bother to start you off with a frame in the window where you can use the visual editor; you have to manually set that up and deal with the hWnd madness.

"Because there are lots of those trivial little applications, and if all of them begin using triple the RAM they needed, you very quickly run into performance issues."

Sure, if you needed to run 100 of them at a time, all the time...

[aegisx]

compromise... use .NET and call functions from the unmanaged COM dll's

[capnq]

capnq said:

I cannot think of a single commercially released game that behaves the way you want.

On further thought, I own at least two games that don't even let you click through the corporate logo splash; they won't respond until the intro movie starts.

Matryx's launcher is sufficient for my needs; Fyron's' feature list seems like overkill to me.

[Fyron]

I tried to accommodate all the crazy configurations people use.

[Suicide Junkie]

Doom and Warcraft come to mind.

[Fyron]

I should also add that the inability to move Matryx' mod launcher around on the screen is what prompted me to make my own in the first place.