min max allowed value of entityorder ?
Blitz3D Forums/Blitz3D Beginners Area/min max allowed value of entityorder ?
| ||
| Hello, I have read the documentation and searched the forums but i have not found the answer : What is the minimum value (example : -999999) and what is the maximum value (example : +999999) allowed for entityorder ? Maybe it is a blitz3d integer max value divided by 2 ? 4294967296/2 = 2147483648 ? Thanks, |
| ||
| My first thought would be blitz max integer range. However I guess you could always test it? |
| ||
| Hi RemiD Look at it from the other side ... Imagine you use 4294967296 different Objects with 4294967296 different entityorders your computer has to sort every 60th of a second ... that are 4294967296 loops to find places and moments when to draw which object on the screen for your computer. Do you think its worth to make yourself a head for this? Especially when you must have in mind that you have to decide personally which object or group of objects shall be drawn first or last. A calculated order is done by Blitz anyway. Can any computer make 4294967296 loops to draw graphic in a fraction of a second? Practical even 100 loops (-50 to +49) can be too much depending on how many objects you have on screen and which have to be sorted each frame to drop the framerate into the cellar ... And its in 99% of all cases you personally who have to select each object or group of objects and give it a number. How long will it take you to place 4294967296 different numbers? As far as I understand how this works: Blitz is looping through the list of objects - no EntityOrder given means 1 Loop to find, 1 loop to draw - Each different EntityOrder given means another loop to paint the found objects onto the background earlier or later than normal. As more different numbers (EntityOrders) are stated, as more loops through all objects are needed ... |
| ||
| Entity order is a plain signed int. Any value in the full range should do. The value of the entity's draw order, or the number of different levels used, has no effect at all on performance. RenderWorld sorts ordered objects into a list, by order-value, then draws using exactly three loops: ordered>0, unordered, ordered<0. It performs this sort and these three loops every frame, regardless of how many objects are ordered or what the actual values are (the value itself makes no difference, only its ordering relative to other explicitly-set values). |
| ||
| the number of different levels used, has no effect at all on performance Yasha, this is wrong I would say ... and if you take a deeper thought, you may come to the same conclusion as I did during the last minutes. Took my interest to think about it. There must be some calculation internally to make the difference: Maybe something like this: LastOrderNumber=2147483647 NextOrderNumber=-2147483647 Repeat Flag=0 For i=1 To NumberOfObjectsUsed If ObjectOrderNumber(i) > NextOrderNumber And ObjectOrderNumber(i) < LastOrderNumber NextOrderNumber = ObjectOrderNumber(i) Flag=1 EndIf Next For i=1 To NumberOfObjectsUsed If ObjectOrderNumber(i) = NextOrderNumber DrawTheObject(MyObject) ; the internal Function which draws the Objects EndIf Next LastOrderNumber=NextOrderNumber Until Flag=0 ;Not tested - just to show what may go on internally Sorting costs time ... always ... and Blitz cannot pre-sort once, since Order can be changed during each Frame. The only way to be sure would be to load 10000 Objects, give them 10000 different random EntityOrders and measure the time compared to other constellations (no Order / only 2 or 3 levels) ;-) Logical seems to me, that as more different numbers for EntityOrder, as more time is used and perfomance drops significantly. Its hypothetic anyway ... no-one places 2 Billion different numbers by hand ... |
| ||
| A hugely memory inefficient way to handle 2 billion numbers in a sorted list (but very fast) is to simply store them by array reference and keep a list of which array indices are not empty...then just loop through the non empty indices in order. Basically a counting algorithm of sorts. |
| ||
| Sorting costs time, but it costs time based on the number of objects to sort. Your post #3 seemed to suggest the values might have some effect on the time for the sort, which they don't (noticing that the only operation you ever perform on a value while sorting is <, so whether it's 10 or 10000, being compared to 0 makes no difference). Obviously more explicitly-ordered entities mean sorting the ord_que takes longer. How this affects overall performance is difficult to say, since obviously an entity being sorted into the right place in the ord_mods vector is an entity not being sorted by draw distance in the unord_mods vector (where everything else goes), so there's probably no significant net effect either way. i.e. the same number of loop iterations is used for a given number of objects, whether they're sorted by explicit order, or by draw distance. Only the number of objects in total matters. |
| ||
| As I said ... interesting to think about it ... not more, not less ... But there must be sorting involved ... and this can not be done in one loop ... for each level of EntityOrder drawing the objects to the buffer is therefore be done in loops also ... and the more loops, the more time is used ... and you only have a fraction of a second each frame Coming back to the topic question. It is not needed to discuss how big the number used in EntityOrder can be, since you use a comprehensible number of levels anyway ... and this is usually -10 to 10 or -100 to 100 or if you have a very complicated situation -1000 to 1000 at most ... |
| ||
| Ok, i asked this by curiosity, and also to not use a number too high/low which would not be considered by Blitz3d... |
   |