Hot answers tagged

20

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.


9

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


9

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


9

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


8

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


8

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


7

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


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

SDL_Window win; will not compile. SDL_Window is a so-called opaque struct. Somewhere in SDL headers, it's declared as struct SDL_Window; or something similar (without the body, as opposed to struct SDL_Window {...};). Since you don't know what members are inside, or even how large the struct is, you can't create an instance of it. Somewhere inside of SDL ...


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

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. Rendering: ...


6

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.


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


6

First of all, you don't have breaks in your switch statement, that means that if your random number is for example 1, after subtracting the speed value from the position, the program will keep running inside the switch statement executing the case 2 and 3, so the case 3 will be always executed, making the object move to the bottom and the case 1 will be more ...


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

As SDL2 is but a wrapper over the graphics API (OpenGL or DirectX), out-of-view triangles will be culled by the GPU before reaching the rasterizer. As GPU's have hardwired or heavily optimized triangle culling, my guess is that the GPU will be faster than the CPU to do it. But ! The CPU/GPU bandwidth comes into play. The GPU may well be a triangle munching ...


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

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.


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

Your question needs re-phrasing. SDL and OPENGL are two different technologies so to speak. Also, this question will lead to opinions instead of facts Wikipedia says: Simple DirectMedia Layer (SDL) is a cross-platform software development library designed to provide a low level hardware abstraction layer to computer multimedia hardware components. Open ...


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

SDL_SetHint(SDL_HINT_RENDER_SCALE_QUALITY, "0"); needs to happen before texture creation. This is because interpolation mode is a property of created textures, not the rendering pipeline.


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