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.


Messages - immotus

Pages: [1]
1
DotNet / Re: Sprite.Transform.TransformRect()
« on: January 02, 2016, 06:18:47 pm »
I apologize.  I missed the link to the low level Transform class.  Thanks for pointing me in the right direction. 

Maybe I am just getting old but it seems that properties like Size should be for configuration at start up and properties/methods of Scale are for runtime/render-loop alteration.  Basically, this is purely semantics.

Sorry to bother you.

2
DotNet / Sprite.Transform.TransformRect()
« on: January 02, 2016, 04:52:26 pm »
It seems like the dotnet version of SFML is becoming a bit convoluted.

Why doesn't the Sprite class simply have access to a Size member where we can set it's size with a method or a Size Property that we can set a Size on? 

Lacking documentation it appears that the purpose of TransformRect() is to change the size of the sprite. This is not very intuitive and seems like something that would be taken care of by the Scale property.  Which is a pain when all you want to do is configure the size of the sprite as you are loading up all the various objects you might need. 

For instance, I have 64x64 pixel texture regions that I want to use in a sprite that is 100x100 world units.. 
I created a Sprite and started to size it .. and promptly got lost trying when trying to set the size of the Sprite.

Just sayin.

I really like the elegance of c# but god damn, I think I'm going to switch back to c++.




3
SFML projects / Quick and Dirty texture management for dotnet users..
« on: January 13, 2015, 08:41:15 am »
Here's a class to manage textures for c#.  No bells, no whistles.


public class ResourceManager
    {
        //Our base texture..
        Texture sfmlTexture;

        //Resource collection(s)..
        protected Dictionary<string, Texture> textureCache;

        //Don't create..
        private ResourceManager()
        {
            textureCache = new Dictionary<string, Texture>();
        }

        //Create a static reference..
        private static ResourceManager manager = null;

        //Return an instance of it on demand to create resources...
        public static ResourceManager ReturnInstance()
        {
            if (manager == null)
            {
                manager = new ResourceManager();
            }

            return manager;
        }

        public Texture CreateTextureResource(string filename)
        {
            //Make sure we havent created the resource already...
            if (textureCache.ContainsKey(filename))
            {
                //We already created it so, return it...
                return textureCache[filename] as Texture;                
            }
            else
            {
                //We havent created it, do so and add it to the collection...
                sfmlTexture = new Texture(filename);
                textureCache.Add(filename, sfmlTexture);

                //Return the texture...
                return textureCache[filename] as Texture;
            }
        }

        //Call this explicitly as you shut down the application to dispose of the textures..
        public void CleanUpTextures()
        {
            //Dispose all textures..
            foreach (Texture t in textureCache.Values)
            {
                if (t != null)
                {
                    t.Dispose();
                }
            }

            //Clear the cache..
            textureCache.Clear();
        }
    }

 

To use this you need to call it directly from the TYPE such as:


MyGameObject.Texture = ResourceManager.ReturnInstance().CreateTextureResource("Foo.png");

 

In essence this class is a singleton.  Seeing as the video card only needs one copy of a bitmap to render to multiple entities creating textures using a method like this ensures there is only ONE of each bitmap ever kept in memory. 

4
DotNet / Re: Exception Handling
« on: December 20, 2014, 12:20:51 pm »
Thanks guys  :)  That was enough to jog the old noodle into thinking about it in the right way!   Almost all of my experience with graphics has been in DirectX.  So, I looked into what OpenGL is doing way down there in the hardware and it appears that it does things in such a way that it never loses the device context or if it does, it keeps the data it needs handy so that it can recover. 

I've got a lot more to learn and, some DirectX baggage I need to discard but, I'm already starting to like what I see in OpenGL.  Thanks for the help.  In the meantime, I looked into exceptions OpenGL might have and I can deal with those easily enough on my own. 

Great library by the way, I really like it. 

Edit*  http://www.glprogramming.com/red/chapter14.html#name1
In case anyone is interested in errors that OpenGL can have.

Oops that's an old one.. try :
https://www.opengl.org/sdk/docs/man4/

Look for glGetError()  to see what errors you can track.

5
DotNet / Exception Handling
« on: December 20, 2014, 01:24:03 am »
I have been looking through the SFML API but, I don't see anything about exceptions that might be thrown by the API Classes.  Basically, one of the things I am interested in is cases in which the application might lose the device.  In DirectX this would be a DeviceLost Exception which can happen when the user does something like Alt-Tab and gives focus to another window.  When this happens you might have to re-create textures, reset render states, etc...  So, does SFML handle all this under the hood? 

I haven't messed with graphics programming in a long time and I am trying to get a feel for what can go wrong with this library.  Can anyone point me in the right direction?  Thank you.

Pages: [1]
anything