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 - thomas9459

Pages: 1 2 [3] 4
31
SFML game jam / Re: Website Status
« on: February 03, 2014, 07:23:45 am »
Is there a maximum length for titles? When I try to submit my game using the full title, "Shielding: Episode 114", it 403s, whereas if I use a title of 20 characters or less, it works just fine. Any chance of getting that fixed, or is it more complicated than it appears on the surface.

32
Window / Re: Window Initialization
« on: February 01, 2014, 05:06:16 am »
I don't understand it too well, but Copy Elision could be the culprit, i.e. Visual Studio is treating the first code sample as if it were the second because the copy can be easily avoided.

33
General discussions / Re: Searching for music compositor software
« on: February 01, 2014, 01:25:27 am »
If you want to go the chiptune route, MilkyTracker is a good option too (although it doesn't really compare to professional workstations).

34
SFML game jam / Re: Theme suggestions now open!
« on: January 27, 2014, 03:27:37 am »
I don't know if we are supposed to mention themes here (it could influence the voting and all), but I don't think "candy" is a good theme; it already seems to be taken. ::)

35
General / Re: Pthread on ubuntu?
« on: January 26, 2014, 09:11:06 pm »
According to this tutorial, the correct package is libpthread-stubs0-dev.

36
The guaranteed minimum texture size in OpenGL 3.x - 4.x is 1024, so you should be safe with that. Unfortunately, the guaranteed minimum in 2.x is only 64.

37
This occurs because no valid OpenGL context exists on the subsequent calls. Here is what are the relevant events that occur when the posted code is run:
  • The program begins and SFML automatically creates an OpenGL context.
  • sf::Texture::getMaximumSize is called. Because it has a valid OpenGL context, it returns a sane value.
  • The sf::RenderWindow gets created, as well as a new OpenGL context for it.
  • The sf::RenderWindow goes out of scope, and its OpenGL context is destroyed. At this point, no OpenGL context is active.
  • sf::Texture::getMaximumSize is called a second time, but because there is not OpenGL context, it returns a "crazy" value.
If the line testing the texture size is moved to after window is created, it should always return the correct value.

(As a bonus, I found out by toying with this problem that on my old Linux Mint machine, my maximum texture size is 2048.)

TL;DR The posted code contains an "error": it calls sf::Texture::getMaximumSize when there is no OpenGL context.

38
SFML game jam / Re: Website News
« on: January 21, 2014, 08:26:18 pm »
Passwords are stored in the database with a SHA512 hash.  ;)

Hmmm... well... hm... Ok, I think it'll do it :p

Are they salted?

39
Feature requests / Re: An Implementation for Generic Blend Modes
« on: January 21, 2014, 03:42:13 am »
So I ended up being rather bored this weekend, so I went ahead and implemented it. The code is available here (specifically, this commit), and a small test program is available here.

This implementation strays from the original design proposed above, most notable using setters and the addition of the apply() function. One of the issues that I found, however, is that the lengths of many of the identifiers are very long. This becomes especially relevant when using the full constructor (see these lines). This is mainly due to sf::BlendFactor and sf::BlendEquation not actually being enumerations, but rather namespaces that contain unnamed enum, in order to enforce scoping, like sf::Style does.

So, now that code actually, which is sometimes easier to judge than a proposal like above, any comments or suggestions?

40
Feature requests / Re: An Implementation for Generic Blend Modes
« on: January 15, 2014, 10:20:50 pm »
To maintain compatibility to a wide extent, you can do the following (keep in mind that enum distributes the enumerators to the surrounding scope):

I completely forgot about that; my code is full of sf::BlendMode::Blend*.  :-[
A quick search on GitHub leads me to believe that no one uses the verbose method, so Nexus's suggestion of using const BlendMode objects seems to be the best solution to provide compatibility.

Concerning glBlendFuncSeparate(), would it be better to simply add srcFactorAlpha, dstFactorAlpha, and equationAlpha? Also, how would you handle the case where it is not supported? Unless SFML still supports versions before OpenGL 1.4 / OpenGL ES 2.0, the test for the extension doesn't seem necessary (unless I am missing something).

41
Feature requests / An Implementation for Generic Blend Modes
« on: January 15, 2014, 12:13:50 am »
The topic of adding more blend modes has come up several times before, and there is even an open issue in the tracker for it (https://github.com/SFML/SFML/issues/298). Unfortunately, there does not seem to be any progress for over a year on the topic. I recently could have used such a feature myself for creating special effects and believe that this feature would benefit many others as well. I would be more than willing to implement the code if Laurent approves a design.

Here is my design proposal:
  • Change sf::BlendMode to a class with the following public members: sourceFactor, destFactor, and equation.
  • Change the current enumerators of sf::BlendMode to static members of sf::BlendMode of type sf::BlendMode (similar to sf::Transform::Identitiy).
  • Overload the == operator in sf::BlendMode to test if the modes are the same (useful for the cache when drawing).
  • Rewrite RenderTarget::applyBlendMode(BlendMode mode) to simply set the OpenGL blend functions to sourceFactor and destFactor.

Issues:
  • Because this proposal changes the type of sf::BlendMode, should it wait until SFML 3.0 to be implemented?
  • Should the OpenGL constants (GL_ZERO, GL_ONE, GL_SRC_ALPHA, etc.) be used, or should similar constants be defined in the sf namespace?
  • How, if at all, should the separate blending function for alpha be handled?

These changes should (if I understand correctly) keep the following code valid,
void Laser::draw(sf::RenderTarget &target, sf::RenderStates states) const {
    states.blendMode = sf::BlendMode::BlendAdd;
    target.draw(m_sprite, states);
}
while allowing the following as well.
void Laser::draw(sf::RenderTarget &target, sf::RenderStates states) const {
    states.blendMode = sf::BlendMode::BlendAdd;
    // The texture uses premultiplied alpha
    states.blendMode.srcFactor = GL_ONE; // or sf::BlendFactor::One
    target.draw(m_sprite, states);
}

What do you guys think? Any suggestions and/or improvements?

42
Feature requests / Re: float, float for ctors or setSize
« on: January 11, 2014, 07:45:40 pm »
It is possible (at least in c++11) to use this:
sprite.setSize({200,200});
instead of this:
sprite.setSize(sf::Vector2f(200.f, 200.f));
This technique can also be applied elsewhere, such as for sf::Color. It's not very clean, but if your lazy, what do you expect? :P

43
Do you want another issue besides this one? https://github.com/SFML/SFML/issues/466

44
All right, now that I have finally got a chance to try this, I can confirm that this produces the correct behaviour under MATE. So the question is, where do we go from here? I am rather new to the project and do not yet know the workflow. Should I fork the repo on Github, commit the changes there, and create a pull request?

45
Then MATE must be one of those windows managers that needs this trick to disable resizing. Does anyone have a different Gnome-derived windows manager and is willing to test this out?

Also, this is my first experience getting this low level with graphics stuff, but maybe the solution is to use this hack from the window creation method in the window resize function as well. Do any, more experienced programmers think that this might work?

Pages: 1 2 [3] 4
anything