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

Pages: 1 [2] 3 4 ... 13
16
Hi Vittorio,
thanks for the videos. Really enjoying folloing them  ;)

Thank you!



Update: I've finished writing the source code for part 4 of the tutorial.
Since I'll be busy this week it will take a while before I start recording.

The source code is available here. If anyone is not currently busy, I'd really like to hear some feedback on the code before I start recording, so that the quality of the final video could improve. Thanks!
This one. Sorry, I must have clicked on the wrong page.

Whoops - you're right. I've moved stuff around in the repository.
You can find "4_SmartPtrs" here:
https://github.com/SuperV1234/Tutorials/tree/master/DiveIntoC%2B%2B11

17
The link doesn't seem to work. It comes up with a 404 this is not the page you are looking for.

What link?

18
Thanks everyone for the feedback!

1) In Episode 2 (about Frametime and FPS) is there a benefit using std::chrono instead of sf::Time? I am researching about Game Loop and Game Time and I am still trying to find the best approach. BTW I really liked the Fixed time slice approach.

I don't think there is a particular benefit - I was trying to be as standard-compliant as possible and use modern STL features.



2) Based on Episode 5 (Game entity management basics) I wanted to make a space invaders clone.
I expanded the p9.cpp and created my game. The problem is that I haven't figured out how to create Entities in real time. For example when player presses the space bar, a bullets gets fired from player ship. (Maybe I need to brush up my C++ skills  :-[)

Create a function similar to `createBrick` and call it during your game loop - you can do it after spacebar is pressed, for example.



  • Base classes that aren't instantiated should be abstract, corresponding virtual member functions pure.
Classes that derive from abstract classes explicitly require to define the base class's abstract methods.
In my design, components can often have an empty `draw` or `update` implementation - forcing the derived type to implement an empty version of those methods is not something I want to do.



  • You could show std::make_unique() (C++14). emplace_back() with raw new
    is not exception-safe, leading to possible memory leaks. In general, I would avoid new where possible -- especially if you wrap the pointer in a smart pointer anyway.
This is correct - the `new` keyword should never be used (unless we're using "placement new").
Unfortunately the video is targeting the C++11 standard, so I can't use `std::make_unique` in it.



  • Calling a parameter mArgs is rather unusual; the "m" prefix is commonly used for members.
I've received the same feedback on my naming conventions before, and you're probably right - "m" could seem an abbreviation for "member".
The truth is that I'm really really used to this naming convention so it would take a lot of time and "find-replace regexes" to change it - I'll think about it.


  • You use both abs() and std::abs(), the latter is correct.
Correct, will fix this as well in the GitHub code.

19
General discussions / Re: static analysis of SFML
« on: April 11, 2015, 10:15:28 pm »
Could you post the complete log?

20
It will certainly work, but it seems unnecessarily inefficient and complex.

`std::typeid` and an `std::unordered_map` have a significant runtime overhead. Also, you cannot use `noexcept` to allow even more aggressive compiler optimizations.

I don't think it can get much faster than a bitset lookup for component availability checks and a direct array access to retrieve a component of a specific type.

A possibly even more efficient version could use a variadic list of component types passed in the manager (which would be a template class) so that appropriate data structures and unique IDs could be generated at compile-time. But I don't think it would be much faster than the implementation I show in the video.

I'm also a little perplexed by the use of `std::list` (which is highly not recommended by Bjarne itself, because of its cache unfriendliness), `std::weak_ptr` (wouldn't a raw pointer do the trick here?) and `std::function`, which, again, has some runtime overhead.

Instead of passing an `std::function` to `EntityManager::ForEach` you can simply add and use a template parameter for the passed function type, which will have no runtime overhead.

Your design and implementation is probably fine for any kind of game that has a small amount of entities... but I really like to make my life harder by trying to squeeze every last bit of performance in my code.
It feels rewarding and I always learn unexpected things about efficient code :)

21
Hello everyone! I've just finished uploading the latest episode of "Dive into C++11".

http://www.youtube.com/watch?v=QAmtgvwHInM

In this episode we'll see various ways of implementing entity management in your games, starting with a very simple "one vector per object type" approach. We'll consider a "polymorphic inheritance tree" approach as well, and finish the video by re-implementing our Arkanoid clone with a simple but effective component-based design.

The goal of the episode is showing the thought process behind the design and improvement of an entity management system.

The intended audience for this tutorial/screencast are people who have some experience with C++ in general, and who watched the previous episodes. This episode also teaches the basics of polymorphism and component-based design.

Hope you'll find the video interesting!
I greatly appreciate comments and criticism, and ideas for future videos/tutorials.

22
General discussions / Re: C#/C++ comparison
« on: March 06, 2015, 11:46:46 pm »
That's true, sorry if it sounded like I was attacking you.
But it looks like you're trying to say (even if this is not your intention): "Aha! I finally proved that C++ is not faster than C#!" ... without even posting the code of your benchmarks.

I should have chosen better words.
Anyway, could you post the code of your benchmarks?

23
Check out my tutorial series:
https://www.youtube.com/watch?v=_4K3tsKa1Uc

I strive to use modern C++11/C++14 features and write idiomatic, safe and efficient code.

Quote
This is my first attempt at a complete C++11 game development tutorial.

In about 40 minutes we will create an arkanoid/breakout clone from scratch, using the Standard Library and SFML 2.1, an amazing easy-to-use library that handles GFX, SFX and input.

The video tutorial was extremely well received by the C++ community.
I even transformed it into a 60 minutes talk that I gave at CppCon 2014, in Bellevue:
https://www.youtube.com/watch?v=TC9zhufV_Z8

The CppCon 2014 video has some additional slides and diagrams that may help you even more.

Hope you find it useful!


24
General discussions / Re: C#/C++ comparison
« on: March 06, 2015, 09:04:40 pm »
How about posting the code for both C# and C++ implementations before drawing conclusions?

25
Graphics / Re: Random Offset of scene [LinuxMint SFML git]
« on: February 28, 2015, 06:08:53 pm »
Really sorry about forgetting to mention the _RELEASE folder detail.
So, what could the issue be? GPU drivers, maybe?

26
Graphics / Re: Random Offset of scene [LinuxMint SFML git]
« on: February 27, 2015, 02:38:56 pm »
Just tested out master on my Arch x64 VM with XFCE4 and XFWM. Everything seems to be running fine...


If you have enough time, could you try cloning and building one of my projects that have this issue?
https://github.com/SuperV1234/DelversChoice
(clone, use ./init-repository.sh, then build with CMake)

Some projects present the issue, some don't - but I can't find a significant difference in the window-creation/rendering code


27
Graphics / Re: Random Offset of scene [LinuxMint SFML git]
« on: February 26, 2015, 03:12:01 pm »
Does trying out any of the commits I listed here resolve the issue?

Issue still occurs with f162857 and f464e25.

The issue **does not occur** with commit 19920f5!


28
Graphics / Re: Random Offset of scene [LinuxMint SFML git]
« on: February 24, 2015, 11:14:30 pm »
Having the same issue, using Arch Linux x64, XFCE4 and XFWM4.
Only happens with the git version of SFML.

3/4 of the window are corrupted:


29
Nice video.

In my current project, I'm storing my entities in a heap (vector of unique_ptr).

Storing the entities cintiguously sounds interesting. but I'm wondering if sorting the atoms, marks etc. might turn out to be more inefficient than using a heap.

What if you don't delete the dead entities, but keep track of their index in a vector and just overwrite them, when you create new entities. That way each entity would keep its index.

Thanks for the feedback.

The advantage of storing the entities contiguously is cache-friendliness, which makes iteration very efficient.
I'm already "recycling" dead entities, as I'm not deallocating/reallocating any memory. The control counter is there to make sure that recycled entities are not mistaken for the entities they were previously.



What problem have you solved? It seems like a solution to a non-existent problem.

You are asserting that the new approach is better but I don't see any reason to believe it. I was going to call it "premature optimization" but you haven't actually optimized anything, where is the analysis that proves the new system is more efficient? All you have is a code comment that says it's better.

If you are going to optimize something, then start by taking a real problem or at the very least an abstracted version of a real problem and apply your solution there so that you can show the data reflecting the improvement.

Thanks for the feedback.

It isn't a magical "solution to a problem", it's more of a different approach to entity management to increase iteration speed and still retain the possibility of tracking several entity instances.

Using a vector of unique pointers is still the easiest (and sometimes best) solution for games that do not require particular iteration efficiency.

There are many studies/, slides and benchmarks online (done by AAA game developers, as well) that show how important is cache-efficiency for game development. Just look for "data-driven design" and "cache friendliness" on google.


30
I'll resurrect the thread with a new video that game developers could find interesting:

"If I want to store entities contiguously to improve efficiency, how can I keep track of them?"

http://www.youtube.com/watch?v=_-KSlhppzNE

In the video, I show two possible ways of dealing with entity storage and management:
  • Storing entities on the heap. Entities are easy to keep track of, but iteration is inefficient. Very easy implementation.
  • Storing entities contiguously. Iteration is cache-friendly, however it is hard to keep track of specific instances. Complex implementation with custom handles.

Hope you find some of the concepts in the video interesting!
I'm looking forward to your feedback and to more ideas on entity management.

Pages: 1 [2] 3 4 ... 13