Suspended App Problems

BlitzMax Forums/BlitzMax Programming/Suspended App Problems

Ked	(Posted 2013) [#1]

Hey!

I've been working on a windowed game, but I'm having trouble with sending and receiving information over a network while the window is no longer active. I remember in the past I had a way of working through this, but I can't find and can't remember the method I used.

Any help would be appreciated.

Thanks!

Hezkore

(Posted 2013) [#2]

Have you tried using a thread for receiving network packets?
It will continue running in the background at all time.

Ked	(Posted 2013) [#3]

I would like to keep from using multiple threads because I know from the past that there is a solution that lets me keep using just a single thread.

I'm pretty sure it involved me using a timer but I'm not sure how I did it. I tried throwing one set at 5hz in the main loop but it still kept blocking until the window was active again.

Hezkore

(Posted 2013) [#4]

You can try using an Event Hook, it should work.

Derron

(Posted 2013) [#5]

There is no reliable way than using threading. Timers may/will stop too.

Just move your window (drag the windowed app) and it gets "suspended" too. As you surely want to avoid "drop outs", you will have to process the network packages before timouts will get triggered on other clients.

Linux and Mac may behave different (may depend on the DE you use).
That is why I use different routes when building a non- or a threaded version (unthreaded should "work" too ...although not in networking mode).

What do you mean with "no longer active" - if you have another window in the foreground (overlapping your application) it should already refresh and therefor also receive networking packets... only "dragging" and "minimized" should be problematic (only "tested" dragging).

As the "graphics" are not threadable in blitzmax you will not be able to redraw the screen when the app is dragged - but thanks of threading you will able to do "physics" and "networking" and ... (sound, AI ...).

bye
Ron

Hezkore

(Posted 2013) [#6]

Here's a sloppy example of how to redraw the screen even when dragging and resizing using a timer and a event hook.

Import MaxGui.Drivers

SuperStrict

Global window:TGadget
Global canvas:TGadget

Global add:Int

window = CreateWindow("App Suspend Test", 0, 0, 320, 240, Null, WINDOW_TITLEBAR | WINDOW_RESIZABLE | WINDOW_CLIENTCOORDS | WINDOW_CENTER)
canvas = CreateCanvas(0, 0, GadgetWidth(window), GadgetHeight(window), window)

CreateTimer(60)

AddHook(EmitEventHook, MyHook)

Function MyHook:Object(iId:Int, tData:Object, tContext:Object)
  Local Event:TEvent=TEvent(tData)

  Select Event.id
  	Case EVENT_TIMERTICK
		add:+2
    		RedrawGadget(canvas)
    		Return(Null)
	
	Case EVENT_GADGETPAINT
		SetGraphics CanvasGraphics(canvas)
		DrawOval(100 + Sin(add) * 100, 100 + Cos(add) * 100, 32, 32)
		Flip()
		Cls()
		Return(Null)
		
  End Select

  Return tData
End Function

While True
	WaitEvent()
Wend

Derron

(Posted 2013) [#7]

You are using a "Redraw"-event which normal Max2d-canvas wont have.

Therefor you need the "timertick"-event. A normal Gadgetpaint should be forced as soon as another window is covering parts of the window and is getting moved some pixels - but this is not the case.

Another problem: you are only able to react on "timer tick" - timers are more limited than normal apps (try a timer of 700 or more).
I do not want to force my customers to limit the FPS or PPS (I have an physics update rate of 200/s or more).

But...
The OP said he is running into problems with networking. Networking is blocked when a window is moved. It is not receiving things. Even if packets will get received "later" you will most of them withdraw as being "to old" and therefor force resynchronisation which is not needed (ok that depends on the app/game) - in fastpaced-action games you will also have to take care of "hey I see a player running around I just killed some seconds ago" etc.

Some years ago we had that topic already:
http://www.blitzmax.com/Community/posts.php?topic=66207#740080

edit: just read that topic again: don't know if there happened important changes to maxgui/blitzmax-itself the last years. What was the most important fact in the thread: your timer will have to be of an interval "low" enough to enable the client to process/draw all things. There is no "dynamic adjustment" if something takes longer or not. Threading will run without freezing the rest of the application. You may kill a WorkerThread if it somehow gets in a stale state.

bye
Ron