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 - eXpl0it3r

Pages: 1 ... 600 601 [602] 603 604 ... 733
9016
Graphics / Re: SetScale
« on: January 14, 2013, 05:46:04 am »
See the documentation...

Btw. you should really be using SFML 2 instead of the 2.5 years old SFML 1.6, which has bugs and lacks a few nice features.

9017
Read the full post I linked in my first post, so you get an idea what 'compiling' and 'link' actually means...

Well if you want to use the provided binaries you'll have to use VS 2010, but if you recompile the whole library (download the source from GitHub and compile it), then you can use VS 2012.

9018
If you use VS 2012 and the provided VS 2010 binaries, then it won't work and you'll have to recompile SFML.

9019
From where did you get SFML 2? Have setup everything as described in the tutorial?

Additionally you should learn what the whole process of linking/compiling does, maybe this helps...

9020
DotNet / Re: .net sound and music?
« on: January 13, 2013, 10:58:39 pm »
If you want actual help, then you start by describing extremly pedantic what you did from the beginning to the end.
As of now the only thing we know for certain is, that "It doesn't work"... ;)

9021
Graphics / Re: RenderTextures and dynamic memory
« on: January 13, 2013, 10:55:07 pm »
I ran some of those examples. It would appear that any code that gets rid of shipRTex before the declaration of the Sprite ship produces a window which appears to never be cleared. (i.e. It's a window that displays what used to be on the screen before it appeared, rather than what I want to be drawn there.)
Sounds strange... :-\

I'm using a "Intel(R) G33/G31 Express Chipset Family" graphics card.
Also, if it's relevant, I recently found out that I'm using OpenGL version 1.4.0
Well the only thing I could say is: Get a newer piece of hardware... ;)
I know, I know you probably don't have the money etc. but it's just that you can't expect that much graphical stuff will work... If you want some very simple graphics, your CPU might be more reliable and thus I'd suggest to take a look at SDL (not the newest version), which makes use of the CPU rather then the GPU...

9022
Graphics / Re: RenderTextures and dynamic memory
« on: January 13, 2013, 05:34:18 pm »
I never posted code without the clear in it. ;)
All the snippets above that show different variants contain all the clear call. :)

9023
Graphics / Re: RenderTextures and dynamic memory
« on: January 13, 2013, 05:17:48 pm »
It requires clear on integrated intel in a laptop.
Yeah well not calling clear is wrong anyways, although it sometimes works. ;)

9024
SFML wiki / Re: Animated Sprite class
« on: January 13, 2013, 04:20:33 pm »
Seems quite nice, though not as flexible as Thor's animation class, but for a simple animation it's straight forward. :)

Wouldn't it make more sense to call the function addFrame instead of pushBackFrame or if you want to go with push back, then why not simply push_back?

Could please include a proper license? Because
Quote
You can use it in any way you want. Just a little note that the class was written by me would be nice :)
doesn't legally hold up. It also doesn't exactly specify, if the mentioning is required or just wished.
If you don't specify any license it will automatically fall into the public domain as stated by the wiki rules. ;)

9025
Graphics / Re: RenderTextures and dynamic memory
« on: January 13, 2013, 04:10:37 pm »
How does a change in memory relate to the rendering of something on a window?
The window you see is just the representation of some memory in the GPU. A render texture is basically nothing else than a window that doesn't get draw to the screen, but is only kept in memory.
So when you look at the chain RenderTexture -> Texture -> Window you see the connection between. But it seems like on your GPU textures are handeled oddly and when you actually copy from the render texture into a normal texture, it somehow still links to the render texture. Now when you delete the render texture before drawing it to the screen, the copied texture seems to be also affected by the deletion and thus shows nothing.

What causes what? Is it direct?
Hard to say... It works for FRex on an Intel GPU and for me on an AMD GPU, so it really seems to be a problem with your PC or at least with the graphics card or its driver. (Is the driver up-to-date?)

What happens if you delete the render texture after the application execution? E.g.
#include <SFML/Graphics.hpp>
#include <SFML/System.hpp>

int main(){

    sf::RenderWindow window(sf::VideoMode(400,300), "Placeholder", 7);

    sf::Vertex * sh = new sf::Vertex[3];
    sh[0] = sf::Vertex(sf::Vector2f(0,64), sf::Color(255,127,64,255));
    sh[1] = sf::Vertex(sf::Vector2f(32,0), sf::Color(255,191,127,255));
    sh[2] = sf::Vertex(sf::Vector2f(64,64), sf::Color(255,127,64,255));

    sf::RenderTexture * shipRTex = new sf::RenderTexture;
    if(!shipRTex->create(64,64)){
        return -1;
    }
    shipRTex->clear(sf::Color::Transparent);
    shipRTex->draw(sh, 3, sf::Triangles);
    shipRTex->setSmooth(false);
    shipRTex->display();

    sf::Texture shipTex;
    if(!shipTex.create(64,64)){
        return -1;
    }
    shipTex = shipRTex->getTexture();

    sf::Sprite ship(shipTex);
    ship.setColor(sf::Color(255,255,255,255));
    ship.setOrigin(32, 32);
    ship.setScale(1.f/4.f, 1.f/4.f);
    ship.setPosition((float)window.getSize().x/2, (float)window.getSize().y/2);
   
    window.setVerticalSyncEnabled(true);
    window.setFramerateLimit(60);

    while (window.isOpen()){
        sf::Event event;
        while (window.pollEvent(event)){
            if(event.type == sf::Event::Closed){
                window.close();
            }
        }

        window.clear(sf::Color(127,63,31,255));
        window.draw(ship);
        window.display();

    }

    delete[] sh;
    delete shipRTex; //That pesky line

    return 0;
}
Note: The application will have a memory leak, if render texture fails to be created.

But as I said the dynamic allocation with new/delete is kind of depreciated in C++. If you don't have to create the render texture on the fly you could just create everything on the applications stack:
#include <SFML/Graphics.hpp>
#include <SFML/System.hpp>

int main(){

    sf::RenderWindow window(sf::VideoMode(400,300), "Placeholder", 7);

    sf::Vertex sh[3];
    sh[0] = sf::Vertex(sf::Vector2f(0,64), sf::Color(255,127,64,255));
    sh[1] = sf::Vertex(sf::Vector2f(32,0), sf::Color(255,191,127,255));
    sh[2] = sf::Vertex(sf::Vector2f(64,64), sf::Color(255,127,64,255));

    sf::RenderTexture shipRTex;
    if(!shipRTex.create(64,64)){
        return -1;
    }
                shipRTex->clear(sf::Color::Transparent);
    shipRTex.draw(sh, 3, sf::Triangles);
    shipRTex.setSmooth(false);
    shipRTex.display();

    sf::Texture shipTex;
    if(!shipTex.create(64,64)){
        return -1;
    }
    shipTex = shipRTex.getTexture();

    sf::Sprite ship(shipTex);
    ship.setColor(sf::Color(255,255,255,255));
    ship.setOrigin(32, 32);
    ship.setScale(1.f/4.f, 1.f/4.f);
    ship.setPosition((float)window.getSize().x/2, (float)window.getSize().y/2);

    window.setVerticalSyncEnabled(true);
    window.setFramerateLimit(60);

    while (window.isOpen()){
        sf::Event event;
        while (window.pollEvent(event)){
            if(event.type == sf::Event::Closed){
                window.close();
            }
        }

        window.clear(sf::Color(127,63,31,255));
        window.draw(ship);
        window.display();

    }

    return 0;
}
 
Note: Since everything is on the stack, there won't be any memory issue.

Or if you really need dynamic memory, then you should make use of the STL with vector and unique_ptr (or if unnecessary shared_ptr):
#include <SFML/Graphics.hpp>
#include <SFML/System.hpp>

#include <memory> // unique_ptr
#include <vector>

int main(){

    sf::RenderWindow window(sf::VideoMode(400,300), "Placeholder", 7);

    std::vector<sf::Vertex> sh(3);
    sh[0] = sf::Vertex(sf::Vector2f(0,64), sf::Color(255,127,64,255));
    sh[1] = sf::Vertex(sf::Vector2f(32,0), sf::Color(255,191,127,255));
    sh[2] = sf::Vertex(sf::Vector2f(64,64), sf::Color(255,127,64,255));

    std::unique_ptr<sf::RenderTexture> shipRTex(new sf::RenderTexture);
    if(!shipRTex->create(64,64)){
        return -1;
    }
                shipRTex->clear(sf::Color::Transparent);
    shipRTex->draw(sh.data(), sh.size(), sf::Triangles);
    shipRTex->setSmooth(false);
    shipRTex->display();

    sf::Texture shipTex;
    if(!shipTex.create(64,64)){
        return -1;
    }
    shipTex = shipRTex->getTexture();

    sf::Sprite ship(shipTex);
    ship.setColor(sf::Color(255,255,255,255));
    ship.setOrigin(32, 32);
    ship.setScale(1.f/4.f, 1.f/4.f);
    ship.setPosition((float)window.getSize().x/2, (float)window.getSize().y/2);

    window.setVerticalSyncEnabled(true);
    window.setFramerateLimit(60);

    while (window.isOpen()){
        sf::Event event;
        while (window.pollEvent(event)){
            if(event.type == sf::Event::Closed){
                window.close();
            }
        }

        window.clear(sf::Color(127,63,31,255));
        window.draw(ship);
        window.display();

    }

    return 0;
}
 
Note: Since unique_ptr is an RAII object, the resources will automatically get released when the scope is left.

But I think your idea was to free the memory as soon as possible, thus when the render texture isn't needed anymore. This could also be easily done with smart pointers and some brackets:
#include <SFML/Graphics.hpp>
#include <SFML/System.hpp>

#include <memory> // unique_ptr
#include <vector>

int main(){

    sf::RenderWindow window(sf::VideoMode(400,300), "Placeholder", 7);

    sf::Texture shipTex;
    if(!shipTex.create(64,64)){
        return -1;
    }

    // RenderTexture scope
    {
        std::vector<sf::Vertex> sh(3);
        sh[0] = sf::Vertex(sf::Vector2f(0,64), sf::Color(255,127,64,255));
        sh[1] = sf::Vertex(sf::Vector2f(32,0), sf::Color(255,191,127,255));
        sh[2] = sf::Vertex(sf::Vector2f(64,64), sf::Color(255,127,64,255));

        std::unique_ptr<sf::RenderTexture> shipRTex(new sf::RenderTexture);
        if(!shipRTex->create(64,64)){
            return -1;
        }
        shipRTex->clear(sf::Color::Transparent);
        shipRTex->draw(sh.data(), sh.size(), sf::Triangles);
        shipRTex->setSmooth(false);
        shipRTex->display();


        shipTex = shipRTex->getTexture();
    }

    sf::Sprite ship(shipTex);
    ship.setColor(sf::Color(255,255,255,255));
    ship.setOrigin(32, 32);
    ship.setScale(1.f/4.f, 1.f/4.f);
    ship.setPosition((float)window.getSize().x/2, (float)window.getSize().y/2);

    window.setVerticalSyncEnabled(true);
    window.setFramerateLimit(60);

    while (window.isOpen()){
        sf::Event event;
        while (window.pollEvent(event)){
            if(event.type == sf::Event::Closed){
                window.close();
            }
        }

        window.clear(sf::Color(127,63,31,255));
        window.draw(ship);
        window.display();

    }

    return 0;
}
 

Would be interesting to see which versions work and which don't.

9026
General / Re: Failed to Initialize GLEW. Missing GL version
« on: January 13, 2013, 03:44:31 pm »
I suppose I compiled the application with gcc when I was running it on VS or C::B because it worked perfectly fine when I did
Visual Studio has its own compiler, I'm not even sure if you'd be able to trick it into compiling with GCC.
But that doesn't answer my question on the version of MinGW and actually what version of QtCreator do you use?

it's the qt creator that's the problem, and I can't quite tell what, and I doubt I'll find out.
Well nobody else here seems to have run into the same problem and since it works with other IDEs, it seems just a like a setup-problem. We can't really help you further here, other than suggesting to freshly install the newest version of QtCreator and make sure you don't setup strange things. :D

I like C::B but it's not really suited for big projects, I used it at first but as the project grew I had to switch the IDE
I'm not sure why you'd conclude that...
C::B and QtCreator are quite similar and I don't see how one IDE would be way better at handling larger projects, I don't even understand what exactly the problem is... ;)

9027
General / Re: Failed to Initialize GLEW. Missing GL version
« on: January 13, 2013, 01:53:21 pm »
What version of MinGW does QtCreator ship with?
Have you ever tried to compile the application directly with GCC instead via the IDE?

I've never had problems with MinGW and SFML, so I don't really see where the problem is. Btw. there's also Code::Blocks if you don't want to work with VS. ;)

9028
General / AW: Re: Compiling SFML for VS2012
« on: January 13, 2013, 02:16:33 am »
The link seems to be broken. Can anyone please give me a new link?
Unoffical Nightly Builds ;)

9029
Graphics / AW: Re: RenderTextures and dynamic memory
« on: January 13, 2013, 02:14:16 am »
  • What you need for a complete and minimal example
  • What's a smart pointer, what does it do? How should I use it? And when?
  • Where can I find a more in-depth resource for learning C++? (Google could hardly help because I don't know enough to know what to search for.)
That's quite alright, everyone as to start somewhere. ;)

A minimal and complete example is a full progam that I can give my compiler and it will compile and run. It of course should also reproduce the problem. Your posted code is neatly complete, it just lacks the definition of the window and how you draw things to it. Addituonally everything should be wrapped into the main function.

Just google the term smart pointer in relation to C++ to get a better understanding of what it is.

SFML is a library that actually requires some basic knowledge in C++, you might still miss so of those basis. To really get into C++ there's no other way around than reading a good book. A list of good books can be found here.

In C++ unlike Java or PHP you don't instanciate classes only with new. You can simply create them on the application's stack, e.g.
sf::Texture tex;
tex.create(...);
// ...

9030
I've found small details of your build environment that don't make a difference to the actual building can completely break cmake, such as the afore mentioned having shell tools on a windows machine in the path.
I'm not sure how you've set things up, but CMake provides a different generator for the cases when the shell is included in the PATH, simply use MSYS Makefile (or similar).

I've had the same problems, though funny enough CMake went still ahead and generated a makefile for me, after pressing the configure button again. ;D

I'm not a huge fan of CMake myself, but for the moment being it's just the next best thing you can have. The sh-issue is strange and not very nice, but I guess applications always do have some requirements.
The actual problem lies with what Nexus said. If it tries to build a bridge between all the compilers, why do we have to specify everything differently for every OS, except the final stages?
On top of that, the dependencies tracking is non-existent, which makes building applications with quite a few dependencies extremely cumbersome.

Pages: 1 ... 600 601 [602] 603 604 ... 733
anything