Messages

1

General / Re: Help on Particle System-Like Rendering

« on: April 07, 2015, 06:18:12 pm »

I was doing that, however the code in Thor confused me because of some  things that I wasn't used to seeing very much. But after grinding on particular parts of C++ that I was still unfamiliar with I got most of it. I'll use this thread though once I am debugging the particle system.

2

General / Help on Particle System-Like Rendering

« on: April 07, 2015, 01:15:47 am »

Hi, I am particularly looking for help on the implementing of a system similar to a particle system. Particularly I do not know exactly how to start with the implementing of emitters and affectors. I also want to implement a way to use animations within the article system as a part of the effects of the creation and deletion of particles.

I understand well enough how particle systems work, however I do not really know how to implement emitters and affectors to work well with the timing to keep the emission rate consistent regardless of the framerate. I know that the Thor Library has a very good implementation of one, however I am reinventing the wheel with learning purposes and I will use the code I develop to implement other things that the Thor Particle system does not allow me to do.

Thanks in advance.

3

SFML website / Re: Promote SFML 2 instead of SFML 1.6

« on: February 19, 2013, 04:11:37 pm »

The RC is already compiled, it depends on what you may want, but you may download the binaries or compile the latest sources, no need (or possibility) to compile the RC.

4

SFML projects / Re: Spine: 2D skeletal animation for games

« on: February 19, 2013, 12:46:36 am »

Awesome software, it will prove useful once I resume my project. Sadly I can't buy it yet, but I will.

5

Graphics / Re: drawing quad efficiently for Spine

« on: February 19, 2013, 12:41:29 am »

I coded this class a while ago: https://github.com/SFML/SFML/wiki/Source%3A-High-Performance-Sprite-Container

It's still lacking some features and good naming, but it has almost all the basic transformations programmed to work through a std::vector of sf::Vertex.

6

General / Re: Graphics tut for SFML 2.0

« on: February 15, 2013, 03:50:44 am »

There's not a full one yet, however, it's easy to port 1.6 code to 2.0, so you can use SFML 1.6 tutorials with only few changes. Also, read this: http://en.sfml-dev.org/forums/index.php?topic=5559.0

7

Graphics / Re: setTextureRect() or setTexture()

« on: February 13, 2013, 02:53:15 am »

setTextureRect(), constantly binding new textures is slow and painful.

This argument is relevant only if you only have one texture in your whole game, otherwise it doesn't make any difference

True, I didn't express myself as well as I should have.

8

Graphics / Re: setTextureRect() or setTexture()

« on: February 12, 2013, 09:46:55 pm »

setTextureRect(), constantly binding new textures is slow and painful.

Thor has some animation classes and there's also class for that in the wiki if you don't want to reinvent the wheel.

9

General / Re: [SOLVED]Assigning a direction to bullets from a vector

« on: February 10, 2013, 10:10:56 pm »

An alternative is to use a polar vector, a polar vector uses an angle and a radius, so you can perfectly calculate an angle and just increase the radius in order to generate linear movement, in order to generate curved movement you can just modify the angle, or modify them both and you get your desired movement in a nice looking notation.

That way you can have linear movement with only one speed instead of two (unless movement is curved, where you'll need an angle offsetting value as well).

10

Graphics / Re: Reusing sprites

« on: February 09, 2013, 04:59:14 pm »

Take a look at my container: https://github.com/SFML/SFML/wiki/Source%3A-High-Performance-Sprite-Container

I am going to make a rework of it soon (more eficiency and a better API), but it's quite complete on reducing draw calls and allowing sprites to be transformed.

11

Graphics / Re: Changing the Hue of a Sprite

« on: February 09, 2013, 01:30:30 am »

After some testing I found out what you meant, for simple images the algorithm works just fine, however there are some pixels that don't get converted correctly (or even not at all) in more complex images which causes it too look very bad. I'm gonna delve further to see if I can fix it and otherwise I'll try the other method to see if it works better.

Edit: I just finished fixing it, it was a problem with float accuracy and other values that weren't correctly passed, the new algorithm uses double and a lower EPSILON for maximum accuracy in all pixels, I'll upload it around midnight if I am still awake or tomorrow. I still have to try the other algorithm and check versus photoshop hue shifting, but at least it now can process big images without producing annoying pixel artifacts.

2nd Edit: It's in the wiki now.

12

Feature requests / Re: Support for more primitives

« on: February 08, 2013, 07:04:41 pm »

No, I hadn't. I made a google search, but forgot to search the forum. This topic's useless then.

13

Feature requests / Support for more primitives

« on: February 08, 2013, 06:43:23 pm »

Something simple and maybe even already planned, but I thought it wouldn't be bad to ask.

All of SFML primitives come from OGL of course, once SFML starts using OGL 2 adding all of it's primitives would be nice and grant more rendering possibilities. GL_POLYGON, GL_QUAD_STRIP and GL_LINE_LOOP are the only missing ones I think.

14

Graphics / Re: Sprite Efficiency

« on: February 05, 2013, 08:18:46 pm »

The RenderStates have a texture* alongside a blendmode and shader if any. Once again a look at the doc or the sources could have solved it without asking.

It would be better to construct the RenderStates with the texture (to be more explicit), a missing include can also be the cause of some compiling errors in the case you are not including the whole graphics module.

15

General / Re: Problem with simple code.

« on: February 04, 2013, 02:52:41 am »

Moreover, the code above can be easily ported from 1.6 to 2.0.