lauch another b3d exe from your program

Hi !
I plan to 'cut' my game program into two exe.
- The first should be the user interface (menus, game option, level choice). It use graphics3d and some music.
- The second should be the 'main program', in fact the 3d level (also graphics3d and game music).

Today i've experimented this, but it seems not be a good solution. My main idea was to free all the memory used by the gui interface before lauching a level ! i've planned to use a swapfile between the two programs to store some parameters. The second program need only the level number !

But... if i use an execfile command from the gui to the second program have an 'memory access violation'(of course this program perfectly works if i directly lauch it). Is somebody have experimented this ? Is it impossible ?

Simple code example (gui)

Graphics3D 800,600,16,0

main() ; gui main program (menu, ...)

ClearWorld
ExecFile "E:\game_010303\game1\start.exe" ; the second program (level)

End 

produce a 'memory allocation error' when the start.exe is executed !

Many thanks for your help.

check you've typed the location and name of the exe right because there shouldn't be any problems with doing that.

I think you might need to use EndGraphics after ClearWorld.

i've tested this, but EndGraphics seems to be a 2d command !


Sinu have you experimented that in yours programs ?

I just tested EndGraphics, it closes a 3D display nicely. Well it was pretty ugly actually so I vote you don't split your code.

This is EXACTLY how I'm making my own game "launcher"... and for the same reasons (cleaning up stuff from the memory). It works perfectly for me, but do it slightly differently... for example I don't have drive letter or path on the ExecFile - bad idea anyway because it does not work if the user installs it to a diferent dir?

I'll post my (simplified) code when I get home so that you can test that approach.

BTW: I plan to release my GameLauncher free with source with next 2-3 weeks too.

mustang your game laucher is b3d code ? This path with the drive letter is just for my tests ! What's your OS ?

My launcher module is basically mix of 2D and 3D, and it can be run full screen or windowed mode (easily configurable). 3D in it is really only for eyecandy, not needed for any critical "menu" stuff. So basically it is 2D, although I initialize it with "Graphics3D".

I thought that the path might for test purposes only, but had to ask! I have w2k-pro at home.

My current project have 17000 lines... it's difficult for me to understand now where is the problem when the second program is executed from the first ! When i test with two basics programs with few lines it works ! Is somebody i've tried this with an huge project ? Fmod problem ?

when i was making a level editor i did this, allowed me to run the game from within the editor with the new level.

Allrighty... here you go. VERY simplified example, but this works at least for me and allows separate "launcher.exe" that can be used to run other "yourgame.exe" with choice of options (like what "level" to load etc).

First .exe:

;compile this as "launcher.exe"


Graphics3D 480,480,16,2

Print "Press any key to load level 1"

WaitKey()


ExecFile("yourgame.exe /loadlevel1")

End

Second .exe:

*note: pressing a key will get you back to "launcher menu" (ends "yourgame.exe")

*note: running this .exe directly is also handled (we do not want that... ppl should run the "launcher.exe")

;compile this as "yourgame.exe"


If CommandLine$() <> "/loadlevel1" Then RuntimeError "Please run the menu Launcher.exe program, not this one." 

Graphics3D 640,480,16,2

Print "allright - it worked! Wo-hoo!"

WaitKey()


ExecFile("launcher.exe")

End

Personally, I don't think it's a good idea to write a launcher as a second blitz exe. Simply because a biltz exe is so large. You'll end up distributing all the blitz functionality TWICE in your download, which is overkill. A launcher made in something like PB would make a lot more sense.

But really, how much extra memory do you figure you're saving, anyway? I doubt that it'd be much more than a few k. And I can't imagine any blitz program causing a huge strain on system memory anyway.

With UPX it is something like 500K? That's smaller than most of my texturemaps and models - and there will be DOZENS of them! So 500K is nothing. Exe size might be an issue for ppl who want to have very small game that is easily downloadable and can be put on a 1.44MB floppy disk - but my goals are different. My game will be in the end so big project that it will be close to commercial game demos (>100 MB). As you can see 500K really is nothing... :)



What does not make sense is me buying Blitz+ too just for shaving few KBs...?



I do not care about the memory usage at all... what I want is easy "housekeeping", ie getting rid of all the stuff that is not need for actual gameplay (and might mess up my game code and be hard to debug). Also keeping them separate projects is better (easier) in coding wise... I can develop "launcher.exe" more easily because it's smaller and does not have any game stuff code in it.

...But everybody is free to do their stuff just like they want, but this is the right way for me and my game. Most commercial games use separate launchers too.

It's still 500k that doesn't need to be there though.



You can write it as a seperate .BB file and tack it on with an "include". The only thing you'd have to worry about is stuff like having a float in one file being used as an int in the other. Which, with only the smallest amount of care taken, won't happen.


I won't try to stop you. Just offering up my take on the pros and cons. Skidracer has offered up another con, too - the switching looks ugly.

Thanks for you ideas !
Finaly i keep my project into a same executable file. I continue to use an include between the two main parts !


I prefer not use globals variables into a program. I store (encapsulate) all these variables into a single global type. So you can free all the useless data if you not need them. Also debugguer inform you if you commit a syntax error into the the variable name !

In theory this is a good idea, seperating the launcher from the game.exe. ( all games i know off work in this manner)

And up until Blitz release 1.77 ( i think ) it was possible.

Blitz use to continue program execution after a ExecFile() was called... So you could;

ClearWorld()
EndGraphics()
ExecFile("blah")
End

But now, Blitz haults execution after the ExecFile is called... Therefore it is no longer able to reach the End() statement... Leaving it in memory.. It seems Blitz only continues if it has focus - after calling an ExecFile().

I've emailed Mark about this in the past, maybe adding a switch to the ExecFile().. something like ExecFile([path/filename],[optional End Task]). But never got a reply :(

So I simply code the launchers into my games now, not the prefered method... But until theres a more feasible solution it'll do.

? I *have* checked with w2k-pro TaskManager that it does not do that... if you compile my two examples they will end themselves totally when they spawn the other exe (launcher -> yourgame, yourgame -> launcher). I switched between them several times and didn't saw any extra .exes running in the memory. Memory stayed around the same level also.

And because I have not noticed any problems with my approach (separate launcher) I will happily continue along that road :)

Another idea is to write the launcher as a self contained procedure. That way it can be easily added to any blitz program, just do a call to Launch_app (or whatever you call it) and it goes.

My launcher code is "quite big"... and since it is basically only used for saving the key configs etc to the disk, it would be unnecessary to drag that code along when the actual game starts.

IMO game.exe itself and the configuring program.exe for it are entirely two different things and should be like that.

Just something I should add - I think that this is a pathing problem:

If you use Windows Explorer to double click a file it sets the current drive and path to the chosen exe (or at least as far as the exe is concerned, so that ..\ etc works).

Using Exec (from any language) does _not_ change the drive and path, so the parent program (which is what Explorer is) _must_ to do this.
Otherwise "E:\MyGame\Game.exe" is trying to loads its files from, say, a "Bmps\" folder, and you think it is "E:\MyGame\Bmps\" while the current drive might still be C: and the current path might still be "Windows".