SFML 2.0 vs SDL 1.3

Both are undergoing development
Both support hardware accelerated 2D out of the box
Both are licensed under the zlib license -- that's right, you are now free to statically link SDL to your programs

SFML is mostly supported by one developer, a much smaller team than the one behind SDL
SFML is only aimed at Windows/Linux/OSX for the moment, while SDL supports a much wider range of platforms
SFML 2.0 is pretty unstable at the moment, with the lead developer stating that he's prepared to completely break parts of the API prior to the 2.0 release
SDL 1.3 is probably pretty unstable as well
SFML has a much more friendly API than SDL, in my experience, although this is limited to usage of 1.2

Given my limited knowledge of SDL 1.3, I'm not sure which is the better library to side with. I originally jumped ship from SDL to SFML because of its friendlier API and hardware accelerated 2D graphics, but if SDL 1.3 is going to feature similar hardware acceleration along with a brisker, more reliable pace of development, my inclined to side with it. Can /prog/ convince me to pick a camp?

>>78
It looks like C
C99 will reject for(int i = 0;, because of int inside for.

>>77
GLSL is not based on C++. Fucking troll.

It's based on C! C99 to be specific, with extensions for vector processing/SIMD.

Man, you don't know shit.

And you don't need graduate level math in order to understand OpenGL. All you need is a basic understanding of geometry, trigonometry, and linear algebra. Linear algebra is so simple that you can teach it to kids in junior high school or perhaps earlier. Fuck, I taught it myself when I was 13 learning to do VGA demo coding in DOS with Pascal, C, and x86 assembly back in the early 90s. Are you admitting that you're more stupid than a kid who is just hitting puberty?

>>81
no it wont.

>>80
Lisp is shit.

>>81
C99 will reject for(int i = 0;, because of int inside for.
Confirmed for retard. C99 does actually allow you to scope variable declarations within the for loop. Try it out. The following code compiles without error or warnings.

// $ gcc -Wall -Wextra -pedantic -std=c99 -o test test.c
#include <stdio.h>

int main() {
    for (int i = 0; i < 5; i++)
        printf("%d\n", i);
    return 0;
}

>>82
see >>81 and >>80

coding in DOS with Pascal, C, and x86 assembly back in the early 90s.
You ate all kind of crap. You should brush you teeth or close your mouth.

>>85
Good. It proves that I dont know a crap about your shitty language. Ignorance of C/C++ is bliss.

>>86
See >>85 dummy. And I do a lot of my DSLs and logic programming in Lisp.

>>87
I can smell your butthurt across my screen. Don't act smart if you are not.

>>79
Where ever you see "vector space over rational field," just replace it with "vector space over computable real field."

Linear algebra has nothing to do with infinity or non-computable reals. It's all about solving computable systems of linear equations. Your vector space could be over the whole numbers for all it cares.

x = 5y + 3
y = 3x + 4z + 2
z = 9x - 17

Solve for x. That's all linear algebra concerns itself with.

If >>70 don't like OpenGL that much, i have to remind, software rendering is several orders of magnitude slower and there is no magic SSE hack which is "at the same speed as GPU" since GPU has thousands of fully parallel cores and CPU is limited to max 4-8 cores explicitly managed by the program(not by hardware,as in GPU parallel calculations). Software rendering is fit only for small, low-resource games and demos.
Perhaps when GPU features are merged into CPU die entirely the need for separate GPU will disappear, and OpenGL will become historical curiosity, but today isn't the year of integrated GPU(despite AMD efforts).

YEAR OF SOFTWARE RENDERING ON THE DESKTOP

>>91
Indeed, the future of software rendering is on GPUs or the remnants of GPUs once they're fulling merged with CPUs. And graphics code will likely be done in OpenCL or DirectCompute or languages like them as they are sufficiently low-level and provide decent abstractions for tile/wavefront-oriented parallelism.

>>93

[b]Finally.[/o]

I hope nVidia finishes OpenCL support for their cards soon.

>>94
I hope Nouveau project finishes OpenCL support for Nvidia's cards soon.

CPU makers are slowly waking up to the fact you can cram enough stuff on the die to make motherboards obsolete for real desktop systems
Like the design of system on a chip, all functions are merged into a single die which can be controlled by CPU maker exclusively.

>>94
Proper OpenCL 1.1 conformant drivers were completed by nVidia back in September, but had some performance problems. I can't remember if they've since fixed them... the drivers in the main repository for Linux Mint are still the September release, and I've been too lazy to bother manually installing the ones on nVidia's site.

OpenCL/DirectCompute are only beginning >>93 once its a CPU feature there will be a huge amount of asm and C apis you could not be locked
into a single model, since you on the level of the CPU opcodes which are standard(far more than locked, proprietary GPUs which require driver interfaces) you can write anything, you don't need to depend on a driver,a library or an API anymore(and construct your own from the vector opcodes).

>>98

I can't wait for those days. Hopefully Trusted Computing won't get in the way.

>>98
Yeah, but OpenCL/DirectCompute compilers are decent enough (most are based off of Clang/LLVM) and getting better, no reason to bother writing in assembly language. The vector intrinsics are sufficiently assembly-like already and usually have a one-to-one mapping with the underlying SIMD/SIMT/MIMD opcodes.

I don't see nVidia, AMD, Intel, ImgTech, S3, etc. all agreeing to a common ISA for programming GPU hardware any time soon, at least not this decade, so using a portable language will continue to make sense well into the future.

But you're right, the GPU/CPU memory model will at least be merged so you can just copy data around and pass pointers across CPU/GPU boundary and it will just work. That at least will make things easier.

dalmatians get

>>100
S3

>>99
Those days are already here, depending on your requirements.

I'm working on an OpenCL based voxel ray-caster and deferred shading renderer as a personal research engine. You won't be able to maximize hardware performance quite as good as if you were using OpenGL/Direct3D due to software driver inefficiences and hacks, but you can expect to be able to get around 75% through OpenCL currently.

Battlefield 3's renderer uses DirectCompute for it's deferred shading composition passes (although it still uses Direct3D pipeline to render polygonal geometry into the g-buffer).

>no benchmarks
nope
nope
nope

>>90
Then why introduce "continuous spaces"? Why not just say that we deal with finite array of cubic voxels? Say (make-vector (* 1000000 10000000 1000000)) should be enough for all video game purposes. And it's proven to exist inside observable universe and it's easier to understand, because you can give real example - array of pixels on screen. But no! Instead of pixels algebra pseudoscience invents these retarded "infinitesimal" "points", that has nothing to do with JRPG video games.

>>105
BTW, beside spaces, they also introduce these "cyclic groups", which at first look like usual logical-and operator, but then it'll be reveled that they are fucking useless, cuz CPU's modulo operator doesnt work that way.

>>105
Because the Jews always have to find a way to stick their infinite sets into places where they don't belong. You should know that by now. It's like how Jewish politicians piggy-back their pork on completely unrelated legislation.

Linear algebra works quite fine without infinite sets. Matrices and vectors are just convenient notation. And as a formal system, it is comprised of simple algebraic identities, relationships and rules for managing, transforming and solving different aspects of linear systems of equations.

>>106
Cyclic groups are artifacts belonging to group theory, a sub-domain of category theory. It is quite divorced from ZFC.

It's not typically used much in computer games or graphics programming, but it does have relevance to repeating tiled or mirrored texture coordinate systems for repeating a texture across a wall or floor or something. Generally, modern GPUs have a builtin fmod circuit in each texture sampling unit for approximating the modulus of floating-point numbers, but older GPU hardware would internally convert floats to quantized fixed-point integers and use logical-and integer arithmetic.

That said, I don't see how you think they're completely useless. A CPU's modulo operator can and does work that way in an associative cyclic group.

>>107

Linear algebra works quite fine without infinite sets.

You're still a fucking stupid shit. This might be a bit too terse for you, but I'm going to take an example from work. Try and follow along you mental miget.

I have a data structure such that, when converted to a series of vectors, becomes an "infinite set". The reason why I want this data structure to be a series of vectors is because I'm interested in the cluster of data at any given point.

This cluster of data can be calculated by finding the eigenvalues of the corresponding matrices. And guess what? The fucking model relies on the notion of an infinite set.

>>109
Infinity is made-up bullshit, champ. It has no place in programming.

>>110
Ah yes, spoken like someone who never has, and probably never will work as a computer programmer. Did you even make it beyond high school calculus?

I dunno, but to make a final fantasy style game, one needs just a nice looking charset (rip these from rpgmaker games) and a reasonably fast blitting routine.

>>109
Sorry, you're wrong. You can represent non-computable reals, the continuum itself, in computer programs. It's impossible.

>>113
Damnit, I meant you can't represent non-computable reals, the continuum itself, in computer programs. It's impossible.

>>113
No you fucking stupid shit jew. You're confusing uncountable with countably infinite. Again, you're stupid. And again, you don't have the mental capacity to be a programmer.

So again, did your monkey ass even make it beyond calculus? I bet not.

>>115
Nope. And I believe you are the Jew. After all, they're the ones who conjured infinity out of the thin air along with their sky God who demands the blood of the goyim.

http://en.wikipedia.org/wiki/Computable_number

>>116
Computable numbers and countably infinite are'nt the same thing you fucking idiot. Again, did you make it beyond calculus? I bet not. Now go scrub another toilet you mental midget.

>>117
You're the one who said "countably infinite." I said "non-computable reals." I got an A+ in Calc 100 & 101, and without sucking any cocks like I know you had to. I then went on to take second and third year calculus courses and other courses on other subjects of mathematics, and have since graduated.

Infinitesimals merely encapsulate some interesting logical predicates in the form of consistent algebraic rules regarding asymptotic boundary conditions of recursive processes. If you've ever had to write code which computes transcendentals, derivatives or integrals in computers using numerical methods, you would know this.

If you've ever had to write code which computes transcendentals, derivatives or integrals in computers using numerical methods, you would know this.


Been there, done that. The point is, I don't think you have any clue as to what you're talking about when it comes to infinity. And again, I think you're fucking stupid.

>>118-119
There are such things as computable reals (they are also countable). There are of course uncomputable reals which cannot be touched by us in any way, except sometimes described (see: chaitin's constant as an example).