Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 06 Jun 2010
Offline Last Active Today, 09:03 AM

Posts I've Made

In Topic: [Question]LPDIRECT3DVERTEXBUFFER9::Lock is making weird things

10 February 2016 - 12:30 PM

Your code mostly looks correct; there are the usual small issues, such as you don't actually need to specify an FVF code in your CreateVertexBuffer call unless you'e using ProcessVertices, but they're not going to cause a crash.
One of two things has happened here.
Either v_buffer is NULL; i.e your call to CreateVertexBuffer failed.  You should be checking the HRESULT from all D3D calls and responding accordingly (in this case you might display an appropriate error message and terminate the program).  Running your program under the debugger you will be able to inspect the value of v_buffer and determine if this is the case.
Or 3 * sizeof (vertex) is not actually equal to sizeof (vertices); i.e when you memcpy the vertices you overrun the buffer.  This is more likely to crash your program if you create your D3D device with D3DCREATE_SOFTWARE_VERTEXPROCESSING, but should be corrected in any case.

In Topic: IDirect3DSurface9::QueryInterface

09 February 2016 - 06:31 AM

According to Microsoft's own d3d9.h, IDirect3DSurface9 also inherits from IDirect3DResource9, so if there is something funny happening it must be happening in IDirect3DSurface9's implementation of QueryInterface.


As a general rule, in cases like this it's a fairly clear "you shouldn't be doing this" flag from Microsoft.

In Topic: Best way of finding resource leaks

07 February 2016 - 10:48 AM

It also helps to know the most likely causes of leaks: getting a surface (either from a texture or from the backbuffer) but not releasing it afterwards, or failing to call the OnLostDevice method of any D3DX objects you've created.

In Topic: Vulkan is Next-Gen OpenGL

29 January 2016 - 06:21 AM

Nobody is saying that the claim is "fuck you if you want a new API"; you seem to be doing a fairly large excluded middle here.


The claim is quite explicitly "you don't need a new API, OpenGL already has all these features for scalability and performance".  There's another AZDO presentation where this is even more explicit: https://www.khronos.org/assets/uploads/developers/library/2014-gdc/Khronos-OpenGL-Efficiency-GDC-Mar14.pdf - "Enables scalable multi-threading with no new API" couldn't be more explicit.


The problem is most definitely not that people were saying "fuck you" - nobody ever claimed that.  The problem is that the people who were saying "you don't actually need a new API" are the same people who are now saying "look at our wonderful new API".

In Topic: Vulkan is Next-Gen OpenGL

29 January 2016 - 04:07 AM

OK, firstly, there was nothing about 'one API per hardware vendor being bad' said - it was "we do not need another API. OpenGL is fine".
That is what is said.

Secondly, yes "write the code once with one API and get it to work everywhere" is a nice idea.. but it is a pipedream even today.

D3D : Does a pretty good job of ironing out the wrinkles of the hardware but even for that you end up with "work around for driver funkiness" code paths which apply per driver/GPU.
OpenGL : See above but worse with added extension funkiness.
OpenGL|ES : Android is where 'one code path' goes to die.

On top of that you have the PS4's API, the subtle differences which are the Xbox360's API, the Xbox One's API, the PS3's API, Wii/WiiU, PSP and more recently Metal.

People are, and were, already writing multiple backends to get the best from hardware so that piece of FUD was already a reality for many.
(And, frankly, I don't expect Vulkan to change that all that much either - Windows will still require per-GPU work arounds and code paths for Reasons, maybe Android will improve is Google somehow get a handle on things, but even that'll suffer the same problem.)

But, again, that wasn't the argument made.

The argument made was 'OpenGL is all you need.' and that 'another API wasn't needed'.

Which was my whole point back in the first post that touched on this and yet people seem to be having a problem understanding a simple concept?


It's all right there in the original AZDO presentation: http://www.slideshare.net/CassEveritt/approaching-zero-driver-overhead


The whole "OpenGL is good enough" thing is on slides 3, 10, 11, 12, 16 (indirectly), 42; and look at the people involved.