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

Pages: 1 2 3 [4] 5 6 ... 18
46
Graphics / Render Targets
« on: June 15, 2010, 05:14:39 am »
Quote from: "NGen"
Alright, when can we expect SFML 2? Not any time soon, I'm guessing? Would it be possible to get at least a basic overview of how it would work? What we're currently using does something along the lines of:

Code: [Select]
// ( width, height ) rounded up to nearest power of 2
HTARGET hTarget = Target_Create ( 800, 600 );
// Begin drawing to the target
Gfx_BeginScene ( hTarget );
// Draw some stuff onto the target
Gfx_EndScene ( );
// Begin drawing to the window buffer
Gfx_BeginScene ( );
// SomeQuad would give the vertices for rendering the target, the second
//    parameter requires a texture, so we get the texture from the target
Gfx_RenderQuad ( &SomeQuad, Target_GetTexture ( hTarget ) );
Gfx_EndScene ( );


I really just need to know how we could make a switch as painless as possible. We're going to be building a high level abstraction layer on top of whatever library we use to allow us to switch from one library to another fairly easily. So I want to create a part of that layer for rendering targets that would give us an interface that would be able to work with both the rendering targets that our library gives us, as well as the render-images that SFML 2 would give us.


I know it supports scaling/drawing well because I used it myself. I assume you need it for transforming a texture fast? If so you would transform the sprite before drawing it to the RenderImage.

Here's the source example:
Code: [Select]
/// Usage example:
///
/// \code
/// // First of all: make sure that rendering to image is supported
/// if (!sf::RenderImage::IsAvailable())
///    return -1;
///
/// // Create a new render-window
/// sf::RenderWindow window(sf::VideoMode(800, 600), "SFML window");
///
/// // Create a new render-image
/// sf::RenderImage image;
/// if (!image.Create(500, 500))
///     return -1
///
/// // The main loop
/// while (window.IsOpened())
/// {
///    // Event processing
///    // ...
///
///    // Clear the whole image with red color
///    image.Clear(sf::Color::Red);
///
///    // Draw stuff to the image
///    image.Draw(sprite);  // sprite is a sf::Sprite
///    image.Draw(shape);   // shape is a sf::Shape
///    image.Draw(text);    // text is a sf::Text
///
///    // We're done drawing to the image
///    image.Display();
///
///    // Now we start rendering to the window, clear it first
///    window.Clear();
///
///    // Draw the image
///    sf::Sprite sprite(image.GetImage());
///    window.Draw(sprite);
///
///    // End the current frame and display its contents on screen
///    window.Display();
/// }
/// \endcode
///
/// Like sf::RenderWindow, sf::RenderImage is still able to render direct
/// OpenGL stuff. It is even possible to mix together OpenGL calls
/// and regular SFML drawing commands. If you need a depth buffer for
/// 3D rendering, don't forget to request it when calling RenderImage::Create.
///
/// \see sf::RenderTarget, sf::RenderWindow, sf::View
///
////////////////////////////////////////////////////////////

47
Feature requests / Anti-Grain Geometry
« on: June 15, 2010, 05:05:32 am »
Quote from: "ilukha"
Quote from: "caracal"
AGG hasn't been worked on since 2006, its templet based as opposed to class based and there is only software rendering.


Do you know any alternatives of the same quality level?


Cairo?

Which I think is being added in a project.

Also I think Laurent has said he might eventually add vector support, not sure though.

48
Feature requests / LAME MP3 support
« on: June 15, 2010, 04:56:48 am »
Quote from: "Walker"
This is rather pointless. The more formats that are supported, the better. However I feel that you are missing a few points brought up by that article.

Compatibility is his only issue with it and its hardly an issue when you are distributing it with a program (game) that plays it.

You also reference the spectrogram for the highest bitrate and then talk about a low bitrate. And you're right, the graphs do not tell the whole story, far from it in fact.

Although Ogg does drop some frequencies that LAME doesn't, personally I find high frequencies in 256kbit and even 320kbit LAME to sound horrible, metallic and distorted - I would actually prefer to not hear them at all and take Ogg's improved mids.

In conclusion, use FLAC.  :lol:


I'm not missing any of the points of the article. I linked the article for people to note the differences and do their own experiments because it is THE ONLY article on lame vs ogg that has graphs.

And why is it you accuse me of trying to distort what the article says by mentioning two different things and then you do the same and go even worse basing your conclusion on 256kb tests?

If you want to compress 160kb and below you are better off just using mono-channeled at 192kb VBR or  going to voice compression/something else. So... 160 and below for OGG is pointless.

This whole metallic sounding stuff also sounds bogus. This article was made in 2001 with LAME v3.88 it is now 2010 and LAME is now at v3.99

There is also a new VBR algorithm that is much better than ABR for quality. I forgot about that and mixed up ABR with VBR. OGG also eventually developed their own version of VBR.

Like I said, I have done many, many, tests/work with the latest OGG/LAME and can see that LAME has better power of sound for the compression level vs OGG. OGG Vorbis's compression philosophy and algorithms are different than LAME's.

So to recap what I originally said in my earlier post: YOU CANNOT COMMENT ON LAME'S QUALITY IF YOU HAVE NOT USED LAME

Download and use it, don't just read an outdated article and act like you found the secret truth.

49
Feature requests / LAME MP3 support
« on: June 14, 2010, 05:13:48 pm »
Quote from: "Spodi"
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.

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?


No, I never said I hated ogg.

I use ogg all the time and if I sell a hobby game I will most likely use it for all music.

However, for a free internet game where compression/quality is important for music I would prefer LAME.

My point is that the algorithm for ogg alters the sound in a way that flattens music:





But even the graphs do not tell the whole story.

LAME sounds better for just general power of music sound, plus the adjusting bit-rate algorithms add more bits to complex parts to increase the overall quality which you can't see in the graphs.

It's also not a simple question of random popularity. Many musicians encode in both and prefer LAME ABR 192 for internet because IT IS BETTER.

"In the ABR 192 Kbit mode the LAME is on the whole better than the OGG."

http://ixbtlabs.com/articles/oggvslame/

If you sell music it's going to most likely be in AAC/whatever on itunes or CDA on a CD so the license doesn't matter. Only the compression/quality matters to most musicians online who are giving out free music.

Also, LAME MP3 was developed independently as open source with a lot of hard work. There are more options for compression than even OGG. Do not think it's just some generic MP3.

50
Feature requests / LAME MP3 support
« on: June 13, 2010, 07:43:26 am »
Quote from: "Spodi"
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.


I'm plenty calm, everything you are saying is wrong and that's why I'm informing you are wrong.

DDS is just as patented as MP3 and so are many other formats. That doesn't mean they aren't useful or implemented. Even having a 3D camera in your game is patented.

Laurent already said it's not a big deal to implement a plug-in system for audio and he's already doing it for MIDI. You're arguing against something he is already going to implement? What is the logic behind that?

He also said it would appears to not be a problem to implement MP3 because it only requires licensing if you are selling the product. Did you not read the his post? Where do you get all these doubts from?

How do you expect people to agree with you when you don't even pay attention to what people type?

Quote from: "pdusen"
Hah, wow. I'm a musician who has dealt extensively in audio production, and you're just full of hot air. No thank you, I'm quite done debating. I can see where this is going.


Right, and I'm a PHD who doesn't want to debate people who are arguing against useful features that can be plugged in. Guess all of those other musicians must be part of the MP3/anti-OGG conspiracy.

The reality is if Vorbis devs got their heads out of the sky and implemented more/better algorithms instead of making excuses they wouldn't have to be blaming everything on a conspiracy against them.

51
Network / Handling asynchronous receive with a TCP socket
« on: June 11, 2010, 04:23:45 am »
Yeah that's kinda what's crazy when you are using constantly evolving code.

You have to dig through the sources for the best documentation. I was surprised to see a mini-tutorial/example in a header file so maybe there is something more if you look?

52
Graphics / Trying to write a program where you move a square...
« on: June 11, 2010, 04:17:31 am »
If you got it to compile and you put the dlls in the folder with the exe you should be able to double click the exe and run it. If not it's something with the code/driver.

I would start with the basic tests/tuts before writing code. That can also help you find which dll you are missing by what you include or not and whether it compiles/crashes when you run the exe.

This will also help you figure out whether it's the IDE setup or something else.

I can't really give you better advice because I don't use VS.

53
General / Collision - example(?)
« on: June 11, 2010, 04:05:45 am »
Quote from: "Nexus"
Quote from: "Ashenwraith"
You must be pretty new to programming if you don't know this. I'm only 26 and C++ was a lot different in the 90's. A lot of the compilers (most?) did not have a built in boolean and you had to make your own or find one to include.
I only referred to the statements if (expr) or if (!expr), which were already in C possible to write, where no bool has ever existed. Sorry if I didn't express myself clearly.


I'm not trying to argue or anything.

A lot of people set their bools to ints to return 0 along with other stuff so I don't see how that would be possible, but before this year I wrote my last C++ program around 99/2000 so I don't know.

But I don't really care, I learned something new to apply so I'm happy. That's what I'm here for.

Quote from: "Fuv"
Im not interested in what u are arguing about now. I just want to know why my collision is not working and so far it seems no one knows. I give you all my code, so if here is somebody who can explain me why it is not working I would be very, very grateful.


Hey we were waiting for you to post code and we told you might have rectangle problems if your SFML is incompatible (if you are using 2.x, I don't think it's been updated for 1.6).

From a quick peak I can see you need to put your if collision check inside of your app's while loop like G said. It's a common mistake.

54
Feature requests / LAME MP3 support
« on: June 11, 2010, 02:39:54 am »
Quote from: "pdusen"
Quote from: "Ashenwraith"
Many artist now offer music in both ogg and mp3 and the mp3 always sounds better. If you take a good wav and encode it to ogg at a higher bit-rate it always sounds more damp/flat sounding vs mp3. For sound effects it doesn't really matter, but you can really tell with music.

I've never heard or been able to make a better sounding ogg vs a properly encoded mp3. Of course old mp3s sound like crap compared to ogg. I know ogg is supposed to be like the png of sound formats, but it's not better.


You use words like "Many" and "always" in a way that I think is grossly inappropriate. And anyway, what you are saying runs in direct contradiction to what I've experienced; given proper encoding all around, I have always greatly preferred the Vorbis version.

Quote
Here is a more technical explanation:

http://ixbtlabs.com/articles/oggvslame/


Maybe you should actually read the sources you post. It's not nearly as clear-cut as you seem to think it is:

Quote
Conclusion
The new versions of both coders handle their tasks much better than the previous ones.
The quality in the ABR mode for the LAME is never worse than in a standard mode, and it is often much better at any bitrates.
In the mode of the maximum similarity with an original (320/350 Kbit) both coders perform excellently.
In the ABR 256 Kbit mode the LAME better reproduces highs, and the OGG works better with middle frequencies. I would rather recommend the OGG, but it hasn't solid advantage as far as compatibility is concerned.
Coding in the 256 Kbit mode for the OGG and in the ABR 256 Kbit mode for the LAME corresponds to high quality and it is a good choice if you don't want the maximum similarity with an original.
In the ABR 192 Kbit mode the LAME is on the whole better than the OGG.
In case of 160 and 128 Kbit the OGG is an obvious leader.
The coding quality of 160 Kbit is much better than that of 128, that is why I recommend to take 160 everywhere where it is possible.


I did read it, but apparently you don't know anything about ogg sound compression and are too lazy to read entire articles before embarrassing yourself about something you know nothing of. You probably didn't even know what LAME MP3 was until you clicked on this link--but you want to debate anyways?

Try reading it again and you will see the part about how ogg smears and flattens the sound in exchange for hiding artifacts.

LAME MP3 will give you a sound closer to the original without as nearly as much smear/flattening. If your song/effect is more simple/low/bass than you might not care . This article is somewhat bias towards ogg in conclusions, but it still points out its problems. Unless you are listening with expensive headphones the slight increase in artifacts is generally preferable.

Quote from: "Spodi"
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.


It's not just the bit-rate it's the compression algorithm and the sound quality. Compare many songs in Ogg Vs LAME MP3 and you will hear the difference. Similarily MPC musepacks is better than ogg at higher bit rates because IT'S THE ALGORITHM(S).

If you haven't sat down and done comparisons you can't really say anything about the matter.

This is like arguing png is superior to dds because you just like it and you've never done anything serious with dds before  

Yes so let's not support dds because it's just patented bloat and png is 'good enough'...:roll:

55
Feature requests / LAME MP3 support
« on: June 10, 2010, 03:44:10 pm »
Quote from: "Laurent"
Quote
From what I've seen you can allow the user to insert the lame_enc.dll at their own discretion which is what most open source audio programs do (including Audacity)

Yes, and that's probably what I'll do in SFML 2, after the plugin system is implemented. I'll do the same for MIDI and other audio formats that require a LGPL shared library.

In addition to what I said previously, it seems that the MP3 license do not apply for personal/home use.


A plug-in system for audio sounds great.

Musepack is impressive too if you want high quality compression vs ogg/wav and it's fully patent free:

http://www.musepack.net/

56
General / Collision - example(?)
« on: June 10, 2010, 02:50:57 pm »
Quote from: "Nexus"
Quote from: "Ashenwraith"
When I learned C++ you had to write your own BOOL!
Did you learn C++ before 1998? Even then, I don't think this was ever the case, since even C can handle boolean expressions like this (take any integer instead of bool).


http://www.google.com/search?hl=en&source=hp&q=compiler+bool+support&btnG=Google+Search

You must be pretty new to programming if you don't know this. I'm only 26 and C++ was a lot different in the 90's. A lot of the compilers (most?) did not have a built in boolean and you had to make your own or find one to include. Writing your own boolean was seen as a cross-compiler/platform solution and useful because you could make it an int or whatever you wanted for your program's specific needs.

Because of this Computer Science courses discouraged dependency on any built-in boolean data type.

57
General / Collision - example(?)
« on: June 09, 2010, 10:20:13 pm »
Quote from: "Laurent"
Ashenwraith, I don't get your point. In its first piece of code there are parenthesis and arguments, so it's a function call which returns a boolean.


Well after checking the code it appears there is two ways to do it and both work.

I didn't know there was a default behavior for checking true and false with ! and the compiler was smart enough to figure it out.

When I learned C++ you had to write your own BOOL!

58
General / Collision - example(?)
« on: June 09, 2010, 10:11:01 pm »
Quote from: "Fuv"
It is not working. Can you tell me how collision should look like? Or what is wrong in my code? Or maybe you need more code?


Well one problem it could be is that depending on what sfml version you are using the Rectangle code has changed so you might have to alter that.

But still it should be returning either true or false or at least crashing/erroring out.

59
General / Collision - example(?)
« on: June 09, 2010, 09:52:00 pm »
Quote from: "Laurent"
Quote
This is asking if the function exists

No no, this is calling the function and testing the boolean it returns. What your code does is to transform the boolean into another boolean of the same value.

Following your point of view, we could as well write
Code: [Select]
if (((Function() == true) == true) == true)
{
   ...
}

;)


I meant if you wrote this it checks if it exists:

Code: [Select]

if(Collision::BoundingBoxTest){}


Without a value isn't the same thing as
Code: [Select]

if(true){}

but it also means
Code: [Select]

if(false){}


Meaning there is no difference in the choice execution of the code?

I use this in javascript all the time and it works:

Code: [Select]

if(Collision::BoundingBoxTest(Object, Bar)==true){}



Are you sure you don't mean this sets the value?

Code: [Select]

if(Collision::BoundingBoxTest(Object, Bar)=true){}

60
General / Collision - example(?)
« on: June 09, 2010, 09:35:05 pm »
Did you try:

Code: [Select]

if(Collision::BoundingBoxTest(Object, Bar)==true)
{
      std::cout<<"Collision occurred!"<<"\n";
}


This is asking if the function exists:

Code: [Select]

if(Function())
{

}

Pages: 1 2 3 [4] 5 6 ... 18
anything