Messages

1

General discussions / Re: Looking for Indie Rockstar Codah (+new user introduction)

« on: December 28, 2014, 11:30:22 am »

Are you looking for an experienced developer who gets the work done and is also easy to work with, or someone who calls themselves a freaking insane fukkin rockstar coder from outer space? Because sometimes those are two different types of people

Anyway, my main question is: Is this an actual job offer for which you will pay money, or are you looking for someone to code for free?

2

General discussions / Re: SFML 2.2 - Next-Gen Multimedia Capability Today

« on: December 11, 2014, 09:34:15 pm »

That's some rocket science stuff right there!

3

General discussions / Re: SFML 2.2 tagged in repository

« on: December 09, 2014, 08:12:07 pm »

Congratulations and thank you for the great work!

4

General / Re: Game Server Structure

« on: October 23, 2014, 09:36:08 am »

Players are allowed to jump thru portal every 5 seconds, so that's the reason of std::deque.

IMHO that's a bad reason. std::deque is used for fast insertions and deletions at the front and the back... but you said, you'd be removing from the middle. If that's the case, then std::deque is a poor choice and instead, as mentioned above it'd be more efficient to either stick with a linked-list or (in your particular case, because you're really just storing pointers) a standard std::vector.

std::list is bit useless because it's doubly-linked to object in front & back, but yeah it's effecient for large objects

Could you elaborate?

5

General / Re: Game Server Structure

« on: October 22, 2014, 09:36:04 pm »

It wasn't clear to me, thus my clarifying answer... but it's no problem, I didn't take it as offensive. Cheers

6

General / Re: Game Server Structure

« on: October 22, 2014, 07:48:36 pm »

Generally, using a linked list is preferred if you're removing very often from the middle - and especially if you're also storing a large amount of elements.

Actually you'd be surprised. Whilst theoretically list does do the removal quicker, the search for what to remove is still O(N) for both vector and list, and vector has better cache coherence so performs this search significantly faster due to less cache misses. Fast enough that vector can outperform list overall, simply because all those cache misses add up.

It's this reason that even himself advocates viewing vector as the default container, and only using a specialisation like list or set when needed (i.e you need iterates to remain valid after a remove) or when profiling shows you that the removal is costing performance and that the specialisation does indeed overall out-perform a vector.

I'm not entirely sure what's your point because I've already said that using std::vector for storing integer-sized objects will likely be cheaper than using an std::list. I read Bjarne's article about std::list in which he was basically encouraging people to think twice before using it because of the very same reason mentioned in the posts above - and I totally agree with him.

Besides, I know that the time complexity for finding the element is the same for both a linked list and an array - and that's why I said that it's always best to measure. Because the thing is, that adding an element in the middle of std::vector is another O(N) in the worst case - and if you're storing a lot of large objects, then copying/moving them will likely diminish any benefit of having the L1/L2 cache-friendliness of an array - and in fact would make linked list a much better solution.

That's also the reason I said that a lot depends on what you'll be doing with the data because if you only add/remove from the middle occasionally, then you probably won't gain much from using std::list - but if it's something that is done every game frame and especially on a container that is supposed to be storing large objects, then that's a different story.

7

General / Re: Game Server Structure

« on: October 22, 2014, 05:20:08 pm »

Yes, std::vector might prove to be cheaper if you're only copying objects of the size of integers and are not storing tens of thousand of elements. That's a special case though.

Generally, using a linked list is preferred if you're removing very often from the middle - and especially if you're also storing a large amount of elements.

That being said, I think it's best to measure it yourself. It may very well turn out that in this specific case using std::vector will be cheaper - if not, then using std::list should be your next choice - but then again, it all boils down to how you're planning to be using the data after you store it (i.e. how often you will iterate, perform random accesses and removals in the middle).

8

General / Re: Game Server Structure

« on: October 22, 2014, 04:20:42 pm »

so i assume theese are the most suitable containers for my needs.

std::vector<std::unique_ptr<entity::Actor>> m_npcs;
std::deque<std::unique_ptr<entity::Actor>> m_players;

std::vector = there is only static amount of npcs that respawns on death
std::deque = because player can change his/her map, so i need to delete in middle

If you're deleting stuff in the middle of a container, you'd be better off using std::list - after all, that's what it's for.

9

SFML projects / Re: The 8-Bit Encounter - My Open-World 2D Game Demo

« on: October 21, 2014, 11:54:57 am »

Annoying song, amazing tech, seems really promising!

Thanks! I like the trailer music, though I'm still considering whether there should be any in-game background music during the world exploration (i.e. while not in buildings/caves etc). Mostly because it may become too tedious after a while.

Where is the music from?

The music was made by bart from OpenGameArt.

10

General / Re: Game Server Structure

« on: October 21, 2014, 09:54:03 am »

I think you didn't understand what Gambit was talking about. Storing everything in RAM doesn't make your data persistent - it'll be gone the moment your std::map is destroyed (either by going out of scope or by closing your application, for example due to a server reboot).

Now, depending on your game, this may be or not a desired behavior. If your game is like an MMO or needs to keep players' stats, then you'll want state persistence, so saving the game state to a file or a database is the way to do it. However, if each multiplayer session is unique and you don't care about tracking any information about the players (and thus everyone always starts from the beginning and the entire map is reloaded every time a new game is hosted), then I guess you could get away without the database.

From your vague description, it seems like you're making a persistent world (at least that's the impression I got), so if that's the case, you'll need some persistent storage for storing your persistent data and storing it in RAM doesn't solve the problem.

11

SFML projects / Re: The 8-Bit Encounter - My Open-World 2D Game Demo

« on: October 21, 2014, 12:31:54 am »

I made a short video, presenting a part of the new upcoming tech demo. At this stage, the game is still very bare-bone, but a lot of the new engine features are already there.

12

Graphics / Re: stuttering on some hardware, not others

« on: October 19, 2014, 11:04:00 pm »

I was just about to post a similar thread. After upgrading to the newest SFML revision, my game started to stutter. I experimented with different settings (choosing different framerate limits etc) but the program was still stuttering no matter what... After reading this thread, I decided to turn threaded optimization off on my Nvidia Optimus setup (it was enabled by default) and, to my surprise, it really fixed the problem

13

General / Re: Lua Integration Affecting Performance

« on: October 19, 2014, 11:17:51 am »

I didn't intend on including any wrappers at first because technically you don't need any to integrate and run Lua with C++, but now I wouldn't mind to try a few out.

I personally switched to luawrapper for the next version of my game. It has a simple API and according to the author, it generates clean assembly code.

14

General / Re: Game Server Structure

« on: October 18, 2014, 05:21:46 pm »

A simple solution could be to access the map directly - for example, by creating a Service Locator as a singleton, which would hold a pointer to the map (or an array of maps).

Also, I have two questions after looking at how you store your maps and entities.

• Why are you using std::map for storing maps? Your keys are enum values, which can be directly casted to integers - you could just use std::vector, resized for the total amount of enum values and then just access the maps directly with the access operator. This way you could get rid of the overhead of using the hashing algorithm every time you access the element in the map (although, in case of integers it's negligible... but still).
• Is there a particular reason to store entities in std::deque? Are you adding or removing the entities from the front? If not, then using std::vector instead would have less overhead too, and would be more efficient for CPU cache.

15

General / Re: Lua Integration Affecting Performance

« on: October 18, 2014, 11:10:46 am »

I think the reason why your framerate drops might be because you're running your Lua state on the rendering thread. Obviously, as stated above, you should profile and see what's really bottlenecking your code.

As a side note, is there a particular reason for using raw Lua in your engine? There are plenty of pretty good Lua wrappers for C++, which take care of threading Lua state automatically (and thus offloading the rendering thread).