91
DotNet / PInvoke Stack Imbalance
« on: July 05, 2010, 04:46:21 am »
What version of SFML? This should be fixed in the latest revision of 2.0.
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.
92
Window / Execute Code on Key Release?
« on: June 30, 2010, 07:19:50 pm »
Sounds like you need to learn the basics of programming. What you are looking for is conditional statements.
93
General / Bullet Hell performance and optimization problems
« on: June 16, 2010, 09:38:48 am »Quote from: "SuperV1234"
Using a profiler I noticed that SFML.Graphic.Sprite instances do not get cleaned up. Running a program at 60FPS for a long time can make 60.000, 70.000 Sprite instances. How can I prevent that?
It will clean up when the GC runs as long as you have no dangling references. You can manually invoke the GC (see the static class members for the "GC" class), but doing so isn't usually needed and shouldn't be done unless you know what you are doing and have spent some time studying the GC. If you have no dangling references, the GC may just not have needed to run yet. They won't affect performance sitting there dead (until the GC runs), so that isn't much of an issue. The fact that you have so many instances is probably a bit of an issue, though, which is why I suggested just using a single global instance of Sprite. That, or design an object pool (a simple Stack<> often suffices).
Quote from: "SuperV1234"
It runs fine on my GTX275 with less than 5000 bullets. The source code I posted before works perfectly. It's just if I add more than 4800-4900 bullets.
Ah, I see. Sorry for the confusion.
Quote from: "SuperV1234"
I can't use a single Sprite instance. Maybe you meant a single Image instance?
Quote from: "Ashenwraith"
You might not be able to use a single sprite
Why not? You should definitely be using a single Image instance since its all the same image, but you can also use the same Sprite instance. Just set the values on the sprite before drawing it.
Quote from: "Ashenwraith"
Well looking at the code above should you really be creating a new vector every time you change the position and draw the sprite?
Structs are not objects in C#, they are value types and are generally considered incredibly cheap. As far as implementation goes, "new" on a struct is completely different than on an object, and structs never result in garbage collection (unless the struct constructor itself generates objects, which itself is a bad idea).
Quote from: "Ashenwraith"
DDS goes directly into video memory without any decompression/work and is much smaller so any time you are moving around lots of texture data it's a lot faster. You may just notice the initial load being faster if you aren't doing anything complex.
DDS can help with loading times like you mentioned, but once its loaded, its all the same no matter what the source was. It does nothing to help the issue of drawing tons of bullets.
Storing in memory in a DDS format can help when bandwidth is an issue, but I highly doubt that would be the case here. I wouldn't be surprised at all if API calls were the main bottleneck.
94
General / Bullet Hell performance and optimization problems
« on: June 14, 2010, 09:19:19 pm »
Well if my 8800 GTS is running it just fine and your GTX 275 is not, its most likely not a problem with your code logic. Its not like my CPU is exactly powerful anymore, either.
For the sprites, you will definitely want to start pooling them instead of creating a new instance per each bullet. You probably can even just use a different Sprite instance for each bullet graphic, not each bullet. Or use one single global Sprite instance and just set it up before each time you draw it.
For the sprites, you will definitely want to start pooling them instead of creating a new instance per each bullet. You probably can even just use a different Sprite instance for each bullet graphic, not each bullet. Or use one single global Sprite instance and just set it up before each time you draw it.
95
General / Bullet Hell performance and optimization problems
« on: June 14, 2010, 10:39:46 am »
Running the attached program, I get a constant spit-out of about: "13 ---- 2000". Runs nice and smooth.
Core 2 Duo E6750
nVidia 8800 GTS 320 MB
Windows 7 (x86-64)
You could try updating to the latest version of SFML since it looks like you are using a build from 4/4/2010. What I namely have in mind is the commit made on 4/24, where Laurent added the calling conventions for the .NET bindings, which was really killing performance with native assembly calls in some rare cases due to some expensive exception checking stuff that could come with .NET (I forget the name of that all - prefer to wipe that bad experience from my memory).
Finally, you can also try building for release and/or running the .exe directly, not through Visual Studio, just in case the debugger is doing something funky.
Core 2 Duo E6750
nVidia 8800 GTS 320 MB
Windows 7 (x86-64)
You could try updating to the latest version of SFML since it looks like you are using a build from 4/4/2010. What I namely have in mind is the commit made on 4/24, where Laurent added the calling conventions for the .NET bindings, which was really killing performance with native assembly calls in some rare cases due to some expensive exception checking stuff that could come with .NET (I forget the name of that all - prefer to wipe that bad experience from my memory).
Finally, you can also try building for release and/or running the .exe directly, not through Visual Studio, just in case the debugger is doing something funky.
96
SFML projects / ShivaVG and SFML (.NET) for Vector Game Engine
« on: June 14, 2010, 05:21:59 am »
Ohh, this definitely sounds like an interesting project. 
97
Feature requests / LAME MP3 support
« on: June 13, 2010, 08:20:48 pm »
What is wrong with what I wrote? The points I made were:
1. Ogg and MP3 at around 192kbps is, to most, very close to the source
2. Effects with larger range can be encoded at 224kbps to retain those excessive high and low ranges that get removed by most any lossy encoder
3. MP3 is "not exactly great" - its popularity is not an indication of its superiority (otherwise, Xvid must be awesome, too)
4. Ogg is pretty much just as good as MP3
None of that is wrong like you said. Some of it is opinionated, but not wrong.
Only thing I am disagreeing with is your lust for MP3 and absolute hatred for Ogg Vorbis, combined with that you are being a dick for no reason towards everyone stating any opinion against mp3.
And why do you seem to think that anyone who likes Ogg Vorbis hates MP3, or vise versa?
1. Ogg and MP3 at around 192kbps is, to most, very close to the source
2. Effects with larger range can be encoded at 224kbps to retain those excessive high and low ranges that get removed by most any lossy encoder
3. MP3 is "not exactly great" - its popularity is not an indication of its superiority (otherwise, Xvid must be awesome, too)
4. Ogg is pretty much just as good as MP3
None of that is wrong like you said. Some of it is opinionated, but not wrong.
Quote
How do you expect people to agree with you when you don't even pay attention to what people type?
Only thing I am disagreeing with is your lust for MP3 and absolute hatred for Ogg Vorbis, combined with that you are being a dick for no reason towards everyone stating any opinion against mp3.
And why do you seem to think that anyone who likes Ogg Vorbis hates MP3, or vise versa?
98
Feature requests / LAME MP3 support
« on: June 11, 2010, 05:07:51 am »
Wow, calm down there sparky. MP3 is not better than Ogg Vorbis, or vise versa. They're just an alternative to one another and none is always the best in all situations. The problem with MP3 is the excessive amount of patents on it, while Ogg Vorbis does not have this issue. If Laurent can add MP3 support without any patient issues (which is doubtful), then that'd be great since it adds variety. If not, then no biggie.
Its not worth arguing MP3 vs Ogg Vorbis vs any other lossy audio format. Everyone has their own opinions. If you are so bent out of shape over audio quality, and Ogg Vorbis encoded at over 200 kbps is really not good enough for you, then just use lossless. Simple as that.
Also, I'm not sure why you are accusing everyone of knowing nothing about audio formats when you have absolutely no idea what kind of experience we have with audio formats.
Its not worth arguing MP3 vs Ogg Vorbis vs any other lossy audio format. Everyone has their own opinions. If you are so bent out of shape over audio quality, and Ogg Vorbis encoded at over 200 kbps is really not good enough for you, then just use lossless. Simple as that.
Also, I'm not sure why you are accusing everyone of knowing nothing about audio formats when you have absolutely no idea what kind of experience we have with audio formats.
99
Feature requests / LAME MP3 support
« on: June 10, 2010, 09:18:02 pm »
Why use MP3? I can understand it for your every-day music just since its such a popular format and widely supported by portable devices, but MP3 is not exactly great. Ogg is just fine as a MP3 alternative, and is perfectly suitable for using for most game sounds. For game music, Ogg at around ~192kbps, like mp3, will be good enough quality in comparison to the source. Of course, you can always go higher (~224kbps), which may be needed for effects like explosions.
100
DotNet / Sprites become flat squares when renderWindow is re-created
« on: June 07, 2010, 09:37:32 am »
I highly suggest grabbing the latest version of 2.0 from the SVN repo. 2.0 is far more stable (in my opinion), and the latest version supports .NET very well.
If its still an issue in 2.0, I'll check it out more thoroughly.
If its still an issue in 2.0, I'll check it out more thoroughly.
101
General discussions / Switching to CMake
« on: June 05, 2010, 02:18:58 am »
If its easier for you, I say go for it! I know what its like to work in a development environment you're not too happy with. Makes you just not want to write anything.
102
General / sf::Image is too big?
« on: June 04, 2010, 07:19:05 pm »Quote from: "Fuv"
Thanks for advices. It was image fault - too many colors.
Kind Regards
Fuv
Oh? Interesting. I wouldn't think that would be a problem, unless maybe your buffer is 16-bit color but image 32-bit. But even then, it should downsample to 16-bit.
103
General / VS 2008 Express or 2010?
« on: June 04, 2010, 11:14:29 am »
Might as well. You can install them side-by-side, so if you don't like 2010, you can go back to 2008.
104
General / sf::Image is too big?
« on: June 03, 2010, 11:28:15 pm »
Texture requirements come in powers of 2, so with that size, your graphics card will have to support 2048x2048. Unless you have a very old graphics card, you most likely can support that.
First off, make sure the file exists and that the casing is correct. Whatever program you used to save the file may have saved it in a nonstandard format. Unlikely, but it does happen. In which case, you can try saving it as a simple bitmap (*.bmp).
First off, make sure the file exists and that the casing is correct. Whatever program you used to save the file may have saved it in a nonstandard format. Unlikely, but it does happen. In which case, you can try saving it as a simple bitmap (*.bmp).
105
General / sf::Image is too big?
« on: June 03, 2010, 08:21:41 pm »
You are restricted by the support of your graphics card. What are the dimensions of the image? The file size shouldn't matter, but the dimensions of the image will.