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 5 ... 13
31
Hello SFML community,
my name is Vittorio Romeo and I'm a Computer Science student.

This year I've attended CppCon2014 and gave a talk about game development (almost) from scratch using the newest C++ standards (C++11 and C++14) and SFML.

The goals of the talk are showing how easy it is to use modern C++ to create a game and encouraging everyone to try game development.

I hope you'll find it interesting!



I'm always open to feedback :)

32
Feature requests / Re: sf::Text::setTracking(int)
« on: October 02, 2014, 10:28:49 pm »
Quote
Still, it could be implemented on top of SFML if required
Hmm... with one sf::Text instance per letter? :-\

Yeah, that's the issue, unless your reinvent 'sf::Text'.
I propose that the addition of a 'tracking' field would be good enough.

If you wanted SFML users to have more control, though, for the future version you should consider allowing users to pass a functor/lambda during text draw/update that is called on every single glyph, or something like that.

33
Feature requests / Re: sf::Text::setTracking(int)
« on: October 02, 2014, 08:30:00 pm »
Laurent is correct. Tracking is not kerning and it is trivial to implement.

I find it useful because it looks really good when used properly.
A simple example would be a level introduction white screen with a black serif font and an high tracking value.
It just looks nicer.

Another idea that just came in my mind is using tracking to make text expand/shrink in animations.


34
Feature requests / sf::Text::setTracking(int)
« on: October 02, 2014, 03:43:44 pm »
It would be really helpful if we could specify a `tracking` int value in `sf::Text`.
All glyphs would be moved apart from each other by `tracking`.


35
SFML projects / Re: Open Hexagon - challenging fast paced game
« on: July 01, 2014, 07:13:30 pm »
Mathias Thomsen, an awesome Open Hexagon fan, is running a 24 hour charity marathon stream:


Check it out!

36
SFML projects / Re: operation bloodshed - (WIP)
« on: January 30, 2014, 05:50:25 pm »
Recursive functions?



Recursive weapons.

37
I've uploaded the fourth episode of "Dive into C++11" on my YouTube channel.

|| Playlist

After looking at C and C++'s memory and lifetime management in part 3, we'll take a brief look at C++11 smart pointers. We will learn what they are, what problem they solve, their advantages and their uses.

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 may be very interesting for pre-C++11 users who want to learn modern C++11 memory management, but it is also suitable for beginners.

I greatly appreciate comments and criticism, and ideas for future videos/tutorials.

Feel free to fork/analyze the source code at: https://github.com/SuperV1234/Tutorials

38
SFML projects / Re: operation bloodshed - (WIP)
« on: January 02, 2014, 04:49:18 pm »
new devlog - (text editing, GUI styling, new particles)



Quote
http://vittorioromeo.info
Devlog: http://forums.tigsource.com/index.php?topic=36131.0
GitHub: https://github.com/SuperV1234/SSVBloodshed

In this video I'll show new minor features and changes for operation bloodshed.

Apart for fixing crashes and bugs (and optimizing the game even more), text editing is now fast and easy (comparable to your favorite text editor).

GUI elements can now be styled and they adapt to the font being used.

Particles are now loaded from easily editable .json data files, so that players can customize particles.

Example of particle file:
https://github.com/SuperV1234/SSVBloodshed/blob/master/_RELEASE/Data/Particles/bloodRed.json

A new particle parameter, "fuzziness", has been added, which basically randomly moves around vertices. It works very well for explosions, smoke, and sparks.

I haven't added any new element since I've been experimenting with other projects.
I've created an assembly language and virtual machine that I will probably show in a future video, and also fixed many Open Hexagon 2.0 bugs.

Thank you for watching!

39
I've looked at part 3, and it's really nice how detailed you explain everything. Also the comments in the code are very useful.

Some remarks:
  • You could use size_t for indices, to avoid conversion warnings on some compilers.
  • In the NaiveVector, the condition should be if (capacity <= size) instead of if (capacity < size). Imagine the case size == 1: After writing the element size will be 2, but you don't reallocate the array, so the next time you have the invalid index access ptrToArray[2]. Likewise, the copy loop accesses an element out of range, since size > capacity. In fact, size should never be bigger than the capacity.
  • Less important: It might be meaningful to reallocate at the beginning, so you only do it when necessary. I personally also find if (size >= capacity) more intuitive, since the variable you query and which you have just changed appears first.

Thanks for the feedback. I've made the changes to code.

40
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!

41
Again, thanks to everyone for the feedback.

I've uploaded the third episode of "Dive into C++11" on my YouTube channel.


Playlist

In this episode we'll take a break from game development to delve into C and C++'s memory and lifetime management. We'll talk about automatic variable lifetime, pointers in general and dynamic memory allocation.

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 may be very interesting for those with experience with C++ who want to learn more about variable lifetime and memory management.

I greatly appreciate comments and criticism, and ideas for future videos/tutorials.

Feel free to fork/analyze the source code at: https://github.com/SuperV1234/Tutorials

42
SFML projects / Re: operation bloodshed - (WIP)
« on: December 08, 2013, 05:21:57 pm »


Spent most of my day working on automatic console formatting.
Basically, you can define template specializations that get automatically called when sending a certain object type to the log stream:

template<> struct Stringifier<ssvs::MBtn>
{
    using T = ssvs::MBtn;
    template<bool TLogify> inline static void impl(const T& mValue, std::ostream& mStream)
    {
        // TLogify determines whether to apply formatting or not,
        // since the same "Stringifier" object is used for simple toStr(...) conversions
        if(TLogify) mStream << Console::setColorFG(Console::Color::Green);
        mStream << "(" + ssvs::getBtnName(mValue) + ")";
    }
};
 

Also, I've adapted my naive GUI system to work with any font, as shown in the screenshot.

43
Ill copy and paste the same i commented in youtube:

I see the constexpr functions like "inline functions" with the only difference they can be used to declare an array because the "compile-time" feature

`constexpr` allows compile-time computation: I don't think the standard allows (or prohibits) simple inline non-`constexpr` functions to be computed at compile-time. It's also useful for compile-time meta-programming and stuff like tuple unpacking and tuple searches.

`inline` functions are not really comparable to `constexpr`, in my opinion. Also, `inline` functions are not only a (probably deprecated) way of suggesting compiler optimizations, but they also have the (in my opinion, very useful) feature of allowing multiple definitions of the same function, as long as the body is exactly the same. In fact, I use (abuse) `inline` functions all the time in my header-only libraries.


44
Thanks to everyone for the feedback!

I've uploaded the second episode of "Dive into C++11" on my YouTube channel.



Playlist: http://www.youtube.com/playlist?list=PLTEcWGdSiQenl4YRPvSqW7UPC6SiGNN7e

The video is quite long - if you want to skip to the parts you may find most interesting, here's a schedule:

Quote
0:00 - constexpr addendum
3:20 - uniform intialization syntax addendum
10:10 - 1st segment (const-correctness, noexcept, event polling)
19:40 - 2nd segment (FPS and Frametime management)
34:15 - 4th segment ("time-slicing" for consistent logic with any FPS)
45:10 - 5th segment (refactoring)

In this episode we will learn more about two previously mentioned new awesome C++11 features: "constexpr" and "uniform initialization syntax".

Most importantly, we will also deal with a very big issue that every game developer must face: FPS/frametime, and how to avoid the game from behaving differently on slower/faster machines.

In addition, we'll also briefly learn about "const-correctness" and using the "noexcept" keyword.

We will analyze the "time-slice" method to allow the game to run smoothly and consistently on every machine.

In the last code segment, we will also "refactor" our code by creating a `Game` class, making our source much easier to read and maintain.

I greatly appreciate comments and criticism, and ideas for future videos/tutorials.

Feel free to fork the game's source code at: https://github.com/SuperV1234/Tutorials

45
I have now watched the video too, and I really like it! :)
It's great how you keep the code simple and short. You explain and visualize it very well, by showing the effect of each code part (and even a collision diagram).

Some remarks (most of them are just minor, your video is really good):

Thanks for the feedback, I'm glad you found the video interesting.



  • The SFML game loop requires event handling with pollEvent(). Depending on the operating system, the window may freeze otherwise.

Totally forgot about this! I added an annotation.



  • You could also mention that in game development, it's common to have a frame time parameter passed to update(). Maybe it would be too much to actually use it in the example, but just as a sidenote...
  • The getter functions such as x(), top() etc. could be const-qualified, as well as the parameters here: isIntersecting(const T1& mA, const T2& mB). Same for testCollision(const Paddle& mPaddle, Ball& mBall).

I wanted to keep the video as simple as possible. I will probably improve the existing code in future videos, and I will deal with const-correctness and frame time.



  • using namespace simplifies the code in your case, but it would be good to mention its disadvantages for larger projects. Without it, it might also be a bit clearer whether a function/class belongs to SFML or the standard library. But I think it's fine in your case in order to keep the code minimal.

Again, I chose to use using namespace for simplicity. I will deal with its drawbacks in future videos.



  • The header #include <SFML/Graphics.hpp> already contains <SFML/Window.hpp>.

Didn't know about it, guess it doesn't hurt to include it anyway.



  • constexpr is nice, but from the video it's not clear why you didn't simply use const, as the effect would have been the same. But you explained it in your last post. const int size = 43; is already a constant expression; the power of constexpr lies in functions.

True, I didn't show the "real benefits" of constexpr. I may do some "quick" videos about C++11 feature, where I show where they can be most useful.

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