SlimDX Official Launch -- Binary Builds and a Wiki!

Started by
61 comments, last by Promit 16 years, 6 months ago
First of all, I really appreciate your work. I'm currently developing a RTS game engine as a hobby. And I'm just a footstep before converting my engine to use SlimDX. So great work, thanks!

But here's my concern, which is maybe related to http://code.google.com/p/slimdx/issues/detail?id=50:

The Mesh.From****** functions are missing the overloads that return EffectInstances (which were present in MDX). There is only the option to return FF material descriptions. This is an important feature as the fixed-function pipeline is already dying. :-)
Advertisement
Ok, I patched up the Mesh issues you two mentioned, plus a whole bunch of others. Mesh should be basically good to go, sans animation. I'm beginning work on all the animation stuff, but if I'm the only one doing it, it's going to take some time.
SlimDX | Ventspace Blog | Twitter | Diverse teams make better games. I am currently hiring capable C++ engine developers in Baltimore, MD.
Quote:Original post by Promit
Ok, I patched up the Mesh issues you two mentioned, plus a whole bunch of others. Mesh should be basically good to go, sans animation. I'm beginning work on all the animation stuff, but if I'm the only one doing it, it's going to take some time.


Thanks for adding the overloads. I checked the source out and it looks ok. I like your coding style. :-)

However I must say, Mesh is still not "good to go", as long as the attribute table is missing (that means the AttributeRange type and the GetAttributeTable() method). The attribute table is important because it enables the developer to set the render state for a subset once and then render multiple instances of that subset. This avoids a big performance overhead and is especially required for instancing features. I suggest this is more important right now than animation features and probably faster to implement.

I thought of implementing this for myself but I never worked with Cplusplus/CLI before. While I can perfectly understand your code, I would most likely violate your coding style. I'm just getting started understanding the code, so it may be better you guys fixed it up. :-)
That should cover it for BaseMesh members. Mesh is in worse shape for the moment, but it should be filled out soon.
SlimDX | Ventspace Blog | Twitter | Diverse teams make better games. I am currently hiring capable C++ engine developers in Baltimore, MD.
Could you implement these constructors?

For Direct3D9.Device, Device(System::IntPtr);
For Font, Font(Device, System::Drawing::Font);

I'm develop plugins for another engine and the Device creator is the most important. Actually, I think this is important for anybody trying to get a pointer from an unmanaged app, as the Device( IDirect3DDevice9* device ) seems useless, as IDirect3DDevice9* is actually internal, so it can not be converted to.

I know it is possible because I downloaded from SVN and included the device creator (and it is working), but not the Font one. I'm not a C++ developer (exclusively C#).

Anyways, keep up the good work, SlimDX is just GREAT after MS's mistake of XNA only.

Best regards,
Thiago
Hi again,

glad to see that SlimDX is coming along! Here's what I found to be still missing with Meshes (except animation):

D3DXINTERSECTINFO
D3DXIntersect
D3DXIntersectSubset

I suggest to also add an overload for the both Intersect() that simply returns a bool without any further information - should be trivial as soon as the other stuff is working. Perhaps I will also try to add missing functions in future and give you the code. But until now, I have too less experience in C++/CLI (although I can program in C++).

Then I have a general suggestion: Don't seal classes like Font, Texture, VertexBuffer and so on, unless you have a reason to. Inheriting a class may not always seem logical to the library designer but it is a good way to add own logic. For example, one might add additional constructors and method overloads that fit in his scenario, maybe creating a VertexBuffer from a MyEngine::ModelDescription object or making a texture implement an interface to react on device loss. Unsealing a class mostly comes with no additional performance cost. See also: http://msdn2.microsoft.com/en-us/library/ms229055.aspx

And a minor thing: Perhaps you could change the order of parameters Texture.LockRectangle(int level, Rectangle rect, LockFlags flags) to Texture.LockRectangle(int level, LockFlags flags, Rectangle rect) so that it conforms to the other overload that does not take a Rectangle parameter.

Are there still you 4 developers or are there more (or less) up to now? Thanks to all of them!
I made the Mesh::SetAttributeTable() and 2 others, because I needed them quickly. You might wanna use it (or not :) ).
	void Mesh::SetAttributeTable( array<AttributeRange>^  attribTable )	{		ID3DXMesh* const mesh = static_cast<ID3DXMesh*>(m_Pointer);		pin_ptr<AttributeRange> pinnedTable = &attribTable[0];		HRESULT hr = mesh->SetAttributeTable(				reinterpret_cast<D3DXATTRIBUTERANGE*>(pinnedTable),				attribTable->Length );		GraphicsException::CheckHResult( hr );	}[...]namespace SlimDX{	bool Geometry::BoxBoundProbe( Vector3 min, Vector3 max, Vector3 rayOrigin, Vector3 rayPosition )	{		BOOL result = D3DXBoxBoundProbe(				reinterpret_cast<D3DXVECTOR3*>(&min),				reinterpret_cast<D3DXVECTOR3*>(&max),				reinterpret_cast<D3DXVECTOR3*>(&rayOrigin),				reinterpret_cast<D3DXVECTOR3*>(&rayPosition) );		return result == TRUE;	}	bool Geometry::SphereBoundProbe( Vector3 center, float radius, Vector3 rayOrigin, Vector3 rayPosition )	{		BOOL result = D3DXSphereBoundProbe(				reinterpret_cast<D3DXVECTOR3*>(&center),				radius,				reinterpret_cast<D3DXVECTOR3*>(&rayOrigin),				reinterpret_cast<D3DXVECTOR3*>(&rayPosition) );		return result == TRUE;	}}


(Geometry is a new class. The DX Doc regards them as mesh functions, however they do not have any direct relationship to mesh)

[Edited by - SecurityException on October 2, 2007 2:06:02 PM]
Can you add this static method to VertexBuffer?

generic<typename T> where T : value classVertexBuffer^ VertexBuffer::Create( Device^ device, int numberVertices,                              SlimDX::Direct3D9::Usage usage,                              VertexFormat format,                              SlimDX::Direct3D9::Pool pool )  {    return gcnew VertexBuffer( device, sizeof(T) * numberVertices,                                           usage, format, pool );  }


Such a method existed in the beta of MDX 2.0 and had a big advantage: One can change the vertex struct and the new size per vertex is automatically used. The reason why I feel this should be done in SlimDX is that it is not possible to write such a function in C#. C# will not permit the sizeof operator on a managed type, whereas C++/CLI does.

[EDIT: Fixed forum-bustin' long lines -- jpetrie]

[Edited by - jpetrie on October 2, 2007 5:33:57 PM]
Marshal.SizeOf() will allow you to do the same thing when you call the existing Create() methods.
Ok. This seems to work as well.

This topic is closed to new replies.

Advertisement