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 - Tex Killer

Pages: 1 ... 9 10 [11] 12 13 ... 17
General discussions / Question about rendering performance.
« on: January 14, 2012, 12:03:27 pm »
Laurent, given that a bunch of animations would be printed at every frame, is there a difference between changing to the large texture for each animation or changing for the small frame texture?

Since there is a lot of animations, the texture will already be changed all the time.

Graphics / Sprite Movement on Single MouseClick
« on: January 14, 2012, 07:54:57 am »
Take all the lines from
Code: [Select]
Direction /= Distance; up and put inside the if. You better make your Direction vector and your Distance variable outside the main loop as well, so that they remain on multiple iterations.

The last three lines I think you should change.
Make something like this:
Code: [Select]
float Speed = 40.f;
float DistanceMoved = Speed * Clock1.GetElapsedTime() / 1000.f;
if (DistanceMoved > Distance) {
    DistanceMoved = Distance;
PlayerObj.SetPosition(Origin + Direction * DistanceMoved);

If you want to change the speed, change the 40.f to something else.

Graphics / Redrawing Sprites in a Multi - Threaded Program
« on: January 14, 2012, 07:43:40 am »
You can pass a pointer like this:
But I don't think you can access the RenderWindow from multiple threads. Laurent should know better than me, though.

General discussions / The new time API
« on: January 13, 2012, 07:57:06 pm »
Yeah, I knew this would come. Totally endorsed.

Graphics / Using View instead of translating all Box2d coordinates
« on: January 13, 2012, 07:42:57 pm »
hayer, why not make the server convert the data before sending to the clients? That way the clients would receive the correct data and the problem would be solved.

Graphics / Can I make an object move smoothly without stuttering?
« on: January 12, 2012, 12:23:18 am »
You can increase the FPS to get smoother results, but anything above 60 FPS is not noticeable by the human eye (and probably not even shown by the monitor, depending on its frequency).

General discussions / New naming convention
« on: January 11, 2012, 08:56:20 pm »
Quote from: "aquanull"
Guess I was skipping too much after the browser swallowed my post twice. The reasoning of the quotation of mine was very simple in logic:
Since the current notation != camelCase, switching to camelCase -> breaking the current convention.

aquanull, imagine this:
Lets supose we are using some shitty convention that must be changed. All existing code will be broken, no mather which convention we choose to change for. This is no argument against camelCase, as any other convention would result in the same thing.

This will only count when deciding if the convention should or should not be changed, and Laurent said that this decision will be made later. But seriously, it is not very hard to change every first letter to lower case. Even the compiler would be pointing you to the right places to do that.

General discussions / New naming convention
« on: January 10, 2012, 08:38:44 pm »
I think get/is should be used wherever there is a value access, no mather what computation lies behind, provided that the method can be called multiple times to get the same results (not changing anything, only getting a value).

In cases that things get changed because of the function, I think get/is is not appropriate.

General discussions / New naming convention
« on: January 09, 2012, 08:38:25 am »
Quote from: "aquanull"
As a side note: I always believe the truth why javaCase was invented is because when there were (and perhaps are still) only slow Java(TM) IDEs to use, they were limited to do cAsEsEnSiVe checks (always faster than cAsE-iNsEnSiVe checks) for not-too-slow-auto-code-completion, so by making the first several letters of class member names lower-case, the code-completion could struggle to prove their usefulness to lazy coders who didn't bother to press CapsLock or Shift key. Nowadays IDEs should be capable of making cAsE-iNsEnSiVe checks anyway, so I don't think there is such a "compelling" reason for lazy coders anymore.

The reason I see for using this convention is to make class names different than function and variable names, making it easy to know what is happening. camelCase() is a function, camelCase is a member variable, and CamelCase is a class name.

General discussions / New naming convention
« on: January 08, 2012, 10:19:05 pm »
I think this was a great decision. The difference between a class name and a class member is now clear.

The only change I would like would be the get/is put back in, as they help understanding the meaning of those functions.

Overall, you have my endorsement on this.

Graphics / The Last Three Points of my shape will not Change Colour
« on: January 08, 2012, 07:05:27 pm »
You should be looking at C++ tutorials, not SFML.

Graphics / The Last Three Points of my shape will not Change Colour
« on: January 08, 2012, 09:44:32 am »
In C++, which I assume you are using, ifs with more than 1 line inside must have brackets, like this:

Code: [Select]
           if((Event.Type == sf::Event::KeyPressed) && (Event.Key.Code == sf::Key::Num1)) {

The way you did it, only the first line after each if is conditional, all the others happens every time.

General / Problem with sequencing events
« on: January 07, 2012, 07:11:35 pm »
This makes no sense. Ifs are not loops.

Graphics / Sprite Movement on Single MouseClick
« on: January 06, 2012, 06:07:18 pm »
Yeah, you must use the distances, but only to get the angle and only one time.
You can use the standard atan function.

Graphics / Sprite Movement on Single MouseClick
« on: January 06, 2012, 12:38:11 am »
Create some current position vector, and get the angle between the start position and the end position, in radians.

Then you can do this each frame:
Code: [Select]
float speed = 40 * FrameTime / 1000;
current_position.x += cos(angle) * speed;
current_position.y += sin(angle) * speed;

When the current position is bigger than the destination, make it be the destination and the transition is over.

Pages: 1 ... 9 10 [11] 12 13 ... 17