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 / Limb Alpha

Author
Message
Sephnroth
20
Years of Service
User Offline
Joined: 10th Oct 2002
Location: United Kingdom
Posted: 27th Jul 2005 23:59
Im curious as to if anyone knows how, probably using directx commands, I can write a function to set the alpha value of an objects limb?

This is for Iro, my puzzle game. A huge optimisation (so I am told) would be to make all the objects that make up the levels into limbs of just one object. I would end up with just 1 object which was the world then rather than upto 1000 different objects (which are all dark basic primitives pretty much, all cubes). I can see why that would be faster, but theres some problems with implementing that with Iro's design - namely with hiding objects.

The engine makes a check of all objects near to the player and using intersect object it checks if any are between the player and the camera and if so it applied ghost and fade commands so the player could still see themselfs. Obviously i cant use those commands on limbs so I need to create one to do the job :/ I heard there was a dll hanging around once apon a time that could set the limb alpha in dbp so I guess its possiable to do this, anyone know how?

Now I think about it I would need something else to check if there is a object between the player and the camera because intersect object wont work on limbs x_X

gah, does anyone have any suggestions? :/

Louiz ofRohr
18
Years of Service
User Offline
Joined: 11th Nov 2004
Location:
Posted: 28th Jul 2005 16:44 Edited at: 28th Jul 2005 16:53
I don't know if it is gonna help you, but..
You could do this:
1_ create "imaginary objects"..
2_ position them to limbs's positions..
3_ associate the objects to limbs via array, variables
---correspondence or whatever other association method..
4_ check intersections of camera to objects..
5_ set alpha to limbs of their respective dummy objects..

It is a gross way to do it..
but I think it works

About your own function for "limb intersection"?
Sorry.. I'm novice at C++ programming (almost nothing)

good luck..

The worst foe lies within the self...
Mike Johnson
TGC Developer
20
Years of Service
User Offline
Joined: 13th Sep 2002
Location: United Kingdom
Posted: 28th Jul 2005 17:21
Turning all the objects into the limbs will be slower. For what you are doing I think it will be better to keep all of your objects separate.
Sephnroth
20
Years of Service
User Offline
Joined: 10th Oct 2002
Location: United Kingdom
Posted: 28th Jul 2005 18:13
Interesting - so one big object is actually slower than lots of little ones totalling the same polygon count? Or is it just slower in this situation with the need to fade limbs?

Thats a bit of a bugger in some ways, Iro does run horrendously slow on some big maps and the polygon count is no where near that of modern games as it were, i'm now out of ideas to speed it all up :/

Mike Johnson
TGC Developer
20
Years of Service
User Offline
Joined: 13th Sep 2002
Location: United Kingdom
Posted: 28th Jul 2005 18:41
One of the problems of using objects with small polygon counts is that this is not efficient. Ideally you need to be drawing several hundred polygons at once and then moving to the next set rather than drawing a few polygons each time which would happen with cubes. If there is any way you can optimise your scenery to ensure this will happen that will help a lot.

You may also like to try experimenting with this function "void dbSetGlobalObjectCreationMode ( int iMode )". This will allow you to control whether an object has its own vertex and index buffers ( iMode == 0 ) or whether these buffers are shared ( iMode == 1 ). Sharing buffers in most cases will result in a much faster frame rate. I expect in your case this will prove to be a good increase.

Have you also considered using dbExcludeObjectOn and dbExcludeObjectOff. These functions can have a significant increase in frame rate for objects that are not in use.

If you can show some screenshots of what you are doing and provide more detail on the specifics we can try and get things going much faster.
Sephnroth
20
Years of Service
User Offline
Joined: 10th Oct 2002
Location: United Kingdom
Posted: 28th Jul 2005 20:14
First off, thanks for replying Mike - I appreiciate this assistance

Some screenshots of Iro can be found in the puzzle competition thread. Primarilly I am looking for techniques to speed it up, but I hope to apply it to other projects in the future.

The entire world is made up using the dbMakeObjectBox() primitive. Some use different size parameters to make thin platforms. Slopes and ramps are made by creating a box and then altering the vertex data like thus:



(vpx etc are all #define macros for vertex position x etc - uses all the normal vertex commands but using short hand macros)

and thats pretty much it except for entities, but those can naturally be handled as normal objects.

Yes, I understood about doing more polygons at once being a better idea - thats why I figured creating all these objects as limbs would be a good idea? Wouldnt that leave you with just one object made out of limbs at the end of the loading process which would be processed all at once? Or does the renderer process limbs seperatly as if they were seperate object?

Those functions look interesting! I just had a quick whip through the help file and couldnt find them by doing a search in the basic3d section so I didnt know they existed x_X What is the downside to sharing a vertex buffer? IE - why WOULDNT I do it? Should only objects with exactally the same vertex data share the same buffer? ie all ramps, all boxes, all paralellograms etc? in which case is there a way to set which buffer they use or is this all handled automatically?

ExcludeObject im guessing removes it completly from the rendering pipeline? Does this not happen when you hide an object? There is already a function I wrote which hides and disables collision for all objects that are not on screen during play - would also calling an exclude on them do something that hide/disable collision doesnt do?

Thanks again for all this assistance Any more ideas will be greatly appreiciated - the faster the better

If its any further help, the level is stored in a kind of node tree - its a custom typed struct which I can use to access any nodes object ID, know its position and its type (is it a normal box, a ramp, a thin box, etc) and also what entity is attached to it.

Thanks again!

Mike Johnson
TGC Developer
20
Years of Service
User Offline
Joined: 13th Sep 2002
Location: United Kingdom
Posted: 28th Jul 2005 23:21
Limbs are essentially a collection of meshes contained within an object. If you are to add a limb into an object it will still remain as a separate mesh and be drawn individually.

For objects which are similar such as your primitives it will make a difference to share vertex and index buffers. If you have objects with lots of different vertex formats then it won't make a big difference. Everything will be handled automatically when you set the flag and the engine will attempt to share as much as possible.

Some work still goes on even when an object is hidden. Excluding the object takes it out of the process completely and this extra step helps a lot. When objects are excluded they are completely ignored.

One thing that will help is if you can cluster objects in your node tree. Say you have a collection of boxes and ramps in one node if you could make it so these were combined to form one object ( add all the vertices and indices in one object ) this will likely improve the frame rate rather than drawing them one at a time.
Sephnroth
20
Years of Service
User Offline
Joined: 10th Oct 2002
Location: United Kingdom
Posted: 29th Jul 2005 00:44
Hmm interesting. Is there any reason I shouldnt go around setting the flag to share buffers in all my applications? Will it either help or do nothing, never "make it worse" as it were?

Thanks for the tip off with exclude, that will certainly be added to all my projects that hide objects when they arnt needed! Will it effect affect collision too?

Grouping objects together into the same mesh sounds just like was I was aiming for though. However, it does bring me back to my original conumdrum which was how can I handle the fading of objects that obstruct the view of the player? If i chunked together a few platforms then it would start looking silly if they all got faded away x_X Im guessing i would need to start somehow seeing which part of the object obstructed the camera and indivudually set vertex alpha - i wouldnt even know where to start there if i am completly honest though.

If I should desire to group objects into one mesh though, how would I go about it? With the vertex commands? or is there another function that has slipped my attention to add one object litrally to another?

Thanks again for all this help

Mike Johnson
TGC Developer
20
Years of Service
User Offline
Joined: 13th Sep 2002
Location: United Kingdom
Posted: 29th Jul 2005 01:43
The best thing you can do with sharing buffers is to experiment. If you're using objects that share the same vertex format then chances are it will bring a good improvement. Even if not then still give it a go just to see how things work.

Can you show some screenshots of how you're currently doing the alpha right now on objects so I can get an idea of it. It might be the case that you can use the vertex commands and work out what triangles are obscuring the view and then modify their alpha. You could even pre calculate a lot of this for example, say you have 100 boxes in one node you could maybe split these up into 4 individual objects and adjust the alpha at the object level for objects 1, 2, 3 or 4 so maybe more of the objects would be having their alpha level on than normal but it may save time. If using this you could be in zone 1 and set the alpha on so it is see through and leave objects 2, 3 and 4 alone. Alternatively you could go further and calculate further regions in more detail as to what needs to be adjusted based on the viewpoint.

There's bound to be many ways of approaching this. Have you got any screenshots that show what you're currently doing or maybe even a demo to try.
Louiz ofRohr
18
Years of Service
User Offline
Joined: 11th Nov 2004
Location:
Posted: 29th Jul 2005 07:10 Edited at: 29th Jul 2005 07:15
Yep
I said that just following the idea of camera intersecting
limp to object's position..
Mike Johnson said all..
I rather use separated objects for doing things like this..
Really interesting..

By the way, Mike Johnson, I usually model my scenes by just
"sweeping" faces to get things like some walls and other
static objects.. even in this case, only one object is
gonna be slower than draw separated objects?

Gluing limbs sounds really gross.. maybe useless if you have
a small scenery, once each limb is drawn individually as
an independent object does..

[edit] is it?

The worst foe lies within the self...
Mike Johnson
TGC Developer
20
Years of Service
User Offline
Joined: 13th Sep 2002
Location: United Kingdom
Posted: 29th Jul 2005 10:26
Louiz - one object will be slower than separated for sweeping through faces but you could always pre calculate certain data and have polygon lists to one side for collision. I suppose theres many ways of doing this but one of the main things is regardless of which way to try and batch polygons together for example, 100 cubes merged into one object will likely draw faster than 100 individual cubes.
Sephnroth
20
Years of Service
User Offline
Joined: 10th Oct 2002
Location: United Kingdom
Posted: 29th Jul 2005 14:31 Edited at: 29th Jul 2005 14:32
Mike hehe Iro is my puzzle competition entry as i commented before, so its fully availiable to download ^^

here is a screenshot i just took of an object being faded:
http://www.melted.com/spectural/storage/iro/fade.jpg

It may a bit hard to spot in the jpeg, but an object as been found between the player and the camera. It simply calls an intersect object between the camera position and the player position and sees if there is an intersection - if so it applys ghost object and fade object to the node obscuring the view.

Calculating specific triangles would be rocking o.O But it sounds like an expensive routine?

I will be trying out the buffer sharing as soon as im done waking up properly ^^ Thanks for all this help, as usual all further suggestions welcome

EDIT - note full source is availiable on request for this game if thats any use.

Mike Johnson
TGC Developer
20
Years of Service
User Offline
Joined: 13th Sep 2002
Location: United Kingdom
Posted: 29th Jul 2005 15:58
The work with calculating specific triangles will be expensive at runtime but if it's all pre calculated and stored in your level data then it would be really simple to access at runtime and fast.
Sephnroth
20
Years of Service
User Offline
Joined: 10th Oct 2002
Location: United Kingdom
Posted: 29th Jul 2005 18:11
pre calculating what is visable for 360 degrees of rotation from any node? hmm.

It was hard enough with my rpg engine where the dungeons were stored like a tile map in a 2d array which i could use line algortihms inside to calculate a half-arsed vis table (far from accurate :/) - i would hate to think how to do that in iro with its 1d node stack x_X The reason i went with the stack instead of the 2d tile-like array was to uncap any limitations on the amount of floors it could have.

Anyway - I have just added a call to dbSetGlobalObjectCreationMode(1); at the top of my program. I think i may of gained 1 or 2 fps, unfortnatly it wasnt the miracle cure everyone is always looking for Whats new XD

If you have time then a good demonstration of the kind of thing that really slows iro down can be viewed by downloading Iro from the puzzle competition board and calling the exe with the command line:
-map beginner\beginner09.iro

That is a map called staircase and the level gets slower and slower as you climb said staircases - right at the top we're looking at about 42fps with the buffer sharing enabled and low 30's without. My aim is for a steady 60. There IS alot being drawn so maybe i simply cant do anything about it, but im sure many games and whatnot render much larger scenes polygon-wise on my computer at over twice the fps. I accept that lower end pc's may never manage it - but im running a p4 2.4ghz with 768megs of ram and a radeon 9600 pro (256 meg card - still cutting the cake with games like doom3, hl2 and prince of persia ) and I kinda hoped I could find a way to get these maps really sped up.

I'm begining to think maybe the only way is by combining all the meshes into one big one. A technique i wished to apply to my rpg Shisaku too - but in that case it again hides all objects you cant see using a LOS algorithm and unless DarkSDK culls all polygons on one model that another part of the model is obscuring (does it? x.X) i think i would be getting a lower fps for doing that --;

Running out of ideas

Login to post a reply

Server time is: 2023-02-02 15:21:59
Your offset time is: 2023-02-02 15:21:59