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.

Dark GDK / Load objects in background?!

Author
Message
Zarillo
17
Years of Service
User Offline
Joined: 7th Aug 2007
Location: Finland
Posted: 9th Jan 2008 10:06
Hello everyone.

I was wondering if it's possible to load objects in the background to speed up the startuptime of my application?!
E.g. If I only need objects 1-8 for the 500 first frames and after that object 9-15. To load all 15 object on startup would double my startuptime.
As I have it now the main loop continue first when the object is loaded completely...

Any advice how to solve this one?

/All The Best,
Zarillo
www.3dstudio.fi
tempicek
16
Years of Service
User Offline
Joined: 27th Nov 2007
Location: Prague
Posted: 9th Jan 2008 13:02
AFAIK there's no direct way to do that in GDK, but you can try load the object in another thread. However, I'm affraid GDK is not allowing you access DX device from multiple threads nor it allows you to create/configure the device on your own Still you are free to try and let us know.
jason p sage
17
Years of Service
User Offline
Joined: 10th Jun 2007
Location: Ellington, CT USA
Posted: 9th Jan 2008 15:23
yeah - and I was thnkning similiar things - but I read that during a SYNC - you can't access anything connected to the display - and adding an object - by default is loaded in a "onscreen" way... AFAIK. So... I've thought about a couple ways to do this - one would be to load mesh data raw, make a memblock, and build it, and have this thread2 (loader) check and critical section (if not in a sync) - converting this prepared memblock to object, then hiding it, and releasing critical section ... and loop again to next thing to load.... Try to at least leverage some parts of the processing in another thread is as inobtrusively as possible.

This would probably (guessing admittedly) be ok for SOUNDS, and loading music, and other prework that is out of gfx pipeline.

It's my understanding this is a good way to do physics as well, and I'd suspect AI.

tempicek
16
Years of Service
User Offline
Joined: 27th Nov 2007
Location: Prague
Posted: 9th Jan 2008 16:24
Quote: "ake a memblock, and build it, and have this thread2 (loader) check and critical section (if not in a sync) - converting this prepared memblock to object"


Is there some direct support in GDK to create object from a memory block? I didn't find anything. Or how would you do that?
jason p sage
17
Years of Service
User Offline
Joined: 10th Jun 2007
Location: Ellington, CT USA
Posted: 9th Jan 2008 17:59
Oh Boy - that's a loaded Question. You have to understand FVF Direct X formats (I'm still learning), you set up a memory block with e DirectX "Mesh Header" and then depending on the FVF format - (determines what data is stored per vertex, like XYZ, NormalsXYZ, UVs? UV's for two textures? 3? up to 8 I think) and then you plow all the data into the memblock, and then create object from memblock.

Pseudo Explaination I saw in another post I saved cuz it was more helpful than a code snippet - as I understood the process - I was able to write it myself!
Quote: "
My knowledge of how to do this is a bit limited, but I'll share with you what I know. This is how you make an FVF 338 memblock mesh. I'm sorry if this is a bit pedestrian, but I don't want to make any assumptions about what anyone who reads this knows.

1. Decide how many tiles you want your mesh to be. When I tried making a mesh larger than 100 x 100, I got some sort of memory error message. I don't know if my system doesn't have enough memory or if there is some limitation, or what. I just use multiple meshes if I need more than 100 x 100 tiles.

2. Determine the number of tiles by multiplying the number of tiles in the X dimension by the number of tiles in the Z dimension.

3. Determine the number of polys by multiplying the number of tiles by 2.

4. Determine the number of vertices by multiplying the number of polys by 3.

5. Determine the memblock size by multiplying the number of vertices by 36 and then adding 12 for header information.

6. Make a memblock of the size determined in step 5.

7. Write the header info as shown:
write memblock dword MemBlockNumber, 0, 338
write memblock dword MemBlockNumber, 4, 36
write memblock dword MemBlockNumber, 8, Number of Vertices

338 is the Flexible Vertex Format of the mesh we're making. 36 is the number of bytes per vertex (more on that later). Number of vertices was determined in step 4.

8. Establish a memory variable for the current memblock byte (MemoryPosition) and initialize the value to 12 - the first byte after the header info.

9. Do a FOR/NEXT loop which will write the following information for each vertex:
write memblock float MemBlockNumber, MemoryPosition, X Position
write memblock float MemBlockNumber, MemoryPosition, Y Position
write memblock float MemBlockNumber, MemoryPosition, Z Position
write memblock float MemBlockNumber, MemoryPosition, X Normal
write memblock float MemBlockNumber, MemoryPosition, Y Normal
write memblock float MemBlockNumber, MemoryPosition, Z Normal
write memblock dword MemBlockNumber, MemoryPosition, Grid Color
write memblock float MemBlockNumber, MemoryPosition, U Coordinate
write memblock float MemBlockNumber, MemoryPosition, V Coordinate

IMPORTANT NOTE: Increment the MemoryPosition variable by 4 after each value is written to the memblock.

The number of iterations of the loop is from 1 to the number of vertices.

The number 36 that has been used before comes from the 9 pieces of information listed times the 4 bytes that each float or dword needs.

10. Make a mesh from the memblock
MAKE MESH FROM MEMBLOCK MeshNumber, MemBlockNumber

11. Make an object from the mesh
MAKE OBJECT FROM MESH MeshNumber, ObjectNumber


Now, like you, I don't know the data layouts for the various FVF formats. But there have been times when I needed FVF 530 meshes which hold two sets of UV data. This is what I do for that:

1. Make an FVF 338 mesh as described above.

2. Convert the mesh to FVF 530:
CONVERT OBJECT FVF ObjectNumber, 530

3. Lock the vertex data.

4. Do a FOR/NEXT loop with the following command:
SET VERTEXDATA UV VertexNumber, TextureStage, U, V

The number of iterations is, once again, the number of vertices.

5. Unlock the vertex data.

Now, getting a second set of UV coordinates may not be what you need. My point is that I got that second set of UV coordinates without knowing the structure of the data for an FVF 530 mesh.

I hope this helps you out.

"


Welded Verts: http://www.thegamecreators.com/?m=codebase_view_code&i=4101d5e4795d262e21c510c47b80ca2e

tempicek
16
Years of Service
User Offline
Joined: 27th Nov 2007
Location: Prague
Posted: 9th Jan 2008 18:45
Sorry that I wasn't more specific. I have no problems with FVF codes in DX My question is whether there is a function in GDK to load/create object from a chunk of memory (in place of file). I've found only dbLoadObject and dbLoadMesh functions which requires file name and don't accept pointer to a memory block where the file is already loaded. If I were able to preload the object to memory (which can be done in another thread), the processing could be a way faster.
jason p sage
17
Years of Service
User Offline
Joined: 10th Jun 2007
Location: Ellington, CT USA
Posted: 9th Jan 2008 19:00 Edited at: 9th Jan 2008 19:01
Yeah - I haven't got there yet - but You can create a mesh from a memblock but I don't know if we can get pointers to these DarkGDK memblocks or not only because I haven't tried yet.

[edit]Then you could make a memblock, already know the size - and manhandle it directly if you wanted.

It needs to be a GDK Memblock - not just allocated ram AFAIK[/edit]

Benjamin
21
Years of Service
User Offline
Joined: 24th Nov 2002
Location: France
Posted: 9th Jan 2008 19:06
What you can do is load the mesh into a memblock (but make sure it is stored in the exact format that it should be in the memblock) and then convert it to a mesh using dbMakeMeshFromMemblock (excuse me if that's slightly wrong, I haven't yet used DarkGDK so I'm just guessing). This should be safe to do in a separate thread. The next thing you do is make the object with dbMakeObject, and for this part it is important that you do not call it while another 3D-related call is in progress. Essentially, you should do this from the same thread that dbSync is called from to avoid problems.

Tempest (DBP/DBCe)
Multisync V1 (DBP/DBCe)
tempicek
16
Years of Service
User Offline
Joined: 27th Nov 2007
Location: Prague
Posted: 9th Jan 2008 19:49
Quote: "What you can do is load the mesh into a memblock (but make sure it is stored in the exact format that it should be in the memblock)"


That means I will have to do the loading part (i.e. parsing particular file format) by myself anyway?

Quote: "... then convert it to a mesh using dbMakeMeshFromMemblock. This should be safe to do in a separate thread."


I thought that the 'Mesh' object already defines the model using vertex and index buffers in video memory. Isn't that so? (In such case I wouldn't believe you could do that in separate thread.) What's the difference between 'Mesh' and 'Object' in GDK anyway?
jason p sage
17
Years of Service
User Offline
Joined: 10th Jun 2007
Location: Ellington, CT USA
Posted: 9th Jan 2008 20:15
One seems to be "Registered For Use" the other not.

Mesh = Ammo

Object = Loaded gun

Benjamin
21
Years of Service
User Offline
Joined: 24th Nov 2002
Location: France
Posted: 9th Jan 2008 20:43
Quote: "That means I will have to do the loading part (i.e. parsing particular file format) by myself anyway?"

Correct. I would recommend loading the media, converting it to memblocks, and saving these memblocks to files. Then your game/application can load these files straight into memblocks without you having to parse anything.

Quote: "I thought that the 'Mesh' object already defines the model using vertex and index buffers in video memory. Isn't that so? (In such case I wouldn't believe you could do that in separate thread.)"

Objects are what you see on the screen, a mesh is just the data of an object. As meshes themselves aren't rendered on the screen, I think it's safe to assume that you can load them without dbSync exploding on you.

Tempest (DBP/DBCe)
Multisync V1 (DBP/DBCe)
tempicek
16
Years of Service
User Offline
Joined: 27th Nov 2007
Location: Prague
Posted: 9th Jan 2008 21:55
Quote: "Correct. I would recommend loading the media, converting it to memblocks, and saving these memblocks to files. Then your game/application can load these files straight into memblocks without you having to parse anything."


Well, what I had on mind was the fact the you actually have to write the parser, which is the most unpleasant stuff in any game (but of course, you have to do that often anyway if you need your own data format).

Quote: "Objects are what you see on the screen, a mesh is just the data of an object. As meshes themselves aren't rendered on the screen, I think it's safe to assume that you can load them without dbSync exploding on you."


Actually I wasn't thinking about dbSync complaining, but the mesh creation function. DX device can be accessed from multiple threads only if you create the device with appropriate flag, which I'm affraid GDK is not doing (and there's no chance AFAIK to choose this in GDK). Finally even if the mesh object is not used for rendering, I assume they use DX buffers for storing the data (but we would have to try that). But that would be a little problem anyway.

Seems to me as another of those pieces where you can get thru pretty easily with basic D3DX stuff, but it's a lot harder with GDK which is supposed to do it easier for you I can't realize why they hide all the good DX stuff behind their API if they can not support all the functionality.
Benjamin
21
Years of Service
User Offline
Joined: 24th Nov 2002
Location: France
Posted: 9th Jan 2008 22:00
Quote: "DX device can be accessed from multiple threads only if you create the device with appropriate flag, which I'm affraid GDK is not doing (and there's no chance AFAIK to choose this in GDK)."

Ah well, if this is the case then the mesh creation would have to be executed synchronously. So really all you can do is load data into the memblock its own thread.

Tempest (DBP/DBCe)
Multisync V1 (DBP/DBCe)
jason p sage
17
Years of Service
User Offline
Joined: 10th Jun 2007
Location: Ellington, CT USA
Posted: 9th Jan 2008 22:29
I'm starting to think - that the best you can do is load raw data, and "lock" during a mem-to-mem copy or something... that's a lot of thunking. Hmm... Well, its still less code than writing directly to Directx.

Can you load direct.x, get 3d sounds, move limbs, make meshes and all of that in Direct.X directly?

tempicek
16
Years of Service
User Offline
Joined: 27th Nov 2007
Location: Prague
Posted: 9th Jan 2008 23:24
Quote: "Well, its still less code than writing directly to Directx."


Not sure what you meant.

Quote: "Can you load direct.x, get 3d sounds, move limbs, make meshes and all of that in Direct.X directly?"


Actually, yes, in some way. It's a bit more complex question. If you consider all the DX SDK components available, then you can load .X files, drawing them is pretty easy too (still harder than with GDK, but that's the price for closer control). With XACT and XAudio2 you can author and play (3d)sounds with a huge comfort of settings configured directly by the author/composer. Moving limbs is a harder job - you have to write your own animating system. On the other side, you have a lot of functions for GUI, easy game timing & control, shader/effect framework is priceless... most of it is just more difficult to use. E.g.: there's a simple function for loading a .X file. Yes, ther is. But it doesn't create an object which you use Object->Draw(). It rather creates set of meshes with their materials info, and you draw them separately, setting a texture/material/shader for every single one.
jason p sage
17
Years of Service
User Offline
Joined: 10th Jun 2007
Location: Ellington, CT USA
Posted: 10th Jan 2008 04:00
Quote: "Quote: "Well, its still less code than writing directly to Directx."

Not sure what you meant."


I mean DarkGDK is a RAD version of DirectX... sure some stuff is limited - but then - you do get a lot of stuff placed right at your finger tips.

In other words - despite limitations that may exist in DarkGDK - My original premise for buying it is steadfast: DarkGDK allows me to get stuff happening without miles and miles of code.

(Instead I just haves miles of code) And that is good enough for me

tempicek
16
Years of Service
User Offline
Joined: 27th Nov 2007
Location: Prague
Posted: 10th Jan 2008 09:06
Quote: "DarkGDK allows me to get stuff happening without miles and miles of code."


And don't allow other stuff happening at all because their hiding of the underlaying technology

Login to post a reply

Server time is: 2024-09-29 09:20:58
Your offset time is: 2024-09-29 09:20:58