Nik02

The function updates the input mesh's vertex buffer with the new data. You need to have the tangent, normal and bitangent allocated in the mesh data in advance, even though they would initially be garbage.

 

To re-allocate a mesh with vertex elements of your choice, you can use ID3DXBaseMesh::CloneMesh .

You have several options:

 

• Install the old SDK to a virtual machine, and build on it.
• Install the old SDK to a virtual machine, and copy the extracted files from there.
• Use WinZip or similar to extract the files from the .exe; I believe the format is self-extracting zip or msi, even though the extractor wouldn't offer to do just the extraction.

 

The easiest way would be the third option.

 

By the way, do you develop using the August 08 SDK? You should have the release libraries already on your machine, unless you have messed up the installation.

Well, conceptually you draw the same way - you set the resources for drawing (buffers, textures) and the input layout (vertex format), and then you draw the geometry.

 

D3D11 does not have fixed function pipeline anymore, so you have to use shaders for vertex and pixel processing.

 

The shader constant registers are replaced by constant buffers, which allow for very flexible memory reads in your shaders. If you have D3D11-class hardware, you can also use read/write buffers for communicating with other shader instances and/or readback data written by the pixel shader or the compute shader.

 

You can still use D3D11 if you don't have the newest hardware, but the advanced features introduced by D3D11 (tessellation, rw buffers, compute shader) will simply be unavailable with older hardware.

 

The device has been separated into a resource factory (for "create*") and a drawing context (for "set*" and "draw*" etc.). In addition, video memory management and windowing system interoperation is provided by a separate (but tightly integrated) component called DXGI.

 

You can create several "deferred" drawing contexts for several threads, and then join them at the main thread when you want to submit them to the device.

 

These are just the tip of the iceberg, but contain the most important changes in my opinion. If you know your way well with D3D9, a little practice will surely get you going with D3D11 as well - even though the API has been overhauled completely.

If the geometry is extremely massive (as you say), you may hit the boundary of how many primitives you can draw in one call.

 

By "later versions" I mean D3D10 and later; in contrast to D3D9, the newer APIs aim to unify the feature set across same-era hardware, while the performance is the biggest varying factor between low and high end.

Also, if you haven't already, update the Intel graphics driver

 

The ones that are commonly pre-installed are usually very poor in terms of features, even though they would be stable otherwise.

 

It is also worth noting that Intel integrated graphics have never been - nor likely will be - as feature-rich as discrete GPUs from NVidia or AMD, even though later versions of D3D do try to fix the feature parity issue.

That's a very reasonable size for a commercial, locally-installable game. Most recent games on the market are way larger due to content size. Of course, for web-based gaming and/or distribution, smaller is usually better.

Windows file cursors are internally 64-bit, so it is easy to access more than 1 gb. On 32-bit systems, you cannot directly map more than 4gb into your process address space - of course - because the pointers are 32-bit. You can still seek, read and write normally, though. It is also possible to map different regions of the file, if it is larger than the available address space.

Just use IDirect3DDevice9::DrawPrimitive instead of DrawIndexedPrimitive (on D3D9 and earlier) and ID3D11DeviceContext::Draw instead of DrawIndexed (on D3D11).

 

You'll waste some bandwidth and GPU processing power if you duplicate your vertices, but if your index calculation is complex for some reason (dynamic geometry, for example), you may actually save time on non-indexed drawing.

Do you mean something like this?

 

It is somewhat more expensive than ordinary texture sampling, and you need some pre-processing to simplify the geometry to pieces that the hardware can easily handle.

 

In practice, the actual rendering is very fast on modern hardware.

Also, if you need many pixels, it is very much faster to copy them by scanline instead of one by one. In case you do scanline copies, your destination would be an array of the pixel structures and the correct first parameter (destination pointer) of the CopyMemory would be the first element of said array.

 

Note that CopyMemory has a nasty habit of crashing your VB6 app if the last parameter (number of bytes) is zero; be sure to safeguard your logic against that

This is difficult in VB6 (and VB in general) because the language doesn't have pointer dereferencing.

 

As a workaround, you can import the CopyMemory function from kernel32, and copy the data from the locked_rect to your own array of pixels.

 

The pBits field of the locked_rect structure represents the pointer (or local memory address) of the first pixel of the first scanline of the area you locked. The scanlines of the locked area are guaranteed to be adjacent in memory, but they may have padding in addition to the actual pixel data; this is why you have to consider the "pitch" to navigate between scanlines, not just width * numbytesperpixel.

 

The address of a given pixel on the locked area is given by the following formula:

 

address(x, y) = pBits + y * pitch + x * bytesPerPixel

 

The bytesPerPixel varies with the texture format, of course.

 

If you know that your pixels are 32-bit (byte per channel rgba), you can use CopyMemory once you have the address on the locked rectangle:

 

type rgbapixel

r as byte

g as byte

b as byte

a as byte

end type

 

dim destination as rgbapixel

CopyMemory(byval varptr(destination), byval address, 4) ' where 4 is the number of bytes to copy, and "address" is the address of the source pixel as described above

Just before you draw your objects (at each frame), set all the states that affect the rendering of said objects. These include input assembler settings, rasterizer state, blend state, output merger state, shaders, views, textures, samplers, buffers, input layout (and some others). Rendering text usually sets some of these states, and in your case the font object isn't apparently resetting some of the states after drawing; this is why you need to do it.

For a small list of objects this may seem like overkill, but if you have many similar objects you can sort their rendering by the states they use (commonly known as "batching"). This potentially saves a lot of user->kernel transitions (driver calls) - those can eat your cpu cycles fast.

---

Note that if you use ID3DX10Font (this is not apparent in your code), you can use a sprite object that you previously allocated in order to store the font's render states. The sprite object uses a Begin/End pair; the Begin method lets you specify that upon calling End the device state is restored to pre-Begin state. So if you surround the font drawing with the Begin/End of its sprite, you can control whether or not it resets the state for you.

All that said, you can potentially save performance if you still do the state sets manually only when you actually do need to set them. You see, resetting takes the same time or more as setting.

Regardless of the API you end up using, my advice is still valid.

DrawText sets some device state in order to do its job, and it's not resetting the state for you. You should explicitly set all the states upon drawing your objects.

Here is an interesting discussion about manager classes.

 

Personally, my preference is that the objects to be managed contain enough functionality to not require a separate manager.