Welcome, Guest. Please login or register. Did you miss your activation email?

Author Topic: SFML 2.0 RC  (Read 116548 times)

0 Members and 1 Guest are viewing this topic.

Cornstalks

  • Full Member
  • ***
  • Posts: 180
    • View Profile
    • My Website
Re: SFML 2.0 RC
« Reply #105 on: May 29, 2012, 04:28:38 am »
No flip function for the Sprite class?  :'(
I'm pretty sure you can scale by negative amounts to flip. So sprite.setScale(1.0f, -1.0f) would be a flip along the x-axis.

kaB00M

  • Full Member
  • ***
  • Posts: 101
    • View Profile
    • Caffeware
    • Email
Re: SFML 2.0 RC
« Reply #106 on: May 30, 2012, 01:19:31 am »
Quote
I'm pretty sure you can scale by negative amounts to flip. So sprite.setScale(1.0f, -1.0f) would be a flip along the x-axis.

Yep! ;) Thank you. Always used the FlipX in 1.6.



soro

  • Newbie
  • *
  • Posts: 1
    • View Profile
Re: SFML 2.0 RC
« Reply #107 on: June 05, 2012, 09:01:20 pm »
Hi,

There is a problem with this funciton:

void sfPacket_readString(sfPacket* packet, char* string);

You may argue that the application should know what is the buffer size needed, but a malicious peer may send a bigger string, which will make the game server segfault.

Here is a test case that produces such a segmentation fault:

#include <stdio.h>
#include <stdlib.h>
#include <SFML/Network/Packet.h>

int main()
{
    char *buf = "+++";
    sfPacket *p = sfPacket_create();
    sfPacket_writeString(p, "0123456789ABCDEF");
    sfPacket_readString(p, buf);
    printf("BUF: %s\n", buf);
    sfPacket_destroy(p);
    return 0;
}

There are one parameter missing and a returned value missing.

It should be something like:

int sfPacket_readString(sfPacket* packet, char* string, int length);

We need a parameter length that tells the size of the buffer string provided, and the function should not try to fill more than that in oreder to prevent the segmentation fault.

We also need a returned value telling how many bytes where filled into the buffer, because if the buffer is of a larger size (for exemple 1024) and the function fills a smaller amount (for exemple 30), we need that value to extract the actual chunk. Using the NULL C string terminator is not enough / is not always a good method.

Ceylo

  • Hero Member
  • *****
  • Posts: 2325
    • View Profile
    • http://sfemovie.yalir.org/
    • Email
Re: SFML 2.0 RC
« Reply #108 on: June 05, 2012, 09:25:23 pm »
Want to play movies in your SFML application? Check out sfeMovie!

kaB00M

  • Full Member
  • ***
  • Posts: 101
    • View Profile
    • Caffeware
    • Email
Re: SFML 2.0 RC
« Reply #109 on: June 22, 2012, 02:39:01 am »
Any Randomizer alternative?



eXpl0it3r

  • SFML Team
  • Hero Member
  • *****
  • Posts: 10820
    • View Profile
    • development blog
    • Email
Re: SFML 2.0 RC
« Reply #110 on: June 22, 2012, 02:52:29 am »
Official FAQ: https://www.sfml-dev.org/faq.php
Official Discord Server: https://discord.gg/nr4X7Fh
——————————————————————
Dev Blog: https://duerrenberger.dev/blog/

Celtic Minstrel

  • Jr. Member
  • **
  • Posts: 80
    • View Profile
Re: SFML 2.0 RC
« Reply #111 on: June 22, 2012, 03:32:13 am »
Or if you're using C++11, there's the <random> header. If you seed your random generator and require the same results on different platforms, you can't rely on rand(), but the <random> header should be consistent across platforms.

Of course, if you don't need repeatable random numbers, all that doesn't matter. ;)
« Last Edit: June 22, 2012, 03:34:37 am by Celtic Minstrel »

tAKi

  • Newbie
  • *
  • Posts: 3
    • View Profile
Re: SFML 2.0 RC
« Reply #112 on: June 23, 2012, 09:41:01 pm »
Hi,
it seems there is an issue with the API 2.0.

I post it here, not in feature request because I have read that there will be no change in the API 2.0 until 3.0.

It seems that it is possible to plug several joypads into the same computer to play multiusers game because there is a joypadID field in the event structure, but it seems that there is no equivalent for mices!

With the SDL it is possible to handle one mouse for each player. So this is impossible with SFML ?

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32504
    • View Profile
    • SFML's website
    • Email
Re: SFML 2.0 RC
« Reply #113 on: June 23, 2012, 10:51:57 pm »
Quote
So this is impossible with SFML ?
Indeed. This feature is not implemented yet.

Quote
I have read that there will be no change in the API 2.0 until 3.0.
The API can't be broken, it must remain backward compatible. But it doesn't mean that new things cannot be added.
Laurent Gomila - SFML developer

tAKi

  • Newbie
  • *
  • Posts: 3
    • View Profile
Re: SFML 2.0 RC
« Reply #114 on: June 23, 2012, 11:28:24 pm »
Quote
So this is impossible with SFML ?
Indeed. This feature is not implemented yet.

Quote
I have read that there will be no change in the API 2.0 until 3.0.
The API can't be broken, it must remain backward compatible. But it doesn't mean that new things cannot be added.

Sorry, I don't see how this could be added without breaking API compatibility?

Wouldn't it be better to add the mouseID field to the event struct, and the mouseID parameter to the sf::Mouse methods now (even if it's ignored at the beginning), so that it wouldn't break 2.0 API when we add this feature?

Celtic Minstrel

  • Jr. Member
  • **
  • Posts: 80
    • View Profile
Re: SFML 2.0 RC
« Reply #115 on: June 24, 2012, 09:04:29 am »
It might be nice to have an operator| for Rects.
Code: [Select]
template<typename Num> sf::Rect<Num> operator| (sf::Rect<Num> lhs, sf::Rect<Num> rhs) {
sf::Rect<Num> intersect;
if(!lhs.Intersects(rhs, &intersect)) return sf::Rect<Num>();
return intersect;
}

template<typename Num> sf::Rect<Num>& operator|= (sf::Rect<Num>& lhs, sf::Rect<Num>& rhs) {
lhs = lhs | rhs;
return lhs;
}

Using the set intersection operator makes sense for this context, and it's slightly different than the member function which returns a boolean rather than the intersecting rectangle. Of course, it's not that important, since these are global functions and therefore I can just do this myself if I need it. Just a random thought in passing.

(It'd also be nice to have a "contains" operator that takes a Rect and a Vector, but I can't think of a reasonably logical operator symbol to use for that one.)

Nexus

  • SFML Team
  • Hero Member
  • *****
  • Posts: 6286
  • Thor Developer
    • View Profile
    • Bromeon
Re: SFML 2.0 RC
« Reply #116 on: June 24, 2012, 10:12:31 am »
It is not obvious at all what operator| means in combination with rectangles, thus I recommend not to overload it.

Why do you call it "set intersection operator"? This one has the symbol ∩. If I had to choose the most appropriate C++ operator for set intersection, it would probably be & (because the intersection contains the elements that are in the first set and the second set) -- on the contrary, | would rather denote set union.
Zloxx II: action platformer
Thor Library: particle systems, animations, dot products, ...
SFML Game Development:

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32504
    • View Profile
    • SFML's website
    • Email
Re: SFML 2.0 RC
« Reply #117 on: June 24, 2012, 10:19:31 am »
Quote
Sorry, I don't see how this could be added without breaking API compatibility?
Adding a member to a struct, and an argument with default value to a function doesn't break API compatibility.
Laurent Gomila - SFML developer

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32504
    • View Profile
    • SFML's website
    • Email
Re: SFML 2.0 RC
« Reply #118 on: June 24, 2012, 03:30:52 pm »
The sfml-window tutorials are online.
Laurent Gomila - SFML developer

Celtic Minstrel

  • Jr. Member
  • **
  • Posts: 80
    • View Profile
Re: SFML 2.0 RC
« Reply #119 on: June 24, 2012, 04:20:25 pm »
Why do you call it "set intersection operator"? This one has the symbol ∩. If I had to choose the most appropriate C++ operator for set intersection, it would probably be & (because the intersection contains the elements that are in the first set and the second set) -- on the contrary, | would rather denote set union.
Huh. You're right, of course. (Duh.) Anyway, I think it's reasonably obvious that what operator& would mean for rectangles, since the logical and set operators are closely related, and documentation would clear up any confusion.

That said, I don't really care that much if it's added. It's just a thought thrown out.