Java

[solgar]

Here were some people being confused because they didn't know that Circle() is a static function

As you have to write :: …

It still looks like constructor of some other type in sf::Shape namespace.  It is not really an issue but i thought that "Create" prefix won't hurt.

I don't know, it sounds more intuitive to me. It looks more like a constructor than a regular function.

I agree with you.

And because this looks like constructor it makes confusion. When I first saw this I wasn't sure whats happening. I thought that Circle is some class inheriting from Shape in sf::Shape namespace and its constructor is called. But I'm not used to C++ syntax and maybe that caused this feeling.

[solgar]

Weekly changes report:
- sf::RenderWindow implemented 92%
- sf::Image implemented
- sf::Sprite implemented

[solgar]

Java binding code:

Code: [Select]

Image img = new Image();
img.loadFromFile("bgr.png");
Sprite spr = new Sprite(img);
img = null;
System.gc();

In case above Java Sprite holds pointer to native Sprite which holds native pointer to non existing native Image and result of Java call (for example) window.draw(spr) is undefined. Java Sprite doesnt hold Java Image object instance, so in code above "img" after GC call will be deleted and coresponding native object also. Calling window.draw(spr) can draw just white rectangle instead of image or even crush. I dont like idea of Sprite holding Image instance in Java, but in many cases my approach to objects handling can couse troubles. How similar code would work in C# binding? I have tried to read cs files in C# binding folder, but i have never seen before any C# code and it is hard for me to understand it.

[Laurent]

I dont like idea of Sprite holding Image instance in Java

But that's the only solution in order to ensure that:
- the sprite can return its Java image
- the Java image is not collected by the GC, because the sprite keeps a link to it

That's how things work in SFML.Net.

[solgar]

C++ Sprite.GetImage() returns const pointer to Image. How in SFML.Net is resolved returning "const" objects? Image object returned from Sprite.getImage() in C# can be modified? I dont know how to resolve this in jSFML. In case small objects like sf::Color or sf::Vector are returned new objects with same field values as returned native const object but what to do with big ones like sf::Image or huge sound objects?

[Laurent]

const-correctness is not a concept that exists in C#, so there's no way of reproducing the C++ behaviour. If it's the same for Java, then you can't help much.

I saw a workaround for C#, but I'm not sure if it's worth it. After all, why should we emulate something that doesn't exist in the language itself?

[solgar]

const-correctness is not a concept that exists in C#, so there's no way of reproducing the C++ behaviour. If it's the same for Java, then you can't help much.

I saw a workaround for C#, but I'm not sure if it's worth it. After all, why should we emulate something that doesn't exist in the language itself?

Maybe you are right. I thought that it will be better to recreate C++ functionality than adapt functionality to Java. For the same reason i didnt liked Sprite having Image instance in Java. So what about other getters? If I'm right in SFML.Net Vectors and Colors (because they cannot be const) are copied and copy is returned. Am i right?

Other thing. C++ sf::Image have GetTexCoords() method which returns non const object and C# implementation does not have this method. Why is that?

[Laurent]

I thought that it will be better to recreate C++ functionality than adapt functionality to Java

I think it is better to stick to the language. People who will use jSFML will be java users, not C++ users. It must look like a native library, not a binding.

So what about other getters? If I'm right in SFML.Net Vectors and Colors (because they cannot be const) are copied and copy is returned. Am i right?

You're right.

Other thing. C++ sf::Image have GetTexCoords() method which returns non const object and C# implementation does not have this method. Why is that?

Some functions are in the public interface of the C++ class, but are for internal use; thus I don't implement them in the bindings. GetTexCoords is one of them.

[solgar]

Some functions are in the public interface of the C++ class, but are for internal use; thus I don't implement them in the bindings. GetTexCoords is one of them.

There is no annotation about that. It would be nice to have this annotation in documentation because i dont know which of public methods are for internal use and I implement all public functions. Can you tell me which public functions in all classes are for internal use?

[Laurent]

Don't worry about that, there are only 3 or 4 functions like this and the others are annotated

[solgar]

Static method sf::Image::GetValidTextureSize is unimplemented in SFML.Net. Why? There is no Glyph class implemented in SFML.Net. Why?

Code: [Select]

View view = new RenderWindow(new VideoMode(240, 320), "calling move will cause crash :(").getDefaultView();
System.gc();
view.move(20, 20);
Consider above code. Will this work in SFML.Net? When destroying render window its view is destroyed also and Java/.Net object is invalid, because it holds pointer to non existing object. When RenderWindow is destroyed in .Net CSFML sfRenderWindow_Destroy is called and this function destroys default view. Am i right? In case above solution is to set default view field holding native pointer to 0 and checking this value in every call. What do you think about it?

[Laurent]

Static method sf::Image::GetValidTextureSize is unimplemented in SFML.Net. Why?

Because this one is mainly for internal use.

There is no Glyph class implemented in SFML.Net. Why?

Same. But I think that this one should get defined (I think I did it in CSFML).

Consider above code. Will this work in SFML.Net?

I don't know. There's specific code to ensure that this kind of situation works, but I think you're right about the internal pointer being destroyed.
But using a window's view after the window has been destroyed is clearly an error, I'm not sure if we should find a solution for this.

[solgar]

Weekly changes report:
- sf::Font implemented
- sf::String2D implemented
- sf::Shader implemented
- sf::RenderWindow fully implemented
- fixed few bugs

[Laurent]

You should update your working copy, sf::String2D is now sf::Text

[solgar]

You should update your working copy, sf::String2D is now sf::Text

I'm working on revision 1283. When I will finish implementing all functionality I will update everything to head revision. But thanks for pointing that .