Graphics mode and thread problems

BlitzMax Forums/BlitzMax Beginners Area/Graphics mode and thread problems

Gary Leeds(Posted 2010) [#1]
I am writing a fruit machine (slot machine) in BlitzMAX which is a conversion of a program I wrote in GLBasic for the iPhone

I want to use the thread function to automatically update the screen without having to constantly call the various update routines (I have flashing graphics that constantly need refreshing while waiting for a keypress) so I have set my thread up like this


Function interrupt:Object( data:Object )

While 1=1

	If(spinning = 0) 
	Cls
	draw_reels()
	DrawImage background,0,0-y_offset,0
	Alp.Display()
	Flip
	EndIf
	
Wend

End Function


the spinning flag is to disable this auto update when I am spinning the reel symbols, I handle the updates manually to make the scrolling smoother.

I am initialising the thread with this in the main program

Global thread:TThread=CreateThread( interrupt,"Data passed to child thread." )


and my graphics are being set up with

Graphics 1024,768,32,60


When I run the code I get the following error

Unhandled Exception:_d3dDev.Reset failed


and the Flip command in interrupt is highlighted

I have commented out every command bar the CLS and Flip commands in this routine yet it still does it

The main thread does carry on running and the screen is updated when I do a manual update but the interrupt thread has stopped.

I have tried setting up various different graphics drivers in case it was that but all either produce the same result or fail totally.

Is it a case of me trying to flip the screen too quickly? there is no other place that calls the flip or cls code unless I have disabled the thread with my spinning flag.

Another puzzling thing is when I have the thread enabled in the start up a complete spin of the symbols takes about 2 seconds. If I disable the thread from running the same loop takes over one minute!! Any reason for this happening? I would have thought it would be the other way around as the thread would be taking half of the processor time

I am willing to provide the full source so far if anyone feels they could help me but cannot see where else I am going wrong from my code on this text

I hope someone can help me, so far people on here have been great in getting me over these little stumbling blocks

Regards
Gary


Brucey(Posted 2010) [#2]
Are you sure you even need to use threads here?

It's perfectly possible to write your code such that you can skip updates and redraw the screen as you need... extremely quickly.
A standard synch'd display will draw 60 page updates per second. That's quite a lot of free-processing for your main-loop to be able to wade through on each cycle.

If it's just a case of using threads because you'd like to try them out, then you need to ensure that your graphics related code occurs in the main thread only.


ima747(Posted 2010) [#3]
Graphics functions (flip, cls, drawimage, etc.) are not thread safe, they must be called from main thread.

Update:
As Brucey said, is there a real reason you need to offload some work from the main thread. If you really want to offload onto a child thread then you should look into putting the work load on the child. Also unless you're trying to update way faster than the screen can even refresh (why?) then there's really no gain (and potentially a lot of hassle with the bugs and debugging related to multithreading) by putting something like update or draw code in multiple threads... But if you're looking to learn multithreading then look at offloading the work rather than the (not child able) graphics code.


Brucey(Posted 2010) [#4]
Like what Logan said :-)


Gary Leeds(Posted 2010) [#5]
Thanks for the tips

The reasoning behind using a thread for the updating is because I will have flashing graphics to simulate flashing lamps on and off which will need refreshing while I am in a loop waiting for buttons to be pressed. I found when I did it in GLBasic and updated everything manually the code got messy and things got out of sync but im sure if I structure things better then I can get round the issues and avoid using threads altogether

Does anyone know the reason why things really slow down though when I dont have the unhandled exception error, i.e. when I remove the thread?


Brucey(Posted 2010) [#6]
Does anyone know the reason why things really slow down

My first guess would be a problem with your design.

a very simple example of some kind of loop independent "flashing"


... time for bed...


Gary Leeds(Posted 2010) [#7]
Thanks for the code Brucey.

I dont actually have any flashing in at the moment, just getting the basic framework sorted first.

I have uploaded a couple of example videos to show what I mean by the slowdown

CLICK HERE for the video with the thread enabled which causes the error.

CLICK HERE for the video with no thread enabled and as you can see is much slower


If you cannot link direct to the movies then CLICK HERE for both videos zipped up

Thanks
Gary


Gary Leeds(Posted 2010) [#8]
Just had a thought about why it could be doing this. I am not using any FPS locking with my flip statement but is it possible that while the d3d has not crashed due to the thread that the FPS is locked at 50 but once it has crashed then it just runs as fast as it can

Is this possible?