SFML community forums
Help => Graphics => Topic started by: general sirhc on August 10, 2010, 10:29:57 am
-
I am currently converting my game from GML (Game Maker Language) to C++ and I am using the SFML library for all graphics however I am having a lot of trouble replicating how surfaces in GM work.
A surface in GM is basically a render target which you can draw onto.
My actual problem is that I have static shadows that I want to draw with say an alpha of 0.6 (these are loaded from file) but the shadows overlap when they're drawn and the overlap areas are darker because of it, so I was wondering how do I draw them all say to say another image or something and then draw that image as a sprite with 0.6 alpha
Apologies if I didn't make myself clear enough, its a bit confusing to explain.
I'm using SFML 1.6.
Thanks to anyone that can help
-
If all you need is a pixel copy, you can use Image::Copy.
If you really need to draw to an image like you would do to a window, SFML 2 has the RenderImage class.
-
Thank you for the very quick reply.
I don't think copy will work in this situation because the in game world is a giant map (not like a simple level based game where everything is on the screen at once) and that the map is built by the player so although the shadows are static they image that has all the shadows needs to be updated fairly often. I decided against using copy because "This function does a slow pixel copy and should only be used at initialization time"
-
Ok I see, you really need the RenderImage class. But you'll have to switch to SFML 2.0, which has not been released yet (but is stable enough to be used).
And don't forget that images have a maximum size, you probably won't be able to render your giant map in a single sf::Image.
-
Sadly that what I was thinking would be the end result.
Don't worry although I am new to SFML and not as much C++ I still have got my fair share of programming experience and I have learned my lesson from having very large amounts of useless data.
I only plan on rendering shadows that you can see, not to mention that the map can reach 2621400px X 2621400px at the moment and I plan on increasing it, so attempting to render every shadow would probably cause some problems :P
EDIT:
I don't suppose there is a chance of a private or beta release of SFML 2, I am not worried if you change it later on and I need to do some minor fixes. I would just like to get this working sooner rather than later.
-
I don't suppose there is a chance of a private or beta release of SFML 2, I am not worried if you change it later on and I need to do some minor fixes. I would just like to get this working sooner rather than later.
You can grab the latest version from the SVN repository.
-
If you don't like SVN, there are even snapshots archives directly available on the download page.
-
Okay so now that I have SFML 2, I'm not really sure of the syntax of the new commands, is there is documentation yet or do I just look at the arguments for the functions?
After trying to run my project on SFML 2 I am getting compile errors saying that "no matching function for call to 'sf::RenderWindow::Draw(sf::String&)', it might be something really stupid I've done because I'm tired but help would be nice none the less (Apologies if its something stupid cause i'm tired)
Also on the tutorial page for mingw saying how to set up SFML I noticed this minor typo
"Go to SFML-x.y\build\codeblocks, and open the file SFML.workspace. Choose the configuration you want to build (Debug or Release, Static or DLL), and ---->clic<---- "build workspace". This should create the corresponding SFML library files in the lib directory, as well as the sample executables."
Just thought you might be interested
-
Documentation is here:
http://www.sfml-dev.org/documentation/2.0/
There's no porting guide yet, but you look at the General forum for major changes, I usually open a new discussion for all of them.
Regarding your error, sf::String is now sf::Text ;)
-
Wow you're so helpful =) Definitely the best forum admin I have ever seen =)
Thanks so much and I don't know if it is helpful but here is my current list of things that I needed to changed from 1.6 -> 2.0
[-]Image() default constructor doesn't take width, height and color arguments anymore instead you have to use create after making the image.
[-]To get the height and width of a float rect you just use .height or .width instead of GetHeight or GetWidth
[-]SetText is now SetString
[-]SetCenter is now SetOrigin
[-]SetSize is now SetCharacterSize
[-]GetCharacterSize has been removed because you can set font size in the text object
[-]SetFromRect for views is now SetViewport
[-]SocketTCP is not TcpSocket (Note the capitals it is case sensitive)
[-]Connect(port,IP) is now Connect(IP,port,timeout)
[-]Close() for networking is now Disconnect()
If you would like I will continue editting this post with all the things I had to change in my project <Not really sure if its useful to you>
EDIT:
Thanks for the clarification on SetCenters replacement
-
[-]SetCenter is now SetPosition <I think...>
SetOrigin ;)
-
Never mind, it couldn't find the files because when they're compiled by the SFML 2.0 stuff they get put into a mingw folder inside the lib folder and that was the problem cause I was searching in the lib folder and not the mingw folder
Btw I added some more things to my list
-
[-]SocketTCP is not TcpSOCKET (Note the capitals it is case sensitive)
TcpSocket, not TcpSOCKET.
There are many many more changes, so I'm not sure this list is worth the effort. I should probably make my own changelog public, instead :lol:
-
Hehe woops =p
Yeah it probably isn't worth the effort.
Btw I fixed my other problem and it compiles and runs and the login screen is fine and everything is drawn as normal (however this bit doesn't have views yet) After the login screen it starts using views, so I am using view.SetCenter but the screen is just black, im not sure if its something I'm doing or what, however I just realised I have some HUD which are always drawn no matter where the view is so the HUD should be getting drawn but its not, any ideas?
-
The View class has changed quite a lot, you should make sure that you've properly converted everything.
-
Okay so I got everything working with the views, I was doing some bad maths that was screwing it up. However I finally managed to find something that isn't my fault (at least I don't think it is)
In the documentation you say
Clear (const Color &color=Color(0, 0, 0))
Clear the entire target with a single color.
However I made a RenderImage and just because I am a persistant bastard I decided I would put
image.Clear(sf::Color(0,0,0,0));
And to my surprise it worked... The RenderImage was invisible and the stuff I drew on it wasn't! I tried different background colors just in case I had white on white but I am pretty confident its not me. If I am right about this we will both be very happy =)
(Sorry if I didn't make sense, im excited about RenderImage's having alpha support!)
-
Of course RenderImage supports alpha ;)
I don't understand what's "wrong" with what you showed, it behaves as expected.
-
Well the documentation says that clear only supports R G B and not A
-
Well the documentation says that clear only supports R G B and not A
No it doesn't.
-
Well the documentation says that clear only supports R G B and not A
No it doesn't.
Public Member Functions
RenderImage ()
Default constructor.
virtual ~RenderImage ()
Destructor.
...
...
...
void Clear (const Color &color=Color(0, 0, 0))
Clear the entire target with a single color.
Yes it does
-
Well the documentation says that clear only supports R G B and not A
No it doesn't.
Public Member Functions
RenderImage ()
Default constructor.
virtual ~RenderImage ()
Destructor.
...
...
...
void Clear (const Color &color=Color(0, 0, 0))
Clear the entire target with a single color.
Yes it does
No, that's a default value. When you make an sf::Color, a defaults to 255, so you don't have to specify it. That const Color &color=Color(0, 0, 0) just means if you don't give it a parameter, it defaults to black.
-
Oh I getcha, well it would be nice if it was
clear(0,0,0,255) for the default in the documentation, I was confused for a while about it
-
Oh I getcha, well it would be nice if it was
clear(0,0,0,255) for the default in the documentation, I was confused for a while about it
I think that reading the sf::Color documentation would help you more than me always using the 4-components color constructor ;)
-
Laurent I can't help it if you have a tendency of being right all the time.
Although I still think it would be nice if it had the 4 arguments in the documentation just so it was nice and clear for dumb dumbs =)
Btw do you plan on adding more blend modes or custom blend modes? Either would be very nice =)
-
Although I still think it would be nice if it had the 4 arguments in the documentation just so it was nice and clear for dumb dumbs =)
Ok, you win :P
Btw do you plan on adding more blend modes or custom blend modes? Either would be very nice =)
No, but we can talk about it. Which blending modes would you like to have?
-
subtract: Because its an important on for doing shadows
There is also
add
max
one
zero
But I personally have no use for them at the moment
Why can't you add custom blend modes?
-
subtract: Because its an important on for doing shadows
Can you explain this? Usually, shadows are achieved using add + multiply (which are both available in SFML).
Why can't you add custom blend modes?
I can :)
I just want to keep it simple, I don't want people to have to deal with source/destination and all OpenGL modes.
-
Blendmodes are not my strong point so I hope you don't mind me quoting the GM manual here.
Besides the normal mode it is possible to indicate that the new color must be added to the existing color or subtracted from the existing color. This can be used to create e.g. spot lights or shadows.
Basically with subtract black takes nothing off the color already drawn and white would take all the color. So if you draw 128,128,128 color with subtract blend mode what ever it was drawn over would be darkened by half.
Also again from the book of GM it would be much better to simply have a second command which is for advanced users.
SetBlendMode(blend mode)
SetBlendModeAdv(source blend,destination blend)
Or a different naming scheme
SetBlendModeExt(source blend,destination blend)
Either way it allows basic users to keep using the simply blend modes and advanced users to use the more advanced version... Although I think it would be for intermediate users not advanced since I probably can do this through openGL how things are now instead, couldn't I?
-
Basically with subtract black takes nothing off the color already drawn and white would take all the color. So if you draw 128,128,128 color with subtract blend mode what ever it was drawn over would be darkened by half.
Multiply is usually better to darken things, I don't think that Subtract is necessary for shadows.
Also again from the book of GM it would be much better to simply have a second command which is for advanced users.
SetBlendMode(blend mode)
SetBlendModeAdv(source blend,destination blend)
Or a different naming scheme
SetBlendModeExt(source blend,destination blend)
I know that I can provide such an API, it's just that I don't want to :)
I never add features jst because "I can", I add them when they are really necessary.
-
Personally I think its necessary, maybe you should do a poll of what the users think, blend modes are an important part of graphics rendering
-
"It could be useful" or "it is important" is not enough for me. I don't want to add a feature that nobody will use.
If one day someone comes and requests new blending modes, with good reasons for it, I'll think about it. But until this happens, I don't see any reason to pollute the public API with stuff that nobody's waiting for.
-
Id argue but you already won. Well hopefully that day comes soon that someone really needs it.
-
I don't understand your point of view.
If you need it, tell me why and let's discuss more about it.
If you don't need it, why do you care?
-
Neither
So I chose to do in between, I half discussed it and I half care
My point of view is that having it would make my life easier.
-
My point of view is that having it would make my life easier.
Ok, so tell me why. Imagine that you have those blending modes, and show me how simpler your code would become ;)
-
Well since I am converting my project from GML to C++ basically everywhere that has draw_clear_alpha(c_black,0) now becomes draw_clear_alpha(c_white,0)
Which is about 4 lines :P
(Yes I want to hit me too, so feel free to get in line haha)
There is also some other stuff so it would be more like a total of 10 lines