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 / id numbers

Author
Message
QuakeMan
14
Years of Service
User Offline
Joined: 2nd May 2010
Location:
Posted: 30th May 2010 16:28
Hellow,i'm a beginer in DarkGDK and i was reading the getiing starting tutorial but i don't understeand wath are the id numbers could someone explain me?please.

id software
Hassan
15
Years of Service
User Offline
Joined: 4th May 2009
Location: <script> alert(1); </script>
Posted: 30th May 2010 19:09
Everything (almost everything..) in DGDK have an ID, for example, lets say you made an object, and you want to position it somewhere in the world, you would call dbPositionObject ( ID, X, Y, Z ), the XYZ parameters are the position coords, and the ID is the ID of the object, if there were no ID's, how would the function know what object you want it to be positioned?

QuakeMan
14
Years of Service
User Offline
Joined: 2nd May 2010
Location:
Posted: 30th May 2010 19:28 Edited at: 30th May 2010 21:31
has to see if I understand...

the object 1 will have the id 1,and the object2 will have de id 2 ¿Right?

id software
Neomex
14
Years of Service
User Offline
Joined: 30th May 2010
Location:
Posted: 30th May 2010 20:44
Hi,
it is just great to use enum types here!
for example

enum
{
id_player = 1,
id_enemy,
id_flower,
};

so you dont need to remember all numbers.
jason p sage
17
Years of Service
User Offline
Joined: 10th Jun 2007
Location: Ellington, CT USA
Posted: 31st May 2010 03:47
The other thing you'll want to search around for is articles on "Class Factories"... In short folks make a class to call when you want to create and object and the class contains info about the object. This can get dicey; but is a good read. This is one of those areas where you ask 2 people for the "correct" way to do it and you get 4 different answers.

I personally like to; at a minimum make a variable; that I keep incemetning when I need to make a new object.

ex:

and the function might be just adding ONE and then returning the new value. The reason I and other use techniques like factories ultimately is to not have to think in terms of numbers like NeoMax said.

So....


Then I'd use the MyNewSpaceShipID variable versus trying to remember or use a bunch of numbers all over the code.

Good Luck!

Hassan
15
Years of Service
User Offline
Joined: 4th May 2009
Location: <script> alert(1); </script>
Posted: 31st May 2010 14:46
QuakeMan, the ID is specified by YOU, when you create an object, you assign an ID for it, for example, dbLoadObject ( "objectname.X", ID ) requires an ID, it will load an object and give it the ID that you passed, so if you give it ID 5 for example, you can adjust it (move/rotate/scale/etc) using this ID (5)

jason p sage
17
Years of Service
User Offline
Joined: 10th Jun 2007
Location: Ellington, CT USA
Posted: 31st May 2010 15:48
Absolutely correct; and managing those ID's with hardcoded values is fine when you are starting out; but making an infrastructure to generate them programmatically will save you headaches as you move forward.

QuakeMan
14
Years of Service
User Offline
Joined: 2nd May 2010
Location:
Posted: 31st May 2010 19:24
Does the id used to not having to type the name of the object x? Each object must have a different id? (Sorry for being heavy)

id software
QuakeMan
14
Years of Service
User Offline
Joined: 2nd May 2010
Location:
Posted: 31st May 2010 19:27
Does the id used to not having to type the name of the object x? Each object must have a different id? (Sorry for being heavy)

id software
Bjorn
14
Years of Service
User Offline
Joined: 20th Mar 2010
Location:
Posted: 31st May 2010 20:34 Edited at: 31st May 2010 20:35
Yea, whit an id you exely point to the object whit that file,

For every object you load you most have a different id
like:

Hassan
15
Years of Service
User Offline
Joined: 4th May 2009
Location: <script> alert(1); </script>
Posted: 31st May 2010 20:41
exactly as above, and yes each object have a unique ID, if you create a new object with and existing id (an ID that is being used by another object) the old object will be destroyed and the new one will replace it, because the ID's cannot overlap

QuakeMan
14
Years of Service
User Offline
Joined: 2nd May 2010
Location:
Posted: 31st May 2010 20:54
haaaaaa ok now i understeand it thanks really thanks to everybody

id software
TechLord
21
Years of Service
User Offline
Joined: 19th Dec 2002
Location: TheGameDevStore.com
Posted: 1st Jun 2010 12:40 Edited at: 1st Jun 2010 12:46
Recycled ID Management



Uses



Morcilla
21
Years of Service
User Offline
Joined: 1st Dec 2002
Location: Spain
Posted: 2nd Jun 2010 12:06
It is said it is wise to keep low Id's for objects and textures.
Also Id's can play a role in Z-order.


Hassan
15
Years of Service
User Offline
Joined: 4th May 2009
Location: <script> alert(1); </script>
Posted: 2nd Jun 2010 15:07
Quote: "Also Id's can play a role in Z-order."


Huh? are you sure? i don't think IDs have anything to do with the z order, i believe it's just to identify the object, and it has nothing to do with the way it is rendered

jason p sage
17
Years of Service
User Offline
Joined: 10th Jun 2007
Location: Ellington, CT USA
Posted: 2nd Jun 2010 17:15
I recall some "weirdness" having to do with either load order or ID number... where loading (or ID number order possibly) changes how filters (when applied) cause objects to "look"... For example; I recall something about turning Z Buffering off for some "skybox" and "Skysphere" effects so landscape never "got clipped" by being bigger than the skybox ... and load order made a difference if the Sky or the object had visual priority.

Diggsey
18
Years of Service
User Offline
Joined: 24th Apr 2006
Location: On this web page.
Posted: 2nd Jun 2010 18:49
ID numbers don't directly affect the Z order, but they can indirectly affect it, simply because if you loop through an array you will go through the lower indexed elements first

Hassan
15
Years of Service
User Offline
Joined: 4th May 2009
Location: <script> alert(1); </script>
Posted: 2nd Jun 2010 18:52
Hmm? i don't think they are arranged according to their ID's, but to their distance from the camera, and thus, IDs have actually NOTHING to do with the Z-order

jason p sage
17
Years of Service
User Offline
Joined: 10th Jun 2007
Location: Ellington, CT USA
Posted: 2nd Jun 2010 19:12
Perhaps; like I said - I noticed something odd here; and it might of been load order effecting internal z order. e.g. Loading Skybox first then terrain versus opposite order; when playing with zorder filters.. dunno... mountains of code to write...I'm off

Morcilla
21
Years of Service
User Offline
Joined: 1st Dec 2002
Location: Spain
Posted: 3rd Jun 2010 10:41
Quote: "Huh? are you sure? i don't think IDs have anything to do with the z order"


Yo, sure I'm sure.
It is some sort of default z-order, that can be used to cleverly stablish your own z-order system, and override the distance from the camera.
However, sometimes this can lead to unexpected 'why is my object behind this if it is in front', as we are not aware of the IDs being used.
Having automatic IDs generation (lowest free available) is interesting and surely it makes things easier, but for a total control, you'll finally find yourself manually assigning IDs for groups of objects.

Here is a function that came in with DGDK 7.3:

Quote: "dbSetGlobalObjectCreationMode( 2 );

"Add this at the top of your program and all objects handled in your application use 'sort by object order' rather than 'sort by texture number'."

What this means is that there is no expensive bubble sort each time new objects are introduced into the engine, and so loading and main loop performance may increase slightly.
The downside is that the GPU will be asked to continually swap textures back and forth with no care to render all objects that share a common texture.
In some cases, this will degrade performance based on your scene complexity. Either way, it is another little tweak you may wish to experiment with to gain a few extra FPS from your projects."


That function switches the ID role from 'Texture IDs'(default) to 'Object IDs', and I can tell it has something to say regarding z-write and z-read.

I use the default 'Texture IDs' mode, as I already had built things around it.
I strongly recommend to run this dbDisableObjectZRead example:



The texture ID decides which object is in front.
Lower IDs will appear behind higher ones, hold 'Space' and 'Enter' to change z-order priority between the planes and the sphere.

Hassan
15
Years of Service
User Offline
Joined: 4th May 2009
Location: <script> alert(1); </script>
Posted: 3rd Jun 2010 15:13
Changing the ID's from 1-2-3 to 1111111-2222222-3333333 would impact the demo? i don't see what is the relation between the texture ID's order and whether the ID's are high/low,i don't think so, well i dont have gdk installed to test

jason p sage
17
Years of Service
User Offline
Joined: 10th Jun 2007
Location: Ellington, CT USA
Posted: 3rd Jun 2010 17:25
Well, Morcilla's findings kinda match the weirdness I ran into but never delved in deep to solve. I figured it was load order and changed a couple things.. just load skybox first (inherently lower id). I never researched it really; he evidently has.

So you have two folks pointing out an oddness; I personally never thought it was a big enough deal to be a bug; and Morcilla basically is confirming things with code to prove it. Both of us have been hammering at this stuff for some time... in fact I was a NUT for awhile coding DarkGDK everyday practically for a LONG TIME...

So I think it's great you are cautious; there seems to be something here.. however minor. (Thankfully these aren't earth shattering "theory busters".) I actually get quite upset at those because then I have to go through all my code and look where I may have coded something destined to suffer from my preconceived understanding.

Regardning your question - 1-2-3 to 111-222-333 etc would only change the demo if you had ids below 111 and above 333 or intermingled. It's not the values themsevles as much as their relationship to other "entities" or "things" if I'm readining everything correctly from Morcilla.

Diggsey
18
Years of Service
User Offline
Joined: 24th Apr 2006
Location: On this web page.
Posted: 3rd Jun 2010 17:34
@Hassan
Objects are not drawn according to their depth to the camera, that is just an illusion because of the Z buffer.
Certain transparency modes can make objects render first/last in the order, and most engines do some sort of ordering based on the textures to reduce the number of texture state changes, but for objects which that doesn't separate, DBPro will just draw going through the list of objects, which is in the order of the IDs.

Hassan
15
Years of Service
User Offline
Joined: 4th May 2009
Location: <script> alert(1); </script>
Posted: 3rd Jun 2010 18:32 Edited at: 3rd Jun 2010 18:40
Quote: "Quote: "do GDK arranges objects render with alpha from the farthest to the closest?"
Yes, ....."


said ianM. [http://forum.thegamecreators.com/?m=forum_view&t=166470&b=22&p=1]

since transparency is used in the example above, they are arranged like that, because the non-transparent object's should be drawn first and then the transparent one's after them so you can see the non-transparent objects through the transparent ones, and the ID have actually no role in this

So yes, object IDs have nothing to do with it's rendering, low or high ID it doesn't matter

i have always been using random ID's, low ID high ID whatever, i have NEVER faced any problem with the Z order or such things, only when using transparency which is because the scale is not considered in the calculations.

Morcilla
21
Years of Service
User Offline
Joined: 1st Dec 2002
Location: Spain
Posted: 4th Jun 2010 11:52
Quote: "... I figured it was load order and changed a couple things.. just load skybox first (inherently lower id)."

Yeah that's a good example about texture IDs and z-order:

Skyboxes usually suffer from z-fighting (flicker in the distance), because they have to be huge to cover the visible scenary.

dbDisableObjectZRead on an object, ensures that any other object, with a higher texture ID, will appear on top of the object with dbDisableObjectZRead applied.

Following? Good. That means that a skybox could be as small as the short camera range. Just texture it with the lowest texture ID, apply dbDisableObjectZRead, and position it as you would (usually centered on camera). This way you can:

-forget about z-fight
-forget about the usual problem of an object going thru the skydome itself because of the distance.
-use smaller texture sizes for the skydome, because it is nearer from the camera.

Quote: "object IDs have nothing to do with it's rendering, low or high ID it doesn't matter"

Well, all that has been said will switch to object IDs, instead of texture IDs, if you place this at the beginning of a program:




Quote: "i have always been using random ID's, low ID high ID whatever, i have NEVER faced any problem with the Z order or such things, only when using transparency which is because the scale is not considered in the calculations."

Hey it is up to you, and if it works for you, then I have nothing to say about it.
IDs can be used to treat z-order in transparent or solid objects, but it is not mandatory to take care of that

Login to post a reply

Server time is: 2024-07-04 10:46:33
Your offset time is: 2024-07-04 10:46:33