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?
Name:
F r o z e n V o i d !!mJCwdV5J0Xy2A212011-11-21 8:45
SDL 324kb dll
SFML 24000kb in 5 DLLs
The latter could be as fast as sepples allows it but adding twenty mb of bloat is not excusable for library which is a minimal layer over OpenGL
twenty mb of bloat twenty mb
Do they still use 56kbod modems in Russia?
Name:
F r o z e n V o i d !!mJCwdV5J0Xy2A212011-11-21 9:12
Speed of transfer isn't the problem, it just indicates there is alot of code for very little function.
Consider that for 24mb would be enough to contain entire DirectX 8.1(11.8 MB as full install),OpenGL(2mb with GLUT, all bells and whistles),3-4 sound libraries and still not reach even 20 mb.
>>10 it just indicates there is alot of code for very little function.
So what? Maybe it's infinitely decompressed or something, anyway, why do you care about functionality density per megabyte? Why is this a metric that one should strive to optimize?
I feel like you maybe read too many books which brainwashed you with patriarchal preconceptions.
Name:
F r o z e n V o i d !!mJCwdV5J0Xy2A212011-11-21 9:48
>>11
Its simply called bloat. I don't read books, i just see this library advertised as "fast and efficient".
Not to mention that SDL.dll does not include networking and audio, last time I checked.
Even if you were to include libsndfile-1.dll (325 120 bytes) and openal32.dll (208 896 bytes) for some reason, you would still be very far away from 20mb.
>>16 .a
Those are supposed to be statically linked into your program executable file and pruned by the linker. The actual size is much smaller.
Name:
F r o z e n V o i d !!mJCwdV5J0Xy2A212011-11-21 11:11
>>18
The post wasn't about them, its about the DLLs. The whole library is at 24mb of DLLs.
Name:
Anonymous2011-11-21 11:27
>>12 Its simply called bloat.
And why you say that as if it were something bad? I don't read books,
Then you got yourself brainwashed by something else. i just see this library advertised as "fast and efficient".
What's slow and inefficient about it?
>>13
well, that's kind of my point. You see people trying to create something under some artificial constraints. You can call it "art" or "intellectual masturbation", or whatever, that's OK, no problemo.
But if you forget about the fact that the constraints are artificial, then you get brainwashed by the semi-imaginary peer pressure which tells you that no "bloat" is good, because it's good, because look at how respected fr are, you should respect what respected people do and try to be respected as well, so stay away from the bloat! First rule of the no-bloat club: don't question why bloat is bad!
Name:
F r o z e n V o i d !!mJCwdV5J0Xy2A212011-11-21 11:40
>>21
When logic fails a brainwashed individual, he resorts to an ad hominem, preferably one which implies that the interrogator belongs to them, the enemy which seeks to destroy the group to which the individual belongs.
Name:
F r o z e n V o i d !!mJCwdV5J0Xy2A212011-11-21 11:55
>>24
I don't have to prove that bloat is bad, it obvious that functionality which comes at lesser cost is better than one that comes at higher cost.
You can fiddle with gigabyte sapping, memory leaking VMs and gigantic libraries all day, that typical for AAA-class Enterprise Software Developers, its just not as efficient or elegant in terms of design as >>13
>>16
My bad; I realize now that you have the supplied pre-compiled DLLs that were built using MingW. Of course it's going to be bloated shit; don't blame SFML, blame the retardation that is MingW.
Name:
Anonymous2011-11-21 12:09
I don't have to prove that bloat is bad, it obvious
Heh.
that functionality which comes at lesser cost is better than one that comes at higher cost.
Define cost.
You can fiddle with gigabyte sapping, memory leaking VMs and gigantic libraries all day, that typical for AAA-class Enterprise Software Developers
Here we can see how brainwashed individual tries to further assert his ad hominem and the notion that the questioner belongs to a hostile class, which is why his questions are dangerous to even try to answer.
its just not as efficient
You must say that it is not as efficient three times, only then it will become true. Two times are not enough.
or elegant in terms of design as
Oh, yes, sure, it's not "elegant", it's not "beautiful", it's not a piece of art -- not something created under pointless constraints.
By the way, while we are at it, do you realize that we are discussing the size of the binary, not the source code? Not that it is terribly important, since your rinsed and dried brain blows fuses when it detects questioning of your silly beliefs either way.
Name:
F r o z e n V o i d !!mJCwdV5J0Xy2A212011-11-21 12:18
>>28
>not something created under pointless constraints
These are qualities of the software, have less size,less more use, more speed are not "pointless"
>CSFML is not C++ so using that supposed ``bloat'' as reason to pick on C++ makes no sense.
Thats exactly why its larger its filled with useless Sepples functions, which mingw compiles in.
Name:
Anonymous2011-11-21 12:25
>>29 These are qualities of the software, have less size,less more use, more speed are not "pointless"
I didn't think your brain would literally short-circuit, ha ha ha.
You poor creature, have you ever been as far as decided even do more like?
>>29
No, it's larger because MingW is a terrible compiler. Clearly you have never actually even bothered to build any windows executables with it or you would be familiar with that. What goes in the VC++ redistributables is pretty much statically linked into every MingW executable in existence and that is the reason it generates massive bloat. It being C++ or C has literally nothing to do with it.
Of course, IHBT since you clearly never even bothered looking at CSFML's source if you say things like its filled with useless Sepples functions.
Name:
F r o z e n V o i d !!mJCwdV5J0Xy2A212011-11-21 12:29
>>30
I don't think so, i meant to type 'less memory use', but missed a few keys.
Is memory use, size of program, speed of execution one of "pointless constraints"?
Name:
F r o z e n V o i d !!mJCwdV5J0Xy2A212011-11-21 12:33
>>31
>never even bothered looking at CSFML's source
I checked the DLLs in notepad, all are filled with thousands of Sepples functions at the end.
>>32 Is memory use, size of program, speed of execution one of "pointless constraints"?
Depends on the actual values. For instance, the difference between 20mb and 2mb used by an in-memory image of library on an 4Gb machine, for a 3d graphics application, is irrelevant, the 2mb memory consumption constraint is artificial, and spending any effort whatsoever to fit the library in the constrained space is pointless.
Name:
F r o z e n V o i d !!mJCwdV5J0Xy2A212011-11-21 12:59
>Depends on the actual values
I see you have some sense, now what would make a library less efficient? Having more size is just one of symptoms, bloated OOP abstraction
layers and generally unoptimized, low-quality code.
>spending any effort
The effect is multiplied by thousands of programs where programmer did not spend any effort. The next enterprise code monkey which is assigned to a program just wants the monthly banana for least effort and will be as lazy as the last.
I see you have some sense, now what would make a library less efficient? Having more size is just one of symptoms, bloated OOP abstraction layers and generally unoptimized, low-quality code.
You are speaking out of your anus.
In this particular case it was demonstrated to you that the "bloat" of the binary was not caused by any of these things.
Brainwashed people tend to ignore facts in favour of "ideologically correct" reasoning.
>>16
1, those are the C SFML bindings, not the default C++ ones.
2, you listed every possible version of the library there. Both the release and debug versions of both the static and dynamically linked libraries.
Can we ignore the impostor FrozenVoid now and get back to discussing the actual merits of SDL 1.3 and SFML 2.0?
Name:
F r o z e n V o i d !!mJCwdV5J0Xy2A212011-11-21 13:41
>those are the C SFML bindings, not the default C++ ones.
here are C++ bindings, i don't see how this improves the size
Directory of C:\download\SFML-1.6-dev-windows-mingw\SFML-1.6\lib
Worst case: 9 MiB of DLLs, plus some linking overhead should add around 10 MiB of overhead to your program.
Typical case: You use the static libraries and only the parts of SFML that you actually used are linked in. The overhead is a fraction of that of using the dynamic libraries.
In either case, SFML doesn't add enough overhead to your executable to impact distribution. Even the 9 MiB of DLLs (plus the libsndfile and openal DLLs) easily compress down to a 1.5 MiB 7z archive, or a 2.5 MiB zip archive.
I have beet rolled.
Name:
Anonymous2011-11-21 14:18
>>11,20,28
protip: processors aren't going to be getting faster for much longer, and same with storage densities increasing.
software, meanwhile, has gone farther and farther from the limits of efficiency. what you could do with 64KB in the 80s with a 10MHz CPU now takes megabytes or even gigabytes and gigahertz-level CPUs.
it's about time they realized how much waste has been going on.
>>45
We're all going to work for video games. Why else would we program?
Name:
F r o z e n V o i d !!mJCwdV5J0Xy2A212011-11-22 1:51
>>46
For the art. If you lack that creative spark which drives you to program, you won't create programs, you would implement or rework existing ones.
Name:
Anonymous2011-11-22 2:55
>>47
Video games are the best art a programmer can make.
Name:
Anonymous2011-11-22 3:30
I, for one, welcome our new video game overlords.
Name:
Anonymous2011-11-22 4:17
Lisp OS should provide it's own graphics and audio API. Loading FFI libs is mediocre solution at best. Besides graphics and audio, everything else could be done internally. And we need better alternatives to ZLIB/PNG, because they arent the right thing. I.e. PNG doesnt support random access, meaning that things like http://en.wikipedia.org/wiki/MegaTexture cannot be easily packed into single PNG. PNG is also bad for sprites and GUI elements, which are frequently clipped, meaning no full decompression needed.
Sorry for a long rant. I just hate Worse is Better KISS solutions.
>>50
You will never amount to anything of significance.
Name:
Anonymous2011-11-22 6:18
>>53
My failure wont stop Unix/Linux from being a crappy OS.
Name:
Anonymous2011-11-22 6:38
>>50
Ever heard of the Single Responsibility Principle or Do One Thing And Do It Well?
Attempting to build file formats that handle a multitude of use cases will only amount to a format that is mediocre everywhere.
PNG, or Portable Network Graphics, has largely been successful at providing ``portable network graphics'' file format with lossy compression and adequate support for different pixel formats.
In fact, why would you even think about using PNG for textures, mega-textures, and the like outside of prototyping a game? PNG is a good intermediate format during development of a game, and provides an interchange container between the content creation tools and your engine's preprocessing tools. But in the context of game development, that's all it's meant for.
Generally, you set up your engine preprocessing tools to convert images to either raw or a special compressed format that your GP can decompress using specialized hardware at no cost, like DXTC/S3TC or PVRTC. That way, loading in a level's texture is super fast, you just do a single unbuffered POSIX read or Windows ReadFile call for the *entire* texture into a memory buffer and transfer it to the GPU using the relevant Direct3D/OpenGL call, no additional processing or decompression required.
It also results in simpler code and less bloated game binaries. All of the bloat and complexity is hidden in the preprocessing aka mod tools.
he wasn't questioning the sexuality of "ey" you fucking retard. It is no secret you are a feminist piece of shit.
Fuck off and die.
Name:
Anonymous2011-11-22 7:27
>>59
All lossless format can also be lossy because nothing prevents the encoder from changing the data in order to increase the compression efficiency.
Name:
Anonymous2011-11-22 7:56
>>55 Single Responsibility Principle or Do One Thing And Do It Well?
Yes. PNG is responsible for being slow and not allowing random access. PNG is also responsible for being a binary format, when sane people want symbolic expressions: you know, putting quickly object placement info into extension chunk, so one could use PNG for holding maps for a video game, which are also rectangular and compress well.
-> ls -ahl SDL-1.2.14.tar.gz SFML-1.6-dev-linux-32.tar.gz
-rw-r--r-- 1 matt users 3.9M Nov 22 05:53 SDL-1.2.14.tar.gz
-rw-r--r-- 1 matt users 713K Nov 22 05:55 SFML-1.6-dev-linux-32.tar.gz
The actual source of SFML is much less than SDL.
Name:
Anonymous2011-11-22 7:58
>>63 implying documentation, image files, configure and unit tests are actual source code
-> du -sh SDL-1.2.14/src/ SFML-1.6/
6.9M SDL-1.2.14/src/
2.2M SFML-1.6/
Here. The entire SFML directory is just source code because I didn't download the SDK. The /src directory in the SDL directory is 100% source.
3 times bigger.
Name:
Anonymous2011-11-22 8:05
>>59
It was a typo. I also meant ``GPU'' when I said ``GP''.
Name:
Anonymous2011-11-22 8:06
>>62 so one could use PNG for holding maps for a video game, which are also rectangular and compress well.
No, you don't get it. PNG was never meant for that, so stop wishing it did.
If you want that, create your own file format.
Name:
Anonymous2011-11-22 8:22
SFML is C++ crap, meaning it can be used only with that crap language. So it's totally useless.
>>77
It looks like C but that is all. Your code is valid in Java too, so should we say learning GLSL requires Java knowledge?
Name:
Anonymous2011-11-22 8:47
>>73
What if I dont believe in Set Theory? There are no standalone linear algebra book - all use some kind of "vector space over rational field" pseudoscience.
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 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;
}
>>87
I can smell your butthurt across my screen. Don't act smart if you are not.
Name:
Anonymous2011-11-22 9:17
>>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.
Name:
F r o z e n V o i d !!mJCwdV5J0Xy2A212011-11-22 9:19
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).
>>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.
>>94
I hope Nouveau project finishes OpenCL support for Nvidia's cards soon.
Name:
F r o z e n V o i d !!mJCwdV5J0Xy2A212011-11-22 9:39
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.
Name:
F r o z e n V o i d !!mJCwdV5J0Xy2A212011-11-22 9:50
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).
I can't wait for those days. Hopefully Trusted Computing won't get in the way.
Name:
Anonymous2011-11-22 9:57
>>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.
>>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).
Name:
Anonymous2011-11-22 10:09
>no benchmarks nope nope nope
Name:
Anonymous2011-11-22 10:46
>>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.
Name:
Anonymous2011-11-22 10:52
>>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.
Name:
Anonymous2011-11-22 10:55
>>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.