Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 24 Mar 2006
Offline Last Active May 24 2014 08:50 AM

Posts I've Made

In Topic: Free texture image memory after binding it

01 April 2013 - 09:42 PM

Yes, glTexImage2D is copying your image data.


Probably worth mentioning GL synchronization notes:

This stuff used to be a little different, and has improved immensely:


From: http://www.opengl.org/wiki/Synchronization

Legacy Note: The only OpenGL functions that behave differently are functions that end in Pointer​. When these use client-side memory (which is no longer permitted in core OpenGL), the pointers are stored for a period of time. During that period, they must remain valid.

These are usually used for rendering calls; in which case, once the rendering call has returned, the memory to be read from client data has been read. Modifications to client memory after the rendering call will only affect future rendering calls, not those that have already passed.
This is generally why Buffer Objects are better than using client memory for rendering. A rendering call with buffers does not have to handle the possibility of the user changing the memory later, so it can simply write a few tokens into the command stream. With client memory, it must copy all of the vertices out of the client-side arrays.

In Topic: How to generate mipmap for a texture

27 March 2013 - 06:36 PM


- If he is targeting Direct3d11 with non Direct3d11 conformant hardware he will have to generate the pyramid on the cpu. Which is why I suggested looking at the nvidia texture tools library.

- If he is targeting Direct3d11 with Direct3d11 conformant hardware he can use compute shaders (and apply compression as needed):



I have not tried applying rendertarget flags to a texture that I'm uploading data to from a staging resource before (never had the need).

I would be intrigued to hear if this works. If it does, this is of course the simplest line to follow, however you thenmiss out on writing a bunch of code that will be useful to you for as long as you continue to render (as long as you don't write it using DirectCompute).

In Topic: How to generate mipmap for a texture

27 March 2013 - 09:40 AM

- If you have photoshop you can generate the mipmap chain using the nvidia dds plugin:


- For mipmap generation, you could integrate nvidia texture tools into your pipeline: http://code.google.com/p/nvidia-texture-tools/

- If you are looking for a general "howto" on generating and loading the chain, I would suggest checking out the replacement code for D3DX load texture:

  (This uses WIC (Windows Imaging Components) and I would not touch it with a 10 ft pole, however, it does show you the steps needed to load the mipmap chain etc...).


- I think MJP's framework supports this, along with hieroglyph if you feel like diving through their code:

  (I think hieroglyph integrated the texture code from the Microsoft example when d3dx was phased out).



In Topic: Pointers invalid between C++ and C#.

26 January 2013 - 01:39 PM

1.) Regarding your managed memory access, you should pin the data that you are working with before copying to the DLL.

using System.Runtime.InteropServices;

GCHandle pinnedWorldMatrix = GCHandle.Alloc(worldMatrix, GCHandleType.Pinned);
// Copy the the pinned memory to some local cache in "AddData".
_renderInterface.AddData("world", pinnedWorldMatrix.AddrOfPinnedObject());

I usually only use this interface on arrays of primitive data.

Your interface would be safer if you copied the data to a float[] locally.


float[]  floatArray = new float[16];

// I'm not sure what the XNA matrix operators look like, but
// for brevity we are just going to copy the data from your matrix to the floatArray.
for (int i = 0;i < 16; i++)
  floatArray[i] = worldMatrix[i];

GCHandle pinnedFloatArray = GCHandle.Alloc(floatArray, GCHandleType.Pinned);
// Copy the the pinned memory to some local cache in "AddData".
_renderInterface.AddData("world", pinnedFloatArray.AddrOfPinnedObject());


2.) I would seriously consider wrapping your unmanaged code up using something like SWIG or C++.NET to present a more concrete interface to your XNA layer.

     Your life will also be made easier if you use a custom allocator in your c++ dll. With the number of boundaries you are crossing, it's always a good idea to be completely clear on where allocation and deallocation are occuring. Steve Streeting had some nice notes on this:



3.) Part of this notes assumes that you would be sending the data using an intptr_t, and using swig to add type maps for IntPtr to intptr_t.


%typemap(ctype)  intptr_t "intptr_t"
%typemap(imtype) intptr_t "IntPtr"
%typemap(cstype) intptr_t "IntPtr"
%typemap(csin)   intptr_t "$csinput"
%typemap(in)     intptr_t %{ $1 = $input; %}
%typemap(out)    intptr_t %{ $result = $1; %}
%typemap(csout)  intptr_t { return $imcall; }

Bon Chance!

In Topic: D3D11_FILL_WIREFRAME order of magnitude slower with 3xx.xx drivers?

28 December 2012 - 04:45 PM

Thanks mate.

Looks like they fixed this with the 310 drivers.