Messages

1

Graphics / Re: Is it possible to 'lower' sprite LOD before drawing

« on: May 19, 2014, 02:28:45 am »

Well, it's not in the millions. Thanks for the help

2

Graphics / Re: Is it possible to 'lower' sprite LOD before drawing

« on: May 18, 2014, 11:04:04 pm »

Yes. You can find a trade-off between texture size and number of draw calls. Even if you end up with a dozen vertex arrays, that's still nothing.

Out of curiosity: how many objects are visible at the same time? And you do manually exclude the invisible ones, don't you?

There isn't a set number of objects appearing on the screen at the same time. And of course I do, I'm using a quadtree

I'm not that clueless 

3

Graphics / Re: Is it possible to 'lower' sprite LOD before drawing

« on: May 18, 2014, 10:19:20 pm »

Using a vertex array like this would require that all of the spirtes share a common texture, correct?

What if, by condensing everything into a single tile sheet, the texture ended up really really big? Wouldn't that be bad?

4

Graphics / Is it possible to 'lower' sprite LOD before drawing

« on: May 18, 2014, 09:03:59 pm »

Disclaimer: I don't really know what I'm talking about

When I zoom my sf::View outwards, more sprites are drawn and subsequently the fps drops like an anvil. Is it possible for me to set my sprites to draw at a 'lower' level of detail, speeding up the process of drawing everything?

Thanks

EDIT: Would mipmapping be the only solution?

5

Graphics / Re: Vsync causing strange jitter effect (SFML 2.0)

« on: April 30, 2014, 04:17:40 am »

I'm bumping this because this issue exists in 2.1 as well, and is really irritating

6

General / Re: My timestep code isn't working, completely baffled

« on: April 15, 2014, 07:52:47 pm »

You guys are toxic as hell.

I told him how to improve his style/code. There's a reason why i splitted it from the other points, because the three others are definitly bad style. It's looking way better if keys&events are seperated from other calculations(my opinion). You can't and shouldn't flame me for what I prefer. If you don't like it, you can give your opinion and stay calm.

You went off on an unrelated tangent.

If someone asked for advice on how to study for an exam, do you tell him to buy a new pair of shoes?

You came off as very condescending, which I did not appreciate.

Now can everyone relax and just help me out? If I wanted a flamewar I'd have gone onto some chan website.

7

General / Re: My timestep code isn't working, completely baffled

« on: April 15, 2014, 07:37:36 pm »

If it's running on a lower fps than 60 you've done something wrong in resource-handling.

Ok I think you need to relax

This is a simple example. Simple. I wrote this example and made sure to use the same timestep code that was in my project. Why? Because I wanted to ask people on this forum why my timestep code isn't working properly, and I didn't want to boggle them down with about 14,000 lines of source code. If you want 14,000 lines of source code to look at be my guest.

Because this example is simple, it will always run at a high framerate. However, my project is a lot more sophisticated, and I cannot guarantee that lower end machines will be able to run it at a constant 60 frames per second.

Do you understand? Now please cut the snarky attitude, it's embarrassing.

Anyway.. You can still make your life easier. Just store a clock.restart() to passedTime each frame and multiply your 1.0f * passedTime .
If I still didn't unterstood what you want to know, I'm done.

I know, and I explained in the opening post that I wanted to avoid multiplying a lot of my physics by deltaTime. It results in cluttering.

Of course, since this is a simple example, multiplying the move values by deltaTime is no big deal. However, as I've mentioned, my project is a lot more sophisticated than this.

8

General / Re: My timestep code isn't working, completely baffled

« on: April 15, 2014, 07:23:13 pm »

Can someone or you explain, why you need this?
With a fps-limit of 60 it's moving smoothly, too.

You can't assume that your game will run at that consistent framerate on every computer. It's a rookie mistake.

Also, I didn't create this thread to learn about proper programming practice. This is a simple example I whipped up that uses similar timestep code found in my project. Don't derail the topic, please.

9

General / My timestep code isn't working, completely baffled

« on: April 15, 2014, 06:53:36 pm »

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

static const int FRAME_LIMIT = 120;

bool WINDOW_FOCUS = true;

const sf::Time TICK_INTERVAL = sf::seconds(1.0f / FRAME_LIMIT);

int main()
{
    // Create the main rendering window
    sf::RenderWindow window(sf::VideoMode(768, 768), "SFML works!");
    sf::RectangleShape Rectangle;

    Rectangle.setSize(sf::Vector2f(300, 300));
    Rectangle.setPosition(150, 150);
    Rectangle.setFillColor(sf::Color::Blue);
    Rectangle.setOutlineThickness(1.0f);
    Rectangle.setOutlineColor(sf::Color::White);

    sf::Clock clock;
    sf::Time accumulatedTime;

    clock.restart();

    //Yes, I've tried commenting out the following line. Nothing changed
    window.setFramerateLimit(FRAME_LIMIT);
   
    //LOOP UNTIL YOU DONT WANT IT TO
    while (window.isOpen())
    {
       
      //WINDOW EVENTS (ignore this)
      sf::Event event;
      while (window.pollEvent(event))
      {
        if (event.type == sf::Event::Closed)
          window.close();
      }
     
      //TIME CALCULATIONS
      accumulatedTime += clock.restart();//.asMilliseconds();
     
      //PHYSICS CODE
      while(accumulatedTime >= TICK_INTERVAL)
      {
        accumulatedTime -= TICK_INTERVAL;
        if (sf::Keyboard::isKeyPressed(sf::Keyboard::A))
        {
          // left key is pressed: move our character
          Rectangle.move(-0.1f, 0);
        }
        else if (sf::Keyboard::isKeyPressed(sf::Keyboard::D))
        {
          Rectangle.move(0.1f, 0);
        }

        if (sf::Keyboard::isKeyPressed(sf::Keyboard::W))
        {
          // left key is pressed: move our character
          Rectangle.move(0, -0.1f);
        }
        else if (sf::Keyboard::isKeyPressed(sf::Keyboard::S))
        {
          Rectangle.move(0, 0.1f);
        }
      }
     
      //DRAWING
      window.clear();
      window.draw(Rectangle);
      window.display();
    }

    return EXIT_SUCCESS;
}
 

With this code, the rectangle's movements are very choppy. I really don't know what I'm doing wrong. I tried the other way (multiplying rectangle move value by deltaTime) and the movement was awesome! Smooth! Pleasant to look at! However, multiplying by deltaTime all the time is tedious and annoying.

I would love some help.

10

General / Re: A way to cobble sprites?

« on: April 13, 2014, 03:04:06 am »

I'm looking around some more, sf::RenderTexture may be what I need actually.

Yeah this is the solution I would go for

On loading the map, draw each tile once to a separate RenderTexture, then on each frame redraw this prepared RenderTexture to the window