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

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Topics - Joki

Pages: [1]
1
DotNet / A few small suggestions
« on: July 10, 2014, 08:28:46 pm »
A few small things that i would like to suggest are:

1.
Instead of having the users override Destroy() of ObjectBase to handle finalizing, let users implement the IDisposable interface and use the standard suggested finalizer.

This used to crash at a decent chance, when i just assigning a new AnimatedSprite to the old variable:

class AnimatedSprite : Sprite, IUpdateable, ICloneable, IDisposable
{
        bool disposed = false;

        public void Dispose()
        {
                Dispose(true);
                GC.SuppressFinalize(this);
        }

        void Dispose(bool disposing)
        {
                if (!this.disposed)
                {
                        if (disposing)
                        {
                                // dispose managed ressources
                                EntityManager.Instance.UnregisterDrawable(this);
                                EntityManager.Instance.UnregisterUpdateable(this);
                        }
                        // dispose unmanaged ressources
                }
        }

        ~AnimatedSprite()
        {
                Dispose(false);
        }
}
 

Access violations when i created a new instance of AnimatedSprite, although i handled disposing myself, until i found out i was supposed to overwrite Objectbase.Dispose() (using an almost empty override just to stop the garbage collector from finalizing the sprite, while sfml was still drawing the object).


2.
Remove the /////////////////////////////////////////////// first and last line of the xml doc tags.
Common IDEs such as Visual Studio and MonoDevelop will not display tooltips (i.e. IntelliSense), since they don't understand xml docu that way. (Also documentation compilers such as SandCastle will not be able to create a documentation that way)

3.
- Add explicit conversions for closely related types, such as Vector2f, Vector2i, Vector2u, e.g.

        public static explicit operator Vector2f(Vector2i vector)
        {
                return new Vector2f(vector.X, vector.Y);
        }
 

- Add extension methods for closely related types, such as Vector2f, Vector2i, Vector2u, e.g.

        public static class VectorExtensions
        {
                public static Vector2i ToVec2i(this Vector2f vec)
                {
                        return new Vector2i((int)vec.X, (int)vec.Y);
                }

                public static Vector2u ToVec2u(this     Vector2f vec)
                {
                        return new Vector2u((uint)vec.X, (uint)vec.Y);
                }

                public static Vector2f ToVec2f(this Vector2i vec)
                {
                        return new Vector2f(vec.X, vec.Y);
                }

                public static Vector2u ToVec2u(this Vector2i vec)
                {
                        return new Vector2u((uint)vec.X, (uint)vec.Y);
                }

                public static Vector2f ToVec2f(this Vector2u vec)
                {
                        return new Vector2f(vec.X, vec.Y);
                }

                public static Vector2f ToVec2i(this Vector2u vec)
                {
                        return new Vector2f(vec.X, vec.Y);
                }
        }
 

allowing for a bit more comfort:

static void Main(string[] args)
{
        Vector2f vec2f = new Vector2f(50f, 100f);
        Vector2u displayResolution = vec2f.ToVec2u();

        Vector2i vec2i = new Vector2i(50, 100);
        Vector2f someVec2f = (Vector2f)vec2i;
}
 

2
DotNet / Suggestion: Make all structs immutable
« on: July 10, 2014, 07:42:29 pm »
Related to this topic I want to suggest to make all structs immutable.

- With mutable structs it is extremely easy to loss data, when e.g. users accidently modify a copy of a struct instead of the structs
- Immutable structs are automatically thread safe by nature
- Users will no longer forget to initialize some of the fields
- There would be almost no performance penalty, as structs (unlike as in Java) are extremely light-weight objects

For reference:
Microsoft Advice on Struct Design

Burning monk on structs

Eric Lippert (Designer of the C# language and the CLR) about mutable structs

Eric Lippert - value types may be created on the stack (extremely light-weight to create)


3
Graphics / Graphic issue with vertical / horizontal lines
« on: July 08, 2014, 07:29:53 pm »
Hello everyone. I am currently on working a small game using the SFML .NET V2.1 bindings and i am encountering some kind of graphic glitch on some machines.

This is what the game currently looks on my desktop:



I have sent someone a copy to try it out on another machine, this is what the game looks for him:







Edit: Added this shot. Vertical line right beside the player sprite and horizontal line above the whole image.



Old Version:



Notice the vertical lines.

I tried rounding down object coordinates to int of my tiles before drawing, various graphic settings including anti-aliasing (makes it a LOT worse), texture filtering (i love the current pixelated look), vsync and what not.

I encountered a similiar issue when creating the initial version of this game, using the slick library for java, before i moved to start over using .NET. Last time i fixed it, by using only floats during all calculations and finally truncating all images to int's immediatly when drawing them.

Does anyone have a suggestion, that i could try?

Pages: [1]