Messages

16

Audio / open AL unexpected message

« on: May 15, 2016, 08:34:31 pm »

Hello,

I've recently come back to my project after about a month long break. Since then, i've started to recieve an error message in the console  - AL lib:: (EE) MMDevApiMsgProc: Unexpected message: 49385

However, the application still runs, but then after about 3-4 mins or so, the app crashes with "no symbol file loaded for openal32.dll" error.

At this point, the app is only streaming music, the dll is in the folder with the game, and as stated runs fine for about 5mins. The crash happens both when running through visual studio, and when running the compiled app.

in vs, it also says: Exception thrown at 0x00EA448D (openal32.dll) in Wetware.exe: 0xC0000005: Access violation writing location 0x0000BAC2. which to me looks like a null pointer error, but again, this doesnt make sense, as the music and dlls etc don't move and everything stays in scope.

game crashes even when there is no music playback.

17

General / Re: performance modulo versus nested for loop

« on: April 14, 2016, 02:34:27 am »

okay thanks guys, much appreciated. Great info! 

18

General / Re: Trouble using iterator for collision

« on: April 12, 2016, 06:13:26 pm »

with a vector instead of using an iterator i'd use a normal for loop. at which point it would just be erase(i).

 

for (int i = 0; i < skeletons.size(); i++)
       {
              if (mainCharacter->mSprite.getGlobalBounds().intersects(skeletons[i]->mSprite.getGlobalBounds()))
              {
                     /*skeletons->erase(skeletons->begin() + *it);*/
                     skeletons->erase(i);
              }
       }

I'm also not sure why you're using new to create the vector. look up RAII or just avoid using a pointer at all.

19

General / Re: isometric grid problems

« on: April 12, 2016, 05:43:53 am »

Okay, so changing the sprites scale so that they 64x64 made it so it is now seamless. problem solved. Also, this can be achieved by making the space between grid cells 16, as if the tile itself were only 16x16; This is better than scaling up perhaps, because scaling can make things look worse, if that bothers you. My current game has mouse zoom so it doesn't bother me too much

20

General / isometric grid problems

« on: April 12, 2016, 05:25:42 am »

hi, just as an aside to what i'm developing at the moment, I decided to try out using isometric perspective. Now to achieve this i made a minimal example:

sf::RenderWindow window;
        window.create(sf::VideoMode(800, 800), "test");
        window.setFramerateLimit(60);
        sf::View view;
        view.setCenter(100, 100);
        view.setSize(800, 800);
        resourceHolder res;
        std::vector<std::vector<std::unique_ptr<sf::Sprite>>> sprites;
        for (int i = 0; i < 10; i++)
        {
                std::vector<std::unique_ptr<sf::Sprite>> b;
                sprites.push_back(std::move(b));
                for (int j = 0; j < 10; j++)
                {
                        auto a = std::unique_ptr<sf::Sprite>(new sf::Sprite);
                        a->setTexture(res.getTexture("graphics/isoGrass.png"));
                        sf::Vector2f vec(i * 32, j * 32);
                        sf::Vector2f vec2(0, 0);
                        vec2.x = vec.x - vec.y;
                        vec2.y = (vec.y + vec.x) / 2;
                        a->setPosition(vec2);
                        sprites[i].push_back(std::move(a));
                }
        }
        while (window.isOpen())
        {
                sf::Event event;
                while (window.pollEvent(event))
                {
                        if (event.type == sf::Event::Closed)
                        {
                                window.close();
                        }
                }
                window.setView(view);
                window.clear(sf::Color::Black);
                for (int i = 0; i < sprites.size(); i++)
                {
                        for (int j = 0; j < sprites[i].size(); j++)
                        {
                                window.draw(*sprites[i][j]);
                        }
                }
                window.display();
        }

the code above gimes me https://www.dropbox.com/s/rmp168f094v5ug1/isoGrid.jpg?dl=0 which is a diamond shaped grid as one would hope and expect. However, you'll notice that the 'cubes' are spaced out and so the grid is full of holes. Here is the png of the 'cube' https://www.dropbox.com/s/z8v5y1vcdl48l1g/isoGrass.png?dl=0

The only thing I can think is that there is something wrong with the dimensions of my 'cubes', all the tutorials i've seen simply use the formular in the above code to convert the cartesian coordinates into isometric ones, and this is working, hence the diamond shaped grid.

Any help would be greatly appreciated - thanks for your time.

21

General / Re: performance modulo versus nested for loop

« on: April 12, 2016, 01:09:43 am »

okay thanks for the reply. Sure i'll use SO next time, I just don't enjoy being condescended to that extreme. The condescension on this site is much more bearable and constructive. Im using visual c++ visual studio 2015. I guess ill try and make a benchmark then, something i've yet to do, but should be a worth while learning experience. Thanks again, Exploiter!

22

General / performance modulo versus nested for loop

« on: April 12, 2016, 12:19:47 am »

Hi there, this is more of a general c++ question, but figured someone on here might have the experience to advise me.

Right, so i have a 2d vector of int tile ids. The vector contains 4,225 ints. In my map editor, I originally used a nested for loop to check through them and change them if a mouse click collided with the space they represent. Here's an example:

bool foundTarg = false;
for (int i = 0; i < tileset.size(); i++)
{
        for (int j = 0; j < tileset[i].size(); j++)
        {
                if (sf::FloatRect(i * 32, j * 32, 32, 32).contains(mouse))
                {
                        tileset[i][j] = tileId;
                        foundTarg = true;
                        break;
                }

        }
        if (foundTarg)
                break;
}

However, I had the following idea, and that was that, at least when the click was deep into the array, that using modulo would save performance by cutting out the nested for loop. So here is an example of the function i used instead:

int x = static_cast<int>(pos.x);
int y = static_cast<int>(pos.y);
int remainderX = x % 32;
int remainderY = y % 32;
sf::Vector2f newPos((x - remainderX) / 32, (y - remainderY) / 32);
return newPos;
 

any thoughts on which would be more performant? Like I said, it seems obvious to me that the modulo method would be faster if the vector element was further in. But I'm sure its making my fps drop more than iterating through the vectors, which doesn't make sense to me.

Thanks for your time and patience 

23

General / Re: alpha being drawn to render texture as black

« on: April 10, 2016, 09:48:21 am »

Thank you Laurent, I had just found out that using sf::BlendNone worked. I can only assume that using a transparent clear is more efficient?

thanks for your reply!

24

General / Re: alpha being drawn to render texture as black

« on: April 10, 2016, 08:57:17 am »

I've already come up with a new idea. I'm satrting to think that it is transparent, but because im clearing it first, the black from the clear is what is causing it to be opaque. I will see if i can fix that and come back and update this thread.

25

General / alpha being drawn to render texture as black

« on: April 10, 2016, 08:53:50 am »

Hello, I'm having issues at the moment, because I am trying to get layers working in my map editor. So basically I have a layer for the next height level and one for the ground, these are basically just vectors of tile numbers. These then get drawn to their own render texture allowing me to split the rendering so that i can render characters and other objects in between. i.e so a character is in a doorway rather than on top of it, etc.

however for some reason the alpha from my top layer is being rendered as black and is hiding the ground layer. I don't have these issues when using one render texture, but i would like them split up for the above reasons as well as for versatility. Here is a minimal example that produces the annomally:

sf::RenderWindow window;
        window.create(sf::VideoMode(400, 400), "test");
        window.setFramerateLimit(60);
        //initialise and load texture of tilesheet
        sf::Texture tileset;
        tileset.loadFromFile("graphics/tileSheet.png");

        //create sprite that uses the tilesheet as its texture
        sf::Sprite tileSprite(tileset);

        //create 2 render textures to act as layers, one for the ground, one for a higher level
        sf::RenderTexture tempTexture1;
        sf::RenderTexture tempTexture2;
        tempTexture1.create(400, 400);
        tempTexture2.create(400, 400);

        //create 2 sprites refering to the render textures
        sf::Sprite tempSprite1(tempTexture1.getTexture());
        sf::Sprite tempSprite2(tempTexture2.getTexture());
        //set texture rects so that one is positioned where tiles are in the tilesheet
        //the second is positioned where empty alpha tiles are for test purposes
        tempSprite1.setTextureRect(sf::IntRect(0, 0, 400, 400));
        tempSprite2.setTextureRect(sf::IntRect(0, 200, 400, 400));
        //set sprites location so the drawn layers will overlap
        tempSprite1.setPosition(0, 0);
        tempSprite2.setPosition(0, 0);
        //draw the sections of the tilesheet to the two different render textures
        tempTexture1.clear();
        tempTexture1.draw(tileSprite);
        tempTexture1.display();
        tempTexture2.clear();
        tempTexture2.draw(tileSprite);
        tempTexture2.display();
        while (window.isOpen())
        {
                sf::Event event;
                while (window.pollEvent(event))
                {
                        if(event.type == sf::Event::Closed)
                                window.close();
                }
                //draw the bottom layer and then the top
                window.clear();
                window.draw(tempSprite1);
                window.draw(tempSprite2);
                window.display();
        }
 

just to clarify, the tilesheet is only half full of tiles, so the second render texture has blank transparent tiles rendered to it.

Any help would be appreciated, pulling hair out etc etc :/

26

General / Re: Programming a billard game

« on: March 23, 2016, 08:57:24 pm »

When checking collisions against balls in a list, the main problem ive encountered with this approach is that the ball you are checking will always be in collision with itself, so the first thing to do is remove the ball you are checking from the list, then iterate through said list checking against the balls in the list, then when you've done that, put the ball back in the list.

27

General / Re: OpenGL: Version 0.0

« on: March 23, 2016, 07:12:18 pm »

Sounds more like some sort of driver error to me, try updating your graphics card drivers perhaps.

28

General / Re: sf::Window::draw

« on: March 22, 2016, 07:53:35 pm »

hmm, well yeah quadtrees will definitley help with collisions checking, and for rendering. dividing the map will definitely help, if only to reduce the size of the one big image at any given time. if you have all your enemies/bullets/etc on one spritesheet then you can also use vertex arrays for them, taking it down to effectively one draw call. So that would help too. Good luck with your implementations!

29

General / Re: sf::Window::draw

« on: March 22, 2016, 04:32:42 pm »

hmm, well to cheapen the drawing of say, floor/map tiles, you can use something called a vertex array: http://www.sfml-dev.org/tutorials/2.0/graphics-vertex-array.php, also do a google search for something called, quadtrees, they make it so you have to check less of your entites etc, by having your world subdivided into smaller areas, meaning less checks.

30

General / Re: Rotate against sprite

« on: March 22, 2016, 12:50:36 am »

This is how i rotate the player. In some situations you need to add or subtract 90 depending on what direction your sprite is facing. The only time you dont add or minus 90 is when your sprite texture faces towards the right, which is where 0 degrees is in sfml.

float angle = atan2(player.y - sprite.getPosition().y, player.x - sprite.getPosition().x);
        angle = ((angle * 180) / 3.14159265) + 90;
        {
                angle = 360 - (-angle);
        }

        sprite.setRotation(angle);
 

and for a bullet for example, use the above to rotate it towards it's target and then :

float x = sprite.getPosition().x;
float y = sprite.getPosition().y;
float xR = sin((sprite.getRotation()*3.14159265 / 180)) * speed;
float yR = cos((sprite.getRotation()*3.14159265 / 180))* -speed;
sprite.setPosition(x + xR * dt, y + yR * dt);
 

to move towards the direction it's rotated towards. As for the bullets not hitting, either make them travel faster, or perhaps make sure that bullets and turrets update before the enemies otherwise the angle will usually be behind where the enemies are unless they are walking directly away from the turret. You could also try and base the turrets firing angle based on where the enemy will be before they're there, i.e a step ahead of them.