Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

AppGameKit Classic Chat / how to use multi-thread in AGK games?

Author
Message
halley
13
Years of Service
User Offline
Joined: 27th Apr 2011
Location: China
Posted: 11th Oct 2011 09:27
in windows development ,I always use createthread api to create a thread.

when I display a image,and at the same time I want to load some resources, I need to use multi-thread, but now I don't know how to.

give my best
Nokiaqd
15
Years of Service
User Offline
Joined: 31st Aug 2009
Location:
Posted: 11th Oct 2011 15:48
If image is static ( like splash screan ) you can do this simple:

load image > show image ( call sync ) > then load other ress


Multi threading in agk (tier 1) ??? hmm, i don't think so
multi threading in C++ yes =)

badablog.ru - bada developer
halley
13
Years of Service
User Offline
Joined: 27th Apr 2011
Location: China
Posted: 11th Oct 2011 15:56
I use C++. in windows I use CreateThread api. but the AppGameKit is cross-platform. how should I create multi-thread?

give my best
bjadams
AGK Backer
16
Years of Service
User Offline
Joined: 29th Mar 2008
Location:
Posted: 11th Oct 2011 16:13
He is asking how you do multi threading on MAC and iOS. He knows how to do that in Windows.
halley
13
Years of Service
User Offline
Joined: 27th Apr 2011
Location: China
Posted: 11th Oct 2011 16:21
There r a lot of platforms. Mac and windows is enough?

give my best
halley
13
Years of Service
User Offline
Joined: 27th Apr 2011
Location: China
Posted: 11th Oct 2011 16:22
If I create a thread with windows api, how it work in mac?

and on the other hand, how it work in windows?

give my best
Paul Johnston
TGC Developer
22
Years of Service
User Offline
Joined: 16th Nov 2002
Location: United Kingdom
Posted: 11th Oct 2011 17:07
If you are in tier 2 you can inherit the AGKThread class and implement the UINT Run(); method, anything in that function will run on a thread and when that function returns the thread quits. Then create an instance of your class and call the Start(); method, that will start the thread and return immediately. There is also a cLock class with cLock::Acquire() and cLock::Release() if you want some synchronisation.

Tier 1 would require a lot of compiler changes to support threading.

Note that the AppGameKit functions themselves are NOT thread safe, for example updating a sprite in one thread whilst another is syncing will cause problems.
halley
13
Years of Service
User Offline
Joined: 27th Apr 2011
Location: China
Posted: 11th Oct 2011 17:16
Thank you very much. Johnston.

give my best
bjadams
AGK Backer
16
Years of Service
User Offline
Joined: 29th Mar 2008
Location:
Posted: 11th Oct 2011 21:42
are the Load (image/music) commands safe to use with threading? in dark gdk they were safe to use.
Paul Johnston
TGC Developer
22
Years of Service
User Offline
Joined: 16th Nov 2002
Location: United Kingdom
Posted: 11th Oct 2011 23:31
I wouldn't risk it, you may find you get away with it but on occasion it'll crash. The OpenGL commands themselves are not thread safe either so loading resources into OpenGL textures simultaneously is probably not safe.
bjadams
AGK Backer
16
Years of Service
User Offline
Joined: 29th Mar 2008
Location:
Posted: 12th Oct 2011 00:28
so better forget multi threading, so as to keep things as simple as possible
MobileCreator
13
Years of Service
User Offline
Joined: 1st Jun 2011
Location: Ottawa - Canada
Posted: 30th Jan 2012 18:26
Hi, I just found this "old" post about multithread. I was planning to create a separated thread to deal with animations on my game (C++) - actually not really animations, but the creating of transformations (Tweener). The AGKThread the cLock seem easy to use, but I wonder what kind of issue I should have when using the agk::Sync();

If I enclose the thread Sync() in a critical section, as well as the main loop sync() I think I'd be protected, but:

- Probably I'll cal Sync() more than the necessary
- Using clock to protect the call might have a huge impact on performance.

Could someone give an insight about this matter?

Thanks

----------
Paulo
http://www.mobilecreators.com
ManOfActionTM
13
Years of Service
User Offline
Joined: 16th May 2011
Location: Sahuarita, Arizona
Posted: 8th Feb 2012 22:14
So from what I get out of these posts are:

Multi-threading is okay as long as you don't use AppGameKit functions in the additional threads. I.e., AppGameKit functions HAVE to be in the primary thread.

Is that correct?
Paul Johnston
TGC Developer
22
Years of Service
User Offline
Joined: 16th Nov 2002
Location: United Kingdom
Posted: 8th Feb 2012 23:42
That would be one way of doing it. You could get away with multiple threads calling AppGameKit if you setup some locks that made sure only one thread was calling an AppGameKit function at a time, but it would make things a lot more complicated.
ManOfActionTM
13
Years of Service
User Offline
Joined: 16th May 2011
Location: Sahuarita, Arizona
Posted: 9th Feb 2012 00:01
I'm afraid we'll have to look at multi-threading for our next game, no matter how hard it is. We've noticed some not-so-good differences between our released game, Double Pinochle, and say, Plants vs. Zombies:

1. Our game takes up nearly twice as much space in RAM as PvZ (~60MB to ~110MB)--how can this be? We have a little card game! This very well might be on our end, so we're looking at how we can optimize our art assets better.

2. (Important for this thread) Our game seems to overuse the CPU, particularly on Android where it can close down other apps. If we can figure out how to multi-thread, perhaps the main cpu won't be so overtaxed.

3. (Also important for this thread) PvZ loads once upon start up, and you never see any other loading screens. Double Pinochle has one load in the beginning, and loads again whenever you change your theme (to load up the new assets and dump the old ones). I can only think that PvZ is loading new assets on a separate thread so that the user does not see any more load screens.

So, in my mind, my team is going to have to figure out how to work multi-threading and AppGameKit together to even have a chance at using AppGameKit and competing with non-card games in the future.

If I'm wrong on multi-threading and the last two points, someone let me know--we don't want to be wasting time on something that's not really going to help!
bitJericho
22
Years of Service
User Offline
Joined: 9th Oct 2002
Location: United States
Posted: 10th Feb 2012 13:16 Edited at: 10th Feb 2012 13:17
Quote: "So, in my mind, my team is going to have to figure out how to work multi-threading and AppGameKit together to even have a chance at using AppGameKit and competing with non-card games in the future. "


As a user on android, I couldn't care less how big the download is, how much ram or cpu it takes, as long as it runs properly and is fun

That said, I was wondering, are you using t1 or t2 to get those results?

As for your art assets taking up memory, you might not be able to do anything about it. PvZ might be compressing textures in memory. I wouldn't know if they do, but that may be something you haven't considered.

ManOfActionTM
13
Years of Service
User Offline
Joined: 16th May 2011
Location: Sahuarita, Arizona
Posted: 10th Feb 2012 16:54
We're not terribly worried about the size of the download, but the RAM is important because it'll shut down your other apps if it takes too much. We've been experiencing the same kinds of shut downs for too much CPU use as well (or so my android programmer tells me). That's the only reason we're worried about it.

We are using T2 for this.

There is a texture tool that is part of XCode, I'm going to look into using it in the future. However, I found a memory leak in my app, and I'm trying to nail that down.
bjadams
AGK Backer
16
Years of Service
User Offline
Joined: 29th Mar 2008
Location:
Posted: 10th Feb 2012 23:29
check out the size of every sprite. Most probably PvZ is using texture atlases to avoid having ram fragmentation with lots of uneven sized sprites. if you have 50 sprite files each 22 by 64 pixels, that will be rounded up to 32 by 64 sized sprite in ram.
ManOfActionTM
13
Years of Service
User Offline
Joined: 16th May 2011
Location: Sahuarita, Arizona
Posted: 10th Feb 2012 23:45
The only sprites we're using that are not packed into one Parent sprite are background images. Though I may be loading them in more often that I have to (may be part of the memory leak that I'm looking into).
bjadams
AGK Backer
16
Years of Service
User Offline
Joined: 29th Mar 2008
Location:
Posted: 11th Feb 2012 21:36
are you doing DeleteImage or just DeleteSprite before you load new a new level bg image?
ManOfActionTM
13
Years of Service
User Offline
Joined: 16th May 2011
Location: Sahuarita, Arizona
Posted: 12th Feb 2012 02:11
Just doing DeleteImage. In fact, I don't think I've ever used DeleteSprite, could that be an issue?
Hockeykid
DBPro Tool Maker
17
Years of Service
User Offline
Joined: 26th Sep 2007
Location:
Posted: 12th Feb 2012 04:21
Quote: "2. (Important for this thread) Our game seems to overuse the CPU, particularly on Android where it can close down other apps. If we can figure out how to multi-thread, perhaps the main cpu won't be so overtaxed."


I was having the same issue, and I found the solution is to use "SetSyncRate( 60,0 )". Mode 0 is a TON lighter on the CPU load.

Sean

baxslash
Valued Member
Bronze Codemaster
17
Years of Service
User Offline
Joined: 26th Dec 2006
Location: Duffield
Posted: 12th Feb 2012 11:40
Quote: "I was having the same issue, and I found the solution is to use "SetSyncRate( 60,0 )". Mode 0 is a TON lighter on the CPU load."

Mode "0" is the default so unless the user has selected mode "1" this would be the case anyway, still worth sharing thanks Hockeykid

Hockeykid
DBPro Tool Maker
17
Years of Service
User Offline
Joined: 26th Sep 2007
Location:
Posted: 12th Feb 2012 19:46
Quote: "Mode "0" is the default so unless the user has selected mode "1" this would be the case anyway, still worth sharing thanks Hockeykid "


That actually doesn't seem to be the case, I don't have any "SetSyncRate" in my code, but the second I add "SetSyncRate( 60, 0 )" the CPU load drops significantly.

Sean

Greg_C
14
Years of Service
User Offline
Joined: 22nd May 2010
Location:
Posted: 12th Feb 2012 20:03
Quote: "Just doing DeleteImage. In fact, I don't think I've ever used DeleteSprite, could that be an issue?"


Someone please corrected me if I am wrong cause it will help me with my games as well but from what I understand is that you load a image in and when you call DeleteImage that erases the Image from memory making it so if you want to use that image again you have to load it again. So if you know you are going to need that image again relatively soon then just call DeleteSprite so you don't have to load the image again and you keep it in memory.

Again this is just how I thought it worked.
ManOfActionTM
13
Years of Service
User Offline
Joined: 16th May 2011
Location: Sahuarita, Arizona
Posted: 12th Feb 2012 20:17
Yeah, I agree, but for my game, when we're deleting images, it's because a new theme is being loaded in, so all of the images need to be deleted, but not the sprites (I just use SetSpriteImage to give the sprites the new, loaded image.
baxslash
Valued Member
Bronze Codemaster
17
Years of Service
User Offline
Joined: 26th Dec 2006
Location: Duffield
Posted: 13th Feb 2012 08:11
@hockeykid, I'll have to check that. Seems pretty important.

@Greg_C, yes that's right.

Paul Johnston
TGC Developer
22
Years of Service
User Offline
Joined: 16th Nov 2002
Location: United Kingdom
Posted: 13th Feb 2012 18:31
Quote: "Mode "0" is the default"


This used to be the case, but the potential for sleep() to be inaccurate meant we switched to mode 1 which just uses a busy loop to maintain the sync rate. Personally I'd use mode 0 unless you experience problems.

Login to post a reply

Server time is: 2024-11-23 04:16:55
Your offset time is: 2024-11-23 04:16:55