Messages

46

General / Re: Fixed Timestep & LERP (yes, I know, *yawn*)

« on: December 26, 2014, 07:33:04 pm »

Your code is very confusing. I don't understand what you're doing, and by the looks of it I'm pretty sure neither do you. Try covering your code with asserts and unit tests, I'll bet a lot of things do not match up with your assumptions.

Also it would have been better to provide a minimal compilable version of your program.

As for your problem, someone who is feeling belligerent may ask you "well if the problem is fixed by using vsync, why don't you just use vsync?" and I would be interested to see how you answer them.

47

General discussions / Re: SFML 2.2 - Next-Gen Multimedia Capability Today

« on: December 14, 2014, 05:22:49 pm »

lxrec confirmed for not even knowing how to write optimized C++ code.

48

General discussions / Re: [Video Tutorial] Arkanoid in 160 lines - C++11 + SFML2

« on: December 07, 2014, 12:52:03 am »

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.

49

SFML projects / Re: Arcane, the roguelike

« on: November 18, 2014, 08:45:50 pm »

It looks pretty good. 

I would slightly change the semantics of the action messages. For example:

• The ancient wyvern claws you for 8 damage
• You stab the gigantic rat for 4 damage

I would change to

• Ancient wyvern clawed you for 8 damage
• You stabbed gigantic rat for 4 damage

but in my opinion this would be even better:

• You were hit for 8 hit points
• Gigantic rat was hit for 4 hit points

Someone who is better at english can tell you whether this is a bad suggestion or give a better explanation of why some changes would make the messages more natural sounding.

50

General / Re: vector with multiple classes | Drawing order

« on: November 15, 2014, 08:18:16 pm »

You should read what I posted before. do while will ALWAYS run once, no matter what, even if the condition is false.

I'm aware what it does, thank you for clarifying that.

51

General / Re: vector with multiple classes | Drawing order

« on: November 15, 2014, 08:17:21 pm »

But in general, it's your task to support your claim with arguments, not ours to disprove it.

I was asking for examples to support this claim:
"[...] in some cases it's the simplest approach, and rewriting to while would just complicate code unnecessarily."

My point being that same could be said in support of goto, of using global variables, #define, manual new and delete, etc.

So, why is do while bad style?

Because it's less readable than normal while. If your intent is to do something once and then loop if a condition is met, then it's better to do so explicitly instead of using an unusual control structure just because it's possible to use it. The logic of why normal while should be preferred is exactly the same as for why you should use break and continue in favour of goto.

You may also take into consideration what Bjarne Stroustrup has written on the topic:

In my experience, the do-statement is a source of errors and confusion. The reason is that its body is always executed once before the condition is evaluated. However, for the body to work correctly, something very much like the condition must hold even the first time through. More often than I would have guessed, I have found that condition not to hold as expected either when the program was first written and tested, or later after the code preceding it has been modified. I also prefer the condition "up front where I can see it." Consequently, I tend to avoid do-statements.

You're aware that you can't simply replace it with while without altering semantics?

I am aware. I am arguing that sticking to while keeps code cleaner and simpler.

52

General / Re: vector with multiple classes | Drawing order

« on: November 14, 2014, 09:36:14 pm »

Who says that and why? There are not many applications for do while, but in some cases it's the simplest approach, and rewriting to while would just complicate code unnecessarily.

Can you demonstrate one or more examples where do while is unequivocally the correct construct?

On a related note, there exists a lot of cases where goto would be "the simplest approach", but I'm not sure you would recommend its usage to people, especially beginners.

Even if you are able to make an argument for why there exists some scenarios where do while is logically the right choice, I will argue that people should stick to normal while anyway because of consistency and simplicity. while is more readable and and easier to reason about.

53

General / Re: vector with multiple classes | Drawing order

« on: November 14, 2014, 06:23:30 pm »

CloudCLASS Clouds;
Drawable * DrawCloud;
DrawCloud = &Clouds;
Scene.push_back(DrawCloud);

You don't need to create a pointer in this case. Just do this:

CloudCLASS Clouds;
Scene.push_back(&Clouds);

do{
// ...
} while(!exit);

`do while` is considered bad style. You should consider using normal `while` instead.

WINDOW.pollEvent(event);

Why are you polling for events when you don't handle any events?

for(uint32_t i=0; i<Scene.size(); i++)
            Scene[!]->Render(&WINDOW);

You have put an exclamation mark instead of i in the subscript operator.

And in any case you should use range based for-loop when iterating all the elements of a container, like this:

for (auto& item : container) {
    // do something with item
}

54

General / Re: Does setframelimit have a memory leak in 2.1?

« on: November 01, 2014, 11:31:23 pm »

Possibly related: http://en.sfml-dev.org/forums/index.php?topic=15364

I haven't tested it recently so that info may be outdated. However I don't see any suspicious increases in system memory usage with my current projects (that implement more than the tutorial loop.)

Maybe it's just a quirk of the tutorial example. As one of the other posters noted: Once you start actually "doing something" in your application the rise in memory usage might stop.

55

General discussions / Re: Insomniac Game Engine Developer Shares Some Thoughts On Engine Design

« on: October 22, 2014, 10:37:49 pm »

Chandler Carruth of Google gave a talk on a similar topic. I thought his approach was more reasonable than Mike Acton.



The short version is: "Forget about the other containers, just use vector."

56

General discussions / Re: Insomniac Game Engine Developer Shares Some Thoughts On Engine Design

« on: October 16, 2014, 03:47:41 pm »

Mike Acton is for sure a better software engineer than I will ever be, but despite that I still prefer the Unix style in favor of Actons incredibly clever data driven optimization.

Rule of Clarity: Clarity is better than cleverness.

Because maintenance is so important and so expensive, write programs as if the most important communication they do is not to the computer that executes them but to the human beings who will read and maintain the source code in the future (including yourself).

In the Unix tradition, the implications of this advice go beyond just commenting your code. Good Unix practice also embraces choosing your algorithms and implementations for future maintainability. Buying a small increase in performance with a large increase in the complexity and obscurity of your technique is a bad trade — not merely because complex code is more likely to harbor bugs, but also because complex code will be harder to read for future maintainers.

Code that is graceful and clear, on the other hand, is less likely to break — and more likely to be instantly comprehended by the next person to have to change it. This is important, especially when that next person might be yourself some years down the road.

Emphasis mine.

57

SFML projects / Re: Witch Blast (dungeon crawl shooter)

« on: October 05, 2014, 06:04:33 pm »

Maybe if you just brought the top of the lowest wall to reach the floor (i.e. so you can't see the wall but all of the floor is still visible) then that might help. I guess that, technically, all that involves is removing the graphics from the bottom of the floor downwards. You could move the info bar higher to cover/replace it.

I agree with this. As an experiment try to make it so that only the top wall is visible. It's a small change, but it might be enough to create the illusion of a consistent perpective.

58

SFML projects / Re: Witch Blast (dungeon crawl shooter)

« on: October 04, 2014, 09:44:18 pm »

The perspective doesn't make any sense to me. It would look better if everything was drawn the same way. At this point I guess it would be easier to make the environment have the same sideways angle as the enemies and player, rather than making them be top-down like the environment is.

59

General / Re: The program exiting with code -1073741515

« on: October 01, 2014, 06:40:43 pm »

Btw, does anybody work with SFML in QTcreator? I have heard it works awkwardly with qtcreator.

Yes daily. I use QT Creator + cmake.

Before I switched to cmake, I did have some trouble sometimes where QMake would require me to run `Clean All` first instead of just building in order to compile all updated files, but I don't remember the specific circumstances of when that would happen.

60

General / Re: Starting on my first project!

« on: September 24, 2014, 06:17:14 am »

I still have to get used to the lingo (statemanager, resourceManager, etc). Im big on planning, but I don't want to spend too much time designing something just to figure out that it won't work.

Just get cracking, everything you make in the first few months is gonna suck anyway so just get it over with. Every time you get better you will look at your old code, laugh, and write new code that sucks less. This is the journey of a self taught programmer.