Welcome, Guest. Please login or register. Did you miss your activation email?

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.


Messages - two-tone-

Pages: [1] 2
1
But because of patent it doesn't come in some Linux distros by default. In Fedora I had to install the extension for GL myself, in OpenSUSE it doesn't come by default too I think, it used to not come with Ubuntu, now it does (I think). I think that extension is technically illegal under USA law but no patent holder would go after pebbles from suing singular users.
Most of us are not from United States of Patents so for 'us' personally it doesn't matter, especially Laurent is in France (I presume) and look at what clusterf**k of patent breaking software is VLC under French law. :P

It's reliant on proprietary drives, yes.  But so what?  Shouldn't the game dev decide if they want to use it and not us?

Anywho, I just thought of a good reason to have it.  I like the simplicity of creating an in-game interface with SFML. I could easily see people using it to create interfaces in 3D games.  The issue is that in 3D games the devs and artists have to be very careful with their memory budget, which is why they use compressed textures.  You can't do that with SFML.

2
Only if you're trying to write software that decodes it.  Telling the GPU driver to decode it is not a violation of those patents.

I just like having the option.

3
I thought of putting this in Feature Requests but decided against it because while I do want this I'm just wanting to generate discussion around the topic.

Examples of texture compression algorithms are S3TC, ETC, and the newer ASTC.

4
Graphics / Re: Complicated movement question
« on: February 03, 2014, 11:02:51 am »
Thanks! I'll do that.

5
Graphics / Re: Complicated movement question
« on: February 03, 2014, 07:20:52 am »
Questions: Isn't normalization just finding the square root of of C^2 from Pythagoras' theorem (Never took geometry so I know very little and the resources online suck)? Wouldn't that then mean that your m_path is just a single float? How does move() use that use that data to direct the transformable? I'm assuming you're using the move() function from the sf::Transformable class, if not please clarify as I have even less of a clue than I already do.

6
Graphics / Re: Complicated movement question
« on: February 02, 2014, 11:59:46 am »
Could you explain your code for me?

7
Graphics / Re: Complicated movement question
« on: February 02, 2014, 10:14:23 am »
Hmm, I understand now but this doesn't solve my original issue.  I realize now that I have not explained my issue very well, so this is all my fault.  I'll restart.

I have 8 locations the player could be on screen and I need to figure out the logic needed to animate the sprite/rect going from on point to another without having write out logic for each of the 64 different paths the sprite could take.

8
Graphics / Re: Complicated movement question
« on: February 01, 2014, 12:43:14 pm »
I am not entirely sure what is going on here.  The map container is something I've been struggling with I'll gladly admit.

9
While they are related, yes, the two problems are very different in nature.  For this question I just wanted an easy way to create a switch based on input from the raw input of the keyboard for key mapping (easier to read), for the other I need to figure out how to move the sprite from one location to x other locations with out having to write an exponential amount of if/if else statements.

10
Graphics / Complicated movement question
« on: February 01, 2014, 10:16:33 am »
My player sprite has a total of 8 different locations it could be on screen based on keyboard input.  If a player presses the A key it sends the sprite to the "A" location. If they press the L key it sends the sprite to the "L" location.

My question is how do I create a movement function that can send the player to any of the 8 locations from any of the other 7 locations without having to write 64 if/else-if statements?  And how can I make sure that it is extensible in the future? So that if I need to bump up or down the amount I don't have to write or remove a dozen statements.

11
Not fast enough.

12
Ah, damn. So much for no if statements.

There has to be a simpler way than writing out a billion if statements.

13
The idea is pretty simple, I would like to write a switch that reads the output from sf::Keyboard. I know I could create a series of if statements, but I feel that makes my code harder to read/more complicated than need be.

I would like it to be something similiar to this

switch(keyboardState)
{
    case A:
        {
            //does stuff
        }
}

14
SFML projects / Re: SFGUI (0.1.1 released)
« on: September 18, 2013, 12:44:35 am »
Question, will there be a tutorial on how to use SFGUI in the future?

15
Ah ha, fixed it.  Simple misunderstanding on what Kojay said

I did

sf::RenderWindow mainWindow;
mainWindow.create(sf::VideoMode(800, 800), "Heros of Late - Extreme Pre Alpha");
    instead of just mainWindow.create(etc).  Oops ^^

Pages: [1] 2
anything