16
General discussions / SourceForge community awards
« on: May 15, 2009, 11:19:17 am »
Love SFML, I'll vote, when the page finally loads 
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.
17
General discussions / Newb question about LGPL license
« on: May 09, 2009, 11:46:49 pm »
SFML is licensed under the zlib/png license which is a lot more permissive than the LGPL.
My understanding:
The LGPL only requires you to release changes you make to the LGPL licensed code IF you dynamically link to the code. You need to released ALL your source code under the LGPL or GPL if you statically link to LGPL libraries.
The simple idea being that end users can take advantage of updates to the LGPL licensed library either by replacing the dynamic libraries with new version or by recompiling with the source you've provided.
Not sure if that makes things clearer or not!
My understanding:
The LGPL only requires you to release changes you make to the LGPL licensed code IF you dynamically link to the code. You need to released ALL your source code under the LGPL or GPL if you statically link to LGPL libraries.
The simple idea being that end users can take advantage of updates to the LGPL licensed library either by replacing the dynamic libraries with new version or by recompiling with the source you've provided.
Not sure if that makes things clearer or not!
18
General / SFML on a Mac using gcc instead of xcode
« on: April 28, 2009, 06:04:19 am »
and it works and is similar enough to my Windows and Linux code to be easy to maintain.
Thanks for your help.
Cheers,
Nick
Thanks for your help.
Cheers,
Nick
19
General / SFML on a Mac using gcc instead of xcode
« on: April 26, 2009, 10:42:01 pm »
Oh, well thats nice and easy! I'll give it a go.
Cheers,
Nick
Cheers,
Nick
20
General / SFML on a Mac using gcc instead of xcode
« on: April 23, 2009, 11:37:35 pm »
I've built the static libs in Linux and got it working and windows under MingW and got it working.
When I was first trying to us the prebuilt Mac OS X binaries I got errors regarding dynlib? (or something) files so I think I got side tracked down a different path trying to avoid them. (There is a Cocoa folder in the Window package, I included that by editing makefiles and got it to compile, but obviously not link!)
If we can forget the mess I've got into is it possible to compile an SFML project using gcc and not xcode's framework system? If not I'll struggle through with xcode and its quirky editing features.
Cheers,
Nick
When I was first trying to us the prebuilt Mac OS X binaries I got errors regarding dynlib? (or something) files so I think I got side tracked down a different path trying to avoid them. (There is a Cocoa folder in the Window package, I included that by editing makefiles and got it to compile, but obviously not link!)
If we can forget the mess I've got into is it possible to compile an SFML project using gcc and not xcode's framework system? If not I'll struggle through with xcode and its quirky editing features.
Cheers,
Nick
21
General / SFML on a Mac using gcc instead of xcode
« on: April 21, 2009, 12:16:17 am »
Oh yes,
I forgot I'd done that, I built static libraries from the Linux sources. Maybe it doesn't work like that!
I'm new to the Mac in case that wasn't apparent. I'm not clear on how dynamic libraries work in that environment and was using static libs on the PC and Linux versions so rebuilt them on the Mac.
I forgot I'd done that, I built static libraries from the Linux sources. Maybe it doesn't work like that!
I'm new to the Mac in case that wasn't apparent. I'm not clear on how dynamic libraries work in that environment and was using static libs on the PC and Linux versions so rebuilt them on the Mac.
22
General / SFML on a Mac using gcc instead of xcode
« on: April 19, 2009, 07:22:05 am »
Is this possible, or is there another good solution to development on a Mac. Basically I'm using Netbeans for the Windows and Linux ports of my project and would love to be able to use NetBeans for the Mac port to keep everything as similar as possible.
I'm making some progress I think, but I'm drowning in dependency hell trying to get it to link properly. I think the amount of errors relating to Cocoa mean I'm missing something critical.
Any ideas?
Cheers,
Nick
I'm making some progress I think, but I'm drowning in dependency hell trying to get it to link properly. I think the amount of errors relating to Cocoa mean I'm missing something critical.
Code: [Select]
Undefined symbols:
"sf::priv::WindowImplCocoa::WindowImplCocoa(void*, sf::WindowSettings&)", referenced from:
sf::priv::WindowImpl::New(void*, sf::WindowSettings&)in libsfml-window-s.a(WindowImpl.o)
"_CGDisplayCurrentMode", referenced from:
sf::priv::VideoModeSupport::GetDesktopVideoMode() in libsfml-window-s.a(VideoModeSupport.o)
"_CFArrayGetCount", referenced from:
sf::priv::VideoModeSupport::GetSupportedVideoModes(std::vector<sf::VideoMode, std::allocator<sf::VideoMode> >&)in libsfml-window-s.a(VideoModeSupport.o)
"_CFDictionaryGetValue", referenced from:
sf::priv::VideoModeSupport::GetDesktopVideoMode() in libsfml-window-s.a(VideoModeSupport.o)
sf::priv::VideoModeSupport::GetDesktopVideoMode() in libsfml-window-s.a(VideoModeSupport.o)
sf::priv::VideoModeSupport::GetDesktopVideoMode() in libsfml-window-s.a(VideoModeSupport.o)
sf::priv::VideoModeSupport::GetSupportedVideoModes(std::vector<sf::VideoMode, std::allocator<sf::VideoMode> >&)in libsfml-window-s.a(VideoModeSupport.o)
sf::priv::VideoModeSupport::GetSupportedVideoModes(std::vector<sf::VideoMode, std::allocator<sf::VideoMode> >&)in libsfml-window-s.a(VideoModeSupport.o)
sf::priv::VideoModeSupport::GetSupportedVideoModes(std::vector<sf::VideoMode, std::allocator<sf::VideoMode> >&)in libsfml-window-s.a(VideoModeSupport.o)Any ideas?
Cheers,
Nick
23
Feature requests / Collisin Detection
« on: March 23, 2009, 09:21:43 pm »
I've put some sample code up on the wiki regarding collision detection, not sure if its the kind of thing you're after.
http://www.sfml-dev.org/wiki/en/sources/simple_collision_detection
while pixel perfect collision detection isn't necessary all the time (and is indeed CPU hogging overkill in most situations) there are times when it is needed and acceptable to use despite quasius's intense hatred of it.
The code I've put on the wiki isn't the best for using pixel perfect detection heavily but its perfectly usable sparingly on any thing I've tried it on. The Circle, AABB and OABB tests are much quicker and cover most situations on their own. This system won't easily let you breakdown sprites into polygon primitives for detection but might be worth using as a start in the absence of any other code.
I've started looking at bitmasks for pixel perfect collision, but I need to improve my maths skills for rotations and translations
My version certainly isn't as fast as PMASK but to prove that pixel perfect collision detection can be done, the PMASK test happily does realtime collisions between 21,000 objects on my machine without even blinking.
http://sourceforge.net/projects/pmask/
Edit: Just re-read the start of this thread. I think any collision detection solution should be completely separate from the core of SFML. Its not really the type of thing a media layer should be responsible for.
http://www.sfml-dev.org/wiki/en/sources/simple_collision_detection
while pixel perfect collision detection isn't necessary all the time (and is indeed CPU hogging overkill in most situations) there are times when it is needed and acceptable to use despite quasius's intense hatred of it.
The code I've put on the wiki isn't the best for using pixel perfect detection heavily but its perfectly usable sparingly on any thing I've tried it on. The Circle, AABB and OABB tests are much quicker and cover most situations on their own. This system won't easily let you breakdown sprites into polygon primitives for detection but might be worth using as a start in the absence of any other code.
I've started looking at bitmasks for pixel perfect collision, but I need to improve my maths skills for rotations and translations
My version certainly isn't as fast as PMASK but to prove that pixel perfect collision detection can be done, the PMASK test happily does realtime collisions between 21,000 objects on my machine without even blinking.
http://sourceforge.net/projects/pmask/
Edit: Just re-read the start of this thread. I think any collision detection solution should be completely separate from the core of SFML. Its not really the type of thing a media layer should be responsible for.
24
General / Change Icon of *.exe
« on: September 17, 2008, 10:17:53 pm »
Its also compiler specific I think, your IDE should have options for it or you can use reshack to change it after its been compiled.
25
Window / A time question
« on: September 16, 2008, 11:22:54 pm »
If you have an ATI card and have that annoying Catalyst Control Center in the system tray that has options for controlling vertical sync for DirectX and OpenGL applications.
Assuming you're on windows right clicking on the desktop a bringing up properties->settings->advanced sometimes includes additional tab specific to your video card which should have those options.
No doubt nVidia has something similar. For other graphics cards I'm not sure.
Assuming you're on windows right clicking on the desktop a bringing up properties->settings->advanced sometimes includes additional tab specific to your video card which should have those options.
No doubt nVidia has something similar. For other graphics cards I'm not sure.
26
General / Implement Collision Detection
« on: September 15, 2008, 05:49:11 am »
Its 'less than a NASA supercomputer'
1.6ghz AMD Laptop with a rubbish video card.
While I appreciate it doesn't mean a whole lot for comparison purposes, the point I'm trying to make is that, when necessary, pixel perfect collision detection is perfectly feasible in a game.
Of course any shortcuts such as bounding boxes etc., should be preferred but there are times (and plenty of times outside of just physics simulations) where pixel perfect detection is required.
I'm sure (without any proof to be honest) plenty of 2D commercial games use pixel perfect collision detection in combination with other methods, and a large number of established 2D game engines do.
3D is a whole other story, but as the OP mentioned sprites to start with I'm assuming we're just talking about 2D here
Anyway without backing things up with actual SFML related advice I'm contributing to this thread getting off track. When I have some OpenGL / SFML collision detection to share I'll be back.
1.6ghz AMD Laptop with a rubbish video card.
While I appreciate it doesn't mean a whole lot for comparison purposes, the point I'm trying to make is that, when necessary, pixel perfect collision detection is perfectly feasible in a game.
Of course any shortcuts such as bounding boxes etc., should be preferred but there are times (and plenty of times outside of just physics simulations) where pixel perfect detection is required.
I'm sure (without any proof to be honest) plenty of 2D commercial games use pixel perfect collision detection in combination with other methods, and a large number of established 2D game engines do.
3D is a whole other story, but as the OP mentioned sprites to start with I'm assuming we're just talking about 2D here
Anyway without backing things up with actual SFML related advice I'm contributing to this thread getting off track. When I have some OpenGL / SFML collision detection to share I'll be back.
27
General / Implement Collision Detection
« on: September 14, 2008, 10:58:36 pm »
Just an update on this approach,
With 20 objects with pixel perfect collision as implemented above in a debug build of Flash it takes up to 2 milliseconds to test the collisions (out of a total of 16-20 millseconds per frame, with Flash locked at 24 frames per second anyways). This is perfectly acceptable for my game, may not be good if you need more objects. This includes includes rotated and occasionally scaled sprites.
Obviously it only detects collisions with a boolean (yes or no) and dispatches events to the collided objects, it doesn't process any information on location of the collision but that can be calculated in the onCollide functions once its necesary.
I know its a completely different story from using SFML and OpenGL, but if Flash can do it, then SFML/OpenGL can do it better I'm sure. It'll be a few months before I'm back working in SFML but I'll share my results when I get there if anyone's interested.
With 20 objects with pixel perfect collision as implemented above in a debug build of Flash it takes up to 2 milliseconds to test the collisions (out of a total of 16-20 millseconds per frame, with Flash locked at 24 frames per second anyways). This is perfectly acceptable for my game, may not be good if you need more objects. This includes includes rotated and occasionally scaled sprites.
Obviously it only detects collisions with a boolean (yes or no) and dispatches events to the collided objects, it doesn't process any information on location of the collision but that can be calculated in the onCollide functions once its necesary.
I know its a completely different story from using SFML and OpenGL, but if Flash can do it, then SFML/OpenGL can do it better I'm sure. It'll be a few months before I'm back working in SFML but I'll share my results when I get there if anyone's interested.
28
General / Implement Collision Detection
« on: August 28, 2008, 12:25:57 am »
Pixel perfect collision detection isn't that slow as long as its done right. I've recently implemented it in Flash and that's GOT to be slower than SFML.
Basic premise:
Do bounding box detection (rectangles) to see if the objects you are testing are even near each other, if not don't bother continuing.
Calculate the rectangle created by the overlap (if this is run ever frame or every n frames for slow moving objects then it'll be a small rectangle we're not working with).
Compare the alpha of the pixels to find pixel perfect collision, there is at most going to be a few hundred to compare, and you can register a hit and bail out at the first pixel that's overlapping.
Done. Doesn't waste much in CPU time, doesn't even get done unless there is a chance that there will be a collision and only runs through the union of the two boxes to ensure the quickest possible comparison.
Obviously if things are a simple primitive shape its better to use that for collision detection as over hundred or thousands of objects it WILL be slower to a pixel level test each time, but its not as doom and gloom aas some people seem to be suggesting.
My SFML game engine will have pixel perfect collision as an option, I image the player sprite will always have it on and other sprites colliding with each other may not need to be so accurate.
Cheers,
Nick
Basic premise:
Do bounding box detection (rectangles) to see if the objects you are testing are even near each other, if not don't bother continuing.
Calculate the rectangle created by the overlap (if this is run ever frame or every n frames for slow moving objects then it'll be a small rectangle we're not working with).
Compare the alpha of the pixels to find pixel perfect collision, there is at most going to be a few hundred to compare, and you can register a hit and bail out at the first pixel that's overlapping.
Done. Doesn't waste much in CPU time, doesn't even get done unless there is a chance that there will be a collision and only runs through the union of the two boxes to ensure the quickest possible comparison.
Obviously if things are a simple primitive shape its better to use that for collision detection as over hundred or thousands of objects it WILL be slower to a pixel level test each time, but its not as doom and gloom aas some people seem to be suggesting.
My SFML game engine will have pixel perfect collision as an option, I image the player sprite will always have it on and other sprites colliding with each other may not need to be so accurate.
Cheers,
Nick
29
General / Contributions
« on: May 01, 2008, 01:04:20 am »
I've had a think about this and come up with a slight change of plan.
ini files obviously only have one level of depth and more flexible preference manager with a hierarchy of nodes and preferences might be more flexible long term and could work for storing localization strings, key maps etc etc.,
Also the information that could be saved could include some sfml specific types (such as sf::Color and sf::Key) in addition to standard int, float, string, boolean etc.,
It'll be a statically linked library with source under the same license as sfml so it can be used in any project with sfml without issue.
Question on use and etiquette do I use the sf namespace or create my own?
ie.,
Cheers
Edit: Sorry about the 'MyPrefs' example, I'm not and never have been a Visual Basic programmer, honest. :lol:
ini files obviously only have one level of depth and more flexible preference manager with a hierarchy of nodes and preferences might be more flexible long term and could work for storing localization strings, key maps etc etc.,
Also the information that could be saved could include some sfml specific types (such as sf::Color and sf::Key) in addition to standard int, float, string, boolean etc.,
It'll be a statically linked library with source under the same license as sfml so it can be used in any project with sfml without issue.
Question on use and etiquette do I use the sf namespace or create my own?
ie.,
Code: [Select]
sf::PreferenceManager MyPrefs; or Code: [Select]
prefs::PreferenceManager MyPrefs;Cheers
Edit: Sorry about the 'MyPrefs' example, I'm not and never have been a Visual Basic programmer, honest. :lol:
30
General / Contributions
« on: April 27, 2008, 07:03:05 am »
Cool, I'll put something together (in the next month or so) and contribute it
Cheers,
Nick
Cheers,
Nick