Messages

1

DotNet / Re: Fps counter results differ from SetFrameLimit() value

« on: October 30, 2014, 05:49:28 pm »

The system module was never part of the SFML .NET framework AFAIK. It's certainly not in the version I'm using.

It was added after 2.1.

Huh. Was there a specific reason you decided to implement it now?

I'll take a look in to upgrading my version.

Also can you elaborate on what zsbzsb said about the accuracy compared to TickCount in high performance scenarios?

2

DotNet / Re: Fps counter results differ from SetFrameLimit() value

« on: October 30, 2014, 05:12:24 pm »

Not to mention that using TickCount is very inaccurate at high speeds. You should instead use the SFML Clock and Time classes.

The system module was never part of the SFML .NET framework AFAIK. It's certainly not in the version I'm using.

Also, how is TickCount inaccurate at high speeds? In this implementation it's simply checking for when 1,000 milliseconds have passed so it can display the amount of frames rendered in that time. What benefit would the SFML Clock and Time classes provide over this?

3

DotNet / Re: Fps counter results differ from SetFrameLimit() value

« on: October 29, 2014, 04:56:41 pm »

https://github.com/SFML/SFML/wiki/FAQ#window-set-framerate-limit

Interesting read, thanks a lot.

4

DotNet / Fps counter results differ from SetFrameLimit() value

« on: October 29, 2014, 04:16:55 pm »

So I wrote a simple FPS counter class which literally counts how many times it is updated per second. Seems to work fine, however when using the RenderWindow.SetFramerateLimit() method the counter gives a different count to what I'm limiting to.

RenderWindow.SetFramerateLimit(16) returns a count of 17.
RenderWindow.SetFramerateLimit(30) returns a count of 32.
RenderWindow.SetFramerateLimit(60) returns a count of 64.
RenderWindow.SetFramerateLimit(120) returns a count of 144.

Is this expected behaviour or is my counter just horribly written?

public class FpsCounter
{
        private uint _timer;
        private int _frameCount;
        private int _fps;

        public int Fps
        {
                get
                {
                        return _fps;
                }
        }

        public void Update()
        {
                if (_timer < Time.TickCount)
                {
                        _fps = _frameCount;
                        _frameCount = 0;
                        _timer = Time.TickCount + 1000;
                }

                _frameCount++;
        }
}
 

5

SFML projects / Re: Dwell - A Retro Sandbox Survival MMO

« on: October 16, 2014, 06:04:01 pm »

I just gave up basically everything in my life to finish this game, so be prepared to see a shitton of updates coming your way soon.

Be very careful with that. The same problems with Haven and Hearth will affect this project without some clever engineering.

As soon as you turn something like this in to a full time job you can't really overlook things you could as a hobby project. Your netcode especially will have to be on point.

Good luck.

6

SFML projects / Re: Dwell - A Retro Sandbox Survival MMO

« on: October 09, 2014, 12:22:40 pm »

Replace the buttons on your forum skin.

What kind of netcode are you running?

7

DotNet / Re: Easier way to clear a specific area of a render target?

« on: September 25, 2014, 06:59:46 pm »

Less hacky and more optimized:

(sorry if the syntax is slightly wrong, I hope you get the idea)

Works like a charm.

Much appreciated.

8

DotNet / Easier way to clear a specific area of a render target?

« on: September 25, 2014, 05:05:38 pm »

Afternoon all,

To cut down on drawing calls I'm playing around with the idea of rendering map sprites to a render target then drawing that to the main screen.

However as this is a map editor I need to be able to invalidate specific regions so I can re-draw the changes the user made.

Here's my current code:

Code: [Select]

var clearShape = new RectangleShape
{
Size = new Vector2f(32, 32),
FillColor = new Color(0, 0, 0, 1)
};
clearShape.Position = new Vector2f(0, 0);
_mapTexture.Draw(clearShape, new RenderStates(BlendMode.None));

It works very well, but I feel like there must be an easier (and less hacky. see: alpha value of 1 in colour) way to do this.

Any ideas?

Thanks,
Robin

9

Graphics / Re: AW: Re: NPOT artefacts on .Repeated = true texture?

« on: January 17, 2014, 07:40:54 pm »

Well that's quite possible. A few years back GPUs often went crazy when dealing with NOPT textures. However we've come quite a bit and drivers/GPUs have "learnt" how to deal with POT textures.

I'm just happy I've got something like SFML to use now-a-days. Working with lower level libraries like DirectX and OpenGL always hurt my head. Can't deal with all the fractions.

Thank you both for your help, it really saved me from a frustrating situation!

10

Graphics / Re: NPOT artefacts on .Repeated = true texture?

« on: January 17, 2014, 01:01:38 pm »

Why not try?

Why manually set sf::View::Center at all? A quick look at sf::View()'s source tells you SFML does it in your stead automatically, without flooring (casting)...

You're right on the money, there. If I remove the integer casting from the View.Size.X in the View.Center change it fixes everything.

Because the artefacts were always there with NPOT rendering I figured it was just how things were... especially because I had similar problems dealing with DirectX8 around 5 years ago. Thinking back I probably just had some dodgy casting errors there too as I was writing my own classes to deal with rendering when I had no idea what I was doing.

Thanks for the help. You may have also retroactively fixed a problem I had when I was a teenager on top of things. :^)

11

Graphics / Re: NPOT artefacts on .Repeated = true texture?

« on: January 15, 2014, 02:18:17 pm »

That was a very good idea.

I ran it in a more standard SFML Window environment. Not only did the repeated texture render flawlessly, but so did the NPOT textures which normally exhibit artefacts when rendering within the WinForms environment...

It seems there is a problem with how I'm handling rendering within the SFML control.

From what I can see, however, there is very little code which could be screwing up here.

Here's how I initialise the class:

Code: [Select]

private void ScrollableSFML_Load(object sender, EventArgs e)
{
    RenderWindow = new RenderWindow(Handle);
    SetView();
    Render();
}

And here's how I create the view:

Code: [Select]

public void SetView()
{
    View = new View(new FloatRect((XOffset * -1), (YOffset * -1), ClientSize.Width, ClientSize.Height));
    RenderWindow.SetView(View);
}

Here is what I do when the client area is re-sized:

Code: [Select]

public void SetAndRefreshView()
{
    View = new View(new FloatRect((XOffset * -1), (YOffset * -1), ClientSize.Width, ClientSize.Height));
    View.Center = new Vector2f(XOffset + ((int)View.Size.X / 2), YOffset + ((int)View.Size.Y / 2));
    RenderWindow.SetView(View);
    Render();
}

You mentioned earlier than floating point numbers can causing rounding issues in texture rendering. Do you think that the way I'm initialising the view rect could be causing these problems?

12

Graphics / Re: NPOT artefacts on .Repeated = true texture?

« on: January 15, 2014, 01:34:18 pm »

Pixel perfect rendering has always been a bit of a pain with SFML/OpenGL...

It's kind of hard to tell where the problem now really is, since you've multiple things mixed.

Does the checkerboard pattern draw normal if you don't load an image at all?
Does the checkerboard pattern draw normal if the loaded image doesn't cover it?
Does the checkerboard pattern draw normal if you move a POT texture a few pixels off?

From what I can see there seems to be something going wrong, when drawing transparent parts of an image on top of the repeated pattern. And you say this only happens with NPOT textures?

What if you for once used a non-repeated texture for the checkerboard background, would it still get corrupted?

I realise now my post had a lot of noise in it. I was simply giving examples of similar corruption occurring when rendering NPOT textures.

The problem is that if I have a 512x512 sprite, my checkerboard pattern will repeat over it flawlessly. If I resize that to, say, 528x528 the checkerboard pattern will appear like it does in those screenshots.

Ignore everything else, that was simply my debugging process.

If a sprite is POT, the repeated texture is fine. If a sprite is NPOT, the repeated texture has artefacts when rendering. The texture being repeated is POT regardless of the situation.

I can create a stand-alone example of the SFML control which shows this behaviour if that would help.

13

Graphics / Re: NPOT artefacts on .Repeated = true texture?

« on: January 15, 2014, 12:43:39 pm »

Good morning!

I'm back after doing a bit more sleuthing.

Every single rendering control in this application is based off a SFML 'mother class' which handles management of the window, view, drawing cycle etc. You basically just build more specific functionality whilst inheriting this class and add an override which the mother class will pull from to render -- simple stuff.

First of all, here's the code for initialising the texture and sprite. (Ignore the lazy resource manager reference, it was just a basic class to avoid duplicate loading. I'm planning on writing a real one at some point.)

Code: [Select]

_checkedTexture = ResourceManager.Instance.LoadTexture(Application.StartupPath + @"\content\textures\transparency.png");
_checkedTexture.Repeated = true;
_checkedSprite = new Sprite(_checkedTexture);
_checkedSprite.TextureRect = new IntRect(0, 0, 0, 0);

Later on I set the TextureRect like this:

Code: [Select]

_checkedSprite.TextureRect = new IntRect(0, 0, ObjectWidth, ObjectHeight);

ObjectWidth and ObjectHeight are both integers which store the size of the sprite. As such I don't think they'll be causing a problem with floating point rounding.

The view is created (and re-created on resize) like this:

Code: [Select]

View = new View(new FloatRect((XOffset * -1), (YOffset * -1), ClientSize.Width, ClientSize.Height));
View.Center = new Vector2f(XOffset + ((int)View.Size.X / 2), YOffset + ((int)View.Size.Y / 2));
RenderWindow.SetView(View);

Now the fact that I'm forced to pass a FloatRect through to create that view is slightly more interesting. From all the examples I looked at when picking SFML up this was the standard way of doing things.

Could this be creating the rounding errors you talked about?

ClientSize.Width and ClientSize.Height come from the System.Drawing.Size class and are both integers.


I did some more screwing around with a more isolated environment to re-create the artefact problems I was having. This is done using a simple ScrollTexture view, which is just the SFML mother class with the ability to have a texture passed through to it.

This first image shows a 1024x1024 texture with a grid pattern of 32x32 squares which alternate between 100% red and 100% transparent, thus showing off the checked pattern which is the .Repeated=true sprite with a 16x16 texture assigned to it.



Zero problems.

However, if I add an extra 32pixels to both dimensions to take it to a 1056x1056...



Chaos! This was actually the first time I saw such aggressive artefacts showing up, so it was slightly shocking.

From what I could tell before my eyes started giving up on me, the 1056x1056 texture is actually rendering properly... it's the repeated background which is screwing up.

However, this is not consistent across all sizes.

This is a 960x384 texture.



The raw image is insanely smooth -- the artefacts are 100% from the rendering code. If you zoom in you can see the repeated background screwing up once again, something which never happens with a standard POT sprite size.

Here are a couple more images showing the artefacts in other situations. I ended up loading a screenshot in to Photoshop to see exactly what kind of skewing was occurring.





I hope this gives a bit more context for my problem. Again, any help would be greatly appreciated!

14

Graphics / Re: NPOT artefacts on .Repeated = true texture?

« on: January 14, 2014, 08:50:07 pm »

I'm still plodding along with it. Things are slow due to work and other commitments, but it's always in the back of my mind.

I figured it'd be something to do with NPOT due to the fact that the rendering is flawless if the total size of the sprite is POT. The only time I've seen slight 'skewing' like this is when loading larger NPOT textures on non-repeating sprites. I can't be 100% sure on that without testing it a bit more, though.

I'll get some time with the code tomorrow and look at the areas you mentioned and get some more information. I only really noticed it an hour or so before posting, so haven't had much time to screw around.

Thanks for the help!

15

Graphics / NPOT artefacts on .Repeated = true texture?

« on: January 14, 2014, 06:39:57 pm »

Afternoon gents,

I'll keep it simple.

We all know that when running non power-of-two textures you get slight artefacts which make the texture look 'off'. EDIT - This is entirely assumed on my part due to consistencies when using DirectX8 like... 5 years ago. May not be true?

I'm getting the same artefacts when running a power-of-two texture with the .Repeated flag set to true on a larger NPOT sprite.



I had a look around but couldn't really find any information on this. Should this be happening? Is there a workaround?

The artefacts are showing up on the grid as well as the 'transparency' checked background. The grid is a 32x32 texture, the checked effect is a 16x16 texture. Both of them are running on a >1024 sprite size, but occur on smaller ones too.

I'm running the .NET implementation of SFML 2.0.

Thanks,
Robin