Messages

1

Graphics / Better FPS drawing 10.000 sprite

« on: March 09, 2012, 03:27:24 pm »

For starters, console IO does lower the performance.
Perhaps it would be better to only show the FPS every few frames(sum the total times of every 20 frames, and then divide by 20 when showing).

2

DotNet / A few design questions

« on: March 08, 2012, 07:31:51 pm »

Unsigned types are not "CLSCompliant"

What does that mean?

MSDN: http://msdn.microsoft.com/en-us/library/bhc3fa7f.aspx

I believe it's related to languages such as the (now obsolete) J#. CLSCompliance refers to a minimum subset of features that all "CLSCompliant languages" must support.

In practice, I don't know how much of an issue this is, since my experience with .NET has been mostly C#.

3

DotNet / A few design questions

« on: March 07, 2012, 12:50:07 am »

The question is: why should it be int

Unsigned types are not "CLSCompliant".
I'm not sure how many CLR languages that causes trouble in, though. If you only want to support C# and VB, that won't be an issue.

4

General discussions / Does SFML work with modern OpenGL?

« on: February 18, 2012, 10:50:37 pm »

If so why not just run SFML in compatibility mode then?

That is the current 2.0 behavior.

5

General discussions / Does SFML work with modern OpenGL?

« on: February 14, 2012, 03:13:47 pm »

SFML 2.0 will (AFAIK) still use legacy features, being incompatible with core profile but supporting older OpenGL versions.

The whole "don't use legacy OpenGL" discussion seems to apply only to SFML 2.x (post-2.0). And even then, that wouldn't prevent SFML from running on older OpenGL. It would only mean no old functions when running on modern OpenGL versions.

6

General discussions / New graphics API ready

« on: December 24, 2011, 03:01:33 pm »

Personally, I'm fine with whatever Laurent picks, provided that:

1. It's fast enough
2. It's simple enough to learn and use
3. It's widely supported
4. Does not rely on deprecated OpenGL functionality (e.g. features not available in Core Profile and OpenGL ES 2.0)

And option 4 does not even have to happen immediately for SFML 2.0 - it can happen gradually over the next few versions.

7

General discussions / Switched times to Uint32 milliseconds in SFML 2

« on: December 16, 2011, 11:49:34 pm »

Are there interfaces for which float is too unprecise in real life situations?

That question has already been answered.

Yes, the problem is that they become less accurate too quickly (apparently it becomes a problem after 2.33 hours).

8

General discussions / Switched times to Uint32 milliseconds in SFML 2

« on: December 14, 2011, 04:14:20 pm »

To be honest, I'm perfectly fine with the current SFML 2 time API.

9

General discussions / Switched times to Uint32 milliseconds in SFML 2

« on: December 14, 2011, 03:12:53 pm »

How about some simple-to-use flexible TimeSpan class?

Code: [Select]


class TimeSpan {
   //Whatever;
public:
  //constructors come here

  Uint64 GetNanoseconds() const;
  Uint32 GetMilliseconds() const;
  double GetSeconds() const;
};


10

General discussions / google chromes Native Client SDK

« on: December 10, 2011, 02:47:51 pm »

Weird. Google Chrome supports WebGL, so I'd expect them to expose OpenGL ES 2.0 to NaCl.

11

General discussions / New graphics API ready

« on: December 05, 2011, 01:59:27 pm »

OpenGL defines the concept of indexes in addition to vertexes. Will this merely be sequential in SFML?

Also, although OpenGL seems to define glVertexPointer, modern OpenGL seems to define glGenBuffers, glBindBuffer, glBufferData and glVertexAttribPointer functions. I'm guessing SFML doesn't take advantage of this, but wouldn't a "Lock()"(or some other better name) in VertexArray improve the opportunities of optimization by ensuring that a given Vertex Array would never be modified again?

12

General discussions / New graphics API ready

« on: December 04, 2011, 01:07:18 am »

Now that I think of it, why not have SFML take advantage of initializer lists? Just add a preprocessor macro SFML_USE_CPP_0X so those parts can be disabled for non-compliant compilers and have the magical ones do all the good stuff.

Code: [Select]


Vector2f x = {1, 1};
Rectangle y = {1, 1, 2, 2};


13

Graphics / Tilemap at 7 fps

« on: December 03, 2011, 05:07:33 pm »

C++ includes the concept of reference "type&" instead of "type", that also doesn't make any copies.

14

General discussions / New graphics API ready

« on: December 03, 2011, 04:39:23 pm »

Just curious - is there any reason not to have "AddPoint", "Clear", etc. in ConvexShape?

About private virtuals: although this is a valid idiom, I have to wonder: how well will this map to other languages(e.g. .NET). Will there be an equivalent for those languages. Should there *be* an equivalent?

RectangleShape only has "size". No position. Is this intentional? Does this mean one would have to use RenderState(or whatever it is called) to set the position?
Also, RectangleShape should at least have two extra constructors:
1. RectangleShape(float sizex, float sizey)
2. RectangleShape(Vector2f size)

15

Graphics / Tilemap at 7 fps

« on: November 30, 2011, 09:16:34 pm »

Is your game still slow when the cout commands are removed(or commented out)? Keep in mind that I/O is an expensive operation to be performing each frame.