Messages

1

SFML projects / Re: sfTheora 1.3.5 and SFML 1.6 VS 2010 Problem

« on: May 18, 2012, 02:58:42 pm »

Oh, to recompile, you'll need to make sure you have the dependencies.

But anyway, I just realized I have one compiled for 1.6 for someone last time, which I uploaded to my server (link should be somewhere in this forum or my blog).
Here's the link to it: www.zorexxlkl.com/files/downloads/SFMLTheora-1.3.5-SFML_1.6.zip

2

SFML projects / Re: sfTheora 1.3.5 and SFML 1.6 VS 2010 Problem

« on: May 15, 2012, 02:12:41 pm »

Did you recompile SFMLTheora 1.3.5 with SFML1.6?
Because the precompiled binaries were compiled with SFML 2 (unstable svn version).

3

SFML projects / Re: sfMidi 1.1 - Play MIDI in SFML

« on: April 12, 2012, 04:22:47 am »

Have you tried following the instructions here?
http://sourceforge.net/apps/trac/fluidsynth/wiki/BuildingWithCMake

4

SFML projects / Re: sfMidi 1.1 - Play MIDI in SFML

« on: April 11, 2012, 06:16:36 pm »

Oh, I just remembered, after clicking configure in CMake for the 1st time, when the red options appear, you'll have to change certain settings, I unchecked everything except for enable-aufile (and BUILD_SHARED_LIBS of course), that's pretty much the bare minimum, which means you don't have anything to play the sound (since we have SFML for that), and enable-aufile allows fluidsynth to load MIDI files, which is all we need.
Trying using that same setting and see if it works.

5

SFML projects / Re: sfMidi 1.1 - Play MIDI in SFML

« on: April 11, 2012, 04:14:57 pm »

yes, you'll have to compile fluidsynth as well if there's no precompiled one available. but if I recall correctly, fluidsynth uses cmake as well, so you shouldn't have problems compiling.

6

SFML projects / Re: sfMidi 1.1 - Play MIDI in SFML

« on: April 11, 2012, 05:05:03 am »

Oh, I didn't realize you were using g++ earlier. >.<
Since the libraries were compiled under MSVC++, I don't think it'll work for g++.
g++ uses libraries which are under the extension .a if I remember correctly. MSVC++ uses .lib files.

Have you tried the CMake version of sfMidi?

7

SFML projects / Re: SolidShaper + Box2D + SFML

« on: April 09, 2012, 03:19:11 pm »

That's pretty damn amazing!
Good work, keep it up!

Thanks for the feedback!

8

SFML projects / Re: SolidShaper + Box2D + SFML

« on: April 06, 2012, 08:29:17 am »

Implementing grouping in SolidShaper will be much more complex than triangulation in SSFile, since it requires changing how shapes are managed in SolidShaper, as well as the file specification as well, so I'd like to avoid that if possible.

However, how SolidShaper is designed to work isn't by putting all the shapes used in your game in 1 file and have different objects use different shape.

You should use SolidShaper to create 1 file for 1 object (characters, etc). This way, you're already grouping shapes as a single object. You also don't have to reload all the shapes if you just want one object, and it's easier to manage as well.

You can, however, put all the static objects in 1 file, like the terrain and other fixed objects.

In other word, if you have a character sprite, just load it as a reference in SolidShaper, outline it with shapes, and save it as a file (i.e. sprite.ssf), then there you go, the collision map for that sprite is done.

You can also achieve concave polygons if you can snap the vertices to the grid, since the only difference between that and triangulation is that, by using polygons, you'll have to manually make sure the vertices are at the same position, so that there isn't any holes (sometimes this doesn't even matter), while with triangulation or triangle strips, this is done automatically.

9

SFML projects / Re: SolidShaper + Box2D + SFML

« on: April 06, 2012, 04:24:58 am »

Yes, triangle strips does help create concave shapes.
However, you have to realize that not all concave polygons can be drawn with triangle strips (without overlapping).

In the link you provided, it says:

this algorithm works ok but the problem is it returns simple triangles which you can't draw with GL_TRIANGLE_STRIP, you need to use GL_TRIANGLES which isn't very efficient on a large number of vertices.

You said you don't want separate shapes connected to a body, however, that is not possible with concave shapes.
Same goes to triangle strips, what triangle strip does is simply break a list of points down into a list of triangles, meaning that if it's 3 triangles, 3 triangles (meaning 3 polygon shapes) will be added to box2d's body.
It isn't inefficient, however, too much of that may of course, slow things down. However, you shouldn't let that bother you, since that's how things are done anyway.

So what I'm saying is, whether you use triangle strips in SolidShaper, or do triangulation in your game engine, the result is the same, you'll still end up having multiple shapes in one body (which is really totally fine).

Ideally I'd like to have one library/method to create and use shapes for collision and drawing. 

I will try to implement triangulation in SSFile, since it's still manageable if I do it there, but since I can't estimate when it will be done, and since you said you're already using Thor in your project, why don't you try (or temporarily use) the triangulation function there until I've implemented it in SSFile?

10

SFML projects / Re: sfMidi 1.1 - Play MIDI in SFML

« on: April 05, 2012, 09:47:42 am »

Oh right, I was stuck with the thought that I have to provide a loadSoundFontFromFile function.
But I do think that function is pretty important, since SoundFonts are reusable, you can unload the midi file and load another midi file without having to reload the SoundFont, and this is pretty important because SoundFont takes a long time to load.

I still think it's cleaner to separate it into 2 libraries, since they work quite differently, and then again there is the multiple dlls problem.
It will also make things easier to manage in the future. 

Edit: Actually, I just realize my first point (in this reply) doesn't change anything since I could make the decision of which backend to use when the loadMidiFromFile function is called, but I still don't see why I should not separate them into 2 libraries.

11

SFML projects / Re: sfMidi 1.1 - Play MIDI in SFML

« on: April 05, 2012, 09:32:45 am »

I'm not sure if I understand exactly what you mean, but how does that solve the problem of differentiation being necessary. Since one library requires SoundFonts to work while the other does not, even if the user don't have to choose between which to use, the internal code will still have to do so somewhere.

Also, since probably nobody will ever use both in the same project (to use SoundFont and to not), there shouldn't be have both in the same library (forcing the user to include both dlls, or recompiling them without either 1).

To my understanding, SFML to abstract platform-dependant code is done during compile time, meaning that it will adapt to whichever platform it is compiled on, not run on, so once it's compiled, it no longer needs to differentiate between which backend to use.
However, in sfMidi's case, sfMidi will have to decide which backend to use depending on whether the programmer provides SoundFont or not, the user may end up using both backends in 1 project for all we know.

Hence, in this case, it would be much better to provide 2 separate libraries.

12

SFML projects / Re: sfTheora 1.4 - Play videos in SFML

« on: April 05, 2012, 08:58:13 am »

Thanks updating.

I compiled the SVN trunk version on 03/03/2012, hopefully the changes you mentioned are made before that date.

13

General discussions / Re: Suggestions for SFMLTheora, sfMod, and sfMidi (Exceptions?)

« on: April 05, 2012, 08:30:03 am »

Klaim and A.D., you're making an assumption that is wrong in my opinion, namely that the presence of exceptions implies bugs in the program.

I don't make this assumption. A healthy program to me means a program that operates in an environment sane enough to never get into the error handling code path. As such, healthiness is more a property of a given run of a program in specified environment, rather than the program itself. Therefore, my point about the exceptional code never being used anywhere in a healthy program still stands.

If, when you say error, you mean unexpected error, then yes, the program should never get into the error handling code path.

However, if you meant any error, then imagine this situation: At some point, you would like to let your user select a video to play, if he selects an invalid or corrupted file, and the program is unable to load it, there you go, an error.
Does this mean that it isn't a healthy program? I don't think so.
Imagine this situation: A user downloaded your program, which includes some data files, the user accidentally deleted 1 of the data file, your program tries to load it, and error. Is it the program's fault?

In conclusion, there are errors that we should "expect", or at least not assume that it won't happen, and this is where the error code vs exceptions come in.

On a side note: sfTheora, sfMidi, and sfMod have just been released, I went with "return boolean", along with an error string. You can retrieve the error string with a function, getError(), or check if there's any error with hasError(). Since it still returns false when it fails, the only time you really have to use get/hasError() (if you don't want any unhandled errors) is after the constructor.

14

SFML projects / Re: SolidShaper + Box2D + SFML

« on: April 05, 2012, 08:03:45 am »

Ah sorry I wasn't specific; I meant while drawing using triangle strip and parts of it overlap how does that draw a shape? 

Triangle strips are pretty much just, well, triangles, so if there's parts overlapped, it's actually just triangles overlapped, like how other shapes overlap, how it's handled will have to depend on your game.
In Box2D, if you set it as a static body, there should be no problems with overlapping shape (since static shapes won't collide with each other).

And I'm a bit confused about the triangle strip/triangulation thing.  When drawing with triangle strip doesn't it break everything into triangles anyway (or that's what it looks like)? Aren't triangle strips just connected triangles? I can eventually outline my sprite using the triangle strip if I do it just right but it takes a while.  Maybe it's just wishful thinking but I think there should be a way to split it up into a strip since everything still does share vertices.  Or maybe have everything share a body and have the shapes grouped?

Well, the difference between triangulation and triangle strips here is, in triangulation, you break them into many triangles, 3 triangles mean 3 shapes, however, triangle strip is considered a single shape, since it's basically just a list of points which are "converted" into triangles when being drawn (in SolidShaper).

After loading triangle strips, what you get is a list of points, then, you can decide to convert it into a list of triangles to be added to Box2D as shapes, or if you're just drawing it, you can just convert them in your draw functions.
However, if it's a triangulated polygon, it will be loaded as a list of triangles instead, the original information of it being from the same shape is lost the moment you triangulate it.

Also, once you triangulate a polygon, the triangles no longer share any vertices, since they are already separate shapes. Meaning that, triangulation is an irreversible process, even if I introduce a grouping system, and you can move the triangulated polygon, they will still not share any vertices.

15

SFML projects / Re: sfMidi 1.1 - Play MIDI in SFML

« on: April 05, 2012, 07:35:11 am »

I'm finally done adapting sfMidi to the latest SFML naming conventions.

I also added a new error handling system (the same one as sfTheora and sfMod).

Dropped SFML 1.6 support as well, since SFML 2.0 will be released as a stable version soon.

See the changelog for the full list of changes.

On a side note, about PortMidi, I've decided to not implement it in sfMidi.
However, there is a chance that I will write another library (sfPortMidi), which will utilize PortMidi.
The main reason is because things will get pretty confusing and/or messy if I introduce PortMidi into sfMidi.
There will be 2 Midi classes, one which uses FluidSynth, and another which uses PortMidi, thus, a name clash (2 Midi classes).
I thought of renaming the current Midi class to SfMidi (SoundFont Midi), but then that will cause confusion in the Music and Loader classes.
I also thought of using the same class, and if you don't load a SoundFont, it will use PortMidi, otherwise it will use FluidSynth, but then every function will have to check if a SoundFont is loaded, then decide what to do, which will create some unnecessary overhead.
Either way, there isn't a clean and simple way to introduce PortMidi in sfMidi.
Hence, I will either drop it or write a new library.
If I do have the time to do so, I will try to write sfPortMidi, but I can't promise anything.