61
Graphics / Re: Drawing efficency concern
« on: December 11, 2015, 09:48:52 pm »
How complex or cluttered are the visuals on screen at any one time? Could we see a screenshot? 
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.
62
Network / Re: Manage Client on the server
« on: December 09, 2015, 10:38:01 am »
Well generally you'd create a unique client ID, then you'll probably be wanting to relay the positions along with the identifying client ID. Of course this would only give you client sided movements.
63
Network / Re: How Mature is the Network Module?
« on: November 04, 2015, 09:04:27 am »
I'll give you my own brief opinion.
-Using bsdsocks/winsock is not really worth it, using something like SFML's networking is a great deal simpler to use.
-SFML does not provide its own low level UDP -> TCP features, like ENET.
-Binaries SFML network library provides support for transporting more complex data types (like multiple dimensional data structures) and a few other nifty things - but it's a bit more complex to implement.
-SFML's networking is very easy to use, the only hiccup is that you need to really do a bit of multi-threading on the server.
I've used the top three libraries mentioned above (bsdsocks/winsock, ENET, SFML network extension library), yet I only see SFML's as a truly portable and simple-to-use approach for the essentials.
-Using bsdsocks/winsock is not really worth it, using something like SFML's networking is a great deal simpler to use.
-SFML does not provide its own low level UDP -> TCP features, like ENET.
-Binaries SFML network library provides support for transporting more complex data types (like multiple dimensional data structures) and a few other nifty things - but it's a bit more complex to implement.
-SFML's networking is very easy to use, the only hiccup is that you need to really do a bit of multi-threading on the server.
I've used the top three libraries mentioned above (bsdsocks/winsock, ENET, SFML network extension library), yet I only see SFML's as a truly portable and simple-to-use approach for the essentials.
64
General discussions / Re: Fundraiser for a Mac mini
« on: November 04, 2015, 08:48:25 am »
"Only Hiura"
We're all doomed! No but seriously, I hope you enjoy it.
We're all doomed! No but seriously, I hope you enjoy it.
You're absolutely right, using Mac alone is enough of a punishment.So, it will your part of job - programming in Xcode? My condolences... =)Oh no! I couldn't force him to do that.
65
Feature requests / Re: File drop
« on: November 03, 2015, 12:26:51 am »
I wouldn't mind using this feature to easily upload skins for user's ship armour, or crawl a resource archive.
66
General / Re: What is better for pure GUI game project?
« on: October 21, 2015, 11:54:33 am »
I've spent a lot of time using various GUI libraries with SFML - there's still not a perfect solution imo.
We used to use SFGUI and moved to CEGUI, for the most part it has more features and is suitable for a game. However they are both quite generic and have minimal integration with SFML. The API's on both include methods which could be simplified significantly - at the probable expensive of compatibility.
Using either of these are not as intuitive or as efficient time-wise to write as SFML could be on the fundamental level. But at least CEGUI can be themed in amazing ways and has widgets for almost everything.
We used to use SFGUI and moved to CEGUI, for the most part it has more features and is suitable for a game. However they are both quite generic and have minimal integration with SFML. The API's on both include methods which could be simplified significantly - at the probable expensive of compatibility.
Using either of these are not as intuitive or as efficient time-wise to write as SFML could be on the fundamental level. But at least CEGUI can be themed in amazing ways and has widgets for almost everything.
67
Network / Re: Optimizing Networking
« on: June 09, 2015, 12:28:52 pm »
Alex, there's actually a reason people aren't being forth coming with answers.
The reason is you provided little to no information, you are receiving equally informative answers. What you may not be aware is, there is no magic remedy. Just code it in a sparingly way. After awhile you may come up with these kinds of optimizations on your own, suited to your specific game.
Perhaps you should start with creating a tick system, for instance, instead of running everything once every ms, (or more without a sleep) - consider executing it once every period of time. Many games use a tick of 33-99 times a second. Then you can start on only processing & sending the data relevant to particular clients.
The reason is you provided little to no information, you are receiving equally informative answers. What you may not be aware is, there is no magic remedy. Just code it in a sparingly way. After awhile you may come up with these kinds of optimizations on your own, suited to your specific game.
Perhaps you should start with creating a tick system, for instance, instead of running everything once every ms, (or more without a sleep) - consider executing it once every period of time. Many games use a tick of 33-99 times a second. Then you can start on only processing & sending the data relevant to particular clients.
68
General / Re: iOS on windows
« on: March 14, 2015, 06:30:25 am »Well you can get around it with virtual machines if you are in the mood for making them mad but it's cheaper to just buy one of their laptops and call it a day.
Apart from that likely diving into hackint0sh territory, don't you also need a really expensive developer license also?
69
General discussions / Re: SFML 2.2 Released!
« on: December 17, 2014, 09:32:43 pm »
It's not April fools guys!
70
General / Re: GUI C++ game World Editor based on SFML
« on: December 01, 2014, 12:56:25 am »Thank you, try find answers there later today, hope it some help in GUI generation source files.
It doesn't help there's no such thing in the standards, nor SFML. Even finding a decent one suitable for games is very hard to come by.
By sticking to such a simple method to create games, they're not going to have anything exactly new or cutting edge. It sounds like you want to make a game without coding anything.
71
Feature requests / Re: System specs
« on: November 17, 2014, 03:05:53 am »Have you searched before posting? This might be interesting for you.
Nexus, perhaps mainlining this community project would be an applicable use of SFML community development team powers. :3
72
Feature requests / Re: SVG Support
« on: November 17, 2014, 03:01:21 am »
I think since the Android SFML port, SVG is a near-future necessity. Imagine having to provide a 1920x1080 image for a portion of a 2k Android screen, and then proving some smaller images just for the lower powered devices. It's only going to get worse as higher density screens kick in.
73
General discussions / Re: SFML 3 - What is your vision?
« on: November 11, 2014, 02:19:21 pm »
More general purpose functionality, such as a fully fleshed vector class.
74
General / Re: Advice on window seperation needed
« on: June 03, 2014, 09:06:48 am »
A few years ago I did something similar with these libraries and requirements, I'll talk briefly about these things.
So the two main areas of interest are views and SFGUI. I'll start off by picking at the oddities of each.
View
The name is self explanatory, it represents a portion of a larger game world. When drawing you may want to draw as an overlay and then reset draw target to the scroll-able view area for unit drawing. Inheriting sf::View is quite common. However note there's no getPosition() anymore, it's been replaced with getCenter(), which gets the centre most position in view instead of the top left corner.
SFGUI
I used to use this before CEGUI. To get a minimap working, I just used an sf::Image (unless I remember incorrectly), and make it draw the new tiles which come in view as you scroll.
There were a few things which put me off using SFGUI however.
Here's a list on some of the notable good and bad:
CEGUI was a little more difficult to compile as minor changes had to be made for it to successfully compile under MinGW, also the documentation for the CEGUI integration for SFML is both outdated for the latest SFML and CEGUI. So this helps: http://skyr.at/sfml-and-cegui-083.html
I'd say CEGUI is a lot better for games and can be made to look much better and the layout handling is great in comparison. It works well with dynamic alignment and resizing, SFGUI is a bit of a hassle in alignment. Maybe it's changed, although I don't believe it has.
CEGUI still has some daft qualities to it, some of which has been addressed recently. For instance, event handling related data in the doc has to have a series of if/else statements static casting it into various type of event data until the cast type is accepted. Naming is very inconsistent, there is a close button yet the method name to "close" a window is destroy. Many defaults are a bit strange, like the close button by default won't do anything until an event is added. The cursor/text/windows all stretch and resize on window change, giving blurred edges and strange graphical artifacts. Windows need to be coded to stop them going out of view, a few annoyances here.. I could go on for days, ultimately it's feature complete and much more convenient to theme, making it desirable for game interfaces.
It's just our personal opinion.
So the two main areas of interest are views and SFGUI. I'll start off by picking at the oddities of each.
View
The name is self explanatory, it represents a portion of a larger game world. When drawing you may want to draw as an overlay and then reset draw target to the scroll-able view area for unit drawing. Inheriting sf::View is quite common. However note there's no getPosition() anymore, it's been replaced with getCenter(), which gets the centre most position in view instead of the top left corner.
SFGUI
I used to use this before CEGUI. To get a minimap working, I just used an sf::Image (unless I remember incorrectly), and make it draw the new tiles which come in view as you scroll.
There were a few things which put me off using SFGUI however.
Here's a list on some of the notable good and bad:
- The documentation is very good, clean and consistent.
- It integrates well with SFML and is updated regularly regularly.
- Event handling is simple and effective.
- The lack of aesthetic fulfillment leaves interfaces looking quite primitive and plain.
- Layouts can be a real hassle to get absolutely right. We always had to settle for something less
CEGUI was a little more difficult to compile as minor changes had to be made for it to successfully compile under MinGW, also the documentation for the CEGUI integration for SFML is both outdated for the latest SFML and CEGUI. So this helps: http://skyr.at/sfml-and-cegui-083.html
I'd say CEGUI is a lot better for games and can be made to look much better and the layout handling is great in comparison. It works well with dynamic alignment and resizing, SFGUI is a bit of a hassle in alignment. Maybe it's changed, although I don't believe it has.
CEGUI still has some daft qualities to it, some of which has been addressed recently. For instance, event handling related data in the doc has to have a series of if/else statements static casting it into various type of event data until the cast type is accepted. Naming is very inconsistent, there is a close button yet the method name to "close" a window is destroy. Many defaults are a bit strange, like the close button by default won't do anything until an event is added. The cursor/text/windows all stretch and resize on window change, giving blurred edges and strange graphical artifacts. Windows need to be coded to stop them going out of view, a few annoyances here.. I could go on for days, ultimately it's feature complete and much more convenient to theme, making it desirable for game interfaces.
It's just our personal opinion.
75
Network / Re: player info sending
« on: May 30, 2014, 04:14:52 pm »
You may want to research good programming practices and design.
Why the heck are you concatenating values at strings, this code is bloated, practically obfuscated and unreadable.
Why the heck are you concatenating values at strings, this code is bloated, practically obfuscated and unreadable.