Is there a way to convert the name of a texture2D to a string?

Let’s say I declare a Texture like so.
Texture2D ball; ball = Content.Load<Texture2D>(@"roundobj");
Now I want use the name of the texture2D, which is ‘ball’ as a string.
How do you do that?

Isn’t there a name property on ball?

1 Like

Starting with C# 6, there’s a nameof expression that you can use. In this case, nameof(ball) would return “ball” as a string. The Texture itself doesn’t have a name associated with it; that’s the just the identifier of the texture.

1 Like

You could make a sprite class with properties like: Name, Texture, Position, Rotation and ofcourse functions like draw & update
It’s not what you asked, but an easy to use work-around that can come in handy later

1 Like

@Alkher is right, Texture2D is a GraphicsResource, which has a Name property. It also has a Tag property (member of type object, unused by MonoGame) in case you want to attach any other data.

actually the Name property returns the name of the texture image without the extension. That’s what I am using now.

There is. It returns the name of the texture. I am using that now.

This is good when you need to give objects your own name! (egoistically… :-D) Using the built in Name saves on time and code.

Hi! Can you elaborate on this one please…
WHat does the Tag do?

It doesn’t do anything. It’s just an object property that you can use to attach any data. MonoGame doesn’t touch it and it will default to null.

So what’s the point in it being there? :smiley: decoration? Someone forgot to remove it? :smiley:
What do you mean by saying " It’s just an object property that you can use to attach any data."? what data?? I tried attaching a color data list but couldn’t.

You can attach any data you want to the Tag (that’s why it defaults to null), then use it when needed.
Maybe this will make it clear:

So in other words let’s say I have some sprites. I can the color data into a list and then attach this to the tag of each sprite and then use it when i need to do the transforms and pixelCollision Dtection etc.?

Yep, that’s pretty much it.

I wouldn’t say Tag properties are used a lot in C# code but they do come in handy sometimes. You’ll often see this pattern in GUI frameworks like WPF and WinForms on controls. Essentially it works like this:

First you load your texture or whatever then you can attach anything you like to the Tag property. I’ve listed a few different examples here to demonstrate the point (obviously you’d only assign the Tag once in real code).

Texture2D ball = Content.Load<Texture2D>(@"roundobj");
ball.Tag = "my-special-data";
ball.Tag = 42;
ball.Tag = new MySpecialObject { Name = "whatever", Age = 42 };

Then later on in your code, typically in a situation when you have access to the Texture2D but you don’t have anything else you can pull the data off the Tag and do what you like with it.

For example:

string data = ball.Tag as string;
int data = ball.Tag as int;
MySpecialObject data = ball.Tag as MySpecialObject;

At this point, if you’ve done it right the data variable will contain the original data you assigned to the Tag. Then you can do with it as you please.

Some things to note about this though.

  • You need to know what type of data is in the Tag (there’s no type safety here).
  • If the Tag isn’t what you think it is it will return null or throw an exception (depending on how you cast it).
  • If you later change the type you’ll need to go hunting around your code to fix all the usages of it (this is a code smell)

So yeah, it can be useful but my advice is to use it sparingly. There’s often better ways to design your code that makes it more robust and more readable.


Thanks very much. That cleared the mist. :slight_smile:

Just a bit of a word of warning about Tag… since it’s untyped and contains no description of the kind of data that you’re using, it can be easy to lose track of what you store there. It can also be easy to fall into the trap of storing different types at different types, which can be a bit of a pain to retrieve if you’re not always aware of that.

It might be better practice to, as suggested above, make your own object type that wraps Texture2D, then you can define the additional data that you need directly. It comes typed and described with a property name, which will help you keep things straight in the future.

Just something that might save you some headache in the future… you know, when you find yourself saying, “Wait, what type did I store in there again!?”