Messages

16

General / Re: Should I start off this complex?

« on: October 18, 2015, 08:43:25 am »

You're doing just fine. The very fact that you are worried about over-engineering indicates that you would recognize if you actually started going down that path.

From personal experience, and from reviewing other peoples code, I have noticed that many novice programmers tend to hack together the bare minimum solution required to fix one single problem as quickly as possible. They then go on to build the next thing on top of that hack instead of refactoring the current code into a sane state, thus creating unrefactorable spaghetti code mess.

For a small demo, that is completely okay. But for anything that is more ambitious than the very simplest of games, having some architectural plan is unequivocally beneficial.

These are good things:

• modularization
• separation of concerns
• functional programming
• unit testing

So depending on the scale of your project, thinking about and employing those concepts might end up taking more time than if you just hacked the solution for immediate results. But striving towards those things will help keep your code clean and make you a better programmer in the long run

17

General / Re: What is the best practice? How fast is copying sprites? A design decision.

« on: October 14, 2015, 06:33:13 pm »

Here is another suggestion based on how I usually do rendering in my small projects.

Instead of using any sf::Sprites, store only one texture in a singleton, lets call it RenderingSystem. That texture is your spritesheet which contains every sprite.

Then, create a base class called something like Renderable, with a virtual method called get_vertices(VertexArray & vertices).

The idea is that every drawable entity in your game inherits Renderable and override get_vertices. When its time to draw, you create a vertex array and pass it to every drawable entity which inserts its vertices according to that instance's position, etc. And then you just draw that array.

That way you don't need to store the sprites in each game entity, nor do you need to keep track of which sprites should be removed.

To make it better, you can use std::vector<sf::Vertex> instead of sf::VertexArray, that way you can keep the vector loaded with static sprites and only insert the vertices of dynamic entities that need re-drawing.

18

General / Re: How to use new C++11 unique and shared pointers?

« on: October 11, 2015, 02:30:24 am »

You can still change the pointed-to object despite get() being const. Just try it.

    const std::unique_ptr<int> ptr{new int(10)};
    std::cout << *ptr << std::endl; // outputs 10
    *ptr.get() = 20;
    std::cout << *ptr << std::endl; // outputs 20

Maybe your confusion is because using unique_ptr changes the type of the object. Instead of dealing with an object of type T, or the address of T, you are now instead dealing with an object of type std::unique_ptr<T>.

19

SFML projects / Re:creation - a top down action rpg about undeads

« on: September 29, 2015, 07:39:39 am »

The new style looks much better.

Seeing all four walls of a room doesn't make any sense when the objects in the room are shown only from one side.

20

General / Re: SFML 2.3.1 GAME DESIGN LESSONS

« on: August 18, 2015, 05:42:19 am »

This is like an exhibitional study of the Dunning–Kruger effect.

21

General / Re: How to setup a game server in the best way?

« on: August 16, 2015, 12:10:29 am »

Then you don't disagree and your post wasn't necessary, because Jesper Juhl said "If you are just starting out...".

False. He said "They take teams of 10-50+ programmers and graphics artists multiple years to build." Which has nothing to do with "just starting out". I disagreed with the 10-50 programmers and multiple years bit, not the just starting out bit.

22

General / Re: How to setup a game server in the best way?

« on: August 15, 2015, 09:01:15 pm »

Seriously. If you are just starting out then DON'T try to build a MMOOOOOOooooo however many Moooos. You'll Fail. They take teams of 10-50+ programmers and graphics artists multiple years to build. Don't go there, you'll just be disappointed.

Well you're talking about building World of Warcraft, but an MMO wouldn't have to be that advanced.

Imagine a game with simple mechanics: you can fight other players, basic item crafting system, top-down 2d graphics, 2-3 different playable classes, and so on. It's totally plausible that, with a clear vision, one expert programmer and a pixel artist could create such a game in one year and have a very playable beta done.

Yes it's not feasible for a newbie to go into MMO right away, but saying that it takes 50 programmers to create an "MMO" period is just not true.

23

General / Re: Accessing Sprites within a vector

« on: July 24, 2015, 06:44:34 am »

Try printing out the value of this statement:

unsigned int selected = -1;

And you will see why this following condition is illogical:

if (!(selected < 0 || 2 < selected))

For a quick fix, change the loops to something like this:

// mouse button press
for (auto & sprite : vect)
    if (ifspritecollision(sprite, mouse.x, mouse.y))
        sprite.setColor(sf::Color(120, 120, 120));
...
// mouse button release
for (auto & sprite : vect)
    sprite.setColor(sf::Color::White);
 

But what you might want to do eventually is to create your own button class that receives click events somehow and keep an internal state based on those, at least that would be the object oriented approach to this type of thing.

24

General / Re: Change hardware cursor?

« on: July 24, 2015, 06:05:54 am »

I want this as well, because even at its most basic there is a noticeable delay in a software rendered cursor, see attached video.

#include <SFML/Graphics.hpp>
int main() {
    sf::RenderWindow win{sf::VideoMode{1600, 900}, "Cursor test"};
    while (win.isOpen()) {
        sf::Event e;
        while (win.pollEvent(e))
            if (e.type == sf::Event::KeyPressed) { win.close(); }
        sf::RectangleShape rect{sf::Vector2f{50, 50}};
        rect.setPosition(sf::Vector2f{sf::Mouse::getPosition(win)});
        win.clear();
        win.draw(rect);
        win.display();
    }
}

25

General discussions / Re: Why use SFML over SDL?

« on: July 18, 2015, 09:37:02 pm »

Google is your friend.

The first result is a reddit thread, and someone posted

If you go either route you'd find yourself doing enginemaking rather than gamemaking. That usually comes later, if ever.

Which I thought was funny because I definitely feel like that most of the time

The lesson being that if you want to create something more elaborate than Pong, then it's honestly not a huge deal whether you're using GLFW, SDL or SFML because your media framework will get buried under several layers of abstraction anyway.

26

General / Re: What about memory leaks?

« on: June 07, 2015, 05:06:28 pm »

Every C program must be a horrible leaking mess right?

is reductio ad absurdum because it was never said that all programs with smart pointers have mistakes in them and the extrapolation that because smart pointers can stop issues, not having them means there must be issues is illogical.

That line was a joke, not a serious argument, which is why it should seem absurd if you take it seriously.

And yes, unique_ptr<int> isn't of type int, but neither is int*. Both use the same operators to access the data they point to but unique_ptr has other functions which can be useful. You can even access the underlying pointer directly if you want to.

That's all true, but the argument here is that it does not merely represent the address of he object, but also brings in a whole bunch of new rules that the programmer must reason about. And also, it changes the memory management mechanism in a way which some of us find undesirable.

27

General / Re: What about memory leaks?

« on: June 07, 2015, 02:55:03 am »

In my case, I'm afraid you're going to be waiting a long time.  Unless you honestly believe that every C++ program in existence before C++11 was a buggy piece of memory leaking crap (which is obviously not true), your statement doesn't hold.

Forget about C++ pre 11, think about plain C! Every C program must be a horrible leaking mess right?

Well I guess there are a significant portion of C++ programmers out there who would answer "YEAH, THAT'S RIGHT" ...but ignoring them I think there is a lot of evidence that low level programming was doing just fine even before smart pointers came along.

28

General / Re: What about memory leaks?

« on: June 07, 2015, 02:44:52 am »

You clearly didn't read correctly all we said. Also, I don't get why you say it changes everything? unique_ptr offer the same operator(*, ->) to access the underlaying object. In fact, it makes the software more robust, because you are sure you are not going to copy the pointer because it is not copyable.

It does change the type of the object. Using an object of type std::unique_ptr instead of simply (the address of) the object brings in a whole bunch of new rules and functionality which requires programmer attention. Just because it shares two of the operators doesn't change that fact.

About copying the pointer, see what I said about accessing freed memory. In that scenario you have written a program which you don't understand. Not being able to effectively reason about your own code is not a problem that smart pointers are going to solve, yes they might sweep some of the symptoms under the rug but they will not fix the underlying issue.

Now, here is another small example of memory leak if you want:

------ snipped ------

Now remember this is a very trivial code, and most useless, but you can (hopefully) get the point. Unless you surround your call to at with try catch of course, you get a memory leak. Truthfully, you'll probably won't use at and use [] which will be UB instead. But you get the point.

Why would you not wrap the thing that can throw in try/catch? Just exactly where is the catching clause located in the scenario you propose? If you don't catch it then it won't matter whether memory leaked. Your example doesn't have anything to do with smart pointers. I want to see some examples of robust and elegant code (i.e. doesn't look like ww3 went through it) where you use smart pointers for everything and let exceptions affect control flow in a major way.

This is what full memory management can cause. It's problem, over problem. It's tricky and complicated.

It's tricky (like programming generally), but I don't think it's complicated. Adding rules and functionality is what makes a program complicated, and that's what smart pointers do. They don't change the fundamental mechanism, they merely hide it behind another mechanism. Note that I am not denying they have any use at all, of course they do, but the trade-off in terms of complexity vs potential benefits is not worth it for me.

29

General / Re: What about memory leaks?

« on: June 06, 2015, 09:31:57 pm »

I too avoid smart pointers. Part of the reason is something Jonathan Blow said—one of very few things I agree with him about—namely that smart pointers changes the type of the object and that's not good. Illustration:

auto ptr = new Object{};

This is very easy to understand. `ptr` is simply the address of my object. The possible operations are also very limited (which is a good thing for stupid programmers like me). Passing it around is straight forward, and so is dereferencing it and performing arithmetic on it in those special cases. I feel like the object I'm handling is small and easy to understand.

auto ptr = std::unique_ptr<Object>(new Object{});

Now the type of the object has changed. It's no longer merely an address to my object, or even my object, but now I have an object of type "std::unique_ptr<..." which is something else than what I wanted. The new object I actually want sort of hidden somewhere inside it, both in terms of how unique_ptr works, and literally by how the declaration reads.

This increases the complexity of the program, because now I have to reason about how std::unique_ptr will act in addition to everything else. Mind you, this doesn't even absolve me from thinking about the lifetime of the object, it merely hides deallocation into the rules of scope instead of having me handle it explicitly. The reason why I use C++ is because I want to do memory management manually, if I wanted memory to be handled in automatic and hidden ways I would just a GC'd language instead.

I enjoy doing things explicitly, because that makes it easier for me to understand the meaning of my code. Someone may argue that smart pointers are actually super simple to understand, and if that's how you feel, then go ahead. However, if you are double freeing your pointers or forgetting to free them, or often trying to access freed memory, well I believe you have problems that smart pointers aren't going to solve. And like Jabberwocky said, if something like allocation fails then smart pointers aren't likely going to save you either.

30

General discussions / Re: A few questions to main developers.

« on: March 02, 2015, 08:59:15 pm »

You misunderstood me. I am not saying a user should not know (or be able to know) how something is implemented. I am saying they don't have to know. There is a difference.

In that case we agree, I mistakenly got the impression that you were encouraging people to be ignorant of the internals of libraries.

This example is flawed. The external behaviour in this case would be inconsistent with the API documentation (because it does more... much more). Remember, it is not about what the library does, but how it does it. Your example delves into the territory of verification, making sure code does exactly what it is meant/advertised to do.

Yes it would be inconsistent, and the possibility of such inconsistencies is a good reason why users ought to have an interest into the internals of libraries they run, which is all I'm arguing.

It is important that security-related applications are verified, that is true, but to go back to my point: If the application does what it is supposed to do and is deemed secure, does it matter how it really does it? Probably not.

That depends on what you mean. Deemed secure by whom? In that statement, are you for example including closed source applications, which the deemed secure by the company that created them and seem to do what they promise? In that case I strongly disagree.