Welcome, Guest. Please login or register. Did you miss your activation email?

Author Topic: 2d scaling, pixel size vs. gameworld size  (Read 9357 times)

0 Members and 1 Guest are viewing this topic.

lid6j86

  • Newbie
  • *
  • Posts: 23
    • View Profile
    • Email
Re: 2d scaling, pixel size vs. gameworld size
« Reply #15 on: July 07, 2014, 04:44:24 am »
I solved the problem.... C# structs strike again.  using the non-default constructor (declaring the position and texture when making a new vertex) it showed up perfectly.

Can someone explain to me more thoroughly why this behavior occurs?  What exactly is going on here?  it seems very strange that using the default constructor ruins everything. 

Is it because you can't initialize anything internally because you can't set a default constructor?  If that's the case, would it make sense in the .net model to add an Initialize method to all structs?  It's very counter intuitive as it sits right now (not that an initialize method is necessarily crystal clear, but i think far less confusing).

Joki

  • Newbie
  • *
  • Posts: 15
    • View Profile
Re: 2d scaling, pixel size vs. gameworld size
« Reply #16 on: July 10, 2014, 12:03:04 am »
Hello lid6j86.

This behaviour is a result of a somewhat poor design choice, of not implementing all structs as immutables in the .net bindings version of SFML. You want to only allow setting field values of value types during construction, either via using a parameterized constructor, or the initialization syntax, e.g.

var vertex = new Vertex { Position = new Vector2f(50, 50) };

It was correctly done with for example the operator overloads of Vertex2f, but not its fields. As a result, people will call the implicit default constructor and forget to assign values to some of the fields.

In your example, when you created a new Vertex using the default (non explicit) constructor, the color was intialized with rgba values (0, 0, 0, 0).

vArray[0].Position = new Vector2f(0, 0);
vArray[0].TexCoords = new Vector2f(0, 0);
vArray[0].Color = new Color(255, 255, 255, 255);   //fine

If all value types would have only read only fields, you would not be able forget to set any of its fields, so it is intialized with the default value of the type of the field. (Or, if you use the initialization syntax with curly brackets, your IDE will probably display all fields and you will not forget to assign a value to the color )

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32504
    • View Profile
    • SFML's website
    • Email
Re: 2d scaling, pixel size vs. gameworld size
« Reply #17 on: July 10, 2014, 08:05:51 am »
I'm still looking for a nice way to work around this very stupid limitation of C#, so thanks for your feedback.

Making all structures immutable is an interesting idea. However it would make the developer's life harder, since it's relatively common to have to change a vertex attribute after it has been created. Same for vectors.

By the way, if anyone wants to discuss further on this subject, please open a new thread on the .Net forum.
« Last Edit: July 10, 2014, 08:14:58 am by Laurent »
Laurent Gomila - SFML developer

Joki

  • Newbie
  • *
  • Posts: 15
    • View Profile
Re: 2d scaling, pixel size vs. gameworld size
« Reply #18 on: July 10, 2014, 07:47:16 pm »
I have opened a new thread with that suggestion on the .net subforum, see here:)

Also it would not really make developers life harder, if you instead turn the fields into properties, and have the setter return a new instance of the modified struct. You might also use extension methods instead, or offer both versions to the users. :)

 

anything