• Advertisement

ori-on

Member
  • Content count

    11
  • Joined

  • Last visited

Community Reputation

113 Neutral

About ori-on

  • Rank
    Member
  1. Sharing textures (and other resources) between devices/threads works just fine as advertised, when using D3D9Ex (and not D3D9). I wish Microsofts' documentation would state that more clearly.   The reason is that only D3D9Ex utilizes the features provided through WDDM display drivers, like eg sharing resources. So D3D9Ex was specifically introduced for people like me that want to stick with D3D9, but want to use some of the features that were introduced with Vista (and later). So thanks for that to Microsoft :)   So the actual fix was to use Direct3DCreate9Ex() and CreateDeviceEx() instead of their D3D9 predecessors. Everything else remains the same.
  2. In this Microsoft article it states that sharing of resources between different d3d devices is possible on Windows Vista. The description sounds straight forward, so I gave it a try on Windows 7, but only get an D3DERR_INVALIDCALL back, when I call CreateTexture()   pSharedHandle points to a HANDLE that is 0.   D3D debug dumps the following:   Direct3D9: (ERROR) :Device is not capable of sharing resource. CreateTexture fails. Direct3D9: (ERROR) :Failure trying to create a texture   I am using an ordinary Direct3D 9 device, not Direct3D 9Ex. But according to the docs it should work with both. I am using a Radeon 57xx, and the drivers are pretty recent. According to the docs, WDDM drivers are a requirement. Since mine are a couple of months old, I believe they should be (this is the year 2013...).   Obviously one question comes to mind: is this a Vista only feature?? Maybe they kicked it out with Win7 again?   So my question is, does anyone successfully use the pSharedHandle parameter?
  3. Zoner, thanks for the detailed explanation! I am quite happy with the current speed, if I should need to squeeze some more out of it I will fire up the dissasembler - but I doubt that will be necessary any time soon. Thanks again!
  4. Awesome, this works right out of the box! This code is around 30% faster than the native c++ code. Thanks for the fast response Zoner! [quote name='Zoner' timestamp='1327960607' post='4907781'] The loop will likely need to be unrolled 2-4 more times as to pipeline better (i.e. use more registers until it starts spilling over onto the stack) If the data is aligned, the load and store can use the aligned 'non-u' versions instead. [/quote] I am using the non-u version, but it didn't make much difference. Also unrolling the loop (4 times) didn't have a significant impact, although I re-used the same variables. By "use more registers" did you mean I should introduce more variables for each unrolled loop sequence?
  5. Hello, I would like to optimize a short piece of C++ code using SIMD SSE2 or SSE3 insructions. Could someone get me up to speed, or ideally (if anyone would be so kind) provide the converted code? The function I need optimized simply reads from a graphics-frame in ARGB format to another frame that is supposed to be in aAAA format (where the actual "a" part is set to 0xff). [code]unsigned int* f = (unsigned int*)frame; unsigned int* k = (unsigned int*)alphaKey; for (unsigned i = mFrameHeight*mFrameWidth; i != 0; i--) { unsigned int a = *f++; a &= 0xff000000; unsigned int v = (a >> 8) | (a >> 16) | (a >> 24) | 0xff000000; *k++ = v; }[/code]
  6. I just quickly tested with exactly the same code that you provided, and I do get a transparent texture with only a red line in it, and that texture displays just fine. if (lock()) { Gdiplus::Bitmap bitmap(mWidth, mHeight, mLockedRect.Pitch, PixelFormat32bppARGB , (BYTE*)mLockedRect.pBits); Gdiplus::Graphics graphics( &bitmap ); graphics.Clear( Gdiplus::Color::Transparent ); Gdiplus::Pen pen( Gdiplus::Color::Red ); graphics.DrawLine(&pen, 10, 10, 120, 120); unlock(); } So that part definitely works fine. What ever else problem you have must be related to your general rendering setup. For a test I would try to load a generic image with transparency in it and see if you manage to render that properly. Alternatively you could try to save the texture right after you created it with GDI+, and see if that is alright (it should, since the code up there produces the correct result for me). Maybe your problem is also related to the fact that you are not creating a power-of-2 texture (yours is 300 x 300, I tested with 512 x 512).
  7. In the meantime I found a clean solution: float fov = Math::PI/4; float aspect = 1.0f; float nearClip = 1.0f; float farClip = 100.0f; Matrix p; p.buildProjection(fov, aspect, nearClip, farClip); // NOTE: at this point we should multiply the projection matrix with a camera look at matrix // but offsetting the projection matrix with that distance is simpler float distance = 1.0f / tan(fov*0.5f); p._43 += distance; p._44 += distance;
  8. I am using a orthogonal projection matrix to set up drawing 2d quads in screen space. Now I want these quads to "tilt" away in a 3-dimensional fashion, and I am struggling with getting a smooth and spotless transition from 2D to 3D. Initially I tried to set up a 3D projection-matrix with a suitable camera position and switch between that and the 2D orthogonal projection as soon as I want my 2D quad to "tilt away". But that is never precise, and I need to work with weird camera offset positions that I am sure only work with the current screen resolution. So there must be a better approach. I started working with transformed vertices, and doing the transformation and projection myself, but don't achieve satisfying results with that yet either. The Desktop Window Manager (starting with Vista) does that all the time: all the windows are properly displayed without any "texture blurring", and it seamlessly transitions between 2D and 3D effects (a perfect exampled is Aero Flip). How do they do that? [Edited by - ori-on on December 2, 2009 5:59:01 PM]
  9. You can do pretty much everything with GDI+, although I am not sure if it does shadowed text out of the box. Although you can do that easily yourself by drawing the text "twice". Here's how to do outlined text with GDI+: Font font(L"Arial", 26, FontstyleBold, UnitWorld); graphics.SetSmoothingMode(SmoothingModeAntiAlias); graphics.SetInterpolationMode(InterpolationModeHighQualityBicubic); graphics.SetTextRenderingHint(TextRenderingHintAntiAlias); GraphicsPath path(FillModeAlternate); FontFamily fontFamily; font.GetFamily(&fontFamily); Rect rect(40, 40, 1000, 1000); StringFormat format; path.AddString(L"Test Text", 9, &fontFamily, font.Getstyle(), font.GetSize(), rect, &format); // draw a 4 pixel wide black outline Pen pen(Color::Black, (REAL)4); pen.SetLineJoin(LineJoinRound); graphics.DrawPath(&pen, &path); SolidBrush brush(Color::White); graphics.FillPath(&brush, &path);
  10. GDI+ is definitely an OK API. It might be a little slow, and there is some minor weirdness with displaying text going on (eg odd behavior with squeezing text when using TextRenderingHintClearTypeGridFit), but overall its very powerful and you can do lots and lots of things that are not available in GDI or other D3D(X) API's. And you get results very quickly. If you only write into a texture once to actually fill it up with content, and not repeatedly every frame, then GDI+ is a very good solution. With the "trick" I explained above you can create transparent textures, and write directly into them using GDI+ transparencies and all.
  11. Hello, I must admit I did not read every single post in this thread very carefully, and what I am suggesting might be off, but I found a method how to draw into a D3D texture with an alpha channel directly, using GDI+, without any conversion required. // lock the d3d-texture D3DLOCKED_RECT lockedRect; Gdiplus::Bitmap bitmap(textureWidth, textureHeight, lockedRect.Pitch, gdiplusPixelFormat, (BYTE*)lockedRect.pBits); Gdiplus::Graphics graphics(bitmap); That way you could for instance create a D3DFMT_A8R8G8B8 texture, and draw into it using transparency coming from GDI+. You only need to use the appropriate gdiplusPixelFormat format. Here's a incomplete table how some d3d pixel formats translate into a gdi+ pixel format. D3DFMT_P8 -> PixelFormat8bppIndexed D3DFMT_X1R5G5B5 -> PixelFormat16bppRGB555 D3DFMT_R8G8B8 -> PixelFormat24bppRGB D3DFMT_X8R8G8B8, D3DFMT_A8R8G8B8 -> PixelFormat32bppARGB D3DFMT_A16B16G16R16 -> PixelFormat64bppARGB
  • Advertisement