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

Pages: [1] 2
1
Network / Piece of network conde not compiling in g++ (it does in VS19!)
« on: November 02, 2021, 05:19:07 pm »
The send code

sf::Packet actorDataPacket;
        sf::Uint8 actorDataHeader = dataType::actorsBlob;
        actorDataPacket << actorDataHeader;
        size_t amountOfActors = listOfActors.size();
        actorDataPacket << amountOfActors;

        for (actors& a : listOfActors) {
            int x = a.getActorCords().x;
            int y = a.getActorCords().y;
            int team = a.getTeam();
            int type = a.getType();
            actorDataPacket << x << y << team << type;
        }
        currentConnection.getTcpSocket()->send(actorDataPacket);

 
The recieve code:
sf::Packet recievePacket;
sf::Socket::Status statusOfSocket = currentConnection.getTcpSocket()->receive(recievePacket);
if (statusOfSocket == sf::Socket::Done) {
        sf::Uint8 recievedHeader;
        recievePacket >> recievedHeader;
        switch (recievedHeader) {

                case dataType::actorsBlob:
                    size_t amountOfActors;
                    recievePacket >> amountOfActors;
                    for (int i = 0; i < amountOfActors; i++) {
                        int x;
                        int y;
                        int team;
                        int type;
                        recievePacket >> x;
                        recievePacket >> y;
                        recievePacket >> team;
                        recievePacket >> type;
                        listOfActors.push_back(actors(type, { x, y }, team, static_cast<int>(listOfActors.size())));
                    }
                    actorBlobRecieved = true;

                    break;
}

On windows using Visual Studio Community 2019 this compiles just fine

On linux using g++ with VSCode and sfml-vscode-boilerplate it does not comile:
Error: invalid conversion from 'size_t'  {aka 'long unsigned int' to 'wchart_t*' [-fpermissive]

When turning on '-fpermissive' I believe it tries to use sf::bool, sf::string, sf::Uint8 to 64 and fails.

Am I right te presume that I am trying to do something undefined by putting a size_t into a SFML packet? And it was dumb luck it worked on windows?

Which sf:: datatype corresponds to a long unsigned int? So I could use that datatype instead to make this piece of code work.

2
SFML projects / Re: Isometric RTS
« on: October 06, 2021, 08:45:36 pm »
Made more progress getting things ready to start prototyping for multiplayer made a little devlog to explain what I am doing/planning to do to get some kind of muliplayer working!

https://youtu.be/3jEDKe8GcIY

3
SFML projects / Re: Isometric RTS
« on: September 09, 2021, 01:01:15 am »
Took most of the feedback I got here to heart in the last couple of weeks.

A short clip of my latest feature:
A content aware mouse pointer :P

https://www.youtube.com/watch?v=xZbtKNFhW8Y

4
Next time when you save double check if transparancy is checked!  ;)

Made it transparant for you.

5
I planned on adding smoothed edges for my sand and water tiles for my isometric RTS game. So while doing some prototyping I concluded that for the complexity of the effect of an adjacent tile I would need 2^8 different tiles per category to cover all possible tile arrangement.

Since I only have limited time there was no way I would sit down and create all these assets myself. So I set out to write a little program that could do it for me. And the idea for groundTilemapGenerator was formed.

It will generate a 16*16 tilemap of a category of ground/water. By switching a specific border on and off. Each tile wil have a 8-bit number (0-256) and if I use the same code to generate the same 8bit bitmask ingame it will allow me to show the pixels of the exact same tile number.

Sample of output:


This will save me a lot of work!

https://github.com/switchboy/groundTilemapGenerator

Currently it is hardcoded to work with 64*128 pixel assets

6
Already did those optimazations. Actors and fog of war are more dynamic so they need a lot of redraws. While I was at it I decided to make the background a vertex array ass well. (Started with that because it was easy for prototyping) and ran into the above problem.

7
Graphics / Re: Isometric tiles, far apart
« on: August 23, 2021, 05:44:02 pm »
All this is my bad. I have checked the texture coordinates 100 times but that was the problem.
At one time i thought it was something wrong with my compiler or sfml. But ofc that is never the case.

The problem was caused due to texture coordinated being rotated wrong and therefor it didn't line up.

Ah that explains it! I did not use textures since I am only using a vertex array for drawing my minimap, which uses solid colors. Good to know of this issue if I ever decide to convert my drawMap() function to use a vertex array instead of only a limit on draw calls to cells visible on screen.

8
Graphics / Re: Isometric tiles, far apart
« on: August 23, 2021, 05:24:13 pm »
 sf::Vector2f miniMapSpace(int i, int j) {
    //To draw from most left and top
    int mapOffsetX = (MAP_WIDTH / 2);
    int mapOffsetY = 0;

    //Get the top left pixel of a isometric texture tile of W64 H32
    int X = mapOffsetX * 64 + (i - j) * (64 / 2);
    int Y = mapOffsetY * 64 + (i + j) * (64 / 2);
 return {X, Y};
}


void setQuadPosition(sf::Vertex* Quad, int i, int j) {
    Quad[0].position = sf::Vector2f(miniMapSpace( i, j ).x, miniMapSpace( i, j ).y);                  // 0 , 0 = 0 , 0
    Quad[1].position = sf::Vector2f(miniMapSpace( i, j ).x + 64.f, miniMapSpace(i, j ).y);           // 1 , 0 = 20 , 0
    Quad[2].position = sf::Vector2f(miniMapSpace( i, j ).x + 64.f, miniMapSpace( i, j ).y + 64.f);    // 1 , 1 = 20 , 10
    Quad[3].position = sf::Vector2f(miniMapSpace( i, j ).x, miniMapSpace( i, j ).y + 64.f);           // 0 , 1 = 0 , 10
}

void drawMap() {
    sf::VertexArray miniMapBackGroundPoints(sf::Quads, x + y * 16 * 4);
    for (int j = 0; j < 16; j++)
    {
        for (int i = 0; i < 16; i++)
        {
            setQuadPosition(&miniMapBackGroundPoints[((i * 16) + j) * 4], i, j);
        }
    }
}

Maybe this might help. Looking at your image. But for an isometric projection you probaly want to use a tile that is wider than it is high. This will result in this:

sf::Vector2f miniMapSpace(int i, int j) {
    //To draw from most left and top
    int mapOffsetX = (MAP_WIDTH / 2);
    int mapOffsetY = 0;

    //Get the top left pixel of a isometric texture tile of W64 H32
    int X = mapOffsetX * 64 + (i - j) * (64 / 2);
    int Y = mapOffsetY * 32 + (i + j) * (32 / 2);
    return { X, Y };
}


void setQuadPosition(sf::Vertex* Quad, int i, int j) {
    Quad[0].position = sf::Vector2f(miniMapSpace( i, j ).x, miniMapSpace( i, j ).y);                  // 0 , 0 = 0 , 0
    Quad[1].position = sf::Vector2f(miniMapSpace( i, j ).x) + 64.f, miniMapSpace( i, j ).y);           // 1 , 0 = 20 , 0
    Quad[2].position = sf::Vector2f(miniMapSpace( i, j ).x + 64.f, miniMapSpace( i, j ).y + 32.f);    // 1 , 1 = 20 , 10
    Quad[3].position = sf::Vector2f(miniMapSpace( i, j ).x, miniMapSpace( i, j ).y + 32.f);           // 0 , 1 = 0 , 10
}

void drawMap() {
    sf::VertexArray miniMapBackGroundPoints(sf::Quads, x + y * 16 * 4);
    for (int j = 0; j < 16; j++)
    {
        for (int i = 0; i < 16; i++)
        {
            setQuadPosition(&miniMapBackGroundPoints[((i * 16) + j) * 4], i, j);
        }
    }
}
Will make more sense. I added my grass tile sprite as an example of an isometric tile.

9
I think something is going wrong here: sf::Vertex* currentMiniMapQuad = &miniMapPoints[(i * MAP_HEIGHT) + j]; Could it be that I am actually the memory adress of another Quad corner?

                        sf::Vertex* currentMiniMapQuad = &miniMapPoints[(i * MAP_HEIGHT) + j];
                        if (i % 2 == 0 && j % 2 == 0) {
                           
                            //Each quad should be 20px wide and 10px high. We define them clockwise from the top left (x + 0 and y + 0)
                            currentMiniMapQuad[0].position = sf::Vector2f(static_cast<float>(miniMapSpace({ i, j }).x), static_cast<float>(miniMapSpace({ i, j }).y));                  // 0 , 0 = 0 , 0
                            currentMiniMapQuad[1].position = sf::Vector2f(static_cast<float>(miniMapSpace({ i, j }).x) + 20.f, static_cast<float>(miniMapSpace({ i, j }).y));           // 1 , 0 = 20 , 0
                            currentMiniMapQuad[2].position = sf::Vector2f(static_cast<float>(miniMapSpace({ i, j }).x) + 20.f, static_cast<float>(miniMapSpace({ i, j }).y) + 10.f);    // 1 , 1 = 20 , 10
                            currentMiniMapQuad[3].position = sf::Vector2f(static_cast<float>(miniMapSpace({ i, j }).x), static_cast<float>(miniMapSpace({ i, j }).y) + 10.f);           // 0 , 1 = 0 , 10

                            currentMiniMapQuad[0].color = colors[currentGame.currentMap[i][j]];
                            currentMiniMapQuad[1].color = colors[currentGame.currentMap[i][j]];
                            currentMiniMapQuad[2].color = colors[currentGame.currentMap[i][j]];
                            currentMiniMapQuad[3].color = colors[currentGame.currentMap[i][j]];
                        }
                        else {
                            currentMiniMapQuad[0].position = sf::Vector2f(0, 0);
                            currentMiniMapQuad[1].position = sf::Vector2f(0, 0);
                            currentMiniMapQuad[2].position = sf::Vector2f(0, 0);
                            currentMiniMapQuad[3].position = sf::Vector2f(0, 0);
                            currentMiniMapQuad[0].color = colors[0];
                            currentMiniMapQuad[1].color = colors[0];
                            currentMiniMapQuad[2].color = colors[0];
                            currentMiniMapQuad[3].color = colors[0];
                        }

See result of my attempt to only draw even coordinates and move the other vertexes to 0,0 with a size of 0 and color black


Fixed it! It was indeed a memory adress issue!
Should have used: sf::Vertex* currentMiniMapQuad = &miniMapPoints[((i * MAP_HEIGHT) + j) *4];


10
Graphics / Re: Isometric tiles, far apart
« on: August 23, 2021, 12:05:25 pm »
I use this to determine the coordinates:

//To draw from most left and top
int mapOffsetX = (MAP_WIDTH/2);
int mapOffsetY = 0

//Get the top left pixel of a isometric texture tile of W64 H32
int X = mapOffsetX * 64 + (pos.x - pos.y) * (64 / 2);
int Y = mapOffsetY * 32 + (pos.x + pos.y) * (32 / 2);
 

11
Graphics / VertexArray Quads not rendering in the right color or place
« on: August 23, 2021, 11:45:12 am »
I am currently working on a RTS game with a minimap. Since drawing this minimap is eating around 20% of my CPU time. I thought of reducing the amount of draw calls. So instead of using a rectangleShape for every map tile I might try using a vertex array of quads instead. And only draw the vertex array going from 62500 (for a 250*250 tiles map) draw calls per miniMap layer update to one!

So I came up with the following code:

        static const sf::Color colors[] =
        {
            {0, 0, 0},
            {152, 205, 115},
            {200, 160, 80},
            {200, 160, 80},
            {200, 160, 80},
            {200, 160, 80},
            {200, 160, 80},
            {69, 164, 208},
            {69, 164, 208},
            {69, 164, 208},
            {69, 164, 208},
            {69, 164, 208}
        };


sf::VertexArray miniMapPoints(sf::Quads, MAP_HEIGHT*MAP_WIDTH);
            minimapTexture.clear(sf::Color(0, 0, 0, 0));
            for (int j = 0; j < MAP_HEIGHT; j++)
            {
                for (int i = 0; i < MAP_WIDTH; i++)
                {
                    sf::Vertex* currentMiniMapQuad = &miniMapPoints[(i * MAP_HEIGHT) + j];

                    currentMiniMapQuad[0].color = colors[currentGame.currentMap[i][j]];
                    currentMiniMapQuad[1].color = colors[currentGame.currentMap[i][j]];
                    currentMiniMapQuad[2].color = colors[currentGame.currentMap[i][j]];
                    currentMiniMapQuad[3].color = colors[currentGame.currentMap[i][j]];

                    //cords miniMapSpace(cords location)
                    //{
                    //    int wX = mapOffsetX * 20 + (location.x - location.y) * (20 / 2);
                    //    int wY = mapOffsetY * 10 + (location.x + location.y) * (10 / 2);
                    //    return { wX, wY };
                    //}
                   
                    //Each quad should be 20px wide and 10px high. We define them clockwise from the top left (x + 0 and y + 0)
                    currentMiniMapQuad[0].position = sf::Vector2f(static_cast<float>(miniMapSpace({ i, j }).x), static_cast<float>(miniMapSpace({ i, j }).y)); //0,0
                    currentMiniMapQuad[1].position = sf::Vector2f(static_cast<float>(miniMapSpace({ i, j }).x) + 20.f, static_cast<float>(miniMapSpace({ i, j }).y)); //1,0
                    currentMiniMapQuad[2].position = sf::Vector2f(static_cast<float>(miniMapSpace({ i, j }).x) + 20.f, static_cast<float>(miniMapSpace({ i, j }).y) + 10.f); //1,1
                    currentMiniMapQuad[3].position = sf::Vector2f(static_cast<float>(miniMapSpace({ i, j }).x), static_cast<float>(miniMapSpace({ i, j }).y)+10.f); //0,1
                   
                   
                    //miniMapPixel.setFillColor(colors[currentGame.currentMap[i][j]]);
                    //miniMapPixel.setPosition(static_cast<float>(miniMapSpace({ i, j }).x), static_cast<float>(miniMapSpace({ i, j }).y));
                    //minimapTexture.draw(miniMapPixel);
                }

            }
            minimapTexture.draw(miniMapPoints);
            minimapTexture.display();

I left the old working code for drawing the miniMapPixels in there for reference. And also added the commented out function miniMapSpace() to make clear what is happening.

I attached the result of the miniMap draw and the expected result.

                        currentMiniMapQuad[0].position = sf::Vector2f(static_cast<float>(miniMapSpace({ i, j }).x), static_cast<float>(miniMapSpace({ i, j }).y) + 10.f); //0,1
                        currentMiniMapQuad[1].position = sf::Vector2f(static_cast<float>(miniMapSpace({ i, j }).x), static_cast<float>(miniMapSpace({ i, j }).y)); //0,0
                        currentMiniMapQuad[2].position = sf::Vector2f(static_cast<float>(miniMapSpace({ i, j }).x) + 20.f, static_cast<float>(miniMapSpace({ i, j }).y)); //1,0
                        currentMiniMapQuad[3].position = sf::Vector2f(static_cast<float>(miniMapSpace({ i, j }).x) + 20.f, static_cast<float>(miniMapSpace({ i, j }).y) + 10.f); //1,1

I tried different orders of the currentQuad corner coordinates. Like starting on the bottom left. While this somewhat fixed the colors the map drawn is not correct. Eg water tiles are drawn where grass tiles need to go. And there is distortion the lower Y goes and the higher X goes. So last attachment.

I think the error lies in the order of assigning the four corners of the quad. But I cant figure out the right order.

And doing this:
currentMiniMapQuad->color = colors[currentGame.currentMap[i][j]];
 
Also does not get the correct result.


12
SFML wiki / Re: Simple Collision Detection for SFML 2
« on: August 18, 2021, 03:03:33 pm »
Sorry for bumping an old thread, but I've written a solution as an add-on to the collision detection from the wiki that checks a single pixel. Usefull for mouse interactions.


bool singlePixelTest(const sf::Sprite& Object1, sf::Vector2f& mousePosition, sf::Uint8 AlphaLimit) {

        if (Object1.getGlobalBounds().contains(mousePosition.x, mousePosition.y)) {
                sf::IntRect O1SubRect = Object1.getTextureRect();

                sf::Uint8* mask1 = Bitmasks.GetMask(Object1.getTexture());

                sf::Vector2f o1v = Object1.getInverseTransform().transformPoint(mousePosition.x, mousePosition.y);
                // Make sure pixels fall within the sprite's subrect
                if (o1v.x > 0 && o1v.y > 0 && o1v.x < O1SubRect.width && o1v.y < O1SubRect.height) {
                        if (Bitmasks.GetPixel(mask1, Object1.getTexture(), (int)(o1v.x) + O1SubRect.left, (int)(o1v.y) + O1SubRect.top) > AlphaLimit) {
                                return true;
                        }
                }
        }
        return false;
}

 

13
SFML projects / Re: Isometric RTS
« on: August 11, 2021, 10:25:13 pm »
The path finding can still be improved, like when you select all four people in the beginning and navigate them somewhere, it's interesting how two of them will move backwards first, probably because the other fields are occupied by other people.
There also seems to be some "recentering" going on, when you move someone from a task (e.g. getting wood) to walk somewhere. They first teleport to the next center of the tile, before moving to the wanted location.
In AoE the people can walk through fields, but here they seem to navigate around them. Maybe this is intentional?

When I first started the game, it loaded for a long time and then simply closed. But with the next run it works now. Do you generate something or write some file at first run?

One thing that can make the feel of the game a lot better, is if you provide indicators on the action. Like when I point someone to a tree, I get the same animation as if they are just walking there. As such I don't get the visual feedback, that I've just given them the command to chop trees.

The camera movement seems a bit annoying to me. I'd expect a fixed "border" (50-100px or so) inside the window that would move the world and not having the move the mouse outside the window. I'd even argue that moving the mouse outside the window should not move the world.

Also I'm really confused about the AI take over. :D
I was typing my response here and when I tabbed back to the game, all my villagers seem to have died and the AI has taken over in a different part of the map. :D

Interesting project:D

For me it started perfectly (without any loading).
After ca. 5 minute the fps dropped (to 1 or maybe 2?) and the AI took over (probably the same case as eXplOit3r described)
The second start was normal - fps-Droppes a few times, but more solid than the first one.
Thanks for the feedback.

The AI is controlling player 2. For debugging purposes I made tab temporarly a "switch player button". It can't get you back to player 0 (the human player) though.

On startup the game is generating a random map. It also does some checks to see if the map is indeed playable. It it finds the map unplayable (unable to spawn enough resources or actors near those resources) it will start over. It will try that a couple of times. Map generation actually had quite some bugs an quircks that got fixed the last couple of days.

On pathfinding: the routine is pretty simple right now 2d A* where two actors can't occupy the same tile at once. This sometimes leads to 'funny' routes being taken because one of the cells needed for the shortest route was occupied by another actor. You can actually see the paths and blocked cells by pressing the 'S' key.

The AI is also very scripted at the moment to a point that it can fall in a loop by giving villagers commands to resources they can't reach. In the new release actors keep an internal list of impossible tasks and would 'refuse' them. This frees up processing power from running unnecessary A* sessions. At the moment the AI is not reactive to this situation. I have to think of a way of catching such a stalemate and let the AI do something else instead.

A very busy dropoff point can also lead to stagnation and A* hogging resources until all the villagers have a route. This could also cause FPS drops. Having multiple actors on one tile would probably solve some of these issues. Or maybe letting the actors of the same team communicate and do a side step if that resolves a stalemate.

I do have to say that now minimap generation is not taking 50% of the CPU time slowdowns because of pathfinding or AI issues are less noticable

Here is a new release: https://github.com/switchboy/IsoRTS/releases

14
SFML projects / Re: Isometric RTS
« on: August 01, 2021, 02:19:23 pm »
I've done a lot of refactoring and expanding on the project recently.

The most important milestones are:
- There is now a framework for AI scripts to interact with the game
- There is a simple AI to play against
- Units have a fight or flight response when being attacked
- Added a mining camp (which can be used for stone and gold)
- You can now issue move commands on the minimap
- When giving a move order to an unreachable target the actor will try to get as close as possible (unless it is an order to build or gather, then it wil try to find an alternative)
- Lots of rework on the villager AI (searching for alternatives, reporting on activity or being idle, pathfinding)
- Fixed a lot of game crashing bugs (selection lists going out of scope)
- Going back to a mostly single threaded application for stability and prevention of weird behaviour of actors

Things I plan on doing in the near term:
- set some winning and losing conditions so it will be an actual game
- stacking of commands
- rally points for buildings
- handeling of a crowded resource or drop-off point that doesn't tank the framerate
- make the AI attack other players at certain conditions (which can be varied a bit to give AI some personality)
- make a menu to select the amount of other players, AI difficulty and AI personality



EDIT

I just compiled a new release! it has the following changes:
  • Fixed potential crash in distanceToResource()
  • Fixed selection box functions going out of scope
  • Allows stacking of commands by holding down the shit key:
    • A list of actions for a given actor is now generated if the order is given while holding down the Shift button
    • Execute list of stacked commands in order for a given actor
    • Show flags for stacked order targets for a given actor if the actor is selected and the actor is owned by the player


Get it here:
https://github.com/switchboy/IsoRTS/releases/tag/stacking

15
SFML projects / Re: Screenshot Thread
« on: July 22, 2021, 07:47:53 pm »
Updated my RTS recently with new building and features

(click the image to enlarge)

https://github.com/switchboy/IsoRTS/releases/tag/mining

Pages: [1] 2