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

Pages: 1 [2] 3 4 ... 7
Hello again, SFML community! Although it has been quite a while since its actual release, I'm still happy (although late) to announce that the newest (to my knowledge) SFML book is finally published and available in a myriad of formats and locations now:


The logical question, I suppose, is what does this one actually offer in comparison to everything else out there. Aside from picking up right where my first book (SFML Game Development by Example) left off, it teaches and demonstrates more advanced rendering techniques to improve your games. Everything from using sf::Shaders to actually going raw OpenGL is covered, and the results range from simply manipulating the rendered image on screen to actually implementing ambient, normal and specular lighting, as well as fully three-dimensional shadows in a 2D game. It also goes over the creation of your own custom tools for building game assets such as maps, using various profiling tools and actually optimizing your game code, and building a particle system that emulates 3D particles in a 2D world.

This is what the shadows look like in the game: (I know the ground looks a bit tiled, and that's simply because auto-generating normal and specular textures for tile-maps is a bit painful, and usually leads to hard edges. I did my best to combat that, but the software I had access to didn't deal with that right, and I have no artistic skills to draw my own material-maps)

There's also a video of this in action, showcasing how raising and lowering the light affects the shadows being displayed on tiles with greater elevation:
A couple of different angles showcasing the specular lighting:

A glimpse at some of the game asset editing tools built from scratch:

Some multi-state particles being used in different ways:

A lot of concerns from previous input I've received have been addressed and taken into account, such as using smart pointers, relying on C++11/14 a lot more, following certain general guidelines etc. In the end, I did want to make this book seem like something I myself would want to purchase and use to get better, so that was my primary objective. I think I have accomplished that, and I can't wait to hear some feedback from the community.

If you do decide this is a book you might enjoy and end up reading it, please feel free to contact me at any time to let me know whether it was acceptable or not. If any problems arise, I'm available (within reason) here through the PM system, or you could just directly shoot me an email at order.nexus.dev@gmail.com. Love it, hate it, bash it or praise it, I'd just be happy to hear from you and potentially help you out.

Hope you all enjoy it, and thanks for reading!

Hey thanks, _Imperial_! I appreciate your kind words and the input on the book(s). You are absolutely right, I should've used reverse iterators. The way your code is written though, every single state will be updated and drawn. The main point of having two loops in each method is first finding the state that is no longer supposed to be "transparent", and then tracing back from that point all the way till the end of the container to update and render the states that are supposed to be "on top of each other". In the code that you posted, that first loop in each method does absolutely nothing.

With that being said, you can definitely still use the reverse iterators. In retrospect, that's what I should have done. I guess I just wanted to outline the process I just explained more clearly. Not sure how well that worked, all things considered.

Either way, thank you so much for your support and the suggestion. Reverse iterators are useful. If I ever get to make editions to either one of the books, I will make sure to put that in. It's on my list! :)

Good evening,

In the downloaded code, chapter 10, ECS/Core/System_Manager.h has an #include "../../Debug/DebugOverlay.h", but that directory/file does not exist in any of the downloaded code's chapters.

Maybe it was clobbered because Visual Studio uses the Debug directory when compiling?  I commented this line out and was able to successfully compile.


No, it was just an include directive that either somehow got left behind by me, or it was not the most recent code file used by Packt, as we have gone over a couple of revisions and they're not the best when it comes to using the most up-to-date code sent in by the author. Either way, it can safely be left out to execute the code. Thanks for bringing this to my attention though.

I´m working with both this book and the new book at the same time.

Any plans of making a thread for the new book?
Yeah, I'll be making a thread soon. I haven't had much time lately to really maintain my online presence, but I'll at least get a thread started when I have more than a minute. In the meantime, if you have any questions or concerns, feel free to just shoot a PM my way and I'll do my best to help you out. Thanks for reading! :)

General discussions / Re: SFML Game Development by Example - 4th SFML book
« on: February 14, 2017, 06:12:55 pm »
Thanks. I bought it :) Looks good.
Thanks! I really appreciate your support. Hope you enjoy it! :)

General discussions / Re: SFML Game Development by Example - 4th SFML book
« on: February 13, 2017, 05:50:52 pm »
I want to buy the new book (it's on sale!) , but I have a couple of questions first:
1. Is it multiplatform? Im on linux.
2. Is it required to have the first book?

1) It should work with other platforms just fine, albeit with a little tweaking on your part if some concepts don't carry over. Nothing about the code screams certain platform dependence, but I've developed it on a Windows machine, so some things may be leaning slightly towards VS. Still, the tweaking should be minor, if any. Take it with a grain of salt and use it as a reference book, while making the necessary adjustments when needed, provided you know C++ rather well.

2) The first book isn't required at all. It uses the third RPG project from the first title, but covers the code-base fairly well so you can jump into it without looking at too much of the underlying code. It may be useful for you to have the first book just to understand the concepts, but if you do already, it's not necessary.

General discussions / Re: SFML Game Development by Example - 4th SFML book
« on: February 06, 2017, 05:02:48 am »
i just ordered the book at packtpub, can't wait to read it.
Thanks for buying it! I really hope you enjoy it. :)


I just wanted to say that your new book looks great! I preordered it a while ago and didn't have time to read everything yet but I looked at all chapters and it contains a lot of very cool/advanced topics and good explanations!

Thanks for making this book  :)
Hello! Thank you for reading. I really appreciate it. Hope you enjoy the book! :)

regarding the new book
Yeah, the book is actually available now! Regarding the code files, the additional map stuff was left in by me. Those were, more or less, just backups for me that I forgot to take out. They simply contain different versions of the game map that hold more entities and lights for stress testing during Chapter 10. Feel free to ditch them, as they're not essential.
I read the first two chapters then did a skim over the rest, it looks great. I'm wondering how I would go about incorporating this text into the server from the project in the final chapter of the last book. Can the shaders and lighting affects be handled solely on the client portion? I'm new to networked programming and just trying to learn everything I can.
I'm really glad it looks good to you at this point. Thanks so much for reading! This book only deals with client-side techniques, so you could easily take all of them and apply them to the client. Lights themselves, as they're part of the map, may need to be updated on the server side if you want to move them around. The approach taken in the first book assumes that the maps are both the same on the client and server sides, but you'd probably either want to only read in tiles on the client side, or just send everything to the client from the server to ensure continuity. When writing networking programs for anything beyond mere testing, client input should never be trusted.

Side note: Packt really messed up by uploading the archives of the code to GitHub, rather than the code files themselves. I have no idea why they did it like that, but it kind of misses the point of source-control if you ask me.

Yeah, I've been done with the book for a while now. The dates they keep giving me are almost always get moved further down, although it shouldn't be much longer. I was honestly expecting it to be out today, but it will probably be out this Monday at the latest. That would be my best guess. Sorry guys. I hope you enjoy it when it comes out though!

Sorry I hate to be that nagging person but this anticipation is killing me! The book was supposed to be out yesterday.. Just a delay from packtpub? Or has it been delayed for another reason?
No, trust me, you're fine! I'm the same way. The book is completely finished and as they informed me, it has been "uploaded". From my previous impressions, I got the feeling that "uploading" it means it will be published, but apparently it will take a couple more days for them to do that for whatever reason. Rest assured though, it will be out sometime this week or the beginning of next week, as all of the final drafts were already finished long before. It's on the fast track to the finish line now.

UPDATE: I just got word that it will be published by this Friday.

Hi _Imperial_.

First and foremost, thanks for reading! I really appreciate your kind words. The new book is supposed to come out either tomorrow or the day after, actually. I have just approved the pre-finals of the last couple of chapters, as well as the cover, and it should be made available soon.

Regarding Chapter 11, it's really hard for me to say what the problem might be without looking at the code. From what you told me, it seems that it may be some sort of simple issue where either the interface file itself isn't correctly defined, isn't properly loaded, or something else of that variety. I'd have to take a look at it and see in order to make sure, but if you want to do it yourself, simply break the program on the point where an interface is created in the main menu state and track it line by line to figure out what the problem is. Seeing the branches your code takes can be a great tool in trying to figure out what the problem might be.

The same deal applies to the error message you attached. While in debug mode, hit retry and look at your stack trace. It will give you a detailed overview of where the program failed. It's most likely my fault, as I probably overlooked something. Rest assured though, it seems like an easy fix.

If you still can't figure it out, zip your code up and send it my way. I'll try to run it on my end and track the problem down when I have a moment.

Yes, it does utilize the third project from the last book, which is the RPG. The last three-four chapters deal with OpenGL stuff by implementing advanced lighting and 3D omni-directional point light shadows, as well as optimizing the project.

The book is going to be up by Monday (23rd). All chapters have already been finished by me and are now in the final stages. Also, some of those points are outdated and are going to be edited before it comes out.

Well, here is the callstack:
One really common and stupid mistake I've made that I'd like to acknowledge here is the necessity to take out line 201 in the EventManager.cpp, inside LoadBindings():
int code = std::stoi(keyval.substr(end + delimiter.length(), keyval.find(delimiter, end + delimiter.length())));
I really don't know why this line stayed in, but after all of the GUI stuff is implemented, this line needs to be removed. Outside of that, I have compiled a list of other quick things I caught with a debugger in your code that were probably just simple copying errors. Please look them over, and I also recommend you comb your code with a debugger as well. Perhaps a static-analysis tool as well, that will be useful when catching weird bugs. I'm sure you just missed an initialization somewhere, and that's what the call-stack looks like to me. AnimBase or one of the parent classes is probably nullptr.

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