Image.Copy copying nothing

[Spodi]

I recently upgraded all my code from SFML 1.5 to the latest 2.0 commit. Everything seems to be working for the most part except for Image.Copy. It simply just copies nothing. I threw together a little mock project to make sure it wasn't my code, and it does definitely seem to be SFML:

Code: [Select]


using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using SFML.Graphics;

namespace ConsoleApplication1
{
    class Program
    {
        static void Main(string[] args)
        {
            using (var rw = new RenderWindow( new SFML.Window.VideoMode(800, 600), ":)"))
            {
                var a = new Image("a.bmp");
                var atlas = new Image(64, 64, new Color(255, 0, 255, 0));

                Copy(atlas, a, 0, 0, new IntRect(0, 0, 32, 32));
                Copy(atlas, a, 32, 0, new IntRect(0, 0, 32, 32));
                Copy(atlas, a, 0, 32, new IntRect(0, 0, 32, 32));
                Copy(atlas, a, 32, 32, new IntRect(0, 0, 32, 32));
     
                var s = new Sprite
                {
                    Position = new Vector2(0, 0),
                    SubRect = new IntRect(0, 0, 64, 64),
                    BlendMode = BlendMode.None,
                    Color = Color.White,
                    Image = atlas
                };

                rw.Show(true);
                rw.UseVerticalSync(true);

                while (rw.IsOpened())
                {
                    rw.DispatchEvents();
                    rw.Clear();
                    rw.Draw(s);
                    rw.Display();
                }
            }
        }

        static void Copy(Image dest, Image src, uint dx, uint dy, IntRect srcRect)
        {
            const bool useSFMLCopy = true;

            if (useSFMLCopy)
            {
                dest.Copy(src, dx, dy, srcRect);
            }
            else
            {
                for (uint x = 0; x < srcRect.Width; x++)
                {
                    for (uint y = 0; y < srcRect.Height; y++)
                    {
                        dest.SetPixel(dx + x, dy + y, src.GetPixel((uint)srcRect.Left + x, (uint)srcRect.Top + y));
                    }
                }
            }
        }
    }
}


If you set the const useSFMLCopy to false, it will do a pixel-by-pixel copy and work fine. But when true, nothing copies over at all.[/code]

Edit: Here is a copy of the project (for VS 2010).

[Ashenwraith]

Did you update your rectangles for the new rectangle format of sfml2.0?

I replaced all of my .copy with updatepixels and it seems to work better.

BTW have you thought of using a texture atlas with UVs instead of copy?

I was thinking about doing something like that myself.

[Spodi]

What do you mean by UVs?

And yes, I have updated my usages of rectangle to the new constructor conventions. Though it shouldn't matter anyways when you have a x/y of (0,0) like I do in the example code.

[Ashenwraith]

You can animate by shifting UVs similar to a scroll rect.

Anyways, not really sure what the problem is since I don't have class implementations like this at all.

Do you really need a new IntRect for every copy, especially when they are all the same size?

Also one thing I remember about switching to sfml 2 is that I had to change some of my Image constructors to Image.Create, ie if there was a color.

[Spodi]

Do you really need a new IntRect for every copy, especially when they are all the same size?

IntRect is a struct, and calling new on a struct in .NET just creates a value type on the stack. So its basically free. But again, this is just a sample project - not intended to be well-coded or optimized or anything.

Also one thing I remember about switching to sfml 2 is that I had to change some of my Image constructors to Image.Create, ie if there was a color.

Hmm, there are no public static members for Image in the .NET implementation from what I see.

Anyone else mind trying using Image.Copy() to see if it works for them? Could at least help narrow down where the problem lies (if its in the .NET bindings, my system, or the SFML core).

[Laurent]

Yeah don't worry I'll test your code as soon as I find 5 minutes

[Ashenwraith]

I used Image.Copy() in C++/SFML2 and it worked fine:

Code: [Select]

   
sf::Image m_img00;
m_img00.LoadFromFile("fb00.png");

sf::Image c_img00; c_img00.Create(w,h,sf::Color(0,0,0,0));
sf::IntRect rct(0,0,0,0);

c_img00.Copy(m_img00,0,0,rct,false);


[Laurent]

This was a bug, it's now fixed.

It was tricky: in CSFML, the function is called sfImage_CopyImage instead of sfImage_Copy, because the latter is used for implementing a kind of copy constructor. And SFML.Net was calling the wrong one, sfImage_Copy.

I used Image.Copy() in C++/SFML2 and it worked fine:

An old revision maybe?

[Spodi]

Thanks, Laurent! I actually do recall noticing that when looking into it, but my lack of knowledge of the SFML internals just led me to assume it was nothing significant. I'll test it out here in a bit and report if there are still any troubles.

Edit: My tests all look good!

[Ashenwraith]

This was a bug, it's now fixed.

It was tricky: in CSFML, the function is called sfImage_CopyImage instead of sfImage_Copy, because the latter is used for implementing a kind of copy constructor. And SFML.Net was calling the wrong one, sfImage_Copy.

I used Image.Copy() in C++/SFML2 and it worked fine:

An old revision maybe?

I haven't updated in about 2 weeks and I'm not using .net.  

In C++ it always worked fine right?

I'm not sure how you are generating the code--is it all originally C at the core?

There's obviously C memcpy stuff in there but I assumed it was C++ first and then C for porting to .Net, etc?

[Laurent]

Ah sorry, I didn't notice that your code was C++. Indeed the bug only happens in .Net.

I assumed it was C++ first and then C for porting to .Net, etc?

It is

[Antidote]

An unrelated note, but unless you plan to have a variable change it's type using var will only lead to unneeded overhead due to the way m$ wrote it.

Don't get me wrong, var is great when using LINQ but in a game it's not necessary.

[Spodi]

An unrelated note, but unless you plan to have a variable change it's type using var will only lead to unneeded overhead due to the way m$ wrote it.

Actually, that is wrong. People commonly confuse var with a dynamic type (which was introduced in .NET 4.0 with the keyword dynamic, intended mostly just for DOM, reflection, and related stuff). var is strongly typed, just not explicitly typed. It is set to the correct type at compile time. So it only makes a difference in the code.

var works fine for anything as long as you still know what type it is resulting in. I use it quite a bit since it makes refactoring countless times easier.

[Ashenwraith]

I know microsoft has patents for EMCA which is also used in javascript and actionscript and that's where my experience comes from.

In that case for instance var x=1; would default to a Number object which will give you significantly less performance for loops than int. That's why javascript/actionscript recommend defining your types for performance, but omitting them for script compression.