Getting stuff to stay on screen until the end, with processes.

[Sslaxx]

Continuing on my voyage to understand processes, I now have this:

Code Select Expand

/*
 LinuxLander/BennuGD
*/

Program LinuxLander;

import "mod_key"
import "mod_map"
import "mod_say"
import "mod_sound"
import "mod_video"
import "mod_wm"

Const
MoveBaseStartX = 0;
MoveBaseStartY = 3; // The starting value for moving the vertical base.
End

Declare Process Test (int x, int y, int z, int file, int graph)
Private
End
Public
End
End

Declare Function int Init (byte FirstTime)
Private
End
Public
End
End

Global
int GameState = 0; /**< 0 = playing, 1 = win, -1 = went off edges of screen, -2 = missed the base. */
int IvoShip = 0;
int PlayerX = 0; /* The player's X location. */
int PlayerY = 0; /* Player's Y location. */
int BaseX = 0; /* As for the player... */
int BaseY = 0; /* ...but detailing the base's location. */
int MoveBaseX = MoveBaseStartX; /* Controls the horizontal movement of the base. */
int MoveBaseY = MoveBaseStartY; /* Vertical base movement. */
int BGMusic = 0;
End

//include "Ship.inc"

Process Test (int x, int y, int z, int file, int graph)
Public
Private
int Count = 0;
Begin
Count++;
for (Count = 0; Count < 10; Count++)
 y++;
 say (id + ": " + Count);
 frame;
end
OnExit
say (id + ": done.");
End

Process Main ()
Public
Private
int Count = 0;
Begin
Init (true);
set_mode (800, 600);
set_title ("Linux Lander");
play_song (BGMusic, -1);
// Each of these three will give different process IDs.
for (Count = 0; Count < 3; Count++)
 Test (300+(Count*100), 300, 0, 0, IvoShip);
end
say ("MAIN.");
While (!key (_space))
 frame;
End
OnExit
say ("Thanks for playing!");
End

Function int Init (byte Firsttime)
Private
Public
Begin
if (FirstTime)
 // First time the game's run, so set up certain things.
 say ("First time initialisation.");
 IvoShip = png_load ("Assets/Player.png");
 BGMusic = load_song ("Assets/63MaxMan.ogg");
end
say ("New game initialisation.");
OnExit
say ("Initialisation done.");
End

So, what it should do is create three instances of the Test process that scroll down the screen and stay on screen until I press the space bar. What it does do is create the three instances, they scroll down the screen and once the processes finish disappear, then I get a blank screen (until I press space and finish the main process). Any hints on how to get what I want it to do, as opposed to what it is doing now?

Thanks!

EDIT: I tried adding these segments:

Code Select Expand

Process Main [...]
exit_status = true;
[...]

Code Select Expand

Process Test [...]
While (!exit_status)
  frame;
End

And now the sprites continue to be visible after the loops have finished, pressing space shows the "Thanks for playing!" string, but... it then goes into an infinite loop. I was going off what SplinterGU had said here, but it's clear I misunderstood somehow. Help?

[handsource-dyko]

So, what it should do is create three instances of the Test process that scroll down the screen and stay on screen until I press the space bar. What it does do is create the three instances, they scroll down the screen and once the processes finish disappear, then I get a blank screen (until I press space and finish the main process). Any hints on how to get what I want it to do, as opposed to what it is doing now?

Well, let's see. You could kill the process type or the individual process instances. Killing the process type is the easiest way to go in this case. This will kill all the instances of a particulair process type. I.e.

Code Select Expand

signal(TYPE my_process,s_kill);

[Sslaxx]

So, what it should do is create three instances of the Test process that scroll down the screen and stay on screen until I press the space bar. What it does do is create the three instances, they scroll down the screen and once the processes finish disappear, then I get a blank screen (until I press space and finish the main process). Any hints on how to get what I want it to do, as opposed to what it is doing now?

Well, let's see. You could kill the process type or the individual process instances. Killing the process type is the easiest way to go in this case. This will kill all the instances of a particulair process type. I.e.

Code Select Expand

signal(TYPE my_process,s_kill);

It works! Seems a bit messy (having a signal for "shut down this process/process type after this/the next frame has been processed" would be nice?), but it works which is the most important thing. Cheers!

[handsource-dyko]

There are other ways too, like putting a BREAK statement in the control flow of the process, but using signals is how I usually do it. A BREAK will kill the process, but with signals you have more control, because you can also use it to temporarely hide a process from display (the sleep signal) or freeze it (keeps displayed, other processes can still detect it, but will not animate thus it appears to be frozen).

When a process is asleep it is not visible, and not detectable. Other processes "think" it's killed, but it's not since it can be brought back again at any time you like.

[Sslaxx]

I think a big reason I misunderstood this one is that I thought that Main, as the main process and having called the other three process instances from within it, would kill all the processes it'd created instances of when it ended. This doesn't appear to be so.

Even if a process is not visible or detectable, it still is there. Replacing s_kill with s_sleep doesn't work.

[handsource-dyko]

Processes called by another process can still exist, even when the calling process is dead. There is not much special about main, it just a process like any other. So other processes can still run even when main itself is killed.

[Sslaxx]

Processes called by another process can still exist, even when the calling process is dead. There is not much special about main, it just a process like any other. So other processes can still run even when main itself is killed.

Hence the _tree signals, yes? I think I understand the basics of this now.

[SplinterGU]

I don't understand, your code works fine.

this is the ouput.

Code Select Expand


splinter@splinter-portatil:~/tmp/lander$ bgdi lander.dcb
First time initialisation.
New game initialisation.
Initialisation done.
Play song called with invalid handle65538: 0
65539: 0
65540: 0
MAIN.
65540: 1
65539: 1
65538: 1
65540: 2
65539: 2
65538: 2
65540: 3
65539: 3
65538: 3
65540: 4
65539: 4
65538: 4
65540: 5
65539: 5
65538: 5
65540: 6
65539: 6
65538: 6
65540: 7
65539: 7
65538: 7
65540: 8
65539: 8
65538: 8
65540: 9
65539: 9
65538: 9
65540: done.
65539: done.
65538: done.
Thanks for playing!


[SplinterGU]

exit_status is an internal var, this is set internally by libwm (mod_wm) when you press close icon on your window (cross icon)

[Sslaxx]

Under Windows this code does, it seems. That's weird. It doesn't work as expected under Linux (the compiler/interpreter I'm using under Linux is a newer version). I had to add what handsource-dyko suggested.

I'm wondering if it's due to the fact that it's supposed to draw something to the screen, but it can't (because I haven't attached/included the relevant files). So http://sslaxx.twu.net/LinuxLander.zip - this code, plus relevant stuff. What does it do for you?

[SplinterGU]

My test was in linux.

[Sslaxx]

My test was in linux.

And I've just confirmed it's something to do with the sprites being drawn/displayed, as I tested the unfixed code with Windows and it demonstrated the same symptoms described in my initial post.

[SplinterGU]

this while in Test is your problem

While (1)
 frame;
End

[SplinterGU]

use this main

Process Main ()
Public
Private
int Count = 0;
Begin
Init (true);
set_mode (800, 600);
set_title ("Linux Lander");
play_song (BGMusic, -1);
// Each of these three will give different process IDs.
for (Count = 0; Count < 3; Count++)
  Test (300+(Count*100), 300, 0, 0, IvoShip);
end
say ("MAIN.");
While (!key (_space))
  frame;
End
let_me_alone();
OnExit
// signal (type Test, s_kill);
say ("Thanks for playing!");
End

[Sslaxx]

Looks good and it works, thanks! Think I read about let_me_alone, but it didn't twig.