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.

DarkBASIC Professional Discussion / Multithreading load map

Author
Message
VisualProg
17
Years of Service
User Offline
Joined: 31st Mar 2009
Location: RussianFederation, Smolensk
Posted: 3rd Jun 2014 14:02 Edited at: 5th Jun 2014 12:59
I Greet all!
I started to learn multithreading, and received synchronization problem. Multithreading turns, albeit crooked, but it works.
Problem in the system I/O - "sync".

When i do create the object, he be added in "sync list", and with command "sync", DirectX be try draw this object. But, me no need draw it, and i am not know what need do that avoid this...

In loading, I need draw only sprites, and then (after loading) go to 3D.

I did try "sync mask" and no use "sync", but this to no avail.

code in dbp:


I created test example, and attached source files and code.

Process loading objects be synchronous, process show information ("wait logo") - asynchronous.

Please, help me figure out what I'm doing wrong!

(test use "Matrix1Util_20.dll" and "MultiThreading.dll")
P.S. Sorry for my language...

MZh[NUL] <---

tiffer
20
Years of Service
User Offline
Joined: 6th Apr 2006
Location: Scotland
Posted: 3rd Jun 2014 23:06
Personally I wouldn't position the objects in the thread. I would make them and hide them and then once the thread is finished I would run one simple for loop to position and unhide them.

Don't over engineer because you will only make problems for yourself. You generally only need multi threading to spread out the big clunky stuff would otherwise get in the way eg. Reading and writing to the HD or talking to a server.
VisualProg
17
Years of Service
User Offline
Joined: 31st Mar 2009
Location: RussianFederation, Smolensk
Posted: 4th Jun 2014 08:11 Edited at: 4th Jun 2014 13:55
Quote: "Personally I wouldn't position the objects in the thread."

Processing objects - is the main program.
Thread need for user, that he see smooth animation and dynamic scene before game mode (during load). If i do dynamic scene in main program, user be get frames slow/broken.

If you tell me a better solution - I'm happy to use it))

Quote: "I would make them and hide them and then once the thread is finished I would run one simple for loop to position and unhide them. "

You do think as synchronous coding. If i create object, thread may "sync" him in this moment, but object did not been initialized, it is created several later. if i do "hide" or "exclude" after "make object", this can be after "make object" or can be after "sync", so the problem is not solved.

But, if i not do use "sync", i not draw scene (
If i use "sync" - draw scene and models...

MZh[NUL] <---

tiffer
20
Years of Service
User Offline
Joined: 6th Apr 2006
Location: Scotland
Posted: 4th Jun 2014 18:07
You're confusing me a little. Are you saying you want the user to see the map load? Why?!

The only thing that would be slow would be loading. Placing the objects and unhiding them would be instant. It would happen in the blink of an eye.

But then I'm not entirely sure what it is you're trying to do.
Chris Tate
DBPro Master
17
Years of Service
User Offline
Joined: 29th Aug 2008
Location: London, England
Posted: 4th Jun 2014 18:17
I do not know anything about the Multithread.DLL plugin.

VisualProg
17
Years of Service
User Offline
Joined: 31st Mar 2009
Location: RussianFederation, Smolensk
Posted: 5th Jun 2014 10:24 Edited at: 5th Jun 2014 10:29
Quote: "You're confusing me a little. Are you saying you want the user to see the map load? Why?!"

No, user be seen loading scene, example in screenshot.

DBP load objects in main program. Thread be show information about loading to user. (for example, this is "loading progress", but, in future, this is dynamic script)

Quote: "I do not know anything about the Multithread.DLL plugin."

sorry, i am not warned. I get this dll from forum:
http://forum.thegamecreators.com/?m=forum_view&t=68623&b=1&msg=747975#m747975
I did put this in archive.

MZh[NUL] <---

tiffer
20
Years of Service
User Offline
Joined: 6th Apr 2006
Location: Scotland
Posted: 5th Jun 2014 16:17 Edited at: 5th Jun 2014 16:18
You don't need mutlti hreading for that

You just need to call a function that covers the screen with a loading screen at the end of every iteraration.

Eg.

for x =1 to 1000
do stuff
showloadscreen(percentagehere)
sync
next x
TheComet
18
Years of Service
User Offline
Joined: 18th Oct 2007
Location: I`m under ur bridge eating ur goatz.
Posted: 5th Jun 2014 16:30
You guys don't understand. If you want a smoothly animated loading screen, then you have to control the loading screen asynchronously from whatever is being loaded.

From what I understand, your objects are appearing on the loading screen when you don't want them to?

You could try and position the camera far away from anything, or maybe set the camera's clipping distance to something very small so no objects are drawn?

Otherwise, tiffer mentioned hiding all of the objects when loading.

VisualProg
17
Years of Service
User Offline
Joined: 31st Mar 2009
Location: RussianFederation, Smolensk
Posted: 5th Jun 2014 18:20
Quote: "You don't need mutlti hreading for that

You just need to call a function that covers the screen with a loading screen at the end of every iteraration.

Eg."


Quote: " If i do dynamic scene in main program, user be get frames slow/broken."


Quote: "You guys don't understand. If you want a smoothly animated loading screen, then you have to control the loading screen asynchronously from whatever is being loaded."


I want to achieve exactly this, but Tiffer do not understand it seems)) I draw the scene asynchronously.

Quote: "You could try and position the camera far away from anything, or maybe set the camera's clipping distance to something very small so no objects are drawn?"


Thanks for the idea, I'll try it)

MZh[NUL] <---

Chris Tate
DBPro Master
17
Years of Service
User Offline
Joined: 29th Aug 2008
Location: London, England
Posted: 5th Jun 2014 18:46
It will be interesting to see how you manage to load objects asynchronously in DBPro.

tiffer
20
Years of Service
User Offline
Joined: 6th Apr 2006
Location: Scotland
Posted: 5th Jun 2014 19:08 Edited at: 5th Jun 2014 19:42
Quote: "You guys don't understand. If you want a smoothly animated loading screen, then you have to control the loading screen asynchronously from whatever is being loaded."


That's not true. Loading bars long predate multithreaded processing. You just have to have a proper structured loading sequence. The loading bar can't be controlled asynchronously anyway because how would it track the loading progress?

Simplest method for a smooth loading screen is fill an array with the objects that need to be loaded. one field for id and the other for the file path. Then you can run a loop which loads the object and then does a load scren at the end of the loop with the percentage of progress. The idea of opening up a thread for something like this is bonkers.
TheComet
18
Years of Service
User Offline
Joined: 18th Oct 2007
Location: I`m under ur bridge eating ur goatz.
Posted: 5th Jun 2014 19:46 Edited at: 5th Jun 2014 19:48
Quote: "That's not true. Loading bars long predate multithreaded processing. You just have to have a proper structured loading sequence."


Said loading bars lag like crazy, though. There's no way you can keep a consistent framerate of 60 fps during a loading sequence.

Quote: "The loading bar can't be controlled asynchronously anyway because how would it track the loading progress? "

Sure it can! The two common ways of doing this:
1) The thread doing the loading can notify how far it's progressed by sharing memory with the thread controlling the loading screen.
2) The loading screen thread can poll the loading thread.

With that said, you might not even want to show a loading bar, but just flash some pretty animation onto the screen.

Van B
Moderator
23
Years of Service
User Offline
Joined: 8th Oct 2002
Location: Sunnyvale
Posted: 5th Jun 2014 20:30
I prefer to use chunky loading bars, like |||||||||||||||

Because you can space out the updates to make it consistant, I'm sure we all hate those linear loading bars that jump around, stop for ages, fill up then do nothing for too long... So I like to space out the loading bar updates throughout the init and loading routines.

Maybe just make a function that shows a loading screen with a segmented loading bar, and update that throughout the loading routine. Like loading a big level object might be 1 bar, but loading 20 low poly objects would be 1 bar as well - you just space out the updates depending on how long each section takes (trial and error). It would hide the 3D view as well if you have a loading screen. It's also the most optimum way for performance, as you only ever update the screen when the progress updates.

I am the one who knocks...
tiffer
20
Years of Service
User Offline
Joined: 6th Apr 2006
Location: Scotland
Posted: 6th Jun 2014 03:04
Why do you need 60 FPS during a loading screen?
VisualProg
17
Years of Service
User Offline
Joined: 31st Mar 2009
Location: RussianFederation, Smolensk
Posted: 6th Jun 2014 11:59 Edited at: 6th Jun 2014 12:02
Quote: "That's not true."

- this True) Believe me, more realizable))
Look latest games - they use multithreading to indicate the progress that user would get a beautiful animation.

Quote: "Said loading bars lag like crazy, though. There's no way you can keep a consistent framerate of 60 fps during a loading sequence."

Exactly)

Van B, this true, but I showed as an example of progressbar. Load screen will display dynamic information to the user about game and about level. Load script is large and does not apply to this issue, so I do not spread.

Quote: "Why do you need 60 FPS during a loading screen?"

I need 30-60 fps. This gives qualitative frames.


I tried use "set camera range" - this did not change error. I created my new dll, but this same did not help. "Sync" still crash in point "make object"/"load object".

I think, this due to object, dbp writes to vertex data, and thread try make a request "sync".

"CrashOn" gives no information...

Now i am reading as DirectX should handle such work. Later i am will write solution.

MZh[NUL] <---

tiffer
20
Years of Service
User Offline
Joined: 6th Apr 2006
Location: Scotland
Posted: 6th Jun 2014 14:48
You'll do what you will but if I recall most of the top end games I've played on Ps3 and PS4 used still splash screens with game hints in between HD loading. There are other things that can be done dynamically such as instancing, positioning, texturing but I'm not sure how many game developers worry about multi threading their loading sequence.

Don't get me wrong it's great if you can make use of multithreading to improve gameplay performance but unless you're neck and neck with Ubisoft I think you'd be better off focusing on the gameplay rather than perfecting the loading sequence. It's great that you're learning multi threading because it means you can make use of it in so many ways in your game.
gamerboots
17
Years of Service
User Offline
Joined: 8th Dec 2008
Location: USA
Posted: 8th Jun 2014 20:09 Edited at: 8th Jun 2014 20:10
Quote: "Said loading bars lag like crazy, though"

which is why you make your own Quite easy to do I might add.

--------
gb
TheComet
18
Years of Service
User Offline
Joined: 18th Oct 2007
Location: I`m under ur bridge eating ur goatz.
Posted: 8th Jun 2014 20:16
Quote: "which is why you make your own"


This discussion was never about the loading bar, it was about having 60 fps during a loading sequence.

gamerboots
17
Years of Service
User Offline
Joined: 8th Dec 2008
Location: USA
Posted: 8th Jun 2014 22:04
Just a curious question but how many find it difficult to achieve this?

--------
gb
TheComet
18
Years of Service
User Offline
Joined: 18th Oct 2007
Location: I`m under ur bridge eating ur goatz.
Posted: 8th Jun 2014 22:16
I've not done it in DBP, but in other languages is trivial. The MultiThread plugin VisualProg is using is probably just as easy.

Whatever language you're using, it comes down to something like this:


tiffer
20
Years of Service
User Offline
Joined: 6th Apr 2006
Location: Scotland
Posted: 8th Jun 2014 23:07
Quote: "
This discussion was never about the loading bar, it was about having 60 fps during a loading sequence."


Ummmm...

Quote: "You guys don't understand. If you want a smoothly animated loading screen, then you have to control the loading screen asynchronously from whatever is being loaded.

From what I understand, your objects are appearing on the loading screen when you don't want them to?"
TheComet
18
Years of Service
User Offline
Joined: 18th Oct 2007
Location: I`m under ur bridge eating ur goatz.
Posted: 8th Jun 2014 23:32
Okay, and where exactly does it say "loading bar"? The discussion is about having animated loading screen.

The thread title is "Multithreading load map", which implies a 60 fps frame rate during loading.

gamerboots
17
Years of Service
User Offline
Joined: 8th Dec 2008
Location: USA
Posted: 9th Jun 2014 00:13
hmm,.. so the problem then is objects showing during the creation/loading process?

--------
DBP Archive
Chris Tate
DBPro Master
17
Years of Service
User Offline
Joined: 29th Aug 2008
Location: London, England
Posted: 9th Jun 2014 00:43 Edited at: 9th Jun 2014 00:45
@VisualProg

I am confused...

When the sync command is invoked in the status function,



And the sleep function is called in the background worker; your object creation thread. This sleep call is supposed to pause that additional thread, but you say your framerate is dropping?

Do you notice the FPS increasing when your decrease the sleep delay? What happens to the FPS if you sleep the loading thread for longer?

IS that sleep command really designed to pause the correct thread?

gamerboots
17
Years of Service
User Offline
Joined: 8th Dec 2008
Location: USA
Posted: 9th Jun 2014 01:40 Edited at: 9th Jun 2014 01:56
I noticed this right away in the code. Increasing the sleep will definitely decrease your overall frame rate because it prevents the program from doing anything (including refreshing the screen). Now, if you have just 10 calls to function with a sleep command which is set to 50 that is a full 500 milliseconds (1/2 second) that the program does nothing. doubling this to 20 calls gives you a full second so naturally its going to lower the overall fps not to mention make for longer load times.

--edit--
I'll put it like this, which one of the following will execute faster:





Hmmmm.. You can get a better idea of how this works in 3d by making a cube and rotating it in a loop. Not pretty.

--------
DBP Archive
tiffer
20
Years of Service
User Offline
Joined: 6th Apr 2006
Location: Scotland
Posted: 9th Jun 2014 16:31 Edited at: 9th Jun 2014 16:44
Quote: "Okay, and where exactly does it say "loading bar"? The discussion is about having animated loading screen.

The thread title is "Multithreading load map", which implies a 60 fps frame rate during loading."


This was the example posted by the OP



It seems you've misunderstood the OP's question and gone off subject.

The OP said he wanted "qualitative fps around 30-60fps"

I think all he's looking for is a steady animated loading screen for when the game media is loading.

This can definitely be done without multithreading. Just structure your loading so you load each bit at a time and concurrently refresh the animation every loop. Sense DBpro wasn't designed to be thread safe if you try to load media on separate threads you could end up with unexpected bugs and crashes (invalid memory).

Eg. (pseudi)
VisualProg
17
Years of Service
User Offline
Joined: 31st Mar 2009
Location: RussianFederation, Smolensk
Posted: 9th Jun 2014 16:49
Quote: "When the sync command is invoked in the status function,"

in thread -

I send a pointer to a function in the distance. C + + performs

upon completion, the thread executes

it works fine.

Quote: "bugs and crashes (invalid memory)"

Yes. Conflict causes a crash, it occurs at the moment trying to access an object (array element of objects) that is loaded.

MZh[NUL] <---

VisualProg
17
Years of Service
User Offline
Joined: 31st Mar 2009
Location: RussianFederation, Smolensk
Posted: 9th Jun 2014 16:56
Quote: "I'll put it like this, which one of the following will execute faster:"

It is not. At the time of sleep, the operating system sends the CPU second fragment program - (thread). sleep is needed to transfer control to different threads. If the process uses 100% of the resources - streams can not be processed asynchronously. You do not think about multiprocessor calculations.

Distribution such calculations a bit slower due to the transfer of programs on the processor and wait for the next turn, but, generally, it allows the user to see that the system works quickly (distribution)

Forgive me if I express it is not clear.

MZh[NUL] <---

Chris Tate
DBPro Master
17
Years of Service
User Offline
Joined: 29th Aug 2008
Location: London, England
Posted: 9th Jun 2014 17:22
Ok, so sleep transfers the control from the calling thread to the others; the same command can be used by different threads.

Can you solution work for large objects; for example scenery which takes more than 1 second to load; or will the sleep call have to wait for the object to finish loading before the main thread can sync the engine?

So far my solution was to write my own 3D file format based on polygon streaming; it will load and display scenery close to the eye polygon by polygon.

Your solution would mean not having to go through the trouble of writing your own file format. Although my solution would mean not requiring multithreading; (even though it does anyway through seperate processes and .NET; I had to split my game into multiple parts because of the DBP function compile limits)

VisualProg
17
Years of Service
User Offline
Joined: 31st Mar 2009
Location: RussianFederation, Smolensk
Posted: 9th Jun 2014 17:27
not to be unfounded, animation multithread - the user can interact with the flow at this point load basic resources for the game. So it will not get bored waiting for the download. (he will work in script-subgame)



MZh[NUL] <---

VisualProg
17
Years of Service
User Offline
Joined: 31st Mar 2009
Location: RussianFederation, Smolensk
Posted: 9th Jun 2014 17:34
Quote: "Can you solution work for large objects; for example scenery which takes more than 1 second to load; or will the sleep call have to wait for the object to finish loading before the main thread can sync the engine?"

Yes. Even if the model is loaded minute, and even more. It is important to start the download, At least give "sleep 1" - flow control, it becomes work on floors with the main stream. (1:1)

For example, this image with multithreading use this code:



you see, this code be very slow))) but this work soft)

MZh[NUL] <---

tiffer
20
Years of Service
User Offline
Joined: 6th Apr 2006
Location: Scotland
Posted: 9th Jun 2014 17:36 Edited at: 9th Jun 2014 17:48
Quote: "Yes. Conflict causes a crash, it occurs at the moment trying to access an object (array element of objects) that is loaded."


This is a textbook problem to run into with asynchronous programming.

The trouble is some things still need to be done in order and sense DB wasn't made thead safe then loading things in a separate thread is very likely to cause a problem where DB might sync or carry out collision checks in the middle of an object being loaded. This is why you shouldn't really load media on a separate thread and you definitely shouldn't sync on a separate thread.

Like I say despite what you guys might think if you actually look at some of the most top end games the loading screens tend to be quite minimalistic in terms of animation and will instead distract the user with a game hint. The cut scenes will only start after the media is loaded. By the time user has read the hint they won't have even noticed the delay and by the time they've seen all the hints they will be used to the delay and will welcome it as a build up to the action ahead. It's a clever tactic by people who know how to sell games.


Here's a prime example



edit:
Visual prog all you're going to achieve is making the game load slower and less reliably. For all you know the user might be content to scratch his nose and take a sip of his coffee while the game loads as quickly as possible.
Chris Tate
DBPro Master
17
Years of Service
User Offline
Joined: 29th Aug 2008
Location: London, England
Posted: 9th Jun 2014 18:28 Edited at: 9th Jun 2014 18:33
Quote: "some of the most top end games the loading screens tend to be quite minimalistic in terms of animation and will instead distract the user with a game hint. The cut scenes will only start after the media is loaded. By the time user has read the hint they won't have even noticed the delay and by the time they've seen all the hints they will be used to the delay and will welcome it as a build up to the action ahead. It's a clever tactic by people who know how to sell games."


I think at this level of discussion, we are all fully aware of that; No doubt we are all most probably game programmers or at the very least people who play games everyday. And I feel that this is a creative discussion, and being a creative discussion, invention is as considerable as convention.

Quote: "Visual prog all you're going to achieve is making the game load slower and less reliably"


Tiffer can you demonstrate that as a fact, or is it not possible for you to provide evidence? Do not get me wrong, I understand your viewpoint, but I would not even trust my own viewpoint until I see evidence, let alone someone elses viewpoint.

I am sure if you can provide evidence, VisualProg will be well advised to consider it.

Quote: "For all you know the user might be content to scratch his nose and take a sip of his coffee while the game loads as quickly as possible. "


The user might be content to scratch his nose and sip his coffee while the game loads as quickly as possible; you are darn right; I do this everyday when waiting for CSGO to load.

But, it might be safe to assume that VisualProg has a good reason for posting this thread; although he would have described it better in his native language.

I for one have my own reasons for not using loading screens; I have to work without loading screens in parts of my game where it would be impossible to play with loading screens or pauses, and impossible to load all the scenery not close to the player. Objects must be loaded on demand during gameplay as the players advance from area to area. These maps are dynamic so therefore in somecases what needs loading is to be determined by the player, during the gameplay; particularly with electronic mazes.

Just for the record, this does not mean that I do not load anything before the game starts. I load many prefabs and modules before the game menu screen so that the hard drive does not need to be accessed during game play, where possible.

The X-Producer is an editor for my game engine which loads objects without stopping the user from using the editor. While my map loads, I can click on object properties, set their names, load some textures and other general tasks while the map loads.

TheComet
18
Years of Service
User Offline
Joined: 18th Oct 2007
Location: I`m under ur bridge eating ur goatz.
Posted: 9th Jun 2014 19:08
@VisualProg
http://forum.thegamecreators.com/?m=forum_view&t=121503&b=6

From Benjamin:
Quote: "It is also possible to call DBPro functions like this, although you must be very careful about the operations you do while a call is in progress. For example, it is possible to call sync to handle rendering in another thread, but while this is processing you must not make/load any media, or modify any data that rendering uses. You can of course read the position/angle of objects and sprites, but you can't set them. This means you are very limited in what you can do while rendering is in progress, but there are some uses to it. Do not assume that just because the application doesn't crash when you test it, what you are doing is safe."


I don't have time right now but basically in your loading screen loop you need to suspend the loading thread during your sync call.

A quick skim of MultiThread.dll shows that this isn't possible, lol. The only functions you have is "MAKE FUNCTION THREAD" and "DELETE THREAD".

The minimum functionality you need is:
1) Find a way to launch a DBP function in a thread
2) Be able to suspend and resume said thread
3) Be able to poll the thread to see if it's finished or not.

You need something that looks like this:



Quote: "This can definitely be done without multithreading. Just structure your loading so you load each bit at a time and concurrently refresh the animation every loop. Sense DBpro wasn't designed to be thread safe if you try to load media on separate threads you could end up with unexpected bugs and crashes (invalid memory)."


Getting 30-60 fps by spacing "update" functions? The only two things you'll be doing with that is 1) slow down the loading time and 2) increase the size of your code to something unbearable.

Maybe you should download the code and try to fix the problem like everyone else is doing?

tiffer
20
Years of Service
User Offline
Joined: 6th Apr 2006
Location: Scotland
Posted: 9th Jun 2014 19:47
So as we've established we can't load media and sync at the same time. We have to suspend one to run another.

What's the point of having separate threads if they still have to wait for each other to finish?
TheComet
18
Years of Service
User Offline
Joined: 18th Oct 2007
Location: I`m under ur bridge eating ur goatz.
Posted: 9th Jun 2014 19:49 Edited at: 9th Jun 2014 19:51
Quote: "What's the point of having separate threads if they still have to wait for each other to finish?"


Because you're only suspending the loading process for the sync command,. They're not "waiting for each other to finish", it's essentially just emulating a mutex. The loading screen will run at 60 fps and the loading process runs as fast as possible.

VisualProg
17
Years of Service
User Offline
Joined: 31st Mar 2009
Location: RussianFederation, Smolensk
Posted: 9th Jun 2014 21:09

Ok! this really logical!
I try it, add this 2 functions in dll - no problem))

MZh[NUL] <---

VisualProg
17
Years of Service
User Offline
Joined: 31st Mar 2009
Location: RussianFederation, Smolensk
Posted: 9th Jun 2014 21:11
Quote: "What's the point of having separate threads if they still have to wait for each other to finish? "

has in mind - do not wait until the end function, and wait for the end of the instructions.

MZh[NUL] <---

TheComet
18
Years of Service
User Offline
Joined: 18th Oct 2007
Location: I`m under ur bridge eating ur goatz.
Posted: 9th Jun 2014 21:33 Edited at: 9th Jun 2014 21:35
I just noticed, if you're using sync rate 60, sync has an internal loop that waits. The loading thread will be suspended for no reason during this time.

You should optimise it by extracting the wait time:



I also fear that there might be a problem with suspending the thread too early. If it gets suspended in the middle of loading an object, what happens when sync is called?

Chris Tate
DBPro Master
17
Years of Service
User Offline
Joined: 29th Aug 2008
Location: London, England
Posted: 9th Jun 2014 21:38 Edited at: 9th Jun 2014 21:40
So, ironically Sleep is the most CPU tiresome DBP command someone could think of using in any application for any purpose under the sun; but do you have any other choice in this situation? The Windows API sleep command was more CPU friendly the last time I checked, as is the case with the Matrix1 Nice Sleep command.

In terms of two DBP processes running side by side, on the same CPU; if both processes run the native Sleep command, that CPU is still occupied (for some reason) by the processes, during their sleep call.

How is this not the case with your solution VisualProg?

tiffer
20
Years of Service
User Offline
Joined: 6th Apr 2006
Location: Scotland
Posted: 9th Jun 2014 21:39
Is your suggestion to pause a load object command to do sync in the middle of it? DBpro wasn't designed to do that. Look at the original problem.
TheComet
18
Years of Service
User Offline
Joined: 18th Oct 2007
Location: I`m under ur bridge eating ur goatz.
Posted: 9th Jun 2014 21:41
Quote: "Is your suggestion to pause a load object command to do sync in the middle of it? DBpro wasn't designed to do that. Look at the original problem."


Exactly the problem. There needs to be a way to somehow mutually exclude all DBP commands across threads, and I don't know how to solve that because DBP was never intended for multithreading.

tiffer
20
Years of Service
User Offline
Joined: 6th Apr 2006
Location: Scotland
Posted: 9th Jun 2014 22:01 Edited at: 9th Jun 2014 22:02
I hate to say it but we're kind of back to square one then. The only thing we can reasonably do is to draw the screen asynchronously but then we'll still be swapping between syncing and loading which means you may as well be on one thread.

@Chris Tate Could you at least try to see where I'm coming from before tearing me a new one again?
Chris Tate
DBPro Master
17
Years of Service
User Offline
Joined: 29th Aug 2008
Location: London, England
Posted: 9th Jun 2014 22:06 Edited at: 9th Jun 2014 22:12
Quote: "Do not get me wrong, I understand your viewpoint, but I would not even trust my own viewpoint until I see evidence"


I think that point I made confirms I do see where you are coming from. Infact, knowing where you are coming from makes it more difficult to agree with you; even if you where my mother I would say the same thing.

Edit: We need that Styx plugin creator for some advice. Back in the day his multi-threaded object loading example used to work like a charm. Perhaps he knows the answer.

TheComet
18
Years of Service
User Offline
Joined: 18th Oct 2007
Location: I`m under ur bridge eating ur goatz.
Posted: 9th Jun 2014 22:09
Here's a thought: Have you tried fastsync instead of sync?

Chris Tate
DBPro Master
17
Years of Service
User Offline
Joined: 29th Aug 2008
Location: London, England
Posted: 9th Jun 2014 22:25 Edited at: 9th Jun 2014 22:27
Perhaps a look at the source code for DBP would help:

Here is the FastSync command:


Compare that to Sync:


Here is where the action takes place during the sync:


Again, I am not actually thinking of getting this to work for my own purposes; I am just trying to help you get what you want.

tiffer
20
Years of Service
User Offline
Joined: 6th Apr 2006
Location: Scotland
Posted: 9th Jun 2014 22:31
Quote: "Infact, knowing where you are coming from makes it more difficult to agree with you; even if you where my mother I would say the same thing."


I hope that doesn't mean what I think it does.
TheComet
18
Years of Service
User Offline
Joined: 18th Oct 2007
Location: I`m under ur bridge eating ur goatz.
Posted: 9th Jun 2014 22:41 Edited at: 9th Jun 2014 22:44
Here's that internal delay I was talking about:


It'd be interesting to see what's inside:


And also see what's inside "load object" and how that's added to the render list.

The cleanest solution would of course be to make all DBP commands thread safe and recompile. Have fun with that!

Chris Tate
DBPro Master
17
Years of Service
User Offline
Joined: 29th Aug 2008
Location: London, England
Posted: 9th Jun 2014 22:48
Quote: "I hope that doesn't mean what I think it does. "


lol
Quote: "
It'd be interesting to see what's inside:"




RenderList.begin/end directs you to:


and is an instance of:


I appear like I know what all of this stuff is doing lol;

Chris Tate
DBPro Master
17
Years of Service
User Offline
Joined: 29th Aug 2008
Location: London, England
Posted: 9th Jun 2014 22:52 Edited at: 9th Jun 2014 22:56
Ahh load object, that would be a good idea now wouldn' it!



Yes, that is the load object section; here are the calling compiler commands:


And last by no means least, an additional, further command calling additional, further commands for the load object procedure:


Good luck.

Nah seriously, there has got to be a better way. Ideally a way which completely seperates the 3D resources from the loading screen.

If nothing can be invented, perhaps loading into memblocks on the other thread then running Make Object From Memblock on the main thread would be plan B.

Login to post a reply

Server time is: 2026-07-05 16:06:31
Your offset time is: 2026-07-05 16:06:31