| |
| |
| |
|
Comments:
<0> hoovemouth
<1> hellow
<1> no we're not here
<1> yes you can ask your question anyhow
<2> ;)
<2> 1: what do you need?
<2> 2: no you cant have it!
<1> 3: we're gonna teach you how you can leave without it
<1> live
<1> well, or leave
<2> :D
<2> i like leave better :)
<2> lol
<1> here I come
<1> Ive seen about doing a multiviewport app, and it seems like creating swap chains is the way to go
<1> but now I wonder if rendering to a Drawing.Image (in c#) wouldnt help better
<1> or maybe I could implement its interface with a swapchain
<1> if what Im saying doesnt make any sense, that's alright
<3> sense not you make
<1> the idea is that I could use that viewport image in any dotnet control which uses an image
<1> see?
<3> you're not going to find a fast way to do that
<1> I guess you're right
<3> =]
<1> that'd be nice to have a dx viewport to render my application icon
<1> I mean, I could state that no one did it before
<1> last time I tried to mess up with images, I couldn't even draw a pixel in it :)
<3> my friend did that
<1> Im not your friend, and I haven't done it yet
<3> thus someone else is!
<3> pwnzd
<1> :'|
<1> I could implement a Image cl*** which would holds a bitmap, and then I'd just need to copy a texture to it
<1> sounds good
<3> nope
<3> any idea you come up with that involves copying the front buffer is going to be slow
<1> how slow?
<1> because if it takes 1ms to render a 64x64 image it's almost fine to me
<3> it takes about 1s to get the front buffer
<1> what's the front buffer? can't I just lock my d3d texture and read from it?
<3> I don't think render targets are lockable
<1> :'|
<3> you'd have to render to a render target, copy it to a system texture, and then read that
<1> and that would take 1sec?
<3> it can, yes
<1> 8|
<3> depends on the hardware, but it's often slow
<1> http://www.gamedev.net/community/forums/topic.asp?topic_id=388746&whichpage=1�
<1> thx for the input
<3> sure, n/p
<1> another question: is it possible to use a texture created from unmanaged d3d into a managed d3d app?
<1> I guess I'd just need to share the d3d device
<1> beh
<4> or move it through a different medium
<3> sounds like a bunch of hippy crap
<1> I'll probably try to use piccolo3d
<1> if I could p*** his device to my unmanaged code, it'll be cool
<1> except if it uses a different device for each canvas, ahh
<1> damn
<1> it does
<1> whatever
<1> Im gonna rollback to software rendering
<1> :)
<1> jk
<3> lawlz
<0> :)
<1> "I have written a wrapper around a C++ SDK and have been able to p*** a managed DirectX Device to the managed wrapper, and extract the unmanaged IDirect3DDevice object."
<1> http://www.gamedev.net/community/forums/topic.asp?topic_id=273717
<1> \o/
<1> IntPtr p = d->GetObjectByValue(0xd2b543af);
<1> ahah
<3> super hax
<5> Is switching rendering contexts relatively slow in DirectX? Such as enabling a light, disabling a light, changing rendering states, etc?
<0> thats called changing state
<0> and well, yes its relatively slow
<0> which means you should avoid it as far as possible
<0> however
<0> the deciding factor is mostly "changing state and then drawing"
<0> not just changing state on its own
<0> so if you have eg
<0> change state, change state, drawprim, change state, drawprim
<0> then you have two "batches"
<0> [change state, change state, drawprim], [change state, drawprim]
<0> the overall goal is to reduce the number of such batches
<0> as each batch eats quite a bit of CPU cycles
<0> different types of state changes also have different costs
<0> but
<0> to begin with, dont worry about that
<5> The problem I have is with meshes though. I'm trying ot setup a sort list of what I call "rendercontexts" and it contains everything I needs to render (texture ref, material, basemesh ref) etc and then just sorting it based on how similar the states are
<0> sounds good
<3> you could save the states and set them with that thingamajigger
<0> state blocks?
<3> yeah
<0> yeah that can be quite handy
<0> dunno how much of a win there is
<0> it used to be pretty bad on slightly older hw
<0> Ferazel, i saw some list of the top 5 most expensive state types... but i can't remember it
<4> does that translate into 'it is pretty bad on really old hardware'?
<0> if you don't use shaders, sort on texture primarily
<0> Slade, ;)
<0> rephrase: it used to be bad on (then) current hw
<0> Ferazel, and if you can, *merge* contexts/batches
<5> aav, Merge them?
<0> like if you have 30 trees, dont draw them as single objects, merge them into one or more meshes (pre-placed on the map)
<0> pretransformed into world space
<0> ***uming they have the same texture, material etc
<0> so they can be drawn in one call
<5> aav, Thanks I just don't think that it applies, I'm rendering a lot of meshes with frame hierarchies with multiple textures on the boat... the boats will mostly be similar
<0> ah boats
<0> could be, could be
<0> yeah moving objects are harder to merge
<0> just start by sorting, and see if you can avoid state changes between similar objects
<5> Yeah, I wish I could just show you guys the code, but it's already probably 3-4K lines of code :(
<5> Yeah I will do, I just wanted to make sure the CPU time I spend on sorting the list and rendering all the subobjects of the hierarchy is going to be worth it
<5> Do you happen to know how much performance one would save with backface culling turned on? Is it greater than 15%?
<0> in terms of fillrate, 50%-ish
<0> depends on what part of the system is the bottleneck
<0> but just leave it ON
<0> unless you need to turn it off
<5> Yeah, I have some 1 poly thick items on the mesh, so I will need to make it a render state.
<0> you can't light those accurately though
<5> Well I have to use 2 lights
<0> you're probably better off duplicating those triangles
<0> and flipping the normal on the backfacing copy
<5> I'm just afraid of z-fighting with the polys being so close
<0> there won't be any since you have backface culling on
<5> Yeah you're right, damn I wish I could just have the modeler change it on the model. Is there always problems with the ***ets makers and the ***et users in production apps?
<5> Duplicating the mesh doesn't sound so fun
<0> well you could detect and duplicate those tris yourself
<0> i dont mean the whole mesh
<0> or do it in the ***et tool
<5> Thanks for the pointers, appreciate it greatly
<0> no prob
<0> hi vrakrav
<6> evening
<6> so, whats been happening around here lately? just as much as usually?
<3> more than usual
<4> and then less son
<4> so
Return to
#directx
or
Go to some related
logs:
#beginner
#linuxhelp
#stocks
#stocks
#tcl
#mirc
Ronaldiio
#beginner
touchstone lightning bolt mickey mouse
#computers
|
|