Jump to content
  • Advertisement

RenderTarget

Member
  • Content Count

    1056
  • Joined

  • Last visited

Community Reputation

398 Neutral

About RenderTarget

  • Rank
    Contributor

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. UV wrapping should be the default addressing mode. You don't have to set anything. Try it out. Like the previous post, your texture coordinates have to go <0 or >1 to be wrapped. Should just work.
  2. RenderTarget

    build error

    Make sure you're linking against d3d9.lib. That might contain the missing thing.
  3. You'll want to get the CM working eventually. It's the 'unified' way of loading things, and moreover, that and the Storage methods are the only ways to load things on the XBox.
  4. Making a M:tG database thingy, perchance? I see Fifth Dawn cards. I'd set it up like this: ... if( !xml.Read() ) throw new Exception( fileName + ": Unable to begin reading file." ); xml.Read(); // bypass 'xml' node if( !xml.IsEmptyElement ) { if( xml.Name == "cards" ) { xml.Read(); while( !xml.IsEmptyElement && xml.Name == "card" ) { xml.Read(); if( !xml.IsEmptyElement ) { switch( xml.Name ) { case "name": /* read xml.ReadElementString(); */ break; case "set": /* read xml.ReadElementString(); */ break; case "rarity": /* read xml.ReadElementString(); */ break; case "price": /* read xml.ReadElementString(); */ break; } } xml.ReadEndElement(); // close the card tag } xml.ReadEndElement(); // close the cards tag } } ... Something like that.
  5. Managed DirectX, December 2005, using .NET 1.1. I'm having strange troubles with Device.ProcessVertices(). My buffers are set up right (created SWVP, device is SWVP, dest buffer created with FVF codes and system pool), and ProcessVertices runs without error--except the data I get back is strange. The first vertex in the return buffer appears legit. Every other vertex in the buffer, however, is exactly the same as the first vertex. The vertex data is duplicated across the destination buffer. I've verified the input vertex data is coming in correctly. The input buffer is created in the managed pool, but I tried system pool as well, with the same results. Is this an MDX bug, or am I smoking the big hookah here? tempTargetVBForPV = new VertexBuffer( typeof( CustomVertex.TransformedTextured ), 4, device, Usage.SoftwareProcessing, CustomVertex.TransformedTextured.Format, Pool.SystemMemory ); float [] floats = vertexBuffer.Lock( subset.minVertexIndex * 8 * 4, typeof( float ), LockFlags.ReadOnly, 8 * 6 ) as float[]; // pos,nor/tx1 vertexBuffer.Unlock(); Debug.Write( string.Format( "Subset: {0}; subset.minVertexIndex: {1}\n", instanceSubset.subsetIndex, subset.minVertexIndex ) ); SpitOutVertexU( floats, 0 ); // this just writes float data to debugger SpitOutVertexU( floats, 1 ); SpitOutVertexU( floats, 2 ); SpitOutVertexU( floats, 3 ); device.ProcessVertices( subset.minVertexIndex, 0, 4, tempTargetVBForPV, null, true ); floats = tempTargetVBForPV.Lock( 0, typeof( float ), LockFlags.ReadOnly, CustomVertex.TransformedTextured.StrideSize * 4 ) as float[]; tempTargetVBForPV.Unlock(); Debug.Write( "Processed:\n" ); SpitOutVertexP( floats, 0 ); SpitOutVertexP( floats, 1 ); SpitOutVertexP( floats, 2 ); SpitOutVertexP( floats, 3 ); Subset: 0; subset.minVertexIndex: 0 Vx: Position: -1, 1, 1; Normal: -1, 0, 0; Texture0: 0, 0 Vx: Position: -1, 1, -1; Normal: -1, 0, 0; Texture0: 0, 1 Vx: Position: -1, -1, 1; Normal: -1, 0, 0; Texture0: 1, 0 Vx: Position: -1, -1, -1; Normal: -1, 0, 0; Texture0: 1, 1 Processed: Vx: Position: 78.34937, 53.34937, 0.243994; RHW: 0.25; Texture0: 0, 0 Vx: Position: 78.34937, 53.34937, 0.243994; RHW: 0.25; Texture0: 0, 0 Vx: Position: 78.34937, 53.34937, 0.243994; RHW: 0.25; Texture0: 0, 0 Vx: Position: 78.34937, 53.34937, 0.243994; RHW: 0.25; Texture0: 0, 0 [Edited by - RenderTarget on October 25, 2006 9:56:00 PM]
  6. Quote:Original post by Machaira I have to disagree partly with RenderTarget. You don't need to call CreateGraphics every time you draw. The graphics object is valid the way you have it. If it were me, though, I'd probably pass a reference to the graphics object to the bullet when you draw it instead of keeping a reference in the class or get the data from the bullet and do the drawing in the form. From MSDN, under Control.CreateGraphics: Quote:The returned Graphics must be disposed through a call to its Dispose method when it is no longer needed. The Graphics is only valid for the duration of the current window's message. Theoretically it may be okay, but who knows what state it's relying on, or will in the future.
  7. You appear to be caching the Graphics object in Bullet. This is no good; the created Graphics object is only valid for a very short while (the current window message, in fact). What you need to do is handle the main form's OnPaint event, and pass the Graphics object you get there to the Bullet class when it's time to draw it. Then that Graphics object will always be good. Or, to get it working more simply, cache the main form reference in Bullet, and call CreateGraphics() during Draw() and ClearOld() (though I'd probably combine the two, or have the main window clear itself instead of Bullet doing it). But that's quick and dirty, and you should really draw in response to OnPaint.
  8. RenderTarget

    Rendering textures

    (And for those that care, ID3DXSprite does do the right thing in regards to using the managed memory pool with NOOVERWRITE and such.)
  9. RenderTarget

    std::vector Not Releasing ID3DXMesh*

    I suspect that somewhere else where you're using the meshes isn't cleaning up right. Breakpoint the destructor, and examine the value returned by the Release() call. If something else has increased the refcount, and assuming D3DX does the right thing, it'll return > 0. If it returns 0, then it should be cleaned up.
  10. You can share the mesh among animation instances, and have an animation controller (and probably frame hierarchy) for each instance. If done correctly, the mesh is never updated; in fact, for hardware skinning it can be a static mesh living in VRAM. AdvanceTime updates the frame hierarchy, not the mesh. The frame hierarchy, which is essentially a tree of matrices, then gets flattened into an array and pushed to the geometry pipeline as transform matrices. The issue of sharing frame hierarchies is one of operation order. If you want to animate all the meshes in one step, and then render them all in another, then each instance needs to maintain its own frame hierarchy so they don't clobber each other. This kind of timing is more common, so you can throttle the animation updates independently of overall rendering framerate. However, if you don't care about that, you can animate and render one instance, animate and render the next, etc. using the same frame hierarchy.
  11. RenderTarget

    Safe To Use D3DX?

    If all else fails, you can put d3dx9.dll in your game's installed directory and it'll work just fine. (And it's legal.)
  12. RenderTarget

    C# Question

    Microsoft certainly doesn't own our C# code, if that's what you mean. But C# compiles to IL, which require the .NET framework to run. Of course there's Mono and others, and the CLI standards are published and open, so you could theoretically write a C# app without requiring the .NET framework (though you'd require another version of the same thing). I'm honestly not sure whether the FCL has been fully ported to Mono, and whether that technically includes System.Windows.Forms or not.
  13. RenderTarget

    Google Video Finds v3.0

    Quote:Original post by MindWipe Gaki no tsukai (Really worth watching! Atleast after a couple of beer) /MindWipe That was funny as hell. :D
  14. RenderTarget

    LETS CHAT IN ANOTHER DEMENSION soon.........

    Quote:Original post by Salsa Dan Quayle lives in my attic. You better let him out. He's starting to turn.
  15. RenderTarget

    [Solved] Matrix Translation Problem

    Huh. Double-check t_x, t_y, t_z? Debug to the SetTransform() call and ensure the matrix looks like identity in memory? All your D3D calls are in the same thread?
  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!