Advertisement Jump to content
  • Advertisement


  • Content Count

  • Joined

  • Last visited

Community Reputation

178 Neutral

About Bleys

  • Rank

Personal Information


  • Twitter
  • Github

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. I'm staring programming stream today: Target audience is people with some programming experience (who know what are variables, loops, functions, etc...), though not necessarily any with C++. We'll be starting from scratch. I'll do at least 5 streams and then decide what to do. Let's see where this takes me.
  2. Bleys

    SDL Game Engine Development (C++)

    Tip #1: Don't use SDL. Use GLFW/GLFM instead of SDL. Or why not something even more powerful like SFML?... If you still think you have to use SDL, don't be tempted to use anything more than window creation, input management, and GL context initialization. This means NO SDL Image, NO SDL Mixer and especially NO SDL net. While these seem tempting and they do kinda-sorta work, they are too limited and most of all absolutely not multi-threading friendly. SDL is one of those nasty globally thread-unsafe libraries. NO SDL call is thread-safe. This includes window creation and input management, but those are generally OK to use in a single thread (the main one). Tip #2: Don't write your engine. Create it out of existing components. The world is full of wonderful libraries for graphics, networking, sound (well not that many of those but there are some), asset management, navigation, UI, object management, and everything else. Writing even a fraction of these is a monumental effort bound to take years. If you want to come close to something near a success, use these a lot. Focus on architecture and try to combine these libraries in a single engine. Contribute to them rather than reimplementing them. You will learn more, you will get ahead and won't get stuck in reinventing the wheel for the thousandth time. Tip #3: Don't even create an engine. Create games instead. Creating an engine for the sake of creating an engine is bound to fail. Instead create games and learn from your mistakes along the way. This will help you have actual real-life use-cases for the engine. This will be a learning experience in creating software instead of in implementing isolated features. I'm sure you can create decent shadow maps. Can you do it for a whole city? Having concrete milestones is a huge motivator and a great way to measure progress. And what better milestones than games. You're no game designer? Well create a tetris game. Create a 3D tetris game. Clone a simple first-person shooter. Create a simple racing game. Add multiplayer to those. By the time you're finished with this list, you won't be needing tips any more.
  3. Bleys

    C++ Gameplay in C++

    Who writes gameplay in C++? I recently wrote an article in codeproject which describes some benefits of this (from a more general purpose perspective), but I'm curious for other thoughts on the subject. If you write engine code in C++ but the gameplay in another language, what made you take this decision? If you do write gameplay in C++, are you happy with your decision? Share some cool stories about it. Bonus points if you write gameplay code in C++ and engine code in another language
  4. Simple C++ reflection with CMake - for engines of all sizes! A friend wrote a blog post about how to add reflection to C++ codebases without heavy template metaprogramming or external tools such as LibClang — you can check it out here:
  5. There's a C++ library I'm developing and while it's not specifically targeted at games, all projects that I know of which use it are games. It's called DynaMix. In short it allows you to compose and modify polymorphic objects at run time. This has proven to be rather useful in gameplay programming. Compared to more traditional ways to write gameplay, like scripting, it has some benefits (well, and some drawbacks). It's C++ so it usually is at least a bit faster (and in the cases that I know of a lot faster) and less power consuming than scripts You can reduce code complexity when you don't have a C++<->scripting language binding layer. You can reuse utility code between the core and gameplay subsystems (instead of having to rewrite it in the scripting language. Hotswapping is supported relatively easily achievable Still, it's C++ so I guess it's a bit harder to write, and impossible to delegate to game-designers and other non-programmers Because of this it has found a niche of sorts in mobile games, where the benefits from the performance and smaller power consumption outweigh the fact that the gameplay code is strictly programmer country (whereas desktop/console developers, might be less willing to pay this price) The repository is here: The docs are here: I have written about it before back when it used to be called Boost.Mixin. I have since rebranded it and removed the dependency on Boost. Recently I released a new version and I'm using this as an opportunity to gather more feedback and, perhaps, maybe new users. So, any comments and questions are welcome
  6. There is a library that gives you such duck typing in C++ allowing you to have a middle ground decision if you don't want to sacrifice the performance when you use a scripting language. The library is made for the Boost collection, but it's not a part of it yet. It's pending review. Docs link: Source link:
  7. I am working, along with 3 other programmers, on a closed source project - a 2d tactics mobile game that's still under development - with it and, having met no problems using it (performance or design), it has proved useful many times in defining the game's logic. The code is clean and readable. Making changes (even rare big ones) is easy and concentrated, and one of the main bonuses is that you can very easily temporarily disable or change entire parts of the game for testing. For example having all attacks deal 1 damage is literally 1 line of code with 1 file being recompiled after the change. This is useful when you only want to see the visualization of the attacks and not worry about units dying. Disabling the graphics is, again, 1 line of code. The battle simulation tool, which simulates many battles with no visualization for balancing purposes, is the game executable with a special command line parameter.  Adding a new type of unit is really easy. The game wasn't supposed to have flying units, but when it was decided that we need to add such, it took 1 programmer only a couple of hours to add them (and this was relatively late in the development). Having the functionality that concerns one feature to be concentrated in one physical location in the code is really helpful, and the library makes this very easy.  As a whole, we're quite happy with Boost.Mixin. I intend to create a simple open source RPG game when I have more time (probably after June this year) mainly to serve as a demo project for the library (and with less focus in the art, story-line and balance). As for what the boost people think of it, I'm not sure. Most of the feedback I've had so far has been positive. But it's been, surprisingly, very little.  I've had 6 people respond to my boost mailing lists posts with positive initial impressions. Throughout various forums including this one I've had about 10 other people with feedback with only two who had a negative one, including yours. I had a presentation of the library in Bulgaria on Open Fest 2013 (November), and the response from the audience has been positive. I have some early adopters who use it in some pet projects and who, for now, seem to be satisfied. Also, as you can see, it has more than 20 stars in GitHub. Still most people just ignore it, it seems. Compared with other new libraries and ideas in the Boost mailing list, this one is fairing rather poorly in the quantity of comments, but fantastically in comment quality as there are no negative ones. Quite strange actually  
  8. Er, the language doesn't do runtime type composition or mutation. The CRTP type type composition is static and doesn't give you polymorphism on its own.  The runtime cost Boost.Mixin adds can only matter in very performance intensive scenarios which would suffer from any type of polymorphism. The fact that the a use case in the library is a couple of nanoseconds slower than a similar case with virtual calls or std::function, is negligible.  It solves the classic composition vs inheritance problem with none of their shortcomings - like coupling and excessive dependencies, combinatorial explosion of types, multiple points for change. Internally instead of keeping the object type information stored per object, it has type info instances that the objects point to. In huge systems, the memory saved by such an approach may be significant.  It doesn't bind the concept of interface to a class, allowing you to have classes that are responsible for multiple interfaces, parts of an interface, or parts of multiple interfaces.  It allows you to very easily create optional dynamic library plugins for your software that change the behavior of your objects.  I also gives you multicast messages, which is a whole new way of thinking about polymorphism. It is a bit like signals, but it's per object. An example of a multicast message could be something like getRenderingParts. A function the engine calls after it has determined which objects are to be rendered in this frame. In most objects this message would be handled by Model (static geometry), AnimatedModel, and such. Now there comes the moment where you need to add quests and some characters need to visually indicate that they are quest givers. With this multicast message we have no problems. We introduce the mixins QuestGiver or InteractiveObject and they start supplying the rendering system with the appropriate data. Then we need to create auras or buff/debuff indications. Again, no problem. We add a mixin called RPGEffects to an object that can have such, and it seamlessly continues to work appropriately. It gives you mutation rules - which can be used to "translate" a type into another type. This may be beneficial if you have a client-server architecture, where the objects exist in parallel. With a mutation rule, you can easily translate a client type to a server type (removing rendering mixins, adding database storage ones) and vice versa.  
  9. Hi, I'm still gathering interest, comments, questions, suggestions and reviews for a library I'm developing. It basically allows you dynamic type composition and mutation in C++. It's called Boost.Mixin (it's for boost, but not part of boost yet) and it's vaguely similar to Ruby's mixins. Code is here: Docs are here: There has been a forum topic on the subject before here but it failed to generate much interest. Hopefully I'll get more this time :)
  10. Bleys

    My mixin library

    Well I revamped the introduction part of the documentation and added two tutorials (more to come). Hopefully it's clearer now.
  11. Bleys

    My mixin library

    Well, to be honest I'm not satisfied with the documentation (the part that's complete by now) and I think it doesn't help people understand what the library is about. I'll be working on an entire doc revamp, and then try gathering interest again. Also, thanks for the link!
  12. Bleys

    My mixin library

    Honestly, I thought this was going to attract more interest  Anyway, I'll try the spam again after more of the documentation is done 
  13. Well something like this should work:   bool useDataFromNowOn = false; while(!feof(fp)) { int ch = fgetc(fp); if(useDataFromNowOn) { ... do something with ch } if(ch == '*') { useDataFromNowOn = true; } }
  • Advertisement

Important Information

By using, you agree to our community Guidelines, Terms of Use, and Privacy Policy. is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!