Author Topic: New graphics API ready (Read 82914 times)

Groogy · « **Reply #60 on:** December 09, 2011, 12:12:30 am »

Here it's a very special case when the points are really close, but it could just be my math for calculating the points that are stupid, I don't know, though it doesn't show without the outline.

If you move the mouse towards one of the corners of the window it should show when the points become more or less parallel. I guess that's why the outline fuck up?

Code: [Select]

#include <SFML/Graphics.hpp>

#define SIZE 16.f
#define HALF_SIZE 16.f / 2.f

int main()
{
	sf::RenderWindow window( sf::VideoMode( 800, 600 ), "Test" );
	sf::Event event;

	sf::ConvexShape shape;
	shape.SetFillColor( sf::Color::White );
	shape.SetOutlineColor( sf::Color::Red );
	shape.SetOutlineThickness( 1 );
	shape.SetPointsCount( 4 );
	shape.SetPosition( 400, 300 );

	sf::Vector2f position;
	sf::Vector2f camera(0,0);

	while( window.IsOpened() == true )
	{
		camera = static_cast< sf::Vector2f >( sf::Mouse::GetPosition() );

		sf::Vector2f movement;
		movement.x = ( 34 * SIZE - camera.x ) / SIZE;
		movement.y = ( 34 * SIZE - camera.y ) / SIZE;

		position = sf::Vector2f( -HALF_SIZE, 0 );
		shape.SetPoint( 0, position );

		position = sf::Vector2f( HALF_SIZE, 0 );
		shape.SetPoint( 1, position );

		position = sf::Vector2f( HALF_SIZE, 0 );
		position.x += movement.x;
		position.y += movement.y;
		shape.SetPoint( 2, position );

		position = sf::Vector2f( -HALF_SIZE, 0 );
		position.x += movement.x;
		position.y += movement.y;
		shape.SetPoint( 3, position );

		window.Clear();
		window.Draw( shape );
		window.Display();

		while( window.PollEvent( event ) == true )
		{
			if( event.Type == sf::Event::Closed )
			{
				window.Close();
				break;
			}

		}
	}
	return 0;
}

This problem was on the previous API as well but I just ignored it and thought that my point calculation fucked up. But seeing how it appears to be when the points are aligned is when it fucks up. I don't even know if it's possible for you to handle that case in your code.

And still, it can be that it's just my point calculations that go haywire?

Update: Checked the exact positions of the points when given to the shape, they are as follow when the camera vector is 872x545

Code: [Select]

0# -8x0
1# 8x0
2# -12x-0.0625
3# 0x0

So they are ALMOST parallel and no values are "wrong"

Laurent · « **Reply #61 on:** December 09, 2011, 07:31:22 am »

If the bug was already there with the old API, you should rather open a new thread, we're getting off-topic here

Laurent · « **Reply #62 on:** December 10, 2011, 01:04:41 pm »

I've pushed the support for vertex shaders, as well as an upgrade of the "shader" example.

Laurent · « **Reply #63 on:** December 10, 2011, 03:26:45 pm »

I've removed the sf::StarShape class, added GetPointsCount/GetPoint in sf::Shape, and added SetPointsCount in sf::CircleShape.

I think everything's ok now, according to the feedback I got in this thread.

I can start working on improving performances.

Groogy · « **Reply #64 on:** December 11, 2011, 12:14:01 am »

Quick question, how is state's now if you want to mix it up with 3D? Is gonna try that next with the new graphics API.

Does it work like it did before where you have to preserve the states? (And will it change?)

Laurent · « **Reply #65 on:** December 11, 2011, 08:18:59 am »

There are two strategies.

1. PushGLStates/draw SFML/PopGLStates()
This one is simple but not optimized, SFML saves *all* the OpenGL states, even the ones that you don't care about

2. your own push/ResetGLStates/draw SFML/your own pop
Here you can save and restore only the states that you need, and ResetGLStates takes care of setting all the states that SFML needs for its own drawing.

Nexus · « **Reply #66 on:** December 11, 2011, 05:31:53 pm »

Nice! Today, I have applied the changes to Thor, and the shapes work very well so far.

However I have a problem with my particle systems which use OpenGL and sf::Texture. Nothing is drawn anymore. I have renamed SaveGLStates() and RestoreGLStates() calls, but this is the only modification in my code. Apart from that, is there something to consider with the new Graphics API?

Richy19 · « **Reply #67 on:** December 11, 2011, 06:11:54 pm »

Quote from: "Laurent"

I've pushed the support for vertex shaders, as well as an upgrade of the "shader" example.

Any chance this could be pushed into the current SFML2 dev build?
Or is it possible to just take the new shader.hpp/cpp and swap them with current SFML2 dev build?

Laurent · « **Reply #68 on:** December 11, 2011, 07:02:24 pm »

Quote

Any chance this could be pushed into the current SFML2 dev build?
Or is it possible to just take the new shader.hpp/cpp and swap them with current SFML2 dev build?

Vertex shaders don't make sense with the old graphics API, so I won't push them alone in the master branch. And no, you can't use the new version without the new API.
But why don't you switch to the new API anyway? It's just a matter of weeks before it becomes official.

Quote

However I have a problem with my particle systems which use OpenGL and sf::Texture. Nothing is drawn anymore.

I think we'll need a complete/minimal code

By the way, have you tried to use sf::VertexArray instead of OpenGL? Unless you do something very specific, you should now be able to implement particle systems with SFML only.

Richy19 · « **Reply #69 on:** December 11, 2011, 07:06:08 pm »

Quote from: "Laurent"

Quote
Any chance this could be pushed into the current SFML2 dev build?
Or is it possible to just take the new shader.hpp/cpp and swap them with current SFML2 dev build?

Vertex shaders don't make sense with the old graphics API, so I won't push them alone in the master branch. And no, you can't use the new version without the new API.
But why don't you switch to the new API anyway? It's just a matter of weeks before it becomes official.

Quote
However I have a problem with my particle systems which use OpenGL and sf::Texture. Nothing is drawn anymore.

I think we'll need a complete/minimal code
By the way, have you tried to use sf::VertexArray instead of OpenGL? Unless you do something very specific, you should now be able to implement particle systems with SFML only.

True, im using pure openGL the actuall API wouldnt bother me too much tbh i just wanted a wrapper around shaders that isnt my ugly code

I take it this https://github.com/SFML/SFML/tree/drawables is the new API

Wyamiz · « **Reply #70 on:** December 12, 2011, 02:52:01 am »

I run into a little bug in drawables branch: Sprites only display the first pixel of the texture scaled to fill the whole area. Everything works normally if I use master branch instead of drawables branch.

Here's complete example to reproduce the bug:

Code: [Select]

#include <SFML/Graphics.hpp>
#include <iostream>

using namespace sf;
using namespace std;

int main(int argc, char *argv[])
{
    if(argc<2){
        cout<<"Usage: "<<argv[0]<<" image_to_display"<<endl;
        return 0;
    }

    RenderWindow wnd(VideoMode(640,480),"Sprite/Texture Bug in New Graphics API");

    Texture img;
    img.LoadFromFile(argv[1]);
    Sprite obj(img);

    while(wnd.IsOpened()){
        Event ev;
        while(wnd.PollEvent(ev)){
            if(ev.Type==Event::Closed)
                wnd.Close();
        }
        wnd.Clear();
        wnd.Draw(obj);
        wnd.Display();
    }

    return 0;
}

Nexus · « **Reply #71 on:** December 12, 2011, 07:10:53 am »

I'll try to minimize the example as soon as possible. Yes, I have already thought about working with sf::VertexArray, but not implemented any corresponding code yet. I guess the performance is similar to direct OpenGL, but don't I lose some flexibility (blend function, texture mapping filters etc)?

Laurent · « **Reply #72 on:** December 12, 2011, 07:42:26 am »

Quote

I run into a little bug in drawables branch: Sprites only display the first pixel of the texture scaled to fill the whole area. Everything works normally if I use master branch instead of drawables branch.

Are you sure that you cleaned/recompiled things properly? I can't reproduce this bug.
What's your graphics card, OS, drivers, ...?

Quote

I guess the performance is similar to direct OpenGL, but don't I lose some flexibility (blend function, texture mapping filters etc)?

Like I said, it depends what you were using before.
You can still apply the SFML blending modes to the vertex array.
What are "texture mapping filters"?

Nexus · « **Reply #73 on:** December 12, 2011, 08:04:38 am »

Quote from: "Laurent"

You can still apply the SFML blending modes to the vertex array.

But only the 4 predefined ones. One cannot combine the modes like glBlendFunc(). Not that I needed this functionality right now, just generally

Quote from: "Laurent"

What are "texture mapping filters"?

I meant GL_TEXTURE_MIN_FILTER and GL_TEXTURE_MAG_FILTER. What's the correct term?

Wyamiz · « **Reply #74 on:** December 12, 2011, 12:40:44 pm »

Quote from: "Laurent"

Quote
I run into a little bug in drawables branch: Sprites only display the first pixel of the texture scaled to fill the whole area. Everything works normally if I use master branch instead of drawables branch.

Are you sure that you cleaned/recompiled things properly? I can't reproduce this bug.
What's your graphics card, OS, drivers, ...?

Well I originally checked out the drawables branch and compiled it and installed it. This Ubuntu 11.10 (x64) didn't have any sfml installed prior that. When I run into this bug I checked out master branch to different directory and run "cmake . && make -j5 && sudo make install && sudo ldconfig" After that all worked as expected. If I go back to drawables branch directory and run "sudo make install && sudo ldconfig" the issue is back. (and gone again if I do the same on master branch directory)

My graphics card is HD 5770 and drivers are normal fglrx drivers that Ubuntu installs automatically. I can try this same thing using open source drivers and then I can try to install newest fglrx.