204 replies to this topic

[TheMagicNumber]

I really don't know how to use this or when... Anyone knows when should it be used in a multiplayer project ?

Just a quick suggestion but: when connecting to a server , instead of the game freezing you can show/do other things.

You can connect and not freeze without threads (39dll).

[Dylan93]

I really don't know how to use this or when... Anyone knows when should it be used in a multiplayer project ?

Just a quick suggestion but: when connecting to a server , instead of the game freezing you can show/do other things.

You can connect and not freeze without threads (39dll).

Yeah and even then I still see 90% of the ORPG made with Gamemaker freeze when they connect to a server.

[TheMagicNumber]

I really don't know how to use this or when... Anyone knows when should it be used in a multiplayer project ?

Just a quick suggestion but: when connecting to a server , instead of the game freezing you can show/do other things.

You can connect and not freeze without threads (39dll).

Yeah and even then I still see 90% of the ORPG made with Gamemaker freeze when they connect to a server.

Yeah, it's easier to just let it freeze than to show a spinning circle while connecting.

[Primoz128]

Can anyone good with this dll make an example game an offline one and an online one with 39dll how to use this exactly because im really confused... if noone does it then ill just spend countless hours researchnig the code and experimating <.<.

[TheMagicNumber]

Can anyone good with this dll make an example game an offline one and an online one with 39dll how to use this exactly because im really confused... if noone does it then ill just spend countless hours researchnig the code and experimating <.<.

You should learn about threads before using this DLL. No examples.

[paul23]

Hi,

In my game I need to load ~50 images, convert them to thumbnails (to prevent memory getting overloaded) and then keep the thumbnails.

This is a pretty big task for gamemaker to do, and as it's not vital the images are all "loaded" at game start (I could just show a temporary image showing the image is still loading) I'm looking into threads. (atm I just handle 1 image a step.. but even that gives noticeable lag).

Would GMTHreads be able to do this? - And I heard gmthreads tends to be not too stable on times, is this true (and would it effect such a simple task as loading + processing images)?

[LaLaLa]

Would GMTHreads be able to do this? - And I heard gmthreads tends to be not too stable on times, is this true (and would it effect such a simple task as loading + processing images)?

Yes, this would be a perfect use for GMThreads. As long as you use it properly (and don't do certain things which it doesn't like) it's quite stable. The only problem is when you attempt to use object-scoped variables or any drawing/surface functions, which will crash the DLL.

You should create one thread and use that to load all 50 images in order. Also have it update a variable with how many images it has added, and then draw the images that have been loaded in the normal thread. You'll then get seemless loading without lag.

[paul23]

Would GMTHreads be able to do this? - And I heard gmthreads tends to be not too stable on times, is this true (and would it effect such a simple task as loading + processing images)?

Yes, this would be a perfect use for GMThreads. As long as you use it properly (and don't do certain things which it doesn't like) it's quite stable. The only problem is when you attempt to use object-scoped variables or any drawing/surface functions, which will crash the DLL.

You should create one thread and use that to load all 50 images in order. Also have it update a variable with how many images it has added, and then draw the images that have been loaded in the normal thread. You'll then get seemless loading without lag.

uhmm, well I read IMP's post above, and it seems to crash if you "use" the image before the thread has closed? - This would mean that for each image I would have to start a new thread.. (as waiting untill 50 images are loaded is just too much).

Also you mention not using surfaces? - so rescaling images is pretty much out the question I guess :/

[LaLaLa]

uhmm, well I read IMP's post above, and it seems to crash if you "use" the image before the thread has closed? - This would mean that for each image I would have to start a new thread.. (as waiting untill 50 images are loaded is just too much).

Also you mention not using surfaces? - so rescaling images is pretty much out the question I guess :/

I looked back at IMP's post (on the previous page) to see what he said. I then whipped up a quick example to do exactly what you're wanting and what he said wasn't possible, and I didn't have any issues. I even have a dual-core CPU, so the problem for him has to be simply his implementation.

The only limitations are that you don't try to draw the sprite in the main game thread before it is loaded with the second thread, else you will get a "trying to draw non-existing sprite" error, obviously. The other restriction is that you don't try to draw a sprite while it is actually being loaded by the second thread, in which case the whole game would probably crash.

So, in order to do what you want, you need to load each sprite in the second thread and pass the sprite handle back to the main game thread. Directly after this in the second thread's code, you need to update a variable in the main game thread which says how many images have been loaded. This way, you won't ever draw a sprite that hasn't been loaded or is in the process of being loaded by the second thread.

As for surfaces, that is true: you cannot use them in a thread. On a single core computer you could possible get away with it, although in my testing it's still crashed occasionaly, but with a multi-core CPU you are guarenteed some nasty crashes. I've even locked up my display driver and had to do a hard-reboot (not fun).

However, that doesn't mean you can't resize sprites. When you go to draw them in the main game thread, just use the scaling functions (draw_sprite_stretched())...

Edited by LaLaLa, 14 March 2011 - 10:01 PM.

[Ronchon le Nain]

I'm testing this , and really weird things happen when i create instances from witin a thread... It seems to be something about the instance's IDs. Anyway it makes the game crash.

Edited by Ronchon le Nain, 09 October 2011 - 10:47 AM.

[Ronchon le Nain]

Moreover i advice everyone never to call any function within a thread ... it's buggy too. If the same script is executed by main thread at same time, there will be weird behaviors that i assumed to be because of variable interferences.
Even considering this, what i'm trying to do is still randomly causing crashes ( no error message )... I guess this module is just unstable.

Edited by Ronchon le Nain, 09 October 2011 - 02:29 PM.

[LaLaLa]

Moreover i advice everyone never to call any function within a thread ... it's buggy too. If the same script is executed by main thread at same time, there will be weird behaviors that i assumed to be because of variable interferences.
Even considering this, what i'm trying to do is still randomly causing crashes ( no error message )... I guess this module is just unstable.

What is it that you're trying to do? Can you post code/a GMK or be more specific than "creating instances"?

[Ronchon le Nain]

I was using function create_instance . It's been a while now already, so i don't have my tests anymore, and anyway as it was within my project it was too complex to be understandable as samples here. I don't pretend the things i analysed up here are right, it's just my personnal conclusions.

More recently, i gave it a try again within simple conditions : creating a thread with a while(1) loop and within a drawing function, drawing a sprite on mouse_x and mouse_y position. But it caused really weird visual bug when ingame, not working. But maybe i'm just not doing it correctly... I just don't really know what can be done with this or not... Seems drawing functions are also to avoid in threads.

[LaLaLa]

...Seems drawing functions are also to avoid in threads.

Yes lol. I got a BSOD after trying to draw in the thread with my dual core processor. It didn't do that on my single core desktop, but I had issues with it showing up because the main GM thread didn't time correctly when it updated the screen buffer.

[dark_master4]

Any chances of this being useable with GM8.1?

I modified the code to get passed the version check but it seems the memory addresses aren't the same in GM8.0 as in GM8.1.135 so it simply crashed.

I think I could get around this if someone could give me GM8.1.135's addresses for the following:
GM_UTILITY_CODEOBJECTCOMPILE dd 00543B38h
GM_UTILITY_CREATECODEOBJECT dd 00543A5Ch
GM_UTILITY_CREATEINSTANCE dd 004AB45Ch
GM_UTILITY_EXECUTECODEOBJECT dd 00528CECh
GM_UTILITY_DESTROYOBJECT dd 00404A30h
GM_ADDRESS_INSTANCECLASS dd 004AA8C4h
GM_ADDRESS_CODECLASS dd 00543754h

Note that I just copied these from the source, they are the addresses for GM8.0. I don't know what they are or where do I get them.

I could also re-upload the DLL so people can use it with the latest version of GM.

[dark_master4]

It would be more than nice having GM8.1 support with this thing since Yoyo stopped offering download for older versions of GM.

Could I either get an answer from last post or the maker of the DLL could update it to 8.1? It would be awesome!

Edited by dark_master4, 02 December 2011 - 03:31 AM.

[oneSOB]

HOLY S-H-I-T

I cant believe GM has thread support so many people have fought with me bout threads/functions/pointers/ect in GM and here is proof i was right

Now its time I just may be able to write my new multithreaded
gm functions

Thanks very much OP or should I say Solid Snake!!!

----------------------------------------------------------------------------------
Lucky Mallet - Cures Mini

[Drara]

It would be more than nice having GM8.1 support with this thing since Yoyo stopped offering download for older versions of GM.

Could I either get an answer from last post or the maker of the DLL could update it to 8.1? It would be awesome!

Apperently absolutely none except us and very few others seem to be interested in this... :/

I don't have the sufficing knowledge for this unfortunately but I noticed a new function in GM 8.1: get_function_address()
Someone told me that this would make it "easy" to create such a multithread dll. Don't know whether that helps at all though or whether you don't know this already...

Edited by Drara, 08 May 2012 - 03:01 PM.

[RevenantGhost]

Looks like this dont execute the entire GML given, sometimes it does, sometimes only a part, sometimes dont execute it at all, and most of times when it executes all the code it messes up variables giving them TOTALLY RANDOM values.
And what is really weird is that a code that takes 10 seconds to be executed without this dll, is executed in 0.1 seconds with it (and most of times works, with the problems above but still works), that makes no sense, should take the same time but only doing it in another thread, maybe this is the reason why it cuts some code... Someone can help me figure out if is me doing something wrong or if is the dll that has such big bugs?

[michael pw]

Would this work to be able to have a 39dll packet read statement in it which runs at 1000fps as i have a C++ Server running at 1000fps or more however as the buffer in gm is only being read at a rate of 60fps, there is a default latency of 16ms added onto the time of each packet which isn't helpful, it has meant i have had to cut back on positioning packets being sent. If this is solveable that would be great however if thats not really possible ill probs leave this dll alone !