Messages

16

Graphics / Re: Changing the Hue of a Sprite

« on: February 03, 2013, 02:17:06 am »

It depends on what you want to do with the image and the image itself. For example there are cases where shifting the hue does nothing or nearly nothing (gray and near gray colors) as they have little to no saturation. In a colorful image it actually has a purpose to shift the hue for color purposes. In the case you want to colorize an image a set in stone saturation helps get more consistent results.

Most of my tests when I first programmed it were with color codes and plain colored images, and since they turned fine after extensive debugging I just uploaded the class and forgot about it. I'm gonna make a more extensive testing of the algorithm with more complex images and see if I get odd results.

Here's the original algorithm written in pseudo-code:

http://www.easyrgb.com/index.php?X=MATH&H=18#text18
http://www.easyrgb.com/index.php?X=MATH&H=19#text19

The raw formula came from wikipedia's entry on HSL and HSV, but it's rather confusing unless you are really into pure math notations.

I set it to a very low number (0.0001 or something). Maybe that was the reason?

The EPSILON is fine as a low number because it's precisely for float comparison, so there should be no problems with it unless the EPSILON value wasn't defined.

Edit: After checking for more algorithms I found a very interesting one, which uses an approach similar to YUV coloring to convert it. If it turns out to be more effective or efficient I'll change the class to use that. Here's the link if you're interested.

http://www.quasimondo.com/archives/000696.php

17

SFML projects / Re: SimpleSprite

« on: February 02, 2013, 03:31:51 am »

All you need is a Github account and you can modify the wiki and add your sources and a short explanation in a new page, and of course link the page to the sources menu.

18

Graphics / Re: Changing the Hue of a Sprite

« on: February 02, 2013, 03:28:19 am »

How did you use it? When I created the class I tested it many times and it worked fine with sf::Image and the console output of the values were mostly correct. The algorithm isn't mine, I took it from another website, but in per-pixel color shifting there were no issues after debugging. Also note that the formula is quite hard to follow, I had tons of hard to track errors when I first programmed it.

19

SFML projects / Re: SimpleSprite

« on: February 01, 2013, 08:04:45 pm »

Post it in the wiki, it's better than to attach it to a thread that may die and not be seen in long time.

20

Graphics / Re: Changing the Hue of a Sprite

« on: February 01, 2013, 07:49:49 pm »

sf::Shader from 2.0 has support for both Fragment and Vertex shaders written in GLSL.

21

Graphics / Re: Changing the Hue of a Sprite

« on: February 01, 2013, 05:45:14 pm »

The problem is that when you modify the image you have to re-bind the texture, and that takes more time than image processing. That is what actually makes it slow. The shader approach works around that.

I dislike the getColor/setColor approach because the default color of a sprite is white, which may or may not have saturation and therefore doesn't matter if you change the hue. To actually make a change you need to do lots of trial and error with the color filter, and probably only one image will get some benefit from that. The shader is the standard and best way of doing things fast.

Moreover, you can program your shader to skip unnecessary computations anyway.

22

Graphics / Re: Tiling with sf::RenderTexture

« on: February 01, 2013, 05:09:30 pm »

If you don't want to reinvent the wheel you can check the wiki, there's some tiled-map classes there.

23

Graphics / Re: Changing the Hue of a Sprite

« on: February 01, 2013, 04:54:06 pm »

so I will  do something similar to HSL, but alot cheaper in computations :-) ty for recommendation to go manual route

My class can work well for preprocessing of images (else it will be painfully slow), but as Laurent said, you can perfectly use it with sf::Color and try to experiment your way to the desired outcome. However if you want full control over the hue change you can perfectly use a hue shifting shader. There's plenty in the net and the algorithm is the same, what changes is the mainly the notation of it.

If you know GLSL you can even make your own by looking at the source of the conversions, that way it can work in a more intuitive way and have it work fast in repeated run-time.

24

Window / Re: Rotating object using analog stick on a game-pad.

« on: January 24, 2013, 05:54:01 pm »

On a more elaborate note you could use polar vectors to power rotations of all types. Polar vectors use std::atan2 and other math to give you more control over what you want to do.

25

SFML projects / Re: Freerider

« on: January 23, 2013, 09:05:17 pm »

but which shape should I use? A circle?

If you use photoshop a single black (or some gray color) overlay and transforming/warping of the original can do well enough.

26

Feature requests / Re: getPressedKey event

« on: January 23, 2013, 08:57:39 pm »

I developed an action system in Thor. It unifies the handling of one-time events and realtime input, and allows boolean combinations of multiple actions (e.g. fire action if shift and X is pressed). You could take a look at it

I have only used the particle system so far, so I'll check it.

This function would be implemented with events. So it would do nothing that you can't already do yourself with the current API.

My bad, I thought it was currently not possible to achieve, it appears I didn't think enough.

27

General / Re: Game making tutorial - mac help

« on: January 23, 2013, 04:17:20 pm »

The best advice would be to get to know the language you are programming in very well, many people start without knowing the language and sometimes end up with bad practices or overseeing features that could have made their life easier from the start. Also note that C++ isn't particularly easy to learn, either if you know how to program in another language or if you start from the very bottom, but it certainly pays off in the end. I prefer the language a lot more than Java now that I've taken my time to learn it well.

I don't know if there really is a tutorial that holds your hand through the entire process, and even if there is one it's even more unlikely that you will find one in SFML (A multimedia library that's just beginning to become important in the market, but will become bigger and more important) since it's relatively new in comparison to other projects. So even it there is such a tutorial it might be hard to find, if not nigh impossible.

Also be in to have the need to learn tons of math, it will become necessary depending on what you want.

I will try out the pc ones, but i'm afraid they might not work propely.

If they are from SFML only they will work, else you will have to adapt code and so on. Note that there are many tutorials and articles that are general and can apply to whatever framework you are using for your programming by only adapting them to your programming language.

28

Feature requests / getPressedKey event

« on: January 23, 2013, 04:03:59 pm »

Not exactly as an event, but could qualify as one.

This feature would be used as a simple way to change the game's controls, when this event is run it polls if any key was touched and it returns the first key touched. Due to it's nature it's not logical (at least to me) for this kind of function to be inside the event loop. It could be as a way to poll for when was a key pressed through real-time keyboard input (without repetition of course), so you can easily get the code of an unknown key and use it for whatever programming you want.

sf::Keyboard::Key NewControl = sf::Keyboard::getPressedKey();
///Returns an invalid key code when no key was pressed.
///If multiple keys were pressed it returns the first one only.
///It could also have certain delay so that it keeps returning the recently pressed key for a short time.
 

This function/feature makes sense in an options menu where you want the player to easily change the input needed for the game. I suggested it as a function, but I don't know if it is really something so convenient that you can easily poll it with just that. Give your opinions towards this.

29

Graphics / Re: Inherited sf::Drawable crashing

« on: January 22, 2013, 09:09:23 pm »

I actually to test this a little more. It was working, but am getting various segfaults even under 32bit. I may have jumped to conclusions.

It was to be expected I guess, note that while a 32bit computer cannot run (sometimes even install) a 64bit program this isn't particularly true backwards. A 64bit computer can perfectly run 32 bit programs.

30

Window / Re: Main while loop is not executing

« on: January 22, 2013, 08:37:23 pm »

I know I'm not supposed to use macro's, but that isn't going to solve the problem now, is it?

Granted that it may not solve the problem, but still it doesn't hurt. It's better to cultivate good habits than bad ones.