Welcome, Guest. Please login or register. Did you miss your activation email?

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - nathanmyersc

Pages: [1]
1
How do i make it so the vertex color is only applied to non 0 alpha pixels?
Because when i have the vertex quad textured and i want to fade it out.
I modify all the vertex's color parameter for alpha. But this makes all the pixels
within the quad the same alpha. regardless if some where transparent in the first place.
How do i solve this?

2
Graphics / Random Lag Spikes.
« on: May 06, 2020, 10:53:59 pm »
Hi i read of one thread written in 2013 about this issue. My program has a strange issue that seems to be one thats been common, I am updating my games logic at least 400 times a second. And it is updating the drawing 400 times per second.
But for some reason once about every 30 seconds or so it dips to 350 fps for a second and there is a noticable skip as it takes 100 miliseconds to get through the window display call. This happens even if i comment out every draw call and just call display.

3
I eventually want to figure out how to use vertexes to group draw calls to the same sprite sheet into one call.

But i have to figure out coloring and rotation and flipping.
How do you rotate quads in a vertex aray?

4
Thanks. Thats an obscure rule.

5
Hello I have an issue in a 2d sidescrolling-kinda game im making.

Currently i store the static tiles in a RenderTexture and have a sprite
that uses the rendertexture as a texture and draw that to the screen.
And i have an effect where when you take damage or enemy takes damage they bleed.
And blood particles of the type sf::Vertex sf::Points fly off in random directions.
And when the particles hit a tile pixel not covered in blood it adds a copy of itself to a
array inside the tile which i draw when i call the draw function of the tile.
So this effect works with the static tiles i can update the rendertexture and it displays fine.
But i have tiles that move also. And for dynamic tiles i dont store them in a renderTexture.
i just call their draw function with the window as the renderTarget and it draws itself and all
its blood particles.
Well this is where the issue occurs. Because for some reason the pixels of blood are alot smaller when
i draw them directly to the window as opposed to when i draw them to the renderTexture.

I am using a 0.5 zoom with the sf::View::zoom feature. And i am considering maybe the zoom
has something to do with it in some way?

EDIT: i just played around a bit. i normally use a 0.5 zoom but i created a toggle between 1 and 0.5
and went in the game at 1 and got blood on a moving platform and then zoomed in.
And i found that as i zoomed in the pixels remain proportional to the zoom. aka shrinking when i zoom in.
Why is that?

The only difference between the sf::Vertex sf::Points is one is drawn to a renderTexture and the other directly to the window.

Also note i am not using the sf::View::Zoom feature actually i am using a custom function that uses
sf::View::setSize() with a float between 0 and 1 and i times that by variables i have stored for the window size.

Any ideas?

I tried messing around with the bits per pixel and antialiasing with different settings no luck.

EDIT2: to clarify a little the renderTexture Blood Pixels are the same size as the pixels of the tile.
i am zoomed in on the sf::View and everything is good. But it is not so for the sf::vertexs i am drawing directly to the screen.

6
General / Re: Trying To Figure Out How To Compile SFML with GCC 9.3
« on: April 10, 2020, 12:22:38 am »
Hey Thanks For Your Comment.
Silly enough through my layman tinkering i actually managed to compile sfml with gcc 9.3 in both 32 bit and 64 bit. Good to know i think i have a method that works without fuss.

What i did was i use codeblocks. I changed the default compiler to the appropiate one. And used codeblocks-mingw settings in cmake and it miraciously worked after so much trouble.
So i can use codeblocks as a tool to mediate the compiler change. Because obviously when i was trying to do it with non default settings i was missing something.

7
General / Trying To Figure Out How To Compile SFML with GCC 9.3
« on: April 09, 2020, 03:30:30 pm »
Hello i have been trying to compile sfml with both gcc 9.3 32 bit and 64 bit. Not having much luck
i used msys2 to download the 32 bit and 64 bit version of MINGW
its updated. i can use [for(THING a = THING();double x : a.listOfNumbers){//dostuff}]  a gcc 9 compiler addition. i assume compiler works.

No real clue about cmake or the cmake list or anything. But i have managed to compile sfml once before to a non precompiled compiler version.

CMAKE IN GUI ERROR OUTPUT
Quote
The C compiler identification is GNU 9.3.0
The CXX compiler identification is GNU 9.3.0
System is unknown to cmake, create:
Platform/Windows 10 to use this system, please post your config file on discourse.cmake.org so it can be added to cmake
Your CMakeCache.txt file was copied to CopyOfCMakeCache.txt. Please post that file on discourse.cmake.org.
Check for working C compiler: D:/CODING/COMPILER/mingw32/bin/gcc.exe
System is unknown to cmake, create:
Platform/Windows 10 to use this system, please post your config file on discourse.cmake.org so it can be added to cmake
Check for working C compiler: D:/CODING/COMPILER/mingw32/bin/gcc.exe - broken
CMake Error at C:/Program Files/CMake/share/cmake-3.17/Modules/CMakeTestCCompiler.cmake:60 (message):
  The C compiler

    "D:/CODING/COMPILER/mingw32/bin/gcc.exe"

  is not able to compile a simple test program.

  It fails with the following output:

    Change Dir: D:/CODING/SFMLOUTPUT/CMakeFiles/CMakeTmp
   
    Run Build Command(s):D:/CODING/COMPILER/mingw32/bin/make.exe cmTC_88135/fast && D:/CODING/COMPILER/mingw32/bin/make.exe -f CMakeFiles/cmTC_88135.dir/build.make CMakeFiles/cmTC_88135.dir/build

    make[1]: Entering directory 'D:/CODING/SFMLOUTPUT/CMakeFiles/CMakeTmp'

    process_begin: CreateProcess(NULL, sh.exe -c "/C/Program Files/CMake/bin/cmake.exe -E cmake_echo_color --switch= --progress-dir=/D/CODING/SFMLOUTPUT/CMakeFiles/CMakeTmp/CMakeFiles --progress-num=1 Building C object CMakeFiles/cmTC_88135.dir/testCCompiler.c.obj", ...) failed.

    make (e=2): The system cannot find the file specified.


    make[1]: *** [CMakeFiles/cmTC_88135.dir/build.make:82: CMakeFiles/cmTC_88135.dir/testCCompiler.c.obj] Error 2

    make[1]: Leaving directory 'D:/CODING/SFMLOUTPUT/CMakeFiles/CMakeTmp'

    make: *** [Makefile:138: cmTC_88135/fast] Error 2

   
   

 

  CMake will not be able to correctly generate this project.
Call Stack (most recent call first):
  CMakeLists.txt:45 (project)


Configuring incomplete, errors occurred!
See also "D:/CODING/SFMLOUTPUT/CMakeFiles/CMakeOutput.log".
See also "D:/CODING/SFMLOUTPUT/CMakeFiles/CMakeError.log".

I pondered if sh.exe was missing
Or the program was messing up the address of cmake.exe with /c/p... instead of c:/p... but perhaps that doesnt matter.
I pondered i was missing a prerequisite for sfml.

I copied random cmakelist.txts for compiling sfml. but no difference in output.

Like i said i have no clue about this aspect. Hope you might be able to help me :). thanks.

8
Thanks for the response I actually figured it out. I tried to make a small example outlining the problem but couldn't and when I looked around for a while I found out that the array i had that held all the textures i had initialized 18 slots in the array but there were 24 textures put into the array. So weirdly enough it still worked and i could use the textures but they were colored strangely. don't really understand why it worked though.

9
No unfortunately that's not it. I had messed around with the colors to see if I could correct it. But with the sword and shield hand it renders on screen darker and different than the picture shows.
For example.

OpenDoor Renders really dark and unseeable almost just faintly but OpenDoorRotated renders as would be expected

10
Ok sure. I have been wondering if it is related to the image itself but I have tried lots of different ways of exporting the png file with no difference. removed the alpha channel that is on by default. Having the same issue with some of the images that compose the player character;

11
I have made a small platformer with no issues. But I created a roguelike top down framework and for some reason the opendoors facing one direction are way darker. There is no sf::Color code or anything it is treated no different than any other texture sprite.
Just initialized setTexture() then for each tile in map window.draw()? What could be the issue?



//INITIALIZE TEXTURES//
enum textures{ENEMYTEX = 0, PLAYERTEX, GUNHANDTEX, BULLETTEX, MENUBLOCKTEX, WALLTEX, FLOORTEX1,FLOORTEX2,
FLOORTEX3,FLOORTEX4,UNUSEDTEX,SMALLHEALTHTEX,MEDIUMHEALTHTEX,SMALLMANATEX,MEDIUMMANATEX,GOLDSACKTEX,
UPSTAIRSTEX,DOWNSTAIRSTEX,CLOSEDDOORTEX,OPENDOORTEX,CLOSEDDOORROTATEDTEX,OPENDOORROTATEDTEX};
enum sounds{ENEMYHURT = 0, ENEMYDEATH, GUNSHOT, SAVEME, DONTWORRY, PROTAGANIST1, PROTAGANIST2
            ,NORMALBACKGROUND,BOSSBACKGROUND};
inline void loadTextures()
{
    textureArray[ENEMYTEX].loadFromFile("data/images/enemy.png");
    textureArray[PLAYERTEX].loadFromFile("data/images/player.png");
    textureArray[GUNHANDTEX].loadFromFile("data/images/gunhand.png");
    textureArray[BULLETTEX].loadFromFile("data/images/bullet.png");
    textureArray[MENUBLOCKTEX].loadFromFile("data/images/menublock.png");
    textureArray[WALLTEX].loadFromFile("data/images/wall.png");
    textureArray[FLOORTEX1].loadFromFile("data/images/floor1.png");
    textureArray[FLOORTEX2].loadFromFile("data/images/floor2.png");
    textureArray[FLOORTEX3].loadFromFile("data/images/floor3.png");
    textureArray[FLOORTEX4].loadFromFile("data/images/floor4.png");
    textureArray[UNUSEDTEX].loadFromFile("data/images/unusedtile.png");
    textureArray[SMALLHEALTHTEX].loadFromFile("data/images/smallhealth.png");
    textureArray[MEDIUMHEALTHTEX].loadFromFile("data/images/mediumhealth.png");
    textureArray[SMALLMANATEX].loadFromFile("data/images/smallmana.png");
    textureArray[MEDIUMMANATEX].loadFromFile("data/images/mediummana.png");
    textureArray[GOLDSACKTEX].loadFromFile("data/images/goldsack.png");
    textureArray[UPSTAIRSTEX].loadFromFile("data/images/upstairs.png");
    textureArray[DOWNSTAIRSTEX].loadFromFile("data/images/downstairs.png");
    textureArray[CLOSEDDOORTEX].loadFromFile("data/images/closedDoor.png");
    textureArray[OPENDOORTEX].loadFromFile("data/images/openDoor.png");
    textureArray[CLOSEDDOORROTATEDTEX].loadFromFile("data/images/closedDoorRotated.png");
    textureArray[OPENDOORROTATEDTEX].loadFromFile("data/images/openDoorRotated.png");
}

//INITIALIZE TEXTURES ON TILE SPRITE//
inline Tile::Tile(short type,sf::Vector2f position)
:GameEntity(position,TileSize)
{
    switch(type)
    {
        case Unused:
            GameEntity::setTexture(UNUSEDTEX);
            break;
        case Wall:
            GameEntity::setTexture(WALLTEX);
            break;
        case Floor:case Corridor:
            GameEntity::setTexture(FLOORTEX1);
            break;
        case ClosedDoor:
            GameEntity::setTexture(CLOSEDDOORTEX);
            break;
        case ClosedDoorRotated:
            GameEntity::setTexture(CLOSEDDOORROTATEDTEX);
            break;
        case OpenDoor:
            GameEntity::setTexture(OPENDOORTEX);
            break;
        case OpenDoorRotated:
            GameEntity::setTexture(OPENDOORROTATEDTEX);
            break;
        case DownStairs:
            GameEntity::setTexture(DOWNSTAIRSTEX);
            break;
        case UpStairs:
            GameEntity::setTexture(UPSTAIRSTEX);
            break;
    }
    setColor(sf::Color(255,255,255,255)); //No effect
}

//DRAW TILE SPRITES WITHIN VIEW BOUNDS//
inline void Tile::draw(WINDOW& appWindow)
{
    appWindow.draw(*this);
    if(thingsOnTile.size() > 0)
    {
        appWindow.draw(*thingsOnTile[thingsOnTile.size()-1]);
    }
}
inline void Map::draw(WINDOW& appWindow,sf::View& view)
{
     sf::FloatRect viewRect = sf::FloatRect{view.getCenter().x-(view.getSize().x/2),
                            view.getCenter().y-(view.getSize().y/2),
                            view.getCenter().x+(view.getSize().x/2),
                            view.getCenter().y+(view.getSize().y/2)};
     short yMax = floor(viewRect.height/TileSize.y);
     short yMin = floor(viewRect.top/TileSize.y);
     if(yMin < 0) yMin = 0;
     short xMax = floor(viewRect.width/TileSize.x);
     short xMin = round(viewRect.left/TileSize.x);
     if(xMin < 0) xMin = 0;
     print("Y MIN:" + tostr(yMin) + "Y MAX: " + tostr(yMax));
     print(viewRect.top);
     for(int y = yMin; y <=yMax; ++y)
         for( int x = xMin; x <=xMax; ++x)
         {
             print(x+(y*tilesWide));
                this->at((y*tilesWide)+x).draw(appWindow);
         }
}
//Although the viewrect thing is irrelevent same thing happens when i just go auto i : Tiles window.draw(i);
 

Its a very strange thing because I have one tile for a door oriented vertically and one for a door oriented horizontally. and all I did is rotate the horizontal one to vertical in GIMP and save it and it comes out way darker than it looks in the PNG file when I draw it in the program. I know I could do the rotations in the program but meh. I honestly will have to try I guess. Just seems very strange that all I did was rotate the PNG file and save it as another PNG file and then add it to the program and it comes out all blacked out like its messed up transparency or something.

I can fix it by doing

        case OpenDoor:
            GameEntity::setTexture(OPENDOORROTATEDTEX);
            setRotation(90);
            move(50,0);
            break;
with the texture that doesn't mess up. But still dunno why it occurs.

Pages: [1]