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

Pages: [1] 2
1
General / Re: Failing to make with MinGW
« on: March 02, 2014, 08:09:37 pm »
I think there should be a mingw32-make in C:\MinGW\bin (at me there is)... are you sure that you installed MinGW correctly? Note that MSYS and MinGW are not the same.

But since you say the very same make.exe works for other projects, you probably did something wrong with the CMake configuration of SFML. Delete everything SFML-related, clone the latest version of the Git repository and try that one again.

I don't know what exactly happened.

I had been trying this whole time to find mingw32-make, but it just didn't seem to exist. I couldn't find the package containing it in the MinGW Get program either...until just now. Got it installed. Don't know why it wasn't automatically installed as a part of the mingw-base package though.

Well, I downloaded 2.1 (I prefer the stable release over the most recent Git version), and tried it again with mingw32-make, and it seems to be working fine. I don't know what the issue was with the MSYS make program... I suppose it is worth noting that the other projects I'd built with make.exe didn't use CMake, they either came with Makefiles or used a custom Configure command. Didn't expect that to be the problem, but maybe it was.

2
General / Failing to make with MinGW
« on: March 02, 2014, 03:20:35 am »
I don't know if there's a better place to put this question, looks like they got rid of the Compiler and IDE-Related forum. I guess if there's a better place it'll be moved.

I've been finding myself unable to compile SFML 2.0 on Windows using MinGW.  I used the CMake GUI to generate a makefile for MinGW. Since there's no mingw32-make in C:\MinGW\bin, I tried building it using the MSYS make command, both from the command line and the MSYS terminal. When I call it from the Windows command line, I simply see:

C:\Data\Programming\SFML\Win64>make.exe
Microsoft Windows [Version 6.3.9600]
(c) 2013 Microsoft Corporation. All rights reserved.

C:\Data\Programming\SFML\Win64>

Which I recognize as the line printed at the top of the prompt when I first open it. It's worth noting that the title of the console window becomes "Command Prompt - make.exe", as if the output is from make. If I try it from the MSYS terminal, I see the same printout, plus the terminal is converted to a Window cmd prompt:

User@Redacted /c/Data/Programming/SFML\Win64
$ make
Microsoft Windows [Version 6.3.9600]
(c) 2013 Microsoft Corporation. All rights reserved.

C:\Data\Programming\SFML\Win64>

I'm using the most recent MinGW build (new laptop, so I just downloading the mingw-get installer), on a Windows 8.1 laptop. I have been able to use make (i.e. the same exact executable in the same ways) to build other projects, so it's not just my installation. I've tried regenerating my makefile, to no avail. I'm not particularly good at reading Makefiles, but it looks like there's nothing wrong with the generation.

Any help would be appreciated. If you need more information, I'd be willing to provide it.

3
Graphics / Re: sf::Image destructor causes SIGABRT crash
« on: October 25, 2013, 04:12:53 am »
It's strange that it doesn't require a const. I never use a const_cast unless a compile error needs me to. But you are right, it's a const GLvoid*, so the const_cast is unnecessary. I corrected that, and it does still work. Thank you all for your help.

4
Graphics / Re: sf::Image destructor causes SIGABRT crash
« on: October 24, 2013, 08:15:13 pm »
And as binary1248 mentioned, don't use const_cast unless you're absolutely sure what you're doing. It is almost only necessary when you interact with code that is not const-correct, i.e. bad code.

I'm uncertain how else I'm supposed to approach this: glTexImage2D requires an unsigned char*, but getPixelsPtr() returns a const unsigned char*, and the two are not interchangeable -- trying to pass the return value of getPixelsPtr() directly to glTexImage2D without the cast results in an error. I'm probably going about this wrong, or otherwise not seeing something obvious, but I'm unsure what else I should do here.

5
Graphics / Re: sf::Image destructor causes SIGABRT crash
« on: October 24, 2013, 08:13:01 pm »
unsigned char* image = const_cast<unsigned char*>(images.at(i).getPixelsPtr());
...
free(image); //Clear our temporary image data
What the... never ever use free in your own C++ code. Here you kind of asked for it by doing something really dumb. The pointer returned from getPixelsPtr() is const for a reason. If you cast away the constness, and free the memory allocated by the underlying object yourself, you can't complain you get all sorts of undefined behaviour. In this case, it results in a double free when the sf::Image destructors are called.

Rule #1 of C dynamic memory management: For every malloc() there must be a free(), and vice versa.

Ah, wow. I'd love to chalk that one up to a lack of sleep or something like that, but all I can really say is that I just pretty well screwed that up. But I understand my problem at least.

Anyway, I removed the call to free(), and that solved the problem. Behavior's now as expected. Thank you for the help.

6
Graphics / sf::Image destructor causes SIGABRT crash
« on: October 24, 2013, 07:36:35 pm »
Hello all! I'm trying to create a Skybox object, which when loaded loads a single image file and splits it into 5 or 6 (depending on if there's a bottom image) sf::Image objects, represented as a std::vector<sf::Image>. I then pass the image data (from image.getPixelsPtr() ) to glTexImage2D and call a number of other OpenGL functions to set up my textures for rendering.

My issue comes at the end of my function: when the vector is cleared off the stack, it results in a crash dump to stderr and then a SIGABRT crash. If I run it in my debugger, it becomes apparent it's resulting from in the sf::Image destructor. Here's my code (with some irrelevant portions removed):

bool Skybox::loadSkybox() {
    glGenTextures(6, ids);

    //Loads the image file, then splits into 5-6 images using sf::Image::copy, returning vector of images
    //returns a list of skybox images, in order: Top, Bottom?, Left, Right, Front, Back
    const std::vector<sf::Image> images = Image->getAsSkybox();
    if (images.empty() || images.at(0).getSize().x == 0) //Empty list or empty images is an error with loading
        return false;

    for (unsigned int i = 0; i < images.size(); i++) {

        glBindTexture(GL_TEXTURE_2D, ids[i]);

        GLuint width = images.at(i).getSize().x, height = images.at(i).getSize().y;
        unsigned char* image = const_cast<unsigned char*>(images.at(i).getPixelsPtr());
        if (image == NULL || width <= 0 || height <= 0) {
            std::err << "Error loading image file." << std::endl;
            glDeleteTextures(6, ids);
            return false;
        }

        glTexImage2D(GL_TEXTURE_2D, 0, GL_COMPRESSED_RGBA, width, height, 0, GL_RGBA, GL_UNSIGNED_BYTE, image);

        GLenum err;
        if ((err = glGetError()) != GL_NO_ERROR) {
            std::err << "OpenGL error in loading image number " << i << ": " << gluErrorString(err) << std::endl;
            glDeleteTextures(6, ids);
            return false;
        }

        //Call other OpenGL functions to set it up

        free(image); //Clear our temporary image data
    }

    return true;
}

I'm using SFML2,  Code::Blocks for my IDE and GCC 4.6 on a 32-bit on an Ubuntu 12.04 LTS environment.

7
Network / Packets getting changed
« on: August 31, 2012, 06:43:59 am »
I have an application which updates itself through a TCP connection to a server application. This works perfectly fine, except for one specific packet transmission, in which the packet is somehow changed. The server sends a packet containing the number 1:

pack << sf::Uint8(1);
ClientSocket.Send(pack);

(Where `pack` is of type sf::Packet and `ClientSocket` is of type sf::SocketTCP)

Stepping through with my debugger does in fact confirm that these lines are executed, and that the next Receive call in my client is the next few lines:

sock.Receive(pack);
sf::Uint8 conf;
pack >> conf;

(Where `pack` is once again an sf::Packet, and `sock` is a SocketTCP)

However, somehow in my client, conf is showing up as having a value of zero (my debugger confirms this) and it acts as so (the next line switches depending on the value). I am running both applications on the same machine, and they are both reading each other as "127.0.0.1", so the packets (if I understand correctly) aren't going through my router, or really ever leaving my machine. Any ideas on why my packets are being corrupted?

8
Window / OpenGL not rendering
« on: August 03, 2011, 04:34:09 am »
Quote from: "Laurent"
Have you tried the Window or OpenGL examples provided with the SFML SDK?


Yes, both of them work just fine, which confuses me greatly.

9
Window / OpenGL not rendering
« on: August 02, 2011, 06:17:24 pm »
Quote from: "Laurent"
Are you sure that your cube is not too big compared to the projection and modelview matrices that you use? If you change the ambient color to something else than white, does it change the output?


I tried changing the cube to be half the size. Same output. I made the ambient colour [0.2, 0.6, 0.9] (random colour I came up with), same output. You can see the output below:


10
Window / OpenGL not rendering
« on: August 02, 2011, 05:53:10 am »
I hate to bump a thread like this, but I seem to still be having this trouble. I created a smaller sample for you which may help, as it only uses SFML and OpenGL, removing wxWidgets from it entirely. It is a truly minimal sample. This is it:

Code: [Select]
#include <SFML/Graphics.hpp>
#include <iostream>

using namespace std;

bool initialised = false;

sf::RenderWindow App;

void setup() {
    cout << "Setting up rendering context." << endl;
    cout << "OpenGL vendor: " << glGetString(GL_VENDOR) << endl;
    cout << "OpenGL renderer: " << glGetString(GL_RENDERER) << endl;
    cout << "OpenGL version: " << glGetString(GL_VERSION) << endl;
    App.PreserveOpenGLStates(true);
    GLfloat ambient[] = {1.0f, 1.0f, 1.0f, 1.0f};
    glLightModelfv(GL_LIGHT_MODEL_AMBIENT, ambient);
    App.SetActive(true);
    initialised = true;
}

void changeSize(GLfloat w, GLfloat h) {
    if (initialised) {
        GLfloat fAspect;

        // Prevent a divide by zero, when window is too short
        // (you cant make a window of zero width).
        if(h == 0)
            h = 1;

        glViewport(0, 0, w, h);

        fAspect = (GLfloat)w / (GLfloat)h;

        // Reset the coordinate system before modifying
        glMatrixMode(GL_PROJECTION);
        glLoadIdentity();

        // Set the clipping volume
        gluPerspective(35.0f, fAspect, 1.0f, 50.0f);

        glMatrixMode(GL_MODELVIEW);
        glLoadIdentity();
    }
}

void render() {
    // Clear the window with current clearing color
    glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT);

    glLoadIdentity();
    glTranslatef(0.0f, 0.0f, -200.0f);

    glBegin(GL_QUADS);
        glColor3f(0.1f, 1.0f, 0.1f);

        glVertex3f(100.0f, -100.0f, 100.0f);
        glNormal3f(100.0f, -101.0f, 100.0f);

        glVertex3f(100.0f, -100.0f, -100.0f);
        glNormal3f(100.0f, -101.0f, -100.0f);

        glVertex3f(-100.0f, -100.0f, -100.0f);
        glNormal3f(-100.0f, -101.0f, -100.0f);

        glVertex3f(-100.0f, -100.0f, 100.0f);
        glNormal3f(-100.0f, -101.0f, 100.0f);

        glVertex3f(-100.0f, 100.0f, 100.0f);
        glNormal3f(-100.0f, 101.0f, 100.0f);

        glVertex3f(-100.0f, 100.0f, -100.0f);
        glNormal3f(-100.0f, 101.0f, -100.0f);

        glVertex3f(100.0f, 100.0f, -100.0f);
        glNormal3f(100.0f, 101.0f, -100.0f);

        glVertex3f(100.0f, 100.0f, 100.0f);
        glNormal3f(100.0f, 101.0f, 100.0f);
    glEnd();

    glFlush();
}

int main()
{
    // Create the main window
    App.Create(sf::VideoMode(800, 600), "SFML window");

    setup();

// Start the game loop
    while (App.IsOpened())
    {
        // Process events
        sf::Event Event;
        while (App.GetEvent(Event))
        {
            // Close window : exit
            if (Event.Type == sf::Event::Closed)
                App.Close();

            if (Event.Type == sf::Event::Resized)
                changeSize(Event.Size.Width, Event.Size.Height);
        }

        // Clear screen
        App.Clear();

        render();

        // Update the window
        App.Display();
    }

    return EXIT_SUCCESS;
}


It still displays no more than a blank screen, and I cannot determine why. Please, any explanation is greatly appreciated, let alone help. I just want to get this working.

11
Window / OpenGL not rendering
« on: June 21, 2011, 06:59:48 pm »
Quote from: "Waterlimon"
Umm... Try making the camera spin to see if the box appears anywhere in the scene? ._.


Okay, I'll to to get at least basic camera movement implemented here, and then I'll try that. Thanks.

No, I'm afraid that didn't work. :? Any other advice? I really appreciate the effort. I don't know why a normal OpenGL sample and a wxWidgets sample would work fine but my code doesn't...

12
Window / OpenGL not rendering
« on: June 20, 2011, 05:46:26 pm »
Quote from: "Nexus"
Sorry that I can't contribute something to the actual topic, but I think nobody has answered because of two reasons: Few people in this forum are familiar with wxWidgets, and your code is rather big and not really minimal. Have you already tried a very simple OpenGL or an SFML rendering example?


Yes, both the wxWidgets sample and the OpenGL sample provided with the full SFML SDK work fine.

13
Window / OpenGL not rendering
« on: June 19, 2011, 12:08:37 am »
I'd still really, really appreciate if I could get some help with this. If there is any information you need me to supply, I would be more than willing to do so. It just doesn't make any sense to me at all.

14
Window / OpenGL not rendering
« on: June 05, 2011, 03:59:22 am »
I could really use some help with this, please. This is like the one major bug I have left with this project, and I can't see any reason why this would be happening...

15
Window / OpenGL not rendering
« on: June 03, 2011, 05:48:47 am »
Yes, this part is basically the wxWidgets-SFML sample, except I changed the resize and rendering functions and added a setup one. The problem is that the clear colour is appearing properly, but then the actual model itself isn't appearing, leaving just a black window.

Pages: [1] 2