How would I get pointer to memory of main screen, assuming all was started with Direct3DCreate8? I would like to be able to directly work with video memory, but I see there is no more DirectDraw in directx 8.
Posted on 2003-10-19 20:28:34 by comrade
GetRenderTarget? Do I have to still call BeginScene/EndScene?
Posted on 2003-10-19 20:36:18 by comrade
Hi

AFAIK from DX 8 upwards you cannot acces the video memory directly (MS decided you are too stupid to do that :) ). On DX7 and below you can Lock any DirectDraw surface you want and you get a pointer to it, but not anymore...

"GetRenderTarget" function as i see in SDK gives a pointer to a surface interface , not to the surface's memory buffer

Still i am not 100% sure you can not get the pointer, maybe i dont know all methods...

Eugen
Posted on 2003-10-19 23:27:01 by Eugen
I tried:


    [*]BeginScene
    [*]surface = GetFrontBuffer/GetRenderTarget/GetBackBuffer
    [*]surface.LockRect
    [*]EndScene


    Yet in all cases, LockRect fails. I have tried it without BeginScene/EndScene too, but again it still fails. Why?
Posted on 2003-10-19 23:42:13 by comrade
You can certainly.
It's not something I've bothered with, but when u make a "real" d3d app, you are meant to create a 2d surface for clipping purposes, and attach it to the render window. You own that surface, and can do what you like with it.
I'll see if I can dig up an example source, but in the meantime, you may wish to look at the DirectWrap dx wrapper code posted by HitchHiker (look for the thread in this forum)
Posted on 2003-10-19 23:44:44 by Homer
Please do, EvilHomer.

hitchhiker's source is not for DX8/9, it uses obsolete DirectDrawCreate. I need specifically for DX8/9, which have removed ddraw. :(
Posted on 2003-10-19 23:52:02 by comrade
A direct3d texture is simply a directdraw surface with a couple different properties in it?s surfacedesc ... (see note below)

ok now, bearing this in mind, please refer to IDirect3DDevice8_GetBackBuffer which returns a (pointer to a) Direct3DSurface8 object representing a backbuffer numbered 0 thru #backbuffers.

Then check out IDirect3DSurface8_GetDesc (if you don't know what the surface attributes were when it was created) and more importantly for you, IDirect3DSurface8_LockRect which will lock a subrectangle of the Surface and return a pointer to the raw binary data there.


* Note * SurfaceDesc.dwFlags = DDSD_CAPS or DDSD_HEIGHT or DDSD_WIDTH or DDSD_TEXTURESTAGE or DDSD_CKSRCBLT
SurfaceDesc.ddsCaps.dwCaps = DDSCAPS_TEXTURE
SurfaceDesc.ddsCaps.dwCaps2 = DDSCAPS2_TEXTUREMANAGE

* Note * that some video cards don?t support these options.. We should really be querying the "caps" (capabilities) of the hardware...

Have a nice day :)
Posted on 2003-10-20 01:25:15 by Homer
You have to set the backbuffer surface to be lockable in order to directly alter it. To do this, in the D3DPRESENT_PARAMETERS structure you use to create the device, set the value for Flags (the twelfth element of the structure) to D3DPRESENTFLAG_LOCKABLE_BACKBUFFER ( = 01h). Or OR it with the value already there.

When you do this, you can lock the IDirect3DSurface that you get from IDirect3DDevice8::GetBackBuffer method, and play with the bits there to your heart's content. Keep in mind, though, that having a lockable backbuffer results in some serious slowdown when rendering. Locking and unlocking the backbuffer also has a massive time loss attached on most video cards, as the backbuffers are usually kept in video memory, and when D3D locks it, the video memory is copied into system memory (and copied back when the buffer is unlocked). You can speed it up a bit by locking the backbuffer with the D3DLOCK_NOSYSLOCK flag, which will let you lock the video memory directly, rather than using a copy of it. However, Windows will be unresponsive while the backbuffer is locked, which can cause some strange problems.

Also, if you use multisapled full-scene rendering, none of the screen resources can be locked.
Posted on 2003-10-20 11:56:34 by Tatterdemalian
I haven't played with it, and that's news to me :)
I'm just an old bugger trying to keep up with the kids !!
As soon as I'm able, I'll implement some code to mess with this stuff, but I'm really too busy trying to get my SkinMesh variant working properly (it's been designed to support subdivided skinmeshes as I described in another thread - search if ur interested, it has some nice pics of my work in the field...)

I've been playing with backbuffers since before the term was coined, and I absolutely despise the lack of clear hardcore documentation in regards to accessing (directly or indirectly) device ram etc.

Information wants to be free :alright:
Posted on 2003-10-20 12:25:50 by Homer
Eh... as things progress, we need to learn to accept limits on what we do, and work within them. It's the same for coding as it is for society; in order to make progress, you have to learn to play nice with those around you. You can't just beat the crap out of anyone "just because" unless you want all the conveniences you enjoy (and most of the ones you can't live without any more) to be destroyed by anarchy, and you can't just lock video memory and suspend the OS just because you want to play with the hardware yourself unless you want all the other kernel and input/output functions to stop working (and in most cases, never start working again).

Civilization comes at a price, and so do convenient API functions and standardized hardware interfaces.
Posted on 2003-10-22 10:57:44 by Tatterdemalian
What ever happened to dma ?
Explain why hardware can't be designed for asynchronous access anymore, and I'll happily lay down and die too.
Should we accept what we are handed by society today?
Should we not make demands apon the purveyors of the technology that we use? Are we not the market? What happened to supply and demand?
What happened to my world? :(
Posted on 2003-10-23 01:59:06 by Homer
What does DMA have to do with this? ;)

3D Rendering is done on the graphics card, which is usually AGP these days.
Now ask yourself - is AGP memory directly addressable from the x86 bus?
Posted on 2003-10-23 04:42:32 by f0dder
I have been led to believe that AGP data transfers are clocked synchronously with the cpu - is this not the case? And seeing as AGP is more or less a dedicated bus for shovelling graphic data (much the same as a scsi device), and can access system memory freely, why then should we not have access from the cpu to video memory indirectly - or at least be able to blit (block image transfer) in hardware via the graphic controller? (remembers this was possible under coprocessors on other platforms in years gone by)
Also, should one be prepared to drop to ring zero and instal an NMI which monitors the Aperture page in system memory, should it not be possible to insert commands sent via GART to the 4kb page(s) of AGP-devoted system memory allocated by the OS? Could this be a way to insert commands sent to the graphic controller, since as I understand it, AGP data accesses are piped inbetween execution of cpu opcodes (in fact, during the opcode Read cycle)...
Am I crazy to want to control my own hardware?
Should I buy a tcpa-equipped box and forget my past?
Still think this has little to do with dma?
Seems to me this is really not a hardware issue at all, rather a software one in terms of the Windows OS is hobbling us because it won't allow us to mess with the video ram without Locking it first, which is a virtual concept !!

Posted on 2003-10-23 06:24:24 by Homer
Oh btw man - YES - AGP memory *IS* accessible from the x86 bus, since it resides in System Memory.. you probably meant Video Ram of course.
Posted on 2003-10-23 06:57:47 by Homer
Should we not make demands apon the purveyors of the technology that we use? Are we not the market? What happened to supply and demand?
What happened to my world?


To be quite frank... no, we are not the market. In the real world, it's majority rule that matters, and people that code their own hardware drivers are a very, very small minority. Pure speed is not a top priority to most of the market. One of the priorities, yes, but there are higher priorities, like "can this software be run without crashing my computer?" and "will this software run along with all the other software I use, without causing a resource conflict or crashing my computer?" Speed doesn't matter if it just slams you into the wall that much faster.

Windows is a great innovation, in that it allows people to operate at so many different levels, and nearly everyone can find a level that is comfortable to them, as long as their demands are not self-contradictory. Casual computer users can easily install software, or even plug in new hardware, and the software will handle all the grim and gritty work of juggling IRQs and DMA channels for them; casual programmers can whip up GDI utilities or DirectX multimedia extravaganzas with little effort and a light learning curve; and serious hackers like us can suspend the normal OS operations and work our magic however we like, though reinventing the wheel is a lot harder a task than you think. (It took hundreds of the most brilliant pro coders in the world, all working together, to write Windows; I don't think any of us, working alone or in small groups, will write a more adaptable OS in a single lifetime.)

There's always Linux, if you have a problem with the way Windows does things. Nobody's managed to make a Linux implementation that has been able to appeal to anyone outside of fellow hackers yet, and it sure isn't for lack of trying. But if you want direct hardware access (as much as the hardware is willing to give you), it's the way to go, and nobody's tying you to Windows.
Posted on 2003-10-24 18:29:50 by Tatterdemalian
I don't really care if its really video memory or not. Just let me write directly to front buffer, be it virtual or not.
Posted on 2003-10-24 21:49:10 by comrade
You can't do that. You can get a copy of the front buffer, but it can't be put back into the front buffer.

What you can do, though, is modify the first back buffer, and then use IDirect3DDevice::Present to post the first back buffer to the front buffer. If you need to use the contents of the front buffer, create the IDirect3DDevice with the SwapEffect member of the D3DPRESENT_PARAMETERS structure set to D3DSWAPEFFECT_COPY ( = 3 ). This guarantees that the contents of the backbuffer (you can have only one when using D3DSWAPEFFECT_COPY) will be preserved by the Present method, so the contents of the backbuffer after the Present are identical to those of the front buffer... so the backbuffer can be treated as a virtual front buffer.

(Remember to also set the D3DPRESENT_PARAMETERS structure to allow lockable backbuffers, too.)
Posted on 2003-10-24 22:04:08 by Tatterdemalian
As far as I am concerned, hardware is not developed with the end-user in mind, it is developed for us - the software development community.
If we want certain functionality in hardware, we develop it in software, then the hardware manufacturers jump on the bandwagon later in the piece. This has historically been the case. It is us, the software developers, who pander to the whims of the mass market, and not the hardware developers, who are only interested in meeting OUR demands... yes, it is a consumer oriented world we live in, I can accept that, but I cannot accept that 2000+ coders at m$ have forgotten us. As OS developers they have a twofold responsibility, to meet the whimsical demands of the mass market of end-users, while catering to the demands of the software development community. Should they fail in the latter, the former are the ones who ultimately lose out. That being said, I'll quit my griping now since this really is not the appropriate thread.
Posted on 2003-10-25 00:24:07 by Homer
It may have been the case historically, but correlation doesn't imply causation all by itself.

Just because hardware manufacturers have followed software innovations (in the case of graphics cards), doesn't mean they are restricted to doing so. They are only obligated to provide hardware the majority of consumers want, and as I've pointed out, the majority of consumers are not software engineers. They are not obligated to ensure their hardware is accessible, only to ensure that it will work with most of the software run by most of the consumers, and do so better than any of the competition's. The rise of Doom and Quake showed that there is both a market for 3-d multimedia, and technology that could cater to that market. Both the hardware and software engineers rushed to fill that niche, the former producing 3-d accelerator cards and the latter producing software drivers and DirectX. They worked together to make money, not out of any sense of obligation to one another.

The unfortunate fact is that there is every reason for the hardware manufacturers to make their hardware as incompatible as possible with that of other vendors, and very few reasons (and no particularly convincing ones, from a marketing standpoint) to allow any more compatibility than is absolutely necessary for the thing to work as advertised. Patent issues, accusations of reverse engineering, corporate espionage... the more information about the inner workings of their hardware the manufacturers can conceal from the public, the less chance that something terrible will happen and the company will start hemmoraging money. (3dfx's head is still hanging on a pike outside nVidia's corporate headquarters, as a warning to anyone who makes the mistake of releasing too much tech information.) So, they retain a small and heavily non-disclosure-contracted team of software engineers to write the drivers that let their proprietary hardware function nicely under Windows, and every other coder in the world can either use those drivers, or go hang. Sure, without software their products would be nothing but very expensive doorstops, but the probability of a significant number of software coders boycotting their product for not letting them bit-twiddle is far less than the probability of some other hardware manufacturer using their product specs to drive their company into the ground.

As for the coders at m$, they haven't forgotten us. Windows is one of the most heavily documented OSes ever, and all the information you need to program it, rewrite it, or even suspend it and fiddle with the hardware directly, is posted somewhere on the MSDN. Just don't expect the hardware to like your fiddling, unless you REALLY know what you're doing. Linux users will be happy to provide you with plenty of hardware horror stories (as long as you don't let them know you're a Windows user, then the demagoguery starts and Linux Can Do No Wrong). It's a valuable insight into what the world was like before DOS.
Posted on 2003-10-25 03:16:02 by Tatterdemalian