Jump to content
  • Advertisement

Archived

This topic is now archived and is closed to further replies.

d000hg

Surely this is possible...?

This topic is 5956 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I want multiple monitor support in my game, 1st a quick q: 1)Does a dual-head 3d card get reported as two separate devices when enumerating graphics devices as if you had two separate cards? 2)A user with 2 monitors is likely to have a good card and an old one, maybe used for debuging or just with their previous graphics card. I don''t want the graphics to be different on different monitors (except resolution and user choices) and since a gf3 can render 8000fps for my simple game probably, when a user has one good card and one crappy one I want to do this: Use the good card to render the scene for both monitors. The copy for itself is easy to arrange - just work as normal. For the second monitor ideally you''d just render to a texture then simply use that on the rubbish 3d card to present the scene. However d3d inherently stops this: textures are only valid on the device which created them. So how can I get around this? Can I manually read texture data across from the texture on one device to a texture with identical properties on the second device? Or have the second device using ddraw (now any old card is supported) and somehow grab the data and use blit() to display it? There must be a way to do this?

Share this post


Link to post
Share on other sites
Advertisement
Do a search, this was discussed before. On that subject my answer was that somewhere in that process (with the possible exception of duel head or duel AGP cards, but even that is sketchy) you''re going to have to copy that screen sized texture into system memory from one card, and into video memory on the other, and that would be very slow.

Share this post


Link to post
Share on other sites
slow is seconds per frame instead of frames per second (even with dual geforce4 running on 2ghz pcs with 1gig of ram).

Share this post


Link to post
Share on other sites
quote:
Original post by a person
slow is seconds per frame instead of frames per second (even with dual geforce4 running on 2ghz pcs with 1gig of ram).


Is that a general statement? I think so

Anyway I''ve been thinking about this:
A COM interface is just a c struct with pointers to functions in it, right?
This means that it can''t have private members so you can access any parts of it you wish. Now when you create a texture interface somewhere inside must be a pointer to the actual data in the format described by the texture format.

So If I create texture1 from device1 and texture2 from device2 then surely I can set texture2''s image pointer to point to texture1''s image data? Or something in that vein anyway!

Does anyone there have the knowledge required to know if this feasible - if it works it would eliminate the need for copying data across.

BTW, if you have two textures in system memory is it still going to be slow copying across?

Oh and
quote:

1)Does a dual-head 3d card get reported as two separate devices when enumerating graphics devices as if you had two separate cards?



Anyone know about this?

Share this post


Link to post
Share on other sites
quote:
Original post by d000hg
Anyway I''ve been thinking about this:
A COM interface is just a c struct with pointers to functions in it, right?
This means that it can''t have private members so you can access any parts of it you wish. Now when you create a texture interface somewhere inside must be a pointer to the actual data in the format described by the texture format.

So If I create texture1 from device1 and texture2 from device2 then surely I can set texture2''s image pointer to point to texture1''s image data? Or something in that vein anyway!

Does anyone there have the knowledge required to know if this feasible - if it works it would eliminate the need for copying data across.


No its not, for two reasons. 1) Your pointer does not point to physical memory on the graphics card, its virtual. 2) Even if it had the pointer one graphics card cannot access and read from another one, it can''t even tell the other one exists.

quote:
Original post by d000hg
BTW, if you have two textures in system memory is it still going to be slow copying across?



On a PCI graphics card yes, you''re looking at a maximum of 10fps running at even the lowest resolution with no drawing at all (just a flip). With an AGP card this may be somewhat different (however I have yet to see a home system with 2 AGP slots, so duel head AGP is the only possibility).

You also have to take into consideration that reading from the video card is far, far slower than writing to it. So if the more powerful card renders the scene it will take a lot of time to copy the data off the card, regardless of how fast it can be moved onto the second card (and like I said, you likely can''t go directly from one to the other, you''ll have to copy to system memory).

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
Tell it to put all the stuff in system mem, that will save time accessing vid mem which is ultra slow (AND SO WE BLOW THE SEC PER FRAME THEORY)

Share this post


Link to post
Share on other sites

I have a question about this "stereoscopic display" thing
in general.

I''ve never tried such thing with 2 displays,
but, does this really look so realistic?
You can''t focus something with your eyes, for, the
two "cameras" don''t change their parallaxe when you''re
moving your eyes. And you won''t eben move your eyes,
because the displays remain at a constant distance to your
eyes. So there''s no way to "naturally" focus something
in a scene, I suppose your eyes ache after some time...

Right?

Share this post


Link to post
Share on other sites
I get the point that video memory is slow to read from, but surely not that slow? I''ve written stuff in 32bit dos mode where you have two backbufers in video memory and switch between them.

A 1024x768 buffer is ~1Mpixels, in 32bit colour thats approx 4Mb. My pentium classic would copy memory at ~400Mb/s and while that was system memory it was only like 66Mhz SDRAM - can''t be faster than the special DDR memory in modern cards?

Or am I mising the point and it''s locking the memory that''s so slow. If that''s the case, why is it so slow?

Share this post


Link to post
Share on other sites

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!