Hot answers tagged

17

The short answer: Using one big texture atlas will probably be faster and should definitely not be slower than multiple small textures and here is why: After taking a look at the SDL source code i can see that SDL supports a bunch of renderers (OpenGL, Gles2, Psp, D3D ...) and (except the software one) all of them are implemented in the same fashion: 1:...


10

Yes, it does make sense. As you said it will make less load on the system, which is good for thermals, and other applications. However.... Your games logic should NOT depend on the updates per second. Therefore I recommebd you to take a look at deltatime, which will make your game independent of the updates per second. I recommend you to take a look at ...


10

An alternative way (Josh's approach is great too!) would be to setup an boolean on SDL_KEYDOWN, and possibly also ignoring all repeated key events. That you can do by checking the repeat member of the key event. Then you could implement your own timer, which doesn't have to be anything fancy, and implement key repetition your self. You could either trigger ...


10

From the SDL Docs: SDL_WINDOW_FULLSCREEN_DESKTOP for "fake" fullscreen that takes the size of the desktop This sounds like what other games call Borderless Mode, Borderless Windowed Mode, or similar. I'm sure, gamers will understand these terms.


8

Another (albeit a little more complicated) thing you could do is have your components register for specific event types: class EventHandler { public: using EventCallback = std::function<void(SDL_Event const&)>; void register(SDL_EventType type, EventCallback callback) { _registeredCallbacks[type].push_back(callback); } void ...


7

My guess is you're trying to implement a camera, and should not be using SDL Viewports. The viewports are for UI elements like menus, minimaps, etc. It's a way of dividing up the screen into multiple areas. To implement a camera, you will want to think about coordinate systems. The world coordinates are the positions in the world, without thinking about the ...


7

To create smooth movement you need 4 things: The position of the character The velocity of the character The acceleration of the character The max speed of the character When the user presses the movement keys you need to set the acceleration of the player to the movement acceleration. When the user releases the key you need to set the acceleration to 0. ...


7

All right, so this is an interesting topic. As per this forum topic, this isn't natively supported by SDL. However, with some minor tinkering I was able to setup a quick and dirty demo that loads a texture just once, for one rendering. I'll go through my setup step by step. Do note that you probably want to change most of the hardcoded stuff (such as the ...


6

When you run your while loop in each of your HandleInput functions, you're burning through the entire event queue up to that moment in time. So yes, whichever event handler you call first will eat all of the events. There are a few ways to handle this problem, but obviously, paramount to every possible solution, is the removal of your destructive ...


6

In SDL2 the creation of the window is separate from the rendering environment used to draw into that window. So, while you might pass "SDL_WINDOW_OPENGL" to SDL_CreateWindow(), this simply states that the window should support rendering from an OpenGL context later down the line and doesn't actually create an OpenGL context at that point. So, from ...


6

Creating a texture with the pixel format SDL_PIXELFORMAT_RGBA8888 was the error here. This format might be different from the one used on the GPU, and the texture had to be converted each frame. I found that using SDL_PIXELFORMAT_ARGB8888 instead completely solved this issue, and uploading the texture is now instant. Although the documentation says that ...


6

The best answer is: It depends. You don't have to limit neither one Updates: If your updates are not bound to an upper limit, then game logic should be dependent on a delta time amount, to avoid running the game faster or slower depending on the machine where it is run. This is a very common approach used by many games, but it is not the only one. ...


6

Yes, in the situation you describe, you want to use SDL_RenderSetLogicalSize(). The function takes in the width and height of the logical viewport, which in your case is the resolution you want to program your game logic in. You would call SDL_RenderSetLogicalSize(renderer, 320, 240);, and after that you don't need to worry about resolution scaling. SDL ...


6

SDL2's "texture" rendering API is designed for accelerated graphics in mind; this is where you upload textures to your graphics hardware beforehand, and then render that texture by referring to it. This is why textures are write-only, and can only be written to if: the texture was created with the SDL_TEXTUREACCESS_STREAMING flag you lock the texture ...


5

I found SDL_UpdateTexture to be the slowdown. The SDL documentation for SDL_UpdateTexture explicitly says in the Remarks section that it is a slow function and only meant for static texture uploads. I heard of SDL_LockTexture but I don't think I should be using it for write-only operations. The documentation for SDL_LockTexture explicitly says in the ...


5

Getting the window handle from an SDL window is pretty straightforward: SDL_SysWMinfo systemInfo; SDL_VERSION(&systemInfo.version); SDL_GetWindowWMInfo(window, &systemInfo); HWND handle = systemInfo.info.win.window;


5

So it seems I was missing this in my Game class, which makes sense: SDL_SetHint( SDL_HINT_RENDER_SCALE_QUALITY, "1" ); https://wiki.libsdl.org/SDL_HINT_RENDER_SCALE_QUALITY


5

In SDL 2, you must set the scaling interpolation algorithm for the whole renderer, using SDL_SetHint (SDL_HINT_RENDER_SCALE_QUALITY, Value); where Value should be, in your case (pixel art) 0. 1 means linear interpolation, and 2 is anistropic (only supported if the app runs on D3D/Windows) (documentation) As far as saying itself is concerned, you can do it ...


5

It means that all existing textures are freed. I checked the SDL source and inside the SDL_DestroyRenderer function they do this: while (renderer->textures) { SDL_DestroyTexture(renderer->textures); } So every texture that was created with the renderer gets destroyed.


5

There is a code smell here: Sprite* Graphics::GetSprite(std::string spriteID) { std::map<std::string,Sprite*>::iterator it; it = sprites.find("Square"); return it->second; } By not making sure that the object is valid, the it could be sprites.end(). According to some documentation, it's very dangerous to dereference the end() iterator. ...


5

You're shooting yourself in the foot: for (unsigned int i = 0; i < BULLET_ARRAY.size(); i++) { if (BULLET_ARRAY.size() > 0) { if ( BULLET_ARRAY[i]->getX() <= 0 - BULLET_ARRAY[i]->getW() || BULLET_ARRAY[i]->getX() >= WINDOW_WIDTH) { BULLET_ARRAY.erase(BULLET_ARRAY.begin() + i); } } BULLET_ARRAY[i]->...


5

SDL uses a type called SDL_RWops for this purpose. This is essentially a wrapper around a stream. When you call a function like IMG_Load(filename) it is just a small wrapper around IMG_Load_RW(ops) which constructs the ops using SDL_RWFromFile. You can create an SDL_RWops yourself (it's just a struct with some function pointers) if you have a custom stream ...


5

The problem with per-pixel collision detection is that 1. it can be very slow and 2. your graphic design can have a lot more impact on your game mechanics than you would like. It is usually better to try to approximate the collision zones of the objects in your game with simple geometrical shapes. The last time I made a game with an isometric perspective, I ...


5

You're not checking the return value of SDL_PollEvent to see if there's a new event, which means that regardless of whether there is an event to handle, you're trying to handle one. In practice, this means that you're constantly handling the last event, even if it's no longer occurring. Try this: SDL_Event e; if (SDL_PollEvent(&e)) { switch (e.type) ...


5

Your event loop looks ill-formed, as it will only process one event per frame. Here's what it probably should look like: SDL_Event e; while (SDL_PollEvent(&e)) { if (e.type == SDL_QUIT) run = false; } And then change your mainloop to depend on run.


4

Store the keys from the last frame and compare in the current frame. if(!old_keys[key] && keys[key]) { /* pressed since last frame */ } if(old_keys[key] && !keys[key]) { /* released since last frame */ } if(old_keys[key] && keys[key]) { /* held since last frame */ }


4

You are checking how many bytes there are per pixel, but you are not checking how colours are ordered, and it could be RGBA or BGRA (or possibly something else). You need something like this instead of mode = GL_RGBA (little-endian machines): if (surface->format->Rmask == 0x000000ff) mode = GL_RGBA; else mode = GL_BGRA; If you want a more ...


4

Take a look at Awesomium. I have integrated it to SDL before and the process was fast. The biggest thing you have to deal with is translating SDL events to Awesomium. Otherwise the rendering is really easy, you can just query pixel data from Awesomium into an SDL surface IIRC, and then render that to your game.


4

This is the data I could gather from a quick glimpse at the SDL's source code. Firstly, the renderer stores the driver data, and the maximum texture size depends on the driver/GPU, so firstly in SDL_CreateTexture the code makes sure that the wanted texture isn't too big. Then the code splits into platform/rendering API specific code. As Alexandre ...


Only top voted, non community-wiki answers of a minimum length are eligible