13 replies to this topic

[Miguel De La Cruz]

I'm having a problem where I must typecast an array of a certain class to an array of structs. So: Class ClassName { }; void draw() { ClassName Uh; vertexbuffer.setdata((struct)Uh);//here its wrong } How would I turn Uh into a struct? Any help here would be greatly appreciated.

[Washu]

You don't. Classes and structures are different concepts in C#.

[Miguel De La Cruz]

Dang. Heh, first week of learning C#. so how would I derive something that is put into the setdata() function?

[Alpha_ProgDes]

My question is why? Second question are you sure that you have convert these classes to struct? Third question what is compelling you to do so?

[Miguel De La Cruz]

1) setdata only takes in a struct, it is used for vertices. I must have a class of it so I can derive from it.
2) yea, me sure. structs can't be derived in C#.
3) I must derive so I can control the vertices in different ways using a virtual update.

[Telastyn]

You don't. You make Uh contain an array of structs and then call

vertexbuffer.setdata(Uh.VertexData);

or something similar.

[blackbird04217]

He is trying to use a vertex buffer... I know this because I am sitting next to him. He isn't listening to my advice and should be creating a different type then what he has... (He has a ParticleVertex which holds TONS of data including velocities...) And thats unneeded, so he needs to make a different vertex deffinition to use in the vertex buffer

[Miguel De La Cruz]

I need that vertex buffer information, it is for the vertex shader moving the point sprites.

[Miguel De La Cruz]

Telastyn, great idea! Why didn't I think of that? I blame this food to my left here. But thanks, I will try that. Eh nope, won't work... I must have the array of structs be derivable. You see the structs are verts like this:

struct array of
100 lava verts
200 exploding verts
100 smoke verts


and I must control the lava verts to flow downwards, but the rest to do their own thing. So basicly, they would all have an empty update except lava verts(derived) which would have a virtual update.

[Telastyn]

vertices are vertices. Their behavior might be controlled by something else, but they don't change type. And this might be better served in the .NET or other forums.

[Miguel De La Cruz]

(scratches head)

[SamLowry]

Quote:

Original post by Miguel De La Cruz (scratches head)

Compare it to numbers. A number is a number, nothing more. You can use a number to indicate a player's health, and when it reaches to 0 the player dies, but you aren't going to put that logic in number, but in player.

Keep the simple concepts simple. If you need to add logic to them, building a new concept (a new class) around it might be a better solution.

[Miguel De La Cruz]

Nice Explanation Sam, however, how would I create an array of them?
I must have an array of structs and pass in the entire array, not one by one.

[Josh Petrie]

Stop thinking so low level. Vertices are vertices, they are "dumb" structures that just hold data and have no logic. The logic is in a higher-level object that holds some vertex data -- that object can be derived from, have behavior overridden via dynamic dispatch, et cetera. So you might have a

class BasicRenderObject
{
  private Vertex[] verts;

  public Vertex[] Vertices
  {
    get
    {
      return verts;
    }
  }

  public BasicRenderObject(int vertexCount)
  {
    verts = new Vertex[vertexCount];
  }

  public virtual void Update()
  {
    // No-op in base class.
  }
}

then you might have TerrainRenderObject and SuperRobotRenderObject and LavaMonsterRenderObject -- whatever. Update the vertices as you need to in the overridden Update() method, and use the Vertices property to access the raw verts for SetData() et al.

(I feel compelled to point out that I do not not like this design, but it addresses your issue.)