Welcome, Guest. Please login or register. Did you miss your activation email?

Author Topic: Access violation when initializing sf::RenderWindow, but only in debug  (Read 2566 times)

0 Members and 1 Guest are viewing this topic.

Installation Warlock

  • Newbie
  • *
  • Posts: 2
    • View Profile
I'm a C++ noob, so please forgive my messy code, but every time I run this code (Game::start() is called immediately by main) I get an access violation error:

Exception thrown at 0x76F9F793 (ntdll.dll) in Game.exe: 0xC0000005: Access violation writing location 0x00000004.

The offending code seems to be this, at the top of Game.cpp:

sf::RenderWindow mainWindow;

Here's the rest of Game.cpp if you want to see it:

#include "Game.h"
#include "Splash.h"
#include "Entity.h"
#include "GameObject.h"
#include "SFML\Graphics.hpp"
#include <vector>


Game::GameState Game::gameState = Uninitialized;
sf::RenderWindow mainWindow;
void Game::start()
{

        if (gameState != Uninitialized)
                return;

        mainWindow.create(sf::VideoMode::getDesktopMode(), "Game", sf::Style::Fullscreen);
        gameState = Game::Splash;

        while (!isExiting())
        {
                gameLoop();
        }

        mainWindow.close();
}

bool Game::isExiting()
{
        if (gameState == Game::Exiting)
                return true;
        else
                return false;
}

std::vector<gameObject*> objects;

void Game::gameLoop()
{
        sf::Event event;
        while (mainWindow.pollEvent(event))
        {

                switch (gameState)
                {
                case Game::Playing:
                {

                        if (event.type == sf::Event::Closed)
                        {
                                gameState = Game::Exiting;
                        }
                        mainWindow.clear(sf::Color(0, 0, 0));
                        for (int i = 0; i < objects.size(); i++)
                        {
                                if (objects[i] != nullptr)
                                    {
                                        objects[i]->tick();
                                        mainWindow.draw(*(objects[i]->getSprite()));
                                    }
                        }
                        mainWindow.display();
                        break;
                }
                case Game::Splash:
                {
                        SplashScreen splash;
                        splash.Show(mainWindow); //temporary splashscreen
                        gameState = Game::Playing;
                }
                }
        }
}


 

And here's Game.h:

#pragma once
#include "SFML/Window.hpp"
#include "SFML/Graphics.hpp"


class Game
{

public:

        enum GameState {
                Uninitialized, Splash, Paused,
                Menu, Playing, Exiting
        };
        static GameState gameState;
        //static sf::RenderWindow mainWindow;
        static void start();
protected:
        static bool isExiting();
        static void gameLoop();



};
 

As you can see in Game.h, my RenderWindow was originally a static member variable of the Game class, but with testing I found that the error still occured even when I tried instantiating a RenderWindow globally or locally inside of Game.cpp. What leads me to believe that it might not be a problem with the code, however, is that the error goes away when I switch configuration from debug to release. In release configuration, the program runs but just shows a black screen until closing, instead of displaying the splashscreen.

And I know the first thing you're thinking, so let me show you my additional dependencies list for both debug and release, in case I'm missing something, which I don't think I am.

Debug:
ws2_32.lib;ogg.lib;vorbis.lib;vorbisfile.lib;vorbisenc.lib;flac.lib;openal32.lib;gdi32.lib;winmm.lib;opengl32.lib;freetype.lib;jpeg.lib;sfml-main-d.lib;sfml-system-s-d.lib;sfml-network-s-d.lib;sfml-audio-s-d.lib;sfml-window-s-d.lib;sfml-graphics-s-d.lib

Release:
ws2_32.lib;ogg.lib;vorbis.lib;vorbisfile.lib;vorbisenc.lib;flac.lib;openal32.lib;gdi32.lib;winmm.lib;opengl32.lib;freetype.lib;jpeg.lib;sfml-main.lib;sfml-system-s.lib;sfml-network-s.lib;sfml-audio-s.lib;sfml-window-s.lib;sfml-graphics-s.lib

As you can see, I'm using the static libraries, and I did include the SFML_STATIC preprocessor definition.
I'm running Visual Studio 2015 with the appropriate 32-bit libraries. I've already re-downloaded SFML several times to make sure I wasn't missing anything. I'm truly stumped here, and I don't feel like it's a problem with the code itself, else it wouldn't be behaving differently in release than in debug.

I'll be happy to post more of my code if anybody considers it relevant.

Hapax

  • Hero Member
  • *****
  • Posts: 3379
  • My number of posts is shown in hexadecimal.
    • View Profile
    • Links
As a general rule, one should avoid fully global objects.
More specifically, with SFML, one must avoid fully global SFML objects so the code you provided should be considered illegal.
However, you mentioned you tried the render window being a locally but did you mean that you also tried it as a local member of a class (and did you try it without static)?
Selba Ward -SFML drawables
Cheese Map -Drawable Layered Tile Map
Kairos -Timing Library
Grambol
 *Hapaxia Links*

Installation Warlock

  • Newbie
  • *
  • Posts: 2
    • View Profile
Just as I suspected, it seems the problem was not the code itself. I created a new project in visual studio, imported all of the .cpp and .hpp files from the old project, re-entered the SFML project settings, and now it's working fine. Interestingly enough, the program seems to run just fine now in both debug and release configurations, and even with the RenderWindow stored globally, as it is in the example code I showed earlier. I'm still not sure exactly what was causing the problem, but I assume it was something in my project settings causing issues, because the very same code that gave me access violations earlier is now running without a hitch, and the only change made was the move to a new VS project.

Hapax

  • Hero Member
  • *****
  • Posts: 3379
  • My number of posts is shown in hexadecimal.
    • View Profile
    • Links
It could have been a mix of different SFML versions...

Still, you should still avoid SFML globals. (all globals really, but that's a different discussion).
Selba Ward -SFML drawables
Cheese Map -Drawable Layered Tile Map
Kairos -Timing Library
Grambol
 *Hapaxia Links*