Messages

1

Network / Re: Receiving packets: while(socket.receive()...) vs. if(socket.receive()...)

« on: December 01, 2018, 07:07:35 pm »

With 'if' you only process one packet. If there are several waiting (in the system buffer) then they'll have to wait until the next few iterations of your game loop -- yes, this is latency

Thank you very much, that clears things up! 

As a follow-up question, I just noticed something odd (not sure if this goes beyond the scope of SFML). I'm currently testing my networked program by running two instances of it, one which hosts and connects to itself via LocalHost in the same process, and the second which connects to the first via LocalHost as well.

Things appear to work when I test things with two instances of the GCC-compiled executables. However, when I try it with two MSVC-compiled executables, there is a significant delay in the packet sending. Interestingly enough, it also works if I try a MSVC host and a GCC client, but the other way around still lags. It's the exact same code, so I'm assuming MSVC is doing something non-standard. Are there any known quirks that would explain the discrepancy in behaviour between these two executables?

Edit: nevermind, I have found the issue. Thank you again for your time!

2

Network / Re: Receiving packets: while(socket.receive()...) vs. if(socket.receive()...)

« on: December 01, 2018, 01:56:45 pm »

That's why I created this topic 

I'm currently using both a mixture of TCP and UDP sockets for a personal project (TCP only for the few, occasional packets I send that need to be guaranteed to arrive, UDP for position updates) . I'm using both in non-blocking mode, so I'm not sure exactly what effect the change really had. It didn't change any other behaviour; all that happened was that the delays vanished. Sorry if I'm missing something simple, this is my first foray in network programming.

3

Network / Receiving packets: while(socket.receive()...) vs. if(socket.receive()...)

« on: December 01, 2018, 10:04:11 am »

I was experiencing some issues in my current project with latency delays while testing locally. Then I came upon this thread, specifically this message:

https://en.sfml-dev.org/forums/index.php?topic=12011.msg91201#msg91201

Changing my if's to while's fixed it. I was just wondering why it made such a huge difference. Is this a bug, or is there an intentional reason/explanation for why this occurs?

Thanks!

4

Graphics / Re: Fixed viewport possible?

« on: June 08, 2016, 03:17:01 am »

Thanks Laurent, it worked like a charm.

5

Graphics / Fixed viewport possible?

« on: June 06, 2016, 08:53:02 pm »

I have a view used to draw the black bar at the bottom. I want that black bar to have a fixed size, and to always be in the bottom-center of the window. By default, the window size is as such, and everything is fine:



What I WANT to happen when I increase the size of the screen is have the black bar remain the same size:



But instead, the black bar scales to the new window size (due to SFML viewports being defined as a ratio of the screen) and this happens:



Is there a solution for this, or is it impossible due to the way SFML's viewports work?

6

SFML projects / Re: Screenshot Thread

« on: January 23, 2016, 05:29:27 am »

A lot of things have been added to xviii since last post:

-Units and factions are now fully creatable and extensively customisable via .txt files. Their sprites can also be created as .png files. You can also define bonuses/maluses on certain terrain tiles, for certain units, under certain conditions, etc.

-Visual ranges, as well as dynamic weather changes and time passage (which both affect visual range), with 1 turn representing 15 minutes. Beyond a certain point, units cannot be made out very well and their positions may not be fully accurate. Beyond even that, they are completely undetected.

-Lots of other minor neat things, like engineers being able to construct [destructible] bridges, and other stuff I can't remember. Gameplay is much more tactical and deep than it was.

My biggest regret was not going with ECS from the start. This deep into development, it would be a nightmare to rewrite everything. OOP is sometimes giving me problems, but I work around them as much as I can, and I consider the whole project an ongoing lesson.

We are currently working on a UI update that will make everything far more user-friendly. Menus are being worked on first, then the custom battle interface.

7

General / Re: Merging multiple image files

« on: August 01, 2015, 09:52:29 pm »

Are you talking about a texture atlas?
It's very well possible to do this with a render texture.

Whether it really makes sense in your situation is another discussion though.

A texture atlas is exactly what I meant. I was not familiar with the term for it.

After doing a little reading on RenderTexture (having never used it before), it indeed does not make much sense for my situation, since I don't want everything in it to be drawn. What I basically want is to create a texture atlas (as a regular sf::Texture) out of multiple images dynamically at runtime, in order to avoid the overhead of lots of different small images.

8

General / Merging multiple image files

« on: August 01, 2015, 09:36:33 pm »

At the moment, for my current project, I store all the sprites needed in a couple of image files, which act as sprite sets. So, for example, in units.png I'll have the different sprites needed for unit type 1, unit type 2, and so on.

The drawback to this is, of course, is that you have a limited subset of sprites to work with, since they all have to be present in that one image file at runtime; adding new ones will involve manually editing it, which is error-prone and a hassle. As far as I'm aware, it's inefficient for the GPU to have a different image file for each different sprite (especially when you have a lot to work with, as I do). However, I want it to be easy to dynamically add new ones - without that overhead of having plenty of image files. The idea I have is to do just that, give each unit its own sprite, but to merge them all into one big, cached image file at runtime - but SFML does not seem to have this capability. Is there a way to accomplish this, or perhaps a different solution altogether?

9

SFML projects / Re: Screenshot Thread

« on: May 17, 2015, 12:11:35 am »

Here are a couple of screenshots from my current (and first real) project, developed with the ideas and input of a friend. It is a turn-based, military boardgame-style game set in the 18th century that uses modified NATO symbols to represent units. The terrain art is a placeholder and not ours, but will be redone from scratch eventually.





Current features include a wide variety of selectable nations and unique units, the ability to save (which allows for hotseat style multiplayer), working melee & ranged combat with rules, and randomly generated terrain (incomplete; needs some more terrain types and actual effects on units).