SFML 2.0 Release Candidate is out
closed account (1yR4jE8b)
Can't wait for the full thing, i'll be using this in the meantime.
http://sfml-dev.org/
http://sfml-dev.org/
Is anyone else bugged by the fact that they've changed the style of method names from
[edit] Also, sf::Shader looks pretty cool.
MyMethod to myMethod?[edit] Also, sf::Shader looks pretty cool.
Last edited on
I don't know that I'm 'bugged' by it, but I did think it was an odd thing to do. Requiring clients to touch almost every snippet of code to update to the new version doesn't seem like such a grand idea.
There are a few other changes I don't like, but they're outweighed by the things I do like.
I kind of hate it too. All my old projects need to be converted -.-
And I associated CamelCase with sfml in my projects too.
And I associated CamelCase with sfml in my projects too.
One thing I've just noticed which seems really stupid is that the pixels in the update method of sf::Texture are Uint8s. Unless they're going waaaaay against convention and using 8 as the number of bytes instead of bits, they're using 8-bit colours. Even if it was 8 bytes it'd be stupid because the human eye can't detect that many different colours. I want 24 bits + 8 bits for the alpha channel :/
Am I missing something?
Am I missing something?
Last edited on
Were you looking at:
If so then you may want to read the full description of the method:
| void sf::Texture::update ( const Uint8 * pixels ) |
If so then you may want to read the full description of the method:
| Update the whole texture from an array of pixels. The pixel array is assumed to have the same size as the area rectangle, and to contain 32-bits RGBA pixels. No additional check is performed on the size of the pixel array, passing invalid arguments will lead to an undefined behaviour. This function does nothing if pixels is null or if the texture was not previously created. |
I read it but I missed the "32-bits RGBA" part. So, then, it goes like this:
That makes a little more sense.
+---------------+---------------+ | pixel 1 | pixel 2 | +---+---+---+---+---+---+---+---+ | r | g | b | a | r | g | b | a | +---+---+---+---+---+---+---+---+ |
That makes a little more sense.
That doesn't bother me at all because that is how I code anyways. The
Just an example.
|
|
Just an example.
I'm having a slight problem with it. Instead of rendering a white dot moving from the top right of the screen to the top left, it's rendering random garbage. It looks like it's rendering other things that are in video memory so my guess is it's a problem with bounds checking. It persists if I set r to 4 (see screenshot).
I don't think it's a bug in my code but I'm not sure.
Here's a screenshot: http://i.imgur.com/eRMw8.png
The relevant code is visible in the screenshot.
I don't think it's a bug in my code but I'm not sure.
Here's a screenshot: http://i.imgur.com/eRMw8.png
The relevant code is visible in the screenshot.
Last edited on
I personally like the convention change cause thats how I call my own methods, and I don't have a code base that could be messed up by it. Did anyone check whether or not you could control the OpenGL context profile now? It used to be forced to Compatibility, and I do remember complaining about that on the forums (and Laurent saying that he was going to change that once the Graphics module was OpenGL3+ compatible).
You can control the major and minor numbers of the OpenGL context so I assume that means you can use core profile if you want to.
Take a look at the ContextSettings class: http://sfml-dev.org/documentation/2.0/structsf_1_1ContextSettings.php
Take a look at the ContextSettings class: http://sfml-dev.org/documentation/2.0/structsf_1_1ContextSettings.php
You could control major and minor version before, but last time I checked you couldn't create a core profile (without editing SFML's source anyways). Of course it wouldn't be compatible to the Graphics module either, but I think I can live with that (barely).
It looks like it's going to be added after SFML 2.0 is released (in a 2.x version): http://en.sfml-dev.org/forums/index.php?topic=4860.0
Ah well. Whatever. I only need it for convenience (specifically, immediately noticing when I'm using deprecated functionality) anyways. I'll just glue myself to the OpenGL docs then. But it seems that starting to use the graphics package now would be a waste of time anyways- he said he'd do a lot of changes to it.
@Chrisname
I haven't had occasion to use sf::Texture::create yet, but the documentation doesn't suggest that the texture created is initialized to anything particular, and you only seem to be updating a portion of the texture (assuming Position.x and Position.y are non-zero.) Perhaps that's the cause of your artifacts?
I haven't had occasion to use sf::Texture::create yet, but the documentation doesn't suggest that the texture created is initialized to anything particular, and you only seem to be updating a portion of the texture (assuming Position.x and Position.y are non-zero.) Perhaps that's the cause of your artifacts?
If you're starting a new project you may as well start using 2.0 now, but there's no point migrating old projects to it, at least until the official version comes out.
@cire,
That's probably it. I thought it was running off the end of the buffer and reading from graphics memory used by other processes.
[edit]: Yep, you were right. Thanks.
@cire,
That's probably it. I thought it was running off the end of the buffer and reading from graphics memory used by other processes.
[edit]: Yep, you were right. Thanks.
Last edited on
Topic archived. No new replies allowed.