31
Graphics / 3d ~ Or SFML + Irrlicht
« on: November 20, 2011, 12:09:47 pm »
Not to be unsupportive of SFML, but Irrlicht does have a 2d module. I've not really used it myself but it seems quite capable.
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.
32
Graphics / RenderWindow.Clear() crashes
« on: November 15, 2011, 04:55:41 am »
You need to link debug libs in debug mode. I'd guess that's the problem.
33
General / [SOLVED]Custom Icons in SFML?
« on: November 14, 2011, 07:43:07 am »
Depending on your IDE, you could try right clicking on Uint8 to find the definition. This is a very common typedef for an unsigned char (Unsigned integer of 8 bits).
The SetIcon function wants a Uint8 pointer which is called pixels(this is a big clue). Hey! 8 bits per channel per pixel - maybe this is related. You need to provide the window with an array of pixels, which, conveniently sf::Image provides. http://sfml-dev.org/documentation/1.6/classsf_1_1Image.php#ad1594ab4251d6fc833a48dd242918631
The SetIcon function wants a Uint8 pointer which is called pixels(this is a big clue). Hey! 8 bits per channel per pixel - maybe this is related. You need to provide the window with an array of pixels, which, conveniently sf::Image provides. http://sfml-dev.org/documentation/1.6/classsf_1_1Image.php#ad1594ab4251d6fc833a48dd242918631
34
Window / Two keys pressed at once - The first key pressed forgotten
« on: October 17, 2011, 06:01:51 am »
1.6 - http://www.sfml-dev.org/documentation/1.6/classsf_1_1Input.php
2.0 - http://www.sfml-dev.org/documentation/2.0/classsf_1_1Keyboard.php
Use real time input instead of events.
2.0 - http://www.sfml-dev.org/documentation/2.0/classsf_1_1Keyboard.php
Use real time input instead of events.
35
Audio / Free music resources?
« on: September 22, 2011, 05:02:33 pm »
http://www.mattmcfarland.com
I found this one a while ago. Not a ridiculously huge repository, but some high quality stuff. Seems like a friendly guy too.
Other than that, you can google "royalty free music" as easily as i can
.
I found this one a while ago. Not a ridiculously huge repository, but some high quality stuff. Seems like a friendly guy too.
Other than that, you can google "royalty free music" as easily as i can
.
36
General discussions / State machines or Screens?
« on: September 17, 2011, 03:53:38 am »Quote from: "thePyro_13"
I think you should consider that both of your links are implementations of State Machines.
The links you provided are both tutorials on state machines. Lazyfoo's even goes into different types before explaining the very robust system he suggests using.
37
General discussions / The new graphics API in SFML 2
« on: September 12, 2011, 04:02:27 am »
I think having some more transformations (like Groogy was saying) would definitely be good. sf::Transform could even be opened up to a policy system to allow users to define their own transformations. Although this may not really fit with the S in SFML.
Other than sf::VertArray I don't think you can get much more descriptive than sf::Mesh
Although "mesh" tends to suggest (to me) three dimensions.
It would be nice to be able to define custom blend modes with sf::BlendMode.
Overall, this looks pretty good.
Higher-level convenience classes:
You could make sf::Sprite really basic and handle texture resources internally. i.e. you could make a sprite with sf::Sprite sprite("somefile.png");
In my opinion sf::Sprite needs to have its own transform stuff - it's very easy to consider that my sprite is rotated so much. But there is always people wanting to be able to rotate about a point that is different from the sprite's "origin" so they will either need to use the lower-level system, be able to use sf::Transform with their sprites, or all of the transforms will be needed to be implemented in sf::Sprite.
I think getting rid of sf::Drawable and having the "drawable" classes as their own things sounds good.
Simple text rendering is a crucial feature but I can't think of any major improvements over the current API.
Other than sf::VertArray I don't think you can get much more descriptive than sf::Mesh
Although "mesh" tends to suggest (to me) three dimensions.It would be nice to be able to define custom blend modes with sf::BlendMode.
Overall, this looks pretty good.
Higher-level convenience classes:
You could make sf::Sprite really basic and handle texture resources internally. i.e. you could make a sprite with sf::Sprite sprite("somefile.png");
In my opinion sf::Sprite needs to have its own transform stuff - it's very easy to consider that my sprite is rotated so much. But there is always people wanting to be able to rotate about a point that is different from the sprite's "origin" so they will either need to use the lower-level system, be able to use sf::Transform with their sprites, or all of the transforms will be needed to be implemented in sf::Sprite.
I think getting rid of sf::Drawable and having the "drawable" classes as their own things sounds good.
Simple text rendering is a crucial feature but I can't think of any major improvements over the current API.
38
Graphics / Technique for drawing splines?
« on: September 04, 2011, 01:51:18 pm »
I've been playing with b-splines a bit lately - working on a small shmup. I was wondering if anyone has a particularly clean way to draw splines/curves.
Currently I am just drawing lines at an interval determined by how many control points are in the spline. This works relatively well while the spline is static, but when modifying the spline this interval changes and the result isn't the most pleasing.
It's not a huge issue, especially because you only see it in the editor, but I figured someone must have done this before, though I didn't find anything in my searching.
tl;dr - I'm bored. Let's talk about computer graphics and programming
Currently I am just drawing lines at an interval determined by how many control points are in the spline. This works relatively well while the spline is static, but when modifying the spline this interval changes and the result isn't the most pleasing.
It's not a huge issue, especially because you only see it in the editor, but I figured someone must have done this before, though I didn't find anything in my searching.
tl;dr - I'm bored. Let's talk about computer graphics and programming
39
General / Strange input behaviour (Checking two inputs at once)
« on: September 02, 2011, 05:49:55 am »
Thanks for the work-around.
Still a strange bug though.
Still a strange bug though.
40
General / Strange input behaviour (Checking two inputs at once)
« on: September 01, 2011, 01:58:37 pm »
Thought I should try this on another computer - same behaviour (Different keyboard/mouse, Windows XP SP3)
41
General / Strange input behaviour (Checking two inputs at once)
« on: September 01, 2011, 01:50:08 pm »Quote from: "Silvah"
are you sure you're actually releasing the mouse button before pressing Shift?
Definitely.
42
General / Strange input behaviour (Checking two inputs at once)
« on: September 01, 2011, 01:32:24 pm »
Sorry, should have put that in the original post. Windows Server 2008 R2.
43
General / Strange input behaviour (Checking two inputs at once)
« on: September 01, 2011, 01:11:45 pm »
I've come across a bit of an odd problem while working on a simple editor for a shmup. I have several controls which require holding down a keyboard key and using the mouse (although it appears to happen with any combination of two inputs).
The if statement will be executed by pressing both Shift and Left mouse, or pressing the mouse button and then shift. If I swap the Mouse button check and the LShift check (Mouse::Left && Keyboard::LShift), it works in the opposite order, which makes me think I'm doing something stupid.
I'd usually do more experimentation/research before posting an issue here, but I have a deadline this time :wink:
I'm using an out of date SFML2 build (end of July) - After the new input system (as you can see) but before the sf::Image/sf::Texture split.
OS: Windows Server 2008 R2
Any help would be great!
Code: [Select]
int main()
{
sf::RenderWindow window(sf::VideoMode(1024, 768, 32), "Blah");
sf::Vector2f pos(0, 0);
bool running = true;
while (running)
{
sf::Event ev;
while (window.PollEvent(ev))
{
if (ev.Type == sf::Event::Closed)
{
running = false;
}
}
if (sf::Keyboard::IsKeyPressed(sf::Keyboard::LShift) && sf::Mouse::IsButtonPressed(sf::Mouse::Left))
{
//this code can be executed by pressing Left mouse, then shift
pos.x = sf::Mouse::GetPosition(window).x;
pos.y = sf::Mouse::GetPosition(window).y;
}
window.Clear();
sf::Shape shape = sf::Shape::Circle(pos, 10, sf::Color::Red);
window.Draw(shape);
window.Display();
}
return 0;
}The if statement will be executed by pressing both Shift and Left mouse, or pressing the mouse button and then shift. If I swap the Mouse button check and the LShift check (Mouse::Left && Keyboard::LShift), it works in the opposite order, which makes me think I'm doing something stupid.
I'd usually do more experimentation/research before posting an issue here, but I have a deadline this time :wink:
I'm using an out of date SFML2 build (end of July) - After the new input system (as you can see) but before the sf::Image/sf::Texture split.
OS: Windows Server 2008 R2
Any help would be great!
44
General discussions / [IDEA] Move sf::Rect into System Module?
« on: August 22, 2011, 05:26:47 pm »
How is it a graphical class? I can't render one :lol:
I tend to use sf::Rect mostly for collision detection.
It seems like it could fit alongside the Vector classes in System quite well but I do see why it is in the Graphics module in the first place.
I tend to use sf::Rect mostly for collision detection.
It seems like it could fit alongside the Vector classes in System quite well but I do see why it is in the Graphics module in the first place.