Allegro.cc - Online Community

Allegro.cc Forums » Off-Topic Ordeals » SFML 2 Vs SDL 1.3/2.0 Vs Allegro 5

This thread is locked; no one can reply to it. rss feed Print
 1   2   3   4 
SFML 2 Vs SDL 1.3/2.0 Vs Allegro 5
Specter Phoenix
Member #1,425
July 2001
avatar

SiegeLord said:

We were talking about Allegro developers, not developers in general.

So was I, Allegro was the only library I messed with under Windows. I do more developing 'in general' under Ubuntu than I ever did in Windows. Under Windows I just did Allegro apps and Allegro GUI apps during A3 and early A4 (using DLG program I think it was called). Since going to Linux I started messing with C++/MySQL, PHP/MySQL, CSS, Java, and several other things that I wouldn't have even considered on Windows.

SiegeLord
Member #7,827
October 2006
avatar

torhu said:

"I think Linux is great. Of course, I'd never use it myself, but I'm sure it's great for other people."That's what the arguments so far are like. See a problem?

But I just said it works with cmd.exe fine enough from my testing. I choose to use bash, but it doesn't seem like git forced you to do so. I believe you don't even have to install the msys bit, as seen in this screenshot (second option):

{"name":"bootcamp_1_win_install_6.jpg","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/e\/9\/e9a4dd3935374324441b23905e5ff573.jpg","w":558,"h":442,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/e\/9\/e9a4dd3935374324441b23905e5ff573"}bootcamp_1_win_install_6.jpg

So was I, Allegro was the only library I messed with under Windows.

Allegro developers are those that develop Allegro, not those that develop using Allegro. Surely after 11 years of being on this forum you've noticed how people who make this mistake by posting a thread on Allegro Development sub-forum have their threads moved to Programming Questions?

"For in much wisdom is much grief: and he that increases knowledge increases sorrow."-Ecclesiastes 1:18
[SiegeLord's Abode][Codes]:[DAllegro5]:[RustAllegro]

Specter Phoenix
Member #1,425
July 2001
avatar

SiegeLord said:

Allegro developers are those that develop Allegro, not those that develop using Allegro. Surely after 11 years of being on this forum you've noticed how people who make this mistake by posting a thread on Allegro Development sub-forum have their threads moved to Programming Questions?

No I normally asked my questions on the mailing list or IRC and did OT topics here. I think I asked about screenshot functions and tilemapping at one point on the programming thread, but other than that it was normally the other two methods. I personally don't pay attention to the programming or development thread as my knowledge is more C++ related and not so much Allegro since I mostly did pong and gui apps.

torhu
Member #2,727
September 2002
avatar

SiegeLord said:

I believe you don't even have to install the msys bit, as seen in this screenshot (second option):

It does talk about a Cygwin Prompt...

If Git would actually work fine with just cmd.exe, why is is Msys, Cygwin, or Bash always mentioned?

Karadoc ~~
Member #2,749
September 2002
avatar

@torhu, what are you getting at here? I've already said that I use git from cmd, and it does work fine. So that's that. It's not relevant that the git installer happens to explain which option people using Cygwin should choose. That's unrelated to cmd, and people who do not use Cygwin can simply ignore that information.

-----------

MiquelFire
Member #3,110
January 2003
avatar

Because it requires a Linux like environment. With Kaspersky, you can see (in red annoying enough) all the commands it calls (perl, sh, bash, maybe some git* exe's, I think I even saw ruby)

I remember installing msysGit and having to exclude like 10 programs from Kaspersky just to run git init, and an extra 5 for git commit (So there are programs it don't use during init that commit uses)

---
Febreze (and other air fresheners actually) is just below perfumes/colognes, and that's just below dead skunks in terms of smells that offend my nose.
MiquelFire.red
If anyone is of the opinion that there is no systemic racism in America, they're either blind, stupid, or racist too. ~Edgar Reynaldo

Karadoc ~~
Member #2,749
September 2002
avatar

Well, I personally don't know, nor do I really care, how git gets its internal work done. All I know is that I can type "git" on the command prompt (cmd.exe) and it does what I expect it to do. -- For me, it doesn't matter if git works by calling a bunch of auxiliary programs, or if it actually has all that functionality built into git itself. That doesn't make any difference to me.

-- But apparently it does make a difference for people who use Kaspersky or something. I haven't heard of that problem before. It sounds like a real pest.

-----------

Arthur Kalliokoski
Second in Command
February 2005
avatar

git works by calling a bunch of auxiliary programs

That's the *nix way. Each program does one thing, and does it well. The MS world just recently got multitasking working right, so they have a legacy of big, buggy monolithic programs.

They all watch too much MSNBC... they get ideas.

weapon_S
Member #7,859
October 2006
avatar

And then you have to download and install a runt-time for some interpreted language, because the programmers felt like using one function of that language.
I have Git for Windows too, without MSYS or CygWin, and it works fine. >:( Why the F did they have to include Vim, though?

bamccaig
Member #7,536
July 2006
avatar

I've been using Git in Windows directly from cmd.exe for a long while with plenty of success. I rarely use MSYS shells because they're only a partial solution and require you to think differently. I am rather sick of cmd.exe though. I finally went out and found PyCmd, which has a few extra UNIX-like features that can be real time-savers: more intelligent tab completion (e.g., expand environment variables in paths), word-based tab completion, and expand ~ to %HOME% or %USERPROFILE%.

As for Git's modular design, there's a very good and intelligent reason for it, and ideally that is how all software would be written. As for your shit anti-virus software running on your shit operating system, you should be blaming your anti-virus software and operating system, not Git.

AFAIK, Git is predominantly written in C, bash, and Perl. I am unaware of any Ruby and I somewhat doubt that they'd use it since they already have plenty of capable language platforms (and I think the developers are mostly Linux-based [C and bash] and Perl-based). Note that every Git command is implemented as a separate process, and many of them are combinations of others. Without knowing the internals, I imagine that git-clone is likely a combination of git-init, git-remote (which is probably built on git-config), git-fetch, and git-checkout (and there are probably lower-level commands within these too). Then there's also the wrapper git process on top of that. In UNIX-based operating systems processes and forks are extremely cheap and this works wonderfully. In Windows land, it's a rather bulky solution, but that is again a deficiency with your operating system and not your source code management software.

Append:

torhu said:

If Git would actually work fine with just cmd.exe, why is is Msys, Cygwin, or Bash always mentioned?

...because cmd.exe sucks, and most people that would choose to use Git are already familiar with Bash shells and UNIX tools that are available with MSYS or Cygwin. Also, part of what makes Git's modular design useful is linking the processes together, which is only partially practical with cmd.exe (for example, I don't think it has a concept of a subshell).

torhu
Member #2,727
September 2002
avatar

Yes, that's another advantage of Mercurial. It doesn't come with a condescending attitude towards Windows and its users ::)

bamccaig
Member #7,536
July 2006
avatar

torhu said:

Yes, that's another advantage of Mercurial. It doesn't come with a condescending attitude towards Windows and its users ::)

Maybe not Windows, but definitely to its users. Whenever I ask #mercurial how to do something the answer is "don't". ::) Mercurial is fundamentally flawed in that its branches are not "distributed" by nature, but they are distributed by default (as if that makes any sense ::)). Their answer to that is "we are right and you are wrong", despite the fact that it causes tons of permanent clutter in all repositories, and is susceptible to collisions. I've used Mercurial more than I have used Git. I am quite familiar with it and its community. My advice would be to prefer Git, but settle on Mercurial if you are collaborating with monkeys. :P

torhu
Member #2,727
September 2002
avatar

Aren't you supposed to use bookmarks if you want local branches? They are not public by default.

bamccaig
Member #7,536
July 2006
avatar

You're not supposed to do anything. There is no single way to do branching in Mercurial. That's the point. Most people in the Mercurial community seem to use entire repository clones for that. Others insist on named branches and permanent history no matter how experimental, uninteresting, or trivial the branch. Others sometimes use bookmarks, named branches, and repository clones all together.

Bookmarks should work for local-only branches. It doesn't include experimental or uninteresting work-in-progress branches that you want to share with a direct collaborator or other interested party, but not the entire team, for example. Bookmarks are not synced between repositories by default, even though branches are. I think that your collaborator would have to be careful to ask for just that branch and bookmark. Still, the Mercurial community also discourages history editing, and there's no other way to delete just a branch, so you'd still have to use repository clones if you stuck to "best practices", making bookmarks "bad practice" by association. :P

Karadoc ~~
Member #2,749
September 2002
avatar

The main thing I like about git is that it doesn't have to be centralized. eg. If I clone something, my repository is then just as valid as the one that I cloned it from. So I can have a copy on my computer, and on my usb stick, and on github, and on sourceforge - and there is no one single 'master copy'. All of the copies have all of the information, and they are all compatible with one another, so that they can push and pull to/from each other. -- That's what I like about git (amongst other things).

I've never used Mercurial, but I know both svn and cvs have a master repository.

-----------

MiquelFire
Member #3,110
January 2003
avatar

For the most part (the bits that bam brings up are just political) Mercurial and Git are the same. There are differences, but it's like the difference between a Honda Fit and a Chevy Aveo/Sonic. For some, which you choose may be nothing more than brand loyalty.

---
Febreze (and other air fresheners actually) is just below perfumes/colognes, and that's just below dead skunks in terms of smells that offend my nose.
MiquelFire.red
If anyone is of the opinion that there is no systemic racism in America, they're either blind, stupid, or racist too. ~Edgar Reynaldo

SiegeLord
Member #7,827
October 2006
avatar

I don't know... bamccaig's blog post about mercurial branches really opened my eyes. Branching is a key feature of DVCS's and the way mercurial does it is just broken, or if nothing else, overcomplicated relative to the elegances of git's approach to that.

"For in much wisdom is much grief: and he that increases knowledge increases sorrow."-Ecclesiastes 1:18
[SiegeLord's Abode][Codes]:[DAllegro5]:[RustAllegro]

Trezker
Member #1,739
December 2001
avatar

What I'm wondering is why there isn't a pure native git for windows.

I think it may have something to do with it using other programs to do stuff that otherwise has nothing to do with git and are not available as native windows programs.

It might also be the case that the git tools are implemented as just programs with no library components. I don't know, I haven't looked at the source, but I think they may not have separated the git functionality from the OS specific code in every git tool.

Every tool you make, if you ever want it to be multiplatform, you have to have one part that'll work anywhere and one clearly separated part that requires a specific platform to work.

To say the same thing thrice, you make an API which is the tool and a program that makes the tool available to users.

Karadoc ~~
Member #2,749
September 2002
avatar

I don't understand what you mean by a pure native git for windows. In what way would such a version be different to the current windows version?

-----------

Thomas Fjellstrom
Member #476
June 2000
avatar

If it helps, there is an effort underway to turn git into a library. Instead of the current blobs of code stuck in separate programs. So if someone really wanted to, they could then use that library to interface with git repos, say from a super friendly ui, perhaps even an IDE :o or an Explorer plugin :o

I think that's what people mean by "pure native windows".

--
Thomas Fjellstrom - [website] - [email] - [Allegro Wiki] - [Allegro TODO]
"If you can't think of a better solution, don't try to make a better solution." -- weapon_S
"The less evidence we have for what we believe is certain, the more violently we defend beliefs against those who don't agree" -- https://twitter.com/neiltyson/status/592870205409353730

Elias
Member #358
May 2000

f it helps, there is an effort underway to turn git into a library.

http://libgit2.github.com/

It's what is used by the link I gave (http://windows.github.com/). Which is a pure native Windows desktop application. So I'm not sure what everyone is talking about here. Anyway, git is a version control system, so by its very nature doesn't have anything to do with what OS it runs on.

--
"Either help out or stop whining" - Evert

MiquelFire
Member #3,110
January 2003
avatar

GitHub for Windows still uses msysGit to fill in the gaps.

---
Febreze (and other air fresheners actually) is just below perfumes/colognes, and that's just below dead skunks in terms of smells that offend my nose.
MiquelFire.red
If anyone is of the opinion that there is no systemic racism in America, they're either blind, stupid, or racist too. ~Edgar Reynaldo

bamccaig
Member #7,536
July 2006
avatar

Trezker said:

It might also be the case that the git tools are implemented as just programs with no library components. I don't know, I haven't looked at the source, but I think they may not have separated the git functionality from the OS specific code in every git tool.

Some of the commands are nothing more than shell scripts. :) In unices you don't notice any difference.

Trezker said:

Every tool you make, if you ever want it to be multiplatform, you have to have one part that'll work anywhere and one clearly separated part that requires a specific platform to work.

To say the same thing thrice, you make an API which is the tool and a program that makes the tool available to users.

That somewhat depends on whether or not there's any reusable code between parts. Take the bash scripts, for example. If you wanted to implement those commands using Windows with no UNIX-like compatibility layer then you wouldn't be able to reuse any of those programs. You'd basically have to implement a Windows-specific alternative from scratch.

The problem here is that Microsoft insists on doing everything differently, and poorly, requiring Windows ports to be completely different than other ports. Using a compatibility layer that will work on both platforms would likely degrade the performance of UNIX-like implementations (some things you just can't do in Windows, like fork()), or at the very least greatly complicate them. In short, fuck Windows. You should be happy to get anything. >:(

gnolam
Member #2,030
March 2002
avatar

Ah, yes, the ever wonderful "it's different from how UNIX does it, therefore it is bad" argument. ::)

--
Move to the Democratic People's Republic of Vivendi Universal (formerly known as Sweden) - officially democracy- and privacy-free since 2008-06-18!

Specter Phoenix
Member #1,425
July 2001
avatar

Back on topic of SFML v SDL v Allegro I think it comes down to how easy the API is to understand and learn as well as the amount of documentation or examples to look at.

 1   2   3   4 


Go to: