Messages

1

SFML game jam / Re: Questions regarding game jam

« on: August 09, 2013, 04:19:33 pm »

2. The Game Jam lasts 72h, the first hour must be dedicated to theme reflexion and only after that you can start to code

From the last jam, it was 1hr planning then 72hr coding.

2

General discussions / Re: SFML Game Jam Submissions!

« on: August 05, 2013, 06:33:14 pm »

the entries all look pretty cool.

Something though that is sadly missing from many are the game assets in the source bundles.  Can you add them please?  It would make recompilation easier from source if the source tree was complete.

3

General discussions / Re: SFML Game Jam 1 Theme Submission Thread

« on: July 28, 2013, 02:43:51 am »

   Can only vote for one option and it doesn't show the votes collected

Isn't there a poll option in the forum?

4

Graphics / Re: Array and tiles

« on: July 25, 2013, 07:52:11 pm »

How I can make collision with t0 rectangle shape?

Code something like this might work:

if(t0.getGlobalBounds().intersects(otherShape.getGlobalBounds())) {
// do something since targetShape has collided with t0 shape.
}
 

This assumes that you are using shape for both your t0 and other object that you are checking has collided.

5

SFML projects / Re: Check out my Engine!

« on: July 25, 2013, 07:44:50 pm »

I have to disagree! While the #ifndef #define #endif pattern is accepted by the C++ standard #pragma once is not and you'll have no guarantee that your compiler is supporting that feature. True it's much nicer to see and write and as a matter of fact I'm using it as well, but it's no where near an indicator for better written code.

By far, it does not make the code any different between the two options outside of 2+ fewer lines.

That is a tricky one, because technically, #pragma once isn't standardized so if you want to get code to compile on some arcane (but standards compliant, like that even exists) compiler, you are safer using the first variant.

Now, re support of this in the compiler/standards..  It is not part of the standard (I thought they put it on a list for Cx10/11 but its not there so oh well)... However, a lot of the compilers out there support it... I would advocate using it over the header guards since the compiler can optimize away recompilation of the unit (not all compilers do that optimization though).

6

General / Re: vectorName.clear() causing problems?

« on: July 25, 2013, 05:47:35 pm »

not having a complete example of the code or any of its dependencies makes it hard to determine the cause of the exception here...

However, something that I can suggest is verify that Group1/Group2 are not-null and that the Get method returns something not-null before you attempt to use it (one headache of using pointers everywhere)

7

SFML projects / Re: Check out my Engine!

« on: July 25, 2013, 05:45:22 pm »

On the plus side, hopefully c++11 and 16 will slowly keep growing and in the end there will be tons of sub standard programmers that write comments like (int i=0;//new local int i, initialized to zero) and can't use literally any library and self cook inefficient unsafe solutions, which will make us the gurus of the time.

You must be new here ...   It has already started.. If you look at the general code quality produced today by recent grads vs seasoned devs you will notice a serious lack of standards.. However, I would love to see comments like that vs none at all!  At least that comment would show the dev knows something about what their program is going to do.

Isn't the pattern of:

#ifndef FOO
#define FOO
... code ...
#endif

in headers a bit of a relic of C days that was replaced with patterns like:

#pragma once
... code ...

8

Graphics / Re: Seg fault in loadFromFile

« on: July 24, 2013, 03:05:32 am »

image files must be more than 1 byte in length.  So I can see why stbi is crashing on that.  I am not sure the fix you proposed is right either though.  I haven't looked at the stbi code in depth (too much of it!) but I am sure there is another simpler (and safer?) fix.

Perhaps after opening the file (via fopen, etc), a file length check can be done and abort if the file is not long enough for any of the image signatures?

9

General / Re: writting std::vector<sf::String> to .txt file and load from it.

« on: July 24, 2013, 03:01:25 am »

for (std::vector<sf::String>::iterator itr = strings.begin(); itr != strings.end(); ++itr)
{
saveIt << *itr // or saIt << &itr or saveIt << itr i get error
}
 

error: no match for ‘operator<<’ in ‘saveIt << itr.__gnu_cxx::__normal_iterator<_Iterator, _Container>::operator* [with _Iterator = sf::String*, _Container = std::vector<sf::String>, __gnu_cxx::__normal_iterator<_Iterator, _Container>::reference = sf::String&]()’|

Change this to:

for (std::vector<sf::String>::iterator itr = strings.begin(); itr != strings.end(); ++itr)
{
saveIt << itr.toAnsiString();
}
 

Or, pass "itr" to the functions that FRex put up.

10

Graphics / Re: Seg fault in loadFromFile

« on: July 24, 2013, 02:46:31 am »

-just use stat or dirent or something to avoid opening directory like that?

This is what I would recommend here.  However, the checking of this should be done wherever file access is done (could there be a common base class that handles file interaction?)

11

Network / Re: Unhandled exception: Access violation

« on: July 24, 2013, 12:01:26 am »

the exception you are seeing is very likely related to using a pointer you have already freed but still trying to use.

You probably want to clear the selector before you start deleting the tcp sockets, also closing them if they are open would be recommended.

If you run this within VS in debug mode it should trigger the debugger and tell you which line is causing the exception.

12

General / Re: Where to deliver shared libaries during installation ?

« on: July 23, 2013, 11:23:46 pm »

For windows, you can package the dll files in the same directory as your main program and they will be picked up automatically.

For linux, it would depend on your packaging.  If you are releasing via rpm/deb/etc you can set a dependency on the packages providing the runtime library bits you require.  Another option is to specify LD_LIBRARY_PATH in a sh script to point to your own lib directory, don't overwrite the value but append it as:

LD_LIBRARY_PATH=<my lib dir>:$LD_LIBRARY_PATH

I would not recommend polluting /usr/local/lib with any pre-compiled libraries you deliver unless they are part of your game!

13

General / Re: writting std::vector<sf::String> to .txt file and load from it.

« on: July 23, 2013, 10:46:35 pm »

Error:  no match for ‘operator<<’ in ‘saveIt << Text’ .

 I think thats becouse standard c++ doesnt know of sf::String. Any idea how to solve this? And sfml addon for file system or anything?

Looks more like a misuse of std::vector.  This is a collection type and you would likely need to iterate it to get the sf::String objects and write those individually instead of trying to write the collection object.

something like this maybe (not exactly right, not in front of an IDE currently):

for(std::iterator *iter = Text.start(); iter != Text.end(); iter++) {
  saveIt << *iter;
}
 

14

Graphics / Re: Seg fault in loadFromFile

« on: July 23, 2013, 10:17:19 pm »

....loading any kind of resource (shader, texture, font, sound, music, ...) with the path of a directory should produce similar results. And not only in SFML. So I really feel like we are missing something obvious.

The problem reported was trying to open "data/" or "data" (both directories, existing) as a file to load something from.  I think this is more of a generic problem in the caller and not necessarily something in SFML that is at fault here.

Though, handling this in a more graceful approach would be nice to have.  Using stat() or GetFileAttributes() would ease the creation of an exception or similar case to be raised when a caller provides an invalid value (directory instead of file, or missing file, etc).

15

Graphics / Re: Seg fault in loadFromFile

« on: July 23, 2013, 08:26:37 pm »

But PhysFS is also nice-- it's written in C however. Thus, in order to use it reasonably in bigger projects, you would have to build RAII wrappers, too.

I would imagine most bigger projects would integrate it using the sf::InputStream approach and cache the SFML objects and not the actual file system objects.

Further on that thought, it would likely be in a small number of Cache objects (ideally one or one per object type) that internally know how to deal with PhysFS or similar interaction with the filesystem objects.