• Advertisement
  • Popular Tags

  • Popular Now

  • Advertisement
  • Similar Content

    • By Kjell Andersson
      Spectral rendering enters the computer graphics world. After a period with not that many feature improvements, Dual Heights Software have now finally released a new major version of their water texture generator software called Caustics Generator. The new version includes full spectrum color rendering allowing the simulation of spectral refraction which produces prismatic coloring effects and thus bringing caustics simulation to a new level. The spectral functionality is available in the Pro version on both Windows, Mac and Linux.
      Read more about the Caustics Generator at https://www.dualheights.se/caustics/
       

      View full story
    • By Kjell Andersson
      Spectral rendering enters the computer graphics world. After a period with not that many feature improvements, Dual Heights Software have now finally released a new major version of their water texture generator software called Caustics Generator. The new version includes full spectrum color rendering allowing the simulation of spectral refraction which produces prismatic coloring effects and thus bringing caustics simulation to a new level. The spectral functionality is available in the Pro version on both Windows, Mac and Linux.
      Read more about the Caustics Generator at https://www.dualheights.se/caustics/
       
    • By Myopic Rhino

      Introduction
      If you've been looking into terrain texturing techniques, you've probably heard about texture splatting. The term was coined by Charles Bloom, who discussed it at http://www.cbloom.com/3d/techdocs/splatting.txt. With no disrespect to Charles Bloom, it was not the most clear or concise of articles, and has left many confused in its wake. While many use and recommend it, few have taken the time to adequately explain it. I hope to clear up the mystery surrounding it and demonstrate how to implement it in your own terrain engine.
      The Basics
      What is texture splatting? In its simplest form, it is a way to blend textures together on a surface using alphamaps.

      I will use the term alphamap to refer to a grayscale image residing in a single channel of a texture. It can be any channel - alpha, red, green, blue, or even luminance. In texture splatting, it will be used to control how much of a texture appears at a given location. This is done by a simple multiplication, alphamap * texture. If the value of a texel in the alphamap is 1, that texture will appear there in full value; if the value of a texel in the alphamap is 0, that texture will not appear there at all.

      For terrain, the texture might be grass, dirt, rock, snow, or any other type of terrain you can think of. Bloom refers to a texture and its corresponding alphamap as a splat. An analogy would be throwing a glob of paint at a canvas. The splat is wherever you see that glob. Multiple globs of paint layered on top of each other create the final picture.

      Let's say you have a 128x128 heightmap terrain, divided into 32x32 chunks. Each chunk would then be made up of 33x33 vertices. Each chunk has the base textures repeated several times over it - but the alphamap is stretched over the entire area. (0, 0) of the chunk would have alphamap coordinates of (0, 0) and texture coordinates of (0, 0). (33, 33) of the chunk would have alphamap coordinates of (1, 1) and texture coordinates of (x, x), where x is the number of times you want the textures to be repeated. x will depend on the resolution of the textures. Try to make sure they repeat enough to make detail up close, but not so much that the repetition is obvious from far away.

      The resolution of your alphamap per chunk is something you need to decide for yourself, but I recommend powers of two. For a 32x32 chunk, you could have a 32x32 alphamap (one texel per unit), a 64x64 alphamap (two texels per unit), or even a 128x128 alphamap (four texels per unit). When deciding what resolution to use, remember that you need an alphamap for every texture that appears on a given chunk. The higher the resolution is, the more control over the blending you have, at the cost of memory.

      The size of the chunk is a little trickier to decide. Too small and you will have too many state changes and draw calls, too large and the alphamaps may contain mostly empty space. For example, if you decided to create an alphamap with 1 texel per unit with a chunk size of 128x128, but the alphamap only has non-zero values in one small 4x4 region, 124x124 of your alphamap is wasted memory. If your chunk size was 32x32, only 28x28 would be wasted. This brings up a point: if a given texture does not appear at all over a given chunk, don't give that chunk an alphamap for that texture.

      The reason the terrain is divided into chunks is now apparent. Firstly, and most importantly, it can save video memory, and lots of it. Secondly, it can reduce fillrate consumption. By using smaller textures, the video card has less sampling to do if the texture does not appear on every chunk. Thirdly, it fits into common level of detail techniques such as geomipmapping that require the terrain to be divided into chunks anyway.
      Creating the Blends
      The key to getting smooth blending is linear interpolation of the alphamaps. Suppose there is a 1 right next to a 0. When the alphamap is stretched out over the terrain, Direct3D creates an even blend between the two values. The stretched alphamap is then combined with terrain texture, causing the texture itself to blend.

      Rendering then becomes the simple matter of going through each chunk and rendering the splats on it. Generally, the first splat will be completely opaque, with the following splats having varying values in their alphamaps. Let me demonstrate with some graphics. Let's say the first splat is dirt. Because it is the first that appears on that chunk, it will have an alphamap that is completely solid.
       *  =   

      After the first splat is rendered, the chunk is covered with dirt. Then a grass layer is added on top of that:
       *  = 
      +  = 

      The process is repeated for the rest of the splats for the chunk.

      It is important that you render everything in the same order for each chunk. Splat addition is not commutative. Skipping splats won't cause any harm, but if you change the order around, another chunk could end up looking like this:
       +  = 

      The grass splat is covered up because the dirt splat is completely opaque and was rendered second.

      You may be wondering why the first splat should be opaque. Let's say it wasn't, and instead was only solid where the grass splat was clear. Here's what happens:
       +  = 

      It's obvious this does not look right when compared with the blend from before. By having the first splat be completely opaque, you prevent any "holes" from appearing like in the picture above.
      Creating the Alphamaps
      Now that we know what texture splatting is, we need to create the alphamaps to describe our canvas. But how do we decide what values to give the alphamaps?

      Some people base it off of terrain height, but I recommend giving the ability to make the alphamaps whatever you want them to be. This gives you the flexibility to put any texture wherever you want with no limitations. It's as simple as drawing out the channels in your paint program of choice. Even better, you could create a simple world editor that allows the artist to see their alphamap and interact with it in the actual world.
      Implementation
      Let's take a step back and look at what we have:
      Some sort of terrain representation, such as a heightmap A set of textures to be rendered on the terrain An alphamap for each texture Look at #3. We know that each alphamap has to be in a texture. Does this mean that every alphamap needs its own texture? Thankfully, the answer is no. Because the alphamap only has to be in a single channel of a texture, we can pack up to four alphamaps into a single texture - one in red, one in green, one in blue, and one in alpha. In order to access these individual channels we will need to use a pixel shader, and because we need five textures (one with the alphamaps and four to blend), PS 1.4 is required. Unfortunately this is a still stiff requirement, so I will show how to use texture splatting with the fixed function pipeline as well as with a pixel shader.
      Splatting with the Fixed Function Pipeline
      Using the fixed function pipeline has one benefit that the pixel shader technique lacks: it will run on virtually any video card. All it requires is one texture unit for the alphamap, one texture unit for the texture, and the correct blending states.

      I chose to put the alphamap in stage 0 and the texture in stage 1. This was to stay consistent with the pixel shader, which makes most sense with the alphamap in stage 0. The texture stage states are relatively straightforward from there. Stage 0 passes its alpha value up to stage 1. Stage 1 uses that alpha value as its own and pairs it with its own color value.
      // Alphamap: take the alpha from the alphamap, we don't care about the color g_Direct3DDevice->SetTextureStageState(0, D3DTSS_ALPHAOP, D3DTOP_SELECTARG1); g_Direct3DDevice->SetTextureStageState(0, D3DTSS_ALPHAARG1, D3DTA_TEXTURE); // Texture: take the color from the texture, take the alpha from the previous stage g_Direct3DDevice->SetTextureStageState(1, D3DTSS_COLOROP, D3DTOP_SELECTARG1); g_Direct3DDevice->SetTextureStageState(1, D3DTSS_COLORARG1, D3DTA_TEXTURE); g_Direct3DDevice->SetTextureStageState(1, D3DTSS_ALPHAOP, D3DTOP_SELECTARG1); g_Direct3DDevice->SetTextureStageState(1, D3DTSS_ALPHAARG1, D3DTA_CURRENT); We have to set the blending render states as well in order to get the multiple splats to combine together correctly. D3DRS_SRCBLEND is the alpha coming from the splat being rendered, so we set it to D3DBLEND_SRCALPHA. The final equation we want is FinalColor = Alpha * Texture + (1 - Alpha) * PreviousColor. This is done by setting D3DRS_DESTBLEND to D3DBLEND_INVSRCALPHA.
       
      g_Direct3DDevice->SetRenderState(D3DRS_ALPHABLENDENABLE, TRUE); g_Direct3DDevice->SetRenderState(D3DRS_SRCBLEND, D3DBLEND_SRCALPHA); g_Direct3DDevice->SetRenderState(D3DRS_DESTBLEND, D3DBLEND_INVSRCALPHA); Splatting with a Pixel Shader
      Why even bother with the pixel shader? Using all the channels available in a texture instead of only one saves memory. It also allows us to render four splats in a single pass, reducing the number of vertices that need to be transformed. Because all of the texture combining takes place in the shader, there are no texture stage states to worry about. We just load the texture with an alphamap in each channel into stage 0, the textures into stages 1 through 4, and render.
      ps_1_4 //////////////////////////////// // r0: alphamaps // r1 - r4: textures //////////////////////////////// // Sample textures texld r0, t0 texld r1, t1 texld r2, t1 texld r3, t1 texld r4, t1 // Combine the textures together based off of their alphamaps mul r1, r1, r0.x lrp r2, r0.y, r2, r1 lrp r3, r0.z, r3, r2 lrp r0, r0.w, r4, r3 The mul instruction multiplies the first texture by its alphamap, which is stored in the red channel of the texture in sampler 0. The lrp instruction does the following arithmetic: dest = src0 * src1 + (1 - src0) * src2. Let's say r0.x is the alphamap for a dirt texture stored in r1, and r0.y is the alphamap for a grass texture stored in r2. r2 contains the following after the first lrp: GrassAlpha * GrassTexture + (1 - GrassAlpha) * DirtBlended, where DirtBlended is DirtAlpha * DirtTexture. As you can see, lrp does the same thing as the render states and texture stage states we set before. The final lrp uses r0 as the destination register, which is the register used as the final pixel color. This eliminates the need for a final mov instruction.

      What if you only need to render two or three splats for a chunk? If you want to reuse the pixel shader, simply have the remaining channels be filled with 0. That way they will have no influence on the final result. You could also create another pixel shader for two splats and a third for three splats, but the additional overhead of more SetPixelShader calls may be less efficient than using an extra instruction or two.

      Multiple passes are required if you need to render more than four splats for a chunk. Let's say you have to render seven splats. You first render the first four, leaving three left. The alpha channel of your second alphamap texture would be filled with 0, causing the fourth texture to cancel out in the equation. You simply set the alphamap texture and the three textures to be blended and render. The D3DRS_BLEND and D3DRS_SRCBLEND stages from before perform the same thing as the lrp in the pixel shader, allowing the second pass to combine seamlessly with the first.
      The Demo
      The demo application uses the two techniques described here to render a texture splatted quad. I decided not to go for a full heightmap to make it as easy as possible to find the key parts in texture splatting. Because of this, the demo is completely fillrate limited. The initial overhead of the pixel shader may cause some video cards to perform worse with it than with its fixed function equivalent, so take the frame rates with a grain of salt. The pixel shader will almost always come out ahead in a more complex scene.

      You can toggle between the fixed function pipeline and the pixel shader through the option in the View menu.

      The textures used are property of nVidia(R) and are available in their full resolution at http://developer.nvidia.com/object/IO_TTVol_01.html.
      The Problem of Seams
      If texture splatting has a downfall, it is this: when two neighboring splats come together, an unattractive seam forms between them. The look can be recreated by tiling four of the example splats from before.



      Why does this happen? Let's look at the grass alphamap of the top two sections:


      Here space has been added between them and the problem becomes apparent. The one on the left does not know the border values of the one on the right. When the video card performs its linear blend, it has no way of knowing that there is in fact a black texel right next to a white one. It simply assumes the same color is on the border.

      This is not an easy problem to fix and many games leave it untouched. It can be disguised a little by properly wrapping textures and a skilled level designer, but I have not thought of an elegant solution. In my experience it has been more trouble than it's worth to solve this problem, and I believe the advantages of texture splatting far outweigh the issue.
      Conclusion
      Hopefully this article has cleared up the mystery behind texture splatting. There are, of course, enhancements to be made, but texture splatting in its basic form is a powerful and flexible technique. It creates a smooth blend between different layers of terrain while giving detail at any distance and avoids the patterned look a detail map can give. Its main disadvantage is that it is very fillrate consuming, but with video cards becoming ever more powerful and the abilities of pixel shaders increasing, this is not an issue on modern and future hardware. Its ease of use and flexibility make it a perfect choice for texturing your terrain.

      Happy splatting!
      Sources
      Terrain Texture Compositing by Blending in the Frame-Buffer by Charles Bloom, http://www.cbloom.com/3d/techdocs/splatting.txt

      And, of course, the helpful people at http://www.gamedev.net.

      Feel free to send any questions or comments to email or private message @Raloth on the forums!
       
       
    • By Luca Davidian
      Hi, I'm implementing a simple 3D engine based on DirectX11. I'm trying to render a skybox with a cubemap on it and to do so I'm using DDS Texture Loader from DirectXTex library. I use texassemble to generate the cubemap (texture array of 6 textures) into a DDS file that I load at runtime. I generated a cube "dome" and sample the texture using the position vector of the vertex as the sample coordinates (so far so good), but I always get the same face of the cubemap mapped on the sky. As I look around I always get the same face (and it wobbles a bit if I move the camera). My code:   
      //Texture.cpp:         Texture::Texture(const wchar_t *textureFilePath, const std::string &textureType) : mType(textureType)         {             //CreateDDSTextureFromFile(Game::GetInstance()->GetDevice(), Game::GetInstance()->GetDeviceContext(), textureFilePath, &mResource, &mShaderResourceView);             CreateDDSTextureFromFileEx(Game::GetInstance()->GetDevice(), Game::GetInstance()->GetDeviceContext(), textureFilePath, 0, D3D11_USAGE_DEFAULT, D3D11_BIND_SHADER_RESOURCE, 0, D3D11_RESOURCE_MISC_TEXTURECUBE, false, &mResource, &mShaderResourceView);         }     // SkyBox.cpp:          void SkyBox::Draw()     {         // set cube map         ID3D11ShaderResourceView *resource = mTexture.GetResource();         Game::GetInstance()->GetDeviceContext()->PSSetShaderResources(0, 1, &resource);              // set primitive topology         Game::GetInstance()->GetDeviceContext()->IASetPrimitiveTopology(D3D_PRIMITIVE_TOPOLOGY_TRIANGLELIST);              mMesh.Bind();         mMesh.Draw();     }     // Vertex Shader:     cbuffer Transform : register(b0)     {         float4x4 viewProjectionMatrix;     };          float4 main(inout float3 pos : POSITION) : SV_POSITION     {         return mul(float4(pos, 1.0f), viewProjectionMatrix);     }     // Pixel Shader:     SamplerState cubeSampler;     TextureCube cubeMap;          float4 main(in float3 pos : POSITION) : SV_TARGET     {         float4 color = cubeMap.Sample(cubeSampler, pos.xyz);         return color;     } I tried both functions grom DDS loader but I keep getting the same result. All results I found on the web are about the old SDK toolkits, but I'm using the new DirectXTex lib.
    • By Tordin
      Hello!
      I have been working on a Scifi RTS for some time and have come a long way with the coding and such. I am trying to put 10-20h a week into the game and it seems to been working out good so far. 
      previously i have worked on multiple AAA titles in the video game industry and as well as some indiegames but decided to start making my own indiegames. Problem is that i suck at making art. =)
       
      So i am looking for someone who wants to help out to make the game look greate by creating 2d art. It mainly consist of isometric art but there are some ui elements and regular 2d perspective aswell.
      Prefebly you should live near the nordic regions and also be able to put in some hours weekly to the project. 
      If you are intressted pm me and i will tell you more indetail stuff about the game and the idea.
      hope to hear from all you crazy good people.
       
  • Advertisement
  • Advertisement

SDL SDL 2: Implementing Sprite Clips

Recommended Posts

I am trying to implement sprite clips, or rendering a portion of a sprite sheet onto the screen. For now, I am least trying to get one sprite to display on the screen. Controller support and adding the other sprites when changing the character direction will come later. Here is what I have so far. 

First, the class declaration:

class World1
{
    public:
        //other stuff

        //screen resolution
        int window_width = 0;
        int window_height = 0;

        //handles player
        void renderPlayer(SDL_Renderer*&);
        //other stuff

        
    private:

        //player graphic and rectangle structs/variables/etc.
        SDL_Texture* pSpriteSheet = nullptr;
        SDL_Rect pSpriteClips[3];
        SDL_Rect* pSprite;
        SDL_Rect pBase;   
	SDL_RendererFlip sFlip = SDL_FLIP_NONE;

        //other stuff
};

Then, the constructor:

World1::World1(int SCREEN_WIDTH, int SCREEN_HEIGHT, SDL_Renderer*& renderer)
{
    window_width = SCREEN_WIDTH;
    window_height = SCREEN_HEIGHT;

    *pSpriteSheet = IMG_LoadTexture(renderer, "male_base-test-anim.gif");

    if (pSpriteSheet == nullptr)
    {
        cout << "Unable to load player Sprite sheet.";
    }

    //facing down sprite
    pSpriteClips[0].x = 14;
    pSpriteClips[0].y = 12;
    pSpriteClips[0].w = 145;
    pSpriteClips[0].h = 320;
 	//more code...
	
    //player sprite
    pBase.x = 0;
    pBase.y = 0;
    pBase.w = pSpriteClips[0].w;
    pBase.h = pSpriteClips[0].h;  
}

Then, the rendering

void World1::renderPlayer(SDL_Renderer*& renderer)
{
    //render
    SDL_RenderClear(renderer); //clears screen
    SDL_RenderCopyEx(renderer, pSpriteSheet, pSprite, &pBase, 0.0, NULL, sFlip);
    SDL_RenderPresent(renderer); //puts image on screen
}

So far, the program does not build and I obtain the following error:

C:\Users\Kevin\Documents\Codeblocks\KnightQuest\worlds.cpp|12|error: invalid use of incomplete type 'SDL_Texture {aka struct SDL_Texture}'|

Am I mistaken to assume that C++ will automatically assign a memory address to SDL_Rect* when I assign a value to it via the dereference operator? Or, perhaps there is another issue?

Share this post


Link to post
Share on other sites
Advertisement
1 hour ago, windghost91 said:

*pSpriteSheet = IMG_LoadTexture(renderer, "male_base-test-anim.gif");

this is your issue.. SDL's SDL_Texture struct is designed to be treated as a pointer only.
Basically SDL dynamically allocates space in memory for that structure and returns pointer. So, you cannot dereference it. 

So basically if you created SDL_Texture *pSpriteSheet;
then to load image in it, you call:
pSpriteSheet = IMG_LoadTexture(renderer, "file.gif"); // behaves like (new)
and later when you won't need it:
SDL_DestroyTexture(pSpriteSheet); // behaves like (delete)

Hope this helps.

Share this post


Link to post
Share on other sites

Your specific error has nothing to do with SDL_Rect*, and it is quite clear that it is referring to SDL_Texture.

It looks like your source code file does not #include the necessary files for the compiler to know how to use an SDL_Texture. Try #include <SDL.h>at the top of the file. There might even be a more specific file for graphics that you can use.

Also, you definitely shouldn't be dereferencing pSpritesheet like that - IMG_LoadTexture returns a pointer so you just need to assign it to pSpritesheet which is also a pointer.

Fix those 2 problems, and see how it goes. Also be aware that you're not initialising pSprite anywhere in that code.

Share this post


Link to post
Share on other sites
On 7/7/2017 at 2:26 AM, tetriarch said:

this is your issue.. SDL's SDL_Texture struct is designed to be treated as a pointer only.
Basically SDL dynamically allocates space in memory for that structure and returns pointer. So, you cannot dereference it. 

So basically if you created SDL_Texture *pSpriteSheet;
then to load image in it, you call:
pSpriteSheet = IMG_LoadTexture(renderer, "file.gif"); // behaves like (new)
and later when you won't need it:
SDL_DestroyTexture(pSpriteSheet); // behaves like (delete)

Hope this helps.

Ok, thanks. I always wondered why tutorials did it that way. I tried it without the pointer, but it sounds like you need it.

On 7/7/2017 at 3:50 AM, Kylotan said:

Your specific error has nothing to do with SDL_Rect*, and it is quite clear that it is referring to SDL_Texture.

It looks like your source code file does not #include the necessary files for the compiler to know how to use an SDL_Texture. Try #include <SDL.h>at the top of the file. There might even be a more specific file for graphics that you can use.

Also, you definitely shouldn't be dereferencing pSpritesheet like that - IMG_LoadTexture returns a pointer so you just need to assign it to pSpritesheet which is also a pointer.

Fix those 2 problems, and see how it goes. Also be aware that you're not initialising pSprite anywhere in that code.

I meant SDL_Texture*. I'm not sure why I put SDL_Rect*.

My include files were not shown in the post, but they are in the file. I have SDL.h and SDL_image.h.

Ok, I was unable to find documentation on IMG_LoadTexture specifically. Thank you for the info.

pSprite was supposed to contain the current sprite being shown on the screen. Thank you for telling me that it was not initialized.

#include "game.h" //contains SDL.h, SDL_image.h, iostream, and stdio.h. Also has using namespace std.
#include "worlds.h" //class declaration

//gets window size, loads sprite sheet, and prepares initial sprite for rendering 
World1::World1(int SCREEN_WIDTH, int SCREEN_HEIGHT, SDL_Renderer*& renderer)
{
    window_width = SCREEN_WIDTH;
    window_height = SCREEN_HEIGHT;
  
    pSpriteSheet = IMG_LoadTexture(renderer, "male_base-test-anim.gif");

    if (pSpriteSheet == nullptr)
    {
        cout << "Unable to load player Sprite sheet.";
    }

    //facing down sprite
    pSpriteClips[0]->x = 14;
    pSpriteClips[0]->y = 12;
    pSpriteClips[0]->w = 145;
    pSpriteClips[0]->h = 320;

    pSprite = pSpriteClips[0]; //sets sprite clip upon game start to be pSpriteClips[0]

    //player rectangle that pSprite is rendered onto
    pBase->x = 0;
    pBase->y = 0;
    pBase->w = pSpriteClips[0]->w;
    pBase->h = pSpriteClips[0]->h;
}
//renders player to screen
void World1::renderPlayer(SDL_Renderer*& renderer)
{
    //Prepare sprite positions for rendering
    pBase->x = static_cast<int>(pPosX);
    pBase->y = static_cast<int>(pPosY);

    //render
    SDL_RenderClear(renderer); //clears screen
    SDL_RenderCopyEx(renderer, pSpriteSheet, pSprite, pBase, 0.0, NULL, sFlip);
    SDL_RenderPresent(renderer); //puts image on screen
}

I initalized pSprite and changed pSpriteClips and pBase to pointers. So far, the program builds, but it crashes at runtime. Using pointers to render has proven tricky for me. What can I do to avoid the crash? I will show more code if necessary.

Edited by windghost91

Share this post


Link to post
Share on other sites

When it crashes, don't you get the option to click 'Debug'? Or can you run the program in the debugger directly?

The debugger can tell you exactly which line has the problem. But without that information the crash could be anywhere in your code.

However, I can guess, having seen that you've apparently changed your code to make pSpriteClips an array of pointers to SDL_Rect instead of an array of SDL_Rects, that that will only work if you have actually dynamically allocated those SDL_Rects, and failing to do that will make it crash. This is probably the wrong approach to have taken, and your original array of SDL_Rects was better.

Pointers are a complex subject and they require that you understand exactly how they work and what they represent. Don't use them unless you need to.

Share this post


Link to post
Share on other sites

I'm not very familiar with C++ but why are you passing reference to pointer SDL_Renderer*& instead of SDL_Renderer* pointer to struct?

Edited by dud3

Share this post


Link to post
Share on other sites

I wouldn't use C++ stuff on SDL, such as the one mentioned on my last comment, I also think you most likely didn't include the SDL header file, or didn't set the correct compiler flags, or both.

Edited by dud3

Share this post


Link to post
Share on other sites
1 hour ago, dud3 said:

I'm not very familiar with C++ but why are you passing reference to pointer SDL_Renderer*& instead of SDL_Renderer* pointer to struct?

That would make no real difference in this case. The renderer being used will be exactly the same. There is the potential to change the pointer but I doubt that is taking place. There's certainly nothing in the code to suggest it.

 

1 hour ago, dud3 said:

I wouldn't use C++ stuff on SDL, such as the one mentioned on my last comment

There's no reason not to. SDL won't suddenly break because it sees a C++ feature.

Share this post


Link to post
Share on other sites
1 hour ago, Kylotan said:

There's no reason not to. SDL won't suddenly break because it sees a C++ feature.

Indeed you right, that statement is irrelevant, as I've mentioned I'm not very familiar with C++, and since SDL is written in C, I tend to write C like C++.

Share this post


Link to post
Share on other sites
On 7/11/2017 at 5:35 AM, Kylotan said:

When it crashes, don't you get the option to click 'Debug'? Or can you run the program in the debugger directly?

The debugger can tell you exactly which line has the problem. But without that information the crash could be anywhere in your code.

However, I can guess, having seen that you've apparently changed your code to make pSpriteClips an array of pointers to SDL_Rect instead of an array of SDL_Rects, that that will only work if you have actually dynamically allocated those SDL_Rects, and failing to do that will make it crash. This is probably the wrong approach to have taken, and your original array of SDL_Rects was better.

Pointers are a complex subject and they require that you understand exactly how they work and what they represent. Don't use them unless you need to.

Yes, I get a screen to choose a debugger. The message sounded like a pointer error, which is what I was wondering about.

In my experience, sometimes, the compiler is able to convert SDL_Rects to pointers, but other times, it is not able to and I get an error something like "Unable to convert SDL_Rect to const SDL_Rect* for argument..." when attempting to render. This has frustrated me, so I tried to switch to pointers. That was troublesome too as you have seen.

If I were to use SDL_Rect instead of SDL_Rect*, do you know of a way to bypass this problem so that the compiler is able to make the conversion to pointers properly for SDL_RenderCopyEX?

 

 

Edited by windghost91

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now


  • Advertisement