Messages

271

SFML projects / Re: Rage - a "modern" rogue-like

« on: September 21, 2014, 10:57:08 am »

I implemented a first approach of reducing the field of view to a limited area. tiles out of this view are rendered dimmed by applying another sf::Color. Also objects are only rendered if they are within the area. So the entire scene gets more atmosphere.

http://youtu.be/7JODb1Kases

The field of view isn't correct, yet - and the field is rendered very awkward, because I can only apply a color per tile. This might be changed later (a lot later, I guess) when introducing shaders .. one day ^^

272

System / Re: sf::Event vs. sf::Keyboard/sf::Mouse/sf::Joystick

« on: September 21, 2014, 08:06:29 am »

If you don't want to reinvent the wheel, you could have a look at Thor.Actions. It provides uniform mappings of events and real-time input to actions, logical combinations of actions and callbacks.

Well, I just built something like this (but just a bit smaller). If I gonna rewrite the input controls to more complex situations, I'll check Thor!

Thanks

273

SFML projects / Re: Rage - a "modern" rogue-like

« on: September 20, 2014, 07:17:56 pm »

Are you planning on releasing it? What about other platforms?

Well, it's a pure hobby-based project. So, if it will be ready one day, I will release it for free. So I cannot state about possible platforms. But I'm thinking about versions for linux and windows (hopefully 32 and 64 bit). I don't have experiences in other platforms like MacOS or various mobile systems, yet.

Anyway, congratulations on the project, seems nice so far.

Thanks!

274

SFML projects / [WIP] Racod's Lair - a coop dungeon crawler [Demo Released]

« on: September 20, 2014, 06:36:11 pm »

Racod, scourge for mankind, escaped to its lair to regenerate for his next decade of terror.
You and your brave fellows are willed to find and defeat Racod.

Playable Demo available
via IndieDB
via GitHub (Source Available)

Genre: Coop Dungeon Crawler / Hack'n'Slash RPG

Target platforms: Windows, Linux

http://www.youtube.com/watch?v=-jm08gtHCZk

Core features:

• Procedurally generated dungeons, enemies and loot
• Cooperative gameplay via splitscreen and/or shared camera
• Mod-friendly through XML-based content and Lua-based AI scripting

What is used: C++11, SFML, Thor, Boost, Sol2

275

System / Re: AW: sf::Event vs. sf::Keyboard/sf::Mouse/sf::Joystick

« on: September 19, 2014, 01:20:20 pm »

As for overhead/performance it really isn't that important, you'll most likely never notice a difference.

Meanwhile, I implemented my own input structure inside my InputComponent by using sf::Keyboard and elapsedTime (as sf::Time given to the update() method), so I can detect whether a key is held - and how long it is held. At least for the moment this works and seems to be the simplest way to satisfy my input needs I don't want to add too much complexity at the moment.

Well, KISS seems to be a great principle also for game dev

276

System / [SOLVED] sf::Event vs. sf::Keyboard/sf::Mouse/sf::Joystick

« on: September 18, 2014, 10:11:11 am »

Hey guys,

I'm using an instance of my GameObject class holding an instance of an InputComponent class, whichs checks sf::Keyboard/sf::Mouse/sf::Joystick to detect user input. So the input component can trigger further actions of the GameObject on each case. But I'm not sure whether this is the right solution for me.

Using this "oldschool" way (means: querying the entire input set on each frame) might cause additional overhead because of checking the entire set on each frame ^^ This seems not so great to me in case of detecting whether the key was pressed/released in this frame, because I need to do this on my self. This isn't a problem to me, but it might be not necessary at all, because SFML provides an event-driven API using sf::Event.

But pulling all events and calling all GameObject's InputComponent's handle()-method might also be not so clever, because each GameObject will be addressed on each event - even if the object would ignore it completly. But (but but but xD) ... but introducing some more intelligent pattern - like registering an object for a limited set of events - seems to be architectural overhead.

Am I wrong in any of this cases? Well, I'm not sure what's the right way for me.. And because this seems an architectural problem I'm gonna solve it now, before writing further input code using "the wrong" design.

Any suggestions?

Kind regards
Glocke

277

SFML projects / Re: TCP-Based Server-Client Framework - based on SFML 2.0 and C++11

« on: June 25, 2013, 05:00:38 pm »

I'm going to rename it to "sfNet - Simple and Fast Networking", stay at the dependency "SFML-2.0" and I will add UDP-support for client-server structure.

I'll update this thread when it's done

278

SFML projects / Re: TCP-Based Server-Client Framework - based on SFML 2.0 and C++11

« on: June 22, 2013, 11:21:55 am »

You understood perfectly

Great So I only need my stream-like implementation

279

SFML projects / Re: TCP-Based Server-Client Framework - based on SFML 2.0 and C++11

« on: June 22, 2013, 10:56:36 am »

You just need to convert all your primitive types to a known byte order, so on systems that don't match this order you need to swap the bytes of types which size is greater than one byte.

Just to make sure I understood correctly: I should decide a byte order for networking (e.g. big endian). Than I check (e.g. at compile time using some preprocessor stuff) which byte order is used by the system. It it's not big endian, I'll convert the data to big endian and send it. Else I send it directly. Same at receiving. That's right?

280

SFML projects / Re: TCP-Based Server-Client Framework - based on SFML 2.0 and C++11

« on: June 22, 2013, 10:42:45 am »

I was thinking about using std::basic_iostream for this purpose: It already has operator<< and operator>> for several types. So the actual socket implementation (I would write) should "only" obtain the data, apply the endianess conversion and send it through itself (the socket). That's it?

This is not the right strategy. std::basic_iostream will process data and send it to its attached std::streambuf, which you would have to override to get the data, using this approach. But it's already too late: the streambuf receives the data as byte blocks, you already lost the original types. You must operate at a higher-level, in fact you need to implement your own stream-like interface, with your own operators << and >>, because each type of data must be treated differently.

Oops Ok, you are right: if I do it on my own, I'll know, who and that it works the way is want

I mean there are e.g. htonl and htons which might convert "host to network long" and "host to network short" (referring to integer). Also SDL_net provides WriteNet16 / WriteNet32 (or with such names). They obviously provide 16-bit (short) and 32-bit (long) integers. But I don't know which to use. I guess there is not a "one fits all cases"-solution. That's why I'm asking

Use the 16 bits function to write 16 bits integers, and the 32 bits function to write 32 bits integers. Sorry for such an obvious answer, but that's really just it

By the way, these functions only perform a byte swap, it's really straight-forward to implement directly. All you need is a reliable endianness detection (either at compile time or at runtime).

Okay, seems logically

But what do you mean with "byte swap"? I thought this was the thing to do, because least vs. most significant bytes first. What to do else? (I guess the answer is as obvious as "always" )

281

SFML projects / Re: TCP-Based Server-Client Framework - based on SFML 2.0 and C++11

« on: June 22, 2013, 10:29:31 am »

I was thinking about using std::basic_iostream for this purpose: It already has operator<< and operator>> for several types. So the actual socket implementation (I would write) should "only" obtain the data, apply the endianess conversion and send it through itself (the socket). That's it?

They also differentiate between 16- and 32-bit conversion for reading and writing purpose. When to use which?

I'm not sure I understand your question, what do you mean?

I mean there are e.g. htonl and htons which might convert "host to network long" and "host to network short" (referring to integer). Also SDL_net provides WriteNet16 / WriteNet32 (or with such names). They obviously provide 16-bit (short) and 32-bit (long) integers. But I don't know which to use. I guess there is not a "one fits all cases"-solution. That's why I'm asking

282

SFML projects / Re: TCP-Based Server-Client Framework - based on SFML 2.0 and C++11

« on: June 22, 2013, 10:21:29 am »

In this case I would stay at SFML-Network as dependency in the first place, because the sf::Packet class is "so mighty", that I don't even want to implement it myself using SDL_net or Boost::Asio.

You don't need any networking function to implement a sf::Packet-like class. It's just a utility that serializes things: it transforms typed data to a sequence of raw bytes.
The only thing you need is the hton/ntoh set of functions, which convert primitive types to network byte order. But they can easily be emulated, if you don't want to depend on each OS networking header just for these functions.

Thanks for that! Afaik SDL_net also provides some functions for this conversion. They also differentiate between 16- and 32-bit conversion for reading and writing purpose. When to use which? I didn't found an answer to this question, yet - so I should ask this question

All together is seems not too difficult to make "SFNet" support SFML-Network, SDL_net and Boost::Asio, I guess

283

SFML projects / SFNet - Simple and Fast Networking

« on: June 22, 2013, 10:00:12 am »

Currently I think about naming my project. It is called "Networking", yet. What do you think about the name "SFNet - Simple and Fast Networking"? In this case I would stay at SFML-Network as dependency in the first place, because the sf::Packet class is "so mighty", that I don't even want to implement it myself using SDL_net or Boost::Asio.

In addition to the rename, I plan to support UDP as well as Peer-to-Peer connections. So I have some additional questions to you:

• How to solve the UDP-support? Afaik I cannot "easily" change the socket protocol and just "plug" an UDP-socket to the client/server instead of a TCP-socket. UDP does not "connect" in the sense of TCP. So there are not connect- or disconnect-methods. As well there is no TCP-listener socket. Also a UDP-socket should obtain/returns (as the UDP-socket implementation by SFML already does ) the target'ss/source's hostname and port number when sending/receiving. So I think of seperate client- and server-classes which are using UDP. They would be derived from a BaseServer/BaseClient (the TCP version would be derived as well). Any ideas?
• Does Peer-to-peer connections make sense using TCP? In case of UDP it would be easiest: each peer knows each other peer's hostname and port and can send directly using its UDP socket. For TCP each peer needs an additional listener socket to accept new peers. Also broadcasting (e.g. when a new peer was added) would be a lot easier when using UDP compared to using TCP. So does it even make sense in this case? In my opinion, peer-to-peer makes only sense when using UDP - but I'm neither a "networking-God" nor very experienced in peer-to-peer architectures.

Kind regards
Glocke

284

SFML projects / Re: TCP-Based Server-Client Framework - based on SFML 2.0 and C++11

« on: June 21, 2013, 02:54:01 am »

I've read the example you provided and it look just great.  I've always search for something that make writing a client/server communication simple but I've never found something really simple and useful. Now it's done thanks to you.

Nice to hear that, thanks! I aim at simplicity - I guess this works ^^

Just one question why in the BaseProtocol::send and received doesn't you directly provide the packet instead of the socket? In my opinion, we don't want  the user to mess with the socket here. We just want to let it him read/write data onto a packet. Don't you think ?

Well, this API is currently "unstable" referring to it's signture It was just my first draft. But I agree: using the package class directly would be a greater win for more abstraction. I was thinking about abstracting the whole stuff even more, so you can use not only SFML sockets but also Boost asio oder SDL_net. For this case I plan to implement something like sf::Packet, based on each of the three socket APIs to make my framework even more flexible and not only too-focused on a specific framework (as it currently is by using SFML).

Of course this is the SFML-forum - so it's "expected" that it works with SFML - but not as the only possibility

285

Graphics / Re: Looking for 2D, non-native Widget-Framework

« on: June 17, 2013, 11:40:41 am »

Don't give up too fast, these problems seem to be easy to solve. However there are better places for requesting help; SFGUI and TGUI have their own website, and their own thread on this forum.

Okay

Texus wrote a PM to me about ja Ubuntu PPA supporting the latest version of SFML (not just the v2.0 RC). So now the SFGUI cmake installation worked. In addition this PPA also support TGUI packages which also work.

So I am going to view both and choose one for my poject.

About the OpenGL widget fameworks: You are all right, I don't know why I did not found them -.-' But I'll focus on SFGUI and TGUI first. But thanks to all of you, too!

Kind regards
Glocke