Does Size Matter ?
-
Hi folks... Looking for an answer if you have one please. I'm currently writing an game using vb.net. Its not the most graphical game on the planet but it's steadily growing... My question relates to size. I already have 18 forms with over 5 Mb's of artwork and sounds. When I compile the program it comes to about 1.4 mb's (I'm keeping the graphics and sound separate for the moment.) As I'm about a third of the way through this small epic I was wondering about the EXE. As it add new forms it grows (not surprising) ;). But what are the limits (if there are any). Most modern game files are small 1mb ish loaders that feed off large data files. Should I be looking this way or am I ok to carrying on increasing the size of my ending EXE. All the best Coops.
-
Hi folks... Looking for an answer if you have one please. I'm currently writing an game using vb.net. Its not the most graphical game on the planet but it's steadily growing... My question relates to size. I already have 18 forms with over 5 Mb's of artwork and sounds. When I compile the program it comes to about 1.4 mb's (I'm keeping the graphics and sound separate for the moment.) As I'm about a third of the way through this small epic I was wondering about the EXE. As it add new forms it grows (not surprising) ;). But what are the limits (if there are any). Most modern game files are small 1mb ish loaders that feed off large data files. Should I be looking this way or am I ok to carrying on increasing the size of my ending EXE. All the best Coops.
coopsqc wrote: But what are the limits (if there are any). Don't worry - You've got a long way to go before you hit these. You're more likely to need to worry about the amount of memory installed on your user's system first. coopsqc wrote: Most modern game files are small 1mb ish loaders that feed off large data files. Should I be looking this way or am I ok to carrying on increasing the size of my ending EXE. I would recommend you would be better splitting it up in to logically separate DLLS so you can load and unload them as the game progresses and keep the runtime memory overhead down. As you're keeping the graphics and sounds separate that at least means, as I see it, these are loaded on demand rather than residing in memory for the duration so it keeps the memory overhead down a little bit also.
EuroCPian Spring 2004 Get Together[^] "You can have everything in life you want if you will just help enough other people get what they want." --Zig Ziglar
-
coopsqc wrote: But what are the limits (if there are any). Don't worry - You've got a long way to go before you hit these. You're more likely to need to worry about the amount of memory installed on your user's system first. coopsqc wrote: Most modern game files are small 1mb ish loaders that feed off large data files. Should I be looking this way or am I ok to carrying on increasing the size of my ending EXE. I would recommend you would be better splitting it up in to logically separate DLLS so you can load and unload them as the game progresses and keep the runtime memory overhead down. As you're keeping the graphics and sounds separate that at least means, as I see it, these are loaded on demand rather than residing in memory for the duration so it keeps the memory overhead down a little bit also.
EuroCPian Spring 2004 Get Together[^] "You can have everything in life you want if you will just help enough other people get what they want." --Zig Ziglar
Colin Angus Mackay wrote: I would recommend you would be better splitting it up in to logically separate DLLS so you can load and unload them as the game progresses Unloading a .NET assembly isn't an easy thing to do. Even if you load it into a separate AppDomain, this will hurt performance, as all calls will need to go through remoting. The resulting code can be much slower than loading everything on memory. Perl combines all the worst aspects of C and Lisp: a billion different sublanguages in one monolithic executable. It combines the power of C with the readability of PostScript. -- Jamie Zawinski