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 - nitrix

Pages: [1] 2
1
General / SFML 2.0 GetInput()
« on: December 23, 2011, 04:58:15 pm »
I didn't know there was a difference. Both are very similar and events are even easier to work with.

2
General / SFML 2.0 GetInput()
« on: December 23, 2011, 03:23:12 pm »
[...]
Event someEvent;
window.PollEvent(someEvent);
[...]
switch (someEvent.type) {
case sf::Event::KeyPressed:
//event.key.code....
//sf::Keyboard::Escape...
}

The event structure will get filled with all the data needed about the event. event.type tells you what kind of event it is (mouse, keyboard, etc). Process everything in a switch case (: Then you can set your own booleans and stuff.

3
Feature requests / stay on top
« on: December 22, 2011, 02:37:46 pm »
I had the same though too, it should be left to the user's choice. Some of them have tiling window managers and stuff that could break.

I mean you could always use sf::Style::Fullscreen if you have no choice. Just don't control the windows for them ;)

4
General discussions / have fast moving sprites without distortion?
« on: December 22, 2011, 02:32:00 pm »
Yeah on older monitors, the pixels appears still lit for few millisecond while its turning off I guess.

Maybe you can enable vertical sync and expect better results?
sf::Window::enableVerticalSync(bool);

5
Window / Non-Copyability And The Instance
« on: December 15, 2011, 05:36:31 pm »
Roflmao. This deserves way more view xD !

6
Network / How to make my program wait for establishing the connection?
« on: December 13, 2011, 08:35:43 pm »
Yep you got it !

I think a socket is blocking by default so you should even be able to get rid of your first line ;3

7
General / Linking error?
« on: December 10, 2011, 03:21:06 am »
Do you have a "SFML-1.6" folder inside your project folder? The tutorial look good as for the instructions.. so you propably just misplaced something.. Visual C++ can't find the sfml-system-d.lib file apparently :/

8
General / Event-Handling ONLY in Console
« on: December 09, 2011, 06:48:15 pm »
I beleive you have ncurses and others for that but its Linux only.

9
Graphics / Destructible terrain, best way w/ SFML?
« on: December 09, 2011, 03:39:57 am »
I'll suggest to look into sf::Texture::Update() from SFML2 until somebody can answer you better than I ;)

10
General / Event-Handling ONLY in Console
« on: December 09, 2011, 03:35:55 am »
Well, your event handling on the console will be fairly limited. The only input a console has is the keyboard. You can't poll the mouse position, nor get minimize/resize events, etc.

Thus are born windows, you need them.

11
Network / Two physical packets per sf::Packet?
« on: December 08, 2011, 10:47:15 am »
. . . right. Okay I'm sorry. I'll implement the said network manager now then x]

Oh well at least its a good warning to anybody who uses blocking sockets + sf::Packet for production. A custom implementation is better.

12
Network / Two physical packets per sf::Packet?
« on: December 08, 2011, 10:35:07 am »
Oh wait. If we exclude sf::Packet, isn't Receive(const char*,size,...) blocking too? I don't need the fancy packets, I just want to read/write raw data through SFML in a way that isn't blocking..

I might owe you some excuses ahah xD Annnnd a beer if I remember right ;)

13
Network / Two physical packets per sf::Packet?
« on: December 08, 2011, 10:03:59 am »
I think you misunderstood my post.

Corrupted data isn't a big deal. SFML doesn't have to do thoses checks, it's our job. For example: If the player wants to move to a coordinates that doesn't exist, we have to check that. When he pickup an item ID, interact with something.. those are integers we can validate ourselves with the game mechanics.

The problem comes from the fact SFML only provides a blocking Receive() function. With this API, you can't retrieve partial data and build a network manager on top. This results in a poor system where you can't control the server flow anymore! (When using a socket selector) Immagine a hacker send to your server a packet size without the data... ALL CONNECTIONS are interrupted because of Receive() waiting for more bytes it'll never receive...

---

Anyway, I think I'll use SFML for the graphics and ENet for the network. Thanks god you divided your project into smaller libraries so when can cherry-pick what we need ;)

14
Network / Two physical packets per sf::Packet?
« on: December 08, 2011, 05:58:49 am »
One more thing to consider even with the current implementation:

If somebody sends a size of 0xFFFFFFFF to the server but no data,
the server will wait forever on the TcpSocket::Receive(packet) and thus block any communications with other clients until data is fully received.

This is quite a huge flaw in my opinion. What I did with my previous server, every connections created a Client object with a buffer. When a packet was received, we would read as much data as we could and push it to the client's buffer. Once there's enough bytes received, it was processed.

So if Receive is really blocking (and I think it is), that's a problem for server using a selector. In a threaded environment it'd be fine... but again, not for selector servers.

15
Graphics / Tutorial Code does nothing
« on: December 08, 2011, 05:34:15 am »
*raises his hand* More candies please~ :3

Pages: [1] 2