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

Pages: [1] 2
Graphics / [Solved] Opacity for Sprites?!
« on: May 20, 2008, 03:05:41 pm »
SFML uses an alpha channel to store opacity as it uses the RGBA colorspace.

You can use the method SetColor to change the alpha value.

Graphics / Drawing Everything
« on: May 19, 2008, 11:49:54 pm »
The reason you get access violations is because your for-statements try to access array elements that are outside the array boundries.

Read up on C++ arrays and try again.

Graphics / Drawing Everything
« on: May 19, 2008, 03:01:45 am »
Code: [Select]
int Position = 1;
First of all, you're declaring the integer Position in the for-loop. So the code will only access the question at index 1. I'm guessing you want to loop through all the questions. Why don't you just use repeat instead of creating a new counter variable?

Code: [Select]
x = x=143;
I'm not sure what you want to do with this line, but it will produce the same code as
Code: [Select]
x = 143;

Graphics / Drawing Everything
« on: May 18, 2008, 05:49:27 pm »
What if you want to change one of those vectors to a list in the future? Then your code would break and you would have to spend time rewriting parts of it.

There's no reason to do that kind of optimization if you don't have huge amounts of static geometry (or sprites) that never change. Even if you did have, there are ways to speed that up by using VBO's, Vertex arrays etc. or just render it to a texture and draw it to the screen before every frame.

It's generally good practice to create the game or application first and optimize later when you actually need better performance. ;)

SFML wiki / SFML wiki is there
« on: May 17, 2008, 12:18:47 pm »
Great. :)
No I don't think subcategories are necessary either.

Quote from: "Laurent"
By the way, why en/miscellaneous/getsvnversion and not en/tutorials/miscellaneous/getsvnversion, or even en/tutorials/getsvnversion ? (I don't think sub-categories are really necessary)

Well when I made the link to the page I created the miscellaneous category in the current namespace, I was thinking that when you add the tutorial namespace it would become en/tutorials/miscellaneous/getsvnversion.
But on second thought, the page wouldn't move if you just updated the link.
Logical error by me. :)

SFML wiki / SFML wiki is there
« on: May 17, 2008, 12:25:29 am »
I have added a first tutorial on how to download the source code from SVN as this seems to be a common question. It can be found under the "Tutorials" section or here: http://www.sfml-dev.org/wiki/en/miscellaneous/getsvnversion.

I would like to come with a suggestion for the wiki though; it would be a good idea to use the namespace functionality for separate categories on the wiki. As it is now all pages are stored under either :wiki:en or :wiki:fr and this might become messy when there are a lot of pages on the wiki.

Wouldn't it be better to create a new namespace for every category? I put the page I created under the namespace "miscellaneous", which would then be a part of the namespace "tutorials" etc.

I would have changed this myself but the main page is locked. :)

Why do you need such a feature anyway?

SDL uses software rendering as default if I'm not mistaken. And thus probably uses bitmaps to store the current frame in RAM. OpenGL talks directly to the graphics hardware which stores the frames in the internal video memory. Thus in SDL you would just be modifying the bitmap in RAM which was then sent to the video card (if present) by OS calls every time it needs to be updated. (I don't know anything about SDL's internals so I'm just speculating here. :))

This is why you only draw what you need to draw onto the bitmap as it's slower for the CPU to blit an image in RAM than using graphics hardware to draw a textured primitive.

You could do the same thing with OpenGL and store the last frame in a texture and then render it before you render the new primitives.

But this kind of defeats the original purpose as this would probably just make it slower.

SFML wiki / SFML wiki is there
« on: May 08, 2008, 08:49:55 pm »
Log in, visit an uncreated page and click the "Create this page" button to the left. :)

But the wiki looks good. I'll post something as soon as I've got something to put up there. :)

General / Contributions
« on: May 04, 2008, 09:04:21 pm »
Well I was thinking more if you wanted to allow it to be endorsed on the site, next to the SFML library. I'd imagine you wouldn't want it to be confused with the original library. ;)

But I'm definately interested in doing such a contribution, now if a few other people are interested we could try to make something like that happen. :)

General / Contributions
« on: May 03, 2008, 08:23:38 pm »
Quote from: "Laurent"
Unless everything is reviewed by someone, separate pieces of code should remain separate.

Why not? There are projects who already have this kind of set up. I'm sure there are plenty of people who wouldn't mind doing such reviews.

There would have to be rules and guidelines so that the code complies with a level of quality before included and endorsed on the site.

But it's up to you if you would want to allow such a thing. :)

Feature requests / Image GL_REPEAT
« on: May 03, 2008, 12:27:42 am »
But these little improvements still take time to implement, even if it is not much time at all. (I have to admit, this specific topic wasn't the best example, but if a number of people requested some advanced functionality to sf::View for example which would break the current one.)

I just think it would be nice to have such features already written, that are easy to get a hold of and integrate well with the library.

It would also stop people from requesting them as a part of the library. ;)

Feature requests / Image GL_REPEAT
« on: May 02, 2008, 01:06:49 pm »
An option could be to add support for these kinds of features as extentions to SFML. That way the library would be consistent "out of the box" and for those who need this extra functionality, they can just get the extention. If a wiki is set up, the extentions could be listed from there.

Just a thought. :)

Graphics / GL_INVALID_ENUM in renderwindow.cpp
« on: April 27, 2008, 01:58:36 am »
The source of the GL_INVALID_ENUM error was probably this line of code:

Code: [Select]

glEnable does not define any GL_PERSPECTIVE_CORRECTION_HINT enum and thus generates the error. http://www.opengl.org/documentation/specs/man_pages/hardcopy/GL/html/gl/enable.html

And that would explain why commenting out those lines removed the error. ;)

Pages: [1] 2