Messages

1

Graphics / Optimizing tilerendering

« on: March 15, 2011, 09:42:09 pm »

why not use the wrapping texture capability of opengl? no need to "shuffle" all rows. just update a single row/column and your texcoords. should be even faster.

Not sure how to implement that, as adjusting texcoords adjusts the coords across the entire buffer...ahhh, I see, shift the texcoords, then update the rest of the buffer? How do I get access to the texcoords of an sfml sprite object?

For me personally, it wouldn't be worth the hassle writing that, especially if you are using sfml; the whole point of sfml for 2D graphics is to use sfml sprites and the nice, clean OO interfaces. If I was going to muck around with texcoords, I'd probably go straight to OpenGL and forgo sfml.

Dunno really, I use OpenGL directly most of the time anyways. I think Get/SetSubRect might be used for this, although it depends on which wrapping mode SFML uses.

2

Feature requests / Non-deprecated OpenGL

« on: March 14, 2011, 09:21:48 pm »

replacement is unlikely to ever happen. switchable backends (opengl 1.x, opengl 3.x, opengl es 1.x, opengl es 2.x) are more likely, but as far as I know this won't be happening any time soon.

3

Graphics / Optimizing tilerendering

« on: March 08, 2011, 12:14:12 pm »

why not use the wrapping texture capability of opengl? no need to "shuffle" all rows. just update a single row/column and your texcoords. should be even faster.

4

Feature requests / File System Support, Part II

« on: March 06, 2011, 03:17:59 pm »

Color me amazed.

After decades, Windows is catching up. Well, guess I'll have to learn using it at some point. From the comparisons I found bash looks a bit more concise, but the differences are minor, which is a good thing.

MS did a lot wrong with previous Windows versions, but Win7 is actually really good IMO

5

Feature requests / File System Support, Part II

« on: March 04, 2011, 01:39:10 pm »

Shouldn't you... you know... ask the player where to install?

I personally loathe games that just install themselves in some folder of their own choice. (doubly so since my %AppData% is on an SSD with very limited amount of space - I prefer to have all my games apart from the one I'm currently playing on another physical drive entirely).

I can see the usefulness of the stuff you're suggesting if it only has the purpose of providing a good first guess though. That being said, writing an installer for any given OS is probably better to do outside of SFML though (like InstallShield etc for Windows).

Well, this is really only an issue in windows. In linux (and macosx if I am not mistaken) there are standard directories for everything.

For example a linux game:
executable in /usr/bin (depending on distribution this could also be /usr/games)
data in /usr/share/appname (depending on distribution this could also be /usr/share/games/appname )
and user files /home/username/.appname

You typically don't get to choose where things go. Of course since everything uses the same structure you can distribute your partition mount points smartly.

And show me a single windows game where you can decide separately where data and executable go And properly designed games will use the user directories as well for saving (saving anywhere else is just wrong on a multiuser system...)

6

Feature requests / File System Support, Part II

« on: March 03, 2011, 06:10:39 pm »

physfs does some of this (at least for the write directory part)

7

Audio / Music Slicing

« on: March 01, 2011, 03:10:21 pm »

Subtraction rarely works at least due to the compression.
You cannot remove vocals perfectly, but you can reduce them.
That can be done by using Fourier transform, reducing frequencies of the vocal range and performing inverse Fourier transform to recreate the wave back.

That will not work, as those pesky "vocal frequencies" are 90% of the important "music frequencies" as well so this would reduce pretty much everything except extreme bass and extreme treble

Subtraction isn't perfect, due to - as you mentioned - compression, but also due to reverb, doubling and other stereo vocal effects, but it really is the best you can do. You could aditionally reduce the "presence" range of 2-3 kHz, but that will also affect your music quite a bit

In an ideal world you could use BSS (blind source separation) and vocal recognition to remove the vocal source. But in the real world... "that ain't happining"

8

General discussions / .h Files and forward Declarations

« on: February 22, 2011, 08:06:34 pm »

About mingw: The current version is ok with pragma once, although I did find a pragma once related bug in it's tracker (for the current version)

It'll be very kind of you if you post a link.

Sure, here you go: http://permalink.gmane.org/gmane.comp.gnu.mingw.announce/2771 (tracker link is in the message)

9

General discussions / .h Files and forward Declarations

« on: February 22, 2011, 07:00:49 pm »

It was. It's not since GCC 3.4.0, which was released in 2004.

I said was.

#pragmas are not extensions. Read my post again.

"#pragma" in and of itself is not an extension, but "#pragma once" is not part of any C or C++ standard. #pragma is specifically designed for compiler/os specific options and therefore non-portable.

About mingw: The current version is ok with pragma once, although I did find a pragma once related bug in it's tracker (for the current version)

10

General discussions / .h Files and forward Declarations

« on: February 22, 2011, 05:52:45 pm »

And in fact it was declared deprecated after a few versions in GCC. soo.. yeah. avoid it, imo...

Now you're just grasping at straws

However, with the 3.4 release of GCC, the #pragma once handling code was fixed to behave correctly with symbolic and hard links. The feature was "un-deprecated" and the warning removed.

So? It was still deprecated for a few versions. Just pointing out that such extensions cannot be relied on.

11

General discussions / .h Files and forward Declarations

« on: February 22, 2011, 05:38:08 pm »

But... thank you for proving that I was wrong: not only very obscure compilers don't support it. Severely outdated ones don't, either.

You are wrong again, as some versions of GCC didn't/still do not support pragma once (like mingw, not sure if that's still true, but it was for a long time)

And in fact it was declared deprecated after a few versions in GCC. soo.. yeah. avoid it, imo...

12

General discussions / .h Files and forward Declarations

« on: February 21, 2011, 07:07:10 pm »

One solution to the whole "same name" problem (which can also occur with namespaces!) is to use a (probably) unique identifier, like a 128 bit hash (as hex prepended with a letter to create a valid identifier or some other format) of your name and the name you actually want to use.

In order to avoid name clashes, you suggest using identifiers that are still non-unique, but additionally unwieldy long and horribly ugly. Oh well...

They aren't that long really. And it only needs to be applied to the top level namespace. And they much, much, much more likely to be unique than any word or readable acronym. So it is definitely an improvement.

13

General discussions / .h Files and forward Declarations

« on: February 20, 2011, 10:11:30 pm »

Ok, so I am gathering that #pragma once is out as a solution.

... because?

I'm only using pragma once (without include guards - I haven't used them for several years after getting bit by the same-name "feature" once) and compiling projects happily on windows, linux and mac os x.

You really shouldn't use only pragma once. It is a nonstandard extension, so if anything use it in addition to include guards to speed up compilation on compilers that support it.

PS: About the "limiting to one compiler" argument: even in that case, I wouldn't use only pragma once, because you risk getting into a "bad habit" which might come back to bite you when you do need to write a portable piece of software.

One solution to the whole "same name" problem (which can also occur with namespaces!) is to use a (probably) unique identifier, like a 128 bit hash (as hex prepended with a letter to create a valid identifier or some other format) of your name and the name you actually want to use.

In the namespace case renaming is then as simple as writing namespace <new> = <old>; (only in source files though, of course). In the includeguard case, no renaming is needed really. And if you have the odd macro... well... it gets a little ugly. but macros are always ugly.

14

Window / [SOLVED] Toggling input language...

« on: February 20, 2011, 07:01:08 pm »

Interesting... do you know why doing this solves the problem?

Doesn't SFML use a hidden window as a common OpenGL context for sharing? Maybe Windows sends these events to the first window opened by an application instead of the current window?

15

Graphics / fullscreen on second monitor

« on: February 15, 2011, 01:37:50 pm »

The problem there will be that you won't be able to change the actual resolution of the display. Meaning you have to always use the desktop resolution.

It is possible in windows with changedisplaysettingsex, afaik