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

Pages: 1 [2]
16
Graphics / Re: Creating simple 3D objects SFML
« on: April 21, 2019, 02:01:07 am »
Thank you for the video link, it is an exact replica of the kind of 3D rendering I am doing.

17
Graphics / Re: Creating simple 3D objects SFML
« on: April 20, 2019, 08:37:11 pm »
Thank you for the help!

18
Graphics / Creating simple 3D objects SFML
« on: April 20, 2019, 06:39:41 am »
For anyone who wants to create simple, rough, and fast 3D models I found a method from Scratch (thanks to kevin11) that works perfectly in SFML. If you separate a 3D object into 2D layers you can stack these layers to create a 3D effects and you can even rotate the objects along the y-axis. This can and will, however, be a bottleneck in your program. If there are any ideas on how to optimize this process they would be very helpful.

19
Network / Shifting sf::Packet into another sf::Packet
« on: April 16, 2019, 05:57:49 pm »
Is there any way to shift a sf::Packet into anoter sf::Packet as seen below(figure1)? I am trying to setup a function that takes a sf::Packet as an arguement, stamps a name on the packet, and then sends it to a client. The problem now is that all that data in the data variable(figure 2) is lost when the data variable is shifted into the newPacket variable.

sf::Packet data;
std::string name = "Bob";
int age;
data << bob <<age;

sf::Packet FinalPacket;
std::string PacketType = "Name";
FinalPacket << PacketType << data;
 



figure 2
bool SFMLNetwork::sendUDP(sf::Packet data, std::string Type, sf::IpAddress receiver, unsigned short rcvPort)
{
        sf::Packet newPacket;
// not sure if data can be shifted into newPacket
        newPacket << Type << data;
        if (UdpSocket.send(newPacket, receiver, rcvPort) == sf::Socket::Status::Done) {
                return true;
        }
        else {
                return false;
        }
}

 

20
Network / Re: Question about: Socket Selectors and UDP
« on: July 15, 2018, 06:27:32 am »
After reading the "SFML Essentials" book I realized that the udp socket receive command needs an sf::IpAddress and unsigned int(port number) so that it can write the sender values to the ip and unsigned int. Because of this confusion I thought a receive command would have to be called for every client( udp.receive(packet, clientIP, clientPORT) ) with the client's IP address being the clientIP variable and the client's port number being the clientPORT variable. I now know the receive command writes values to the sf::IpAddress and port instead of reading them. Sorry for the all the confusion.

21
Network / Re: Question about Socket Selector and UDP sockets
« on: June 10, 2018, 11:28:09 pm »
From my basic understanding of sfml's networking library and networking in general, TCP requires a connection while UDP does not. When you call the send command for TCP it tells the other end that there is a packet coming, waits for a reply, then sends the package, waits for conformation that the package was received, and then continues with it's business. Due to TCP requiring a connection between the client and server you often need to have multiple sockets (usually one for each client).

UDP, on the other hand, often just sends the packet without notifying the receiver that it is going to send a packet. Due to this lack of connection between the server and client UDP only requires one socket to receive and send data.

The reason socket Selectors exist is to prevent socket blocking (mainly with TCP) from becoming a problem. With the socket selector you can poll the status of and receive from many sockets without having to wait on any one socket to receive data. Using UDP with a socket selector would be pointless because there's only one socket (the receiving and sending socket) meaning there aren't any other sockets to block. Because of this, you should probably just store the IP address of each client since you can't make a socket for each client with UDP, you can only make one for the receiving and sending end of the server.

TLDR you should just store the IP's of the clients.

22
Network / Question about: Socket Selectors and UDP
« on: June 07, 2018, 05:14:01 pm »
I'm currently working on an "Soul Knight" esk (top down shooter) game and I decided to use UDP for networking amongst players. The only problem is I don't know exactly how I should receive packets simultaneously from multiple clients on the server. Right now I have a loop going through a list of all the client IP's and client Ports calling receive commands for each client. For each packet I store a copy of it in a std::vector list. Should I continue to use this method for receivin data or use a socketSelector or some other method?

Pages: 1 [2]
anything