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

16
Announcements / Re: New GitHub Repository
« on: January 06, 2012, 05:52:32 PM »
git clone is closer to a remote svnadmin dump actually :P
Except, it works with compressed objects, not raw files.

17
Announcements / New GitHub Repository
« on: January 06, 2012, 05:45:49 PM »
I've just set up a repository on GitHub for ENIGMA. You can find it here: https://github.com/enigma-dev/enigma-dev

If you're running a Linux-based distro, you can install the git package, then run the following command to create a local copy:
Code: [Select]
git clone git://github.com/enigma-dev/enigma-dev.git(note: git checkout is not like svn checkout; git clone is svn checkout)

For those of you that want something like TortoiseSVN, TortoiseGit is also available. If you don't know how Git works, I'd suggest learning it (it's not the same as SVN) or asking someone how to use it.

From GitHub, you can fork the repository (and then push changes in your fork back to us), submit bugs (either there or on flyspray here), and watch for changes. You can also view a list of files and commits with much more ease. If you want to download a copy of the repo at any time, GitHub also supports this: https://github.com/enigma-dev/enigma-dev/downloads

One of the largest differences between Git and SVN is Git's naming of commits; instead of using incremented numbers, it uses hashes. Commits can be named using tags (git tag <name> <commit>), and you can switch to a specific tag or branch with (git checkout <tag/branch>). Git also makes a single .git directory in the root instead of SVN's recursive .svn nonsense.

Note that the SVN repo is still up, but I'm not entirely sure of how things are going to work with either.  This is a very large change, however, is really for the better.

18
General ENIGMA / Re: Use git instead of SVN.
« on: January 03, 2012, 09:42:25 PM »
Unfortunately, while I have a ton of experience with SVN, I only have a tiny bit of experience with GIT, so either I'm going to have to do some learning, or someone else is going to have to be our resident repository expert.
I know loads about git, so, I can tell you want if/when needed. When you're developing on Linux, I recommend looking into gitg; it's an extremely useful commit history visualiser (particularly with branches) and supports mediocre staging/committing.

Essentially, Git works off of unstaged, staged, stashed, and committed changes:
  • Unstaged changes are just unversioned file changes.
  • Staged changes are the changes that are ready to commit.
  • Stashed changes are sort of halfway between unstaged and staged; they work somewhat like stacks.  You can stash changes if you want to keep changes that you've made on hand while returning back to the last versioned state.
  • Git operates as a fully local repo with links to other repos. On your own repository, you can commit and uncommit as much as you want, and when you're ready, you can push those changes to another repo. You can also pull changes from said repo. You can technically uncommit on your local repo even if you've pushed changes, but then, you'll have problems when you want to push new changes forward.
  • I don't fully understand how SVN's branches work, but git's are essentially "branching" off of an existing commit.  Essentially, what this means is that on your new branch, all changes will be inherited up until a point, and then, you'll only inherit future commits on that branch.  You can merge branches, too.  You can stash changes and switch branches if you want to save your work from another branch while saving your progress on another. From what I've heard of SVN's, those are more of "let's create a repo within a repo and not care about past changes"
  • Git also supports cherry-picking, which enables you to pull single commits from one branch onto another.
  • Git's version control is object-based, not file-based (like SVN). This means that renames will not bork the entire system, but getting a single file's commit history is slightly more difficult.


Git operates based off of changes and merges a lot better than SVN does.  If you modify the first half of a file in one branch, then the second half in another, git can merge both changes without a problem.  It's only where these changes intersect that it causes problems (such as two branches changing the same line).

There are loads of things that you can actually do with it, but I'll explain them as they're needed rather than all at once.  Plus, you probably know a lot of it.

19
General ENIGMA / Re: Use git instead of SVN.
« on: January 02, 2012, 12:24:07 PM »
I'd be willing to do it.  Or help out, at least.

I can set up a repo here if someone gives me the permissions.

20
General ENIGMA / Re: Use git instead of SVN.
« on: January 01, 2012, 05:42:29 PM »
Do you really care?
I mean, will you take advantage of forking, etc.? Are you planning to switch to github? Something like that?
No, I'm saying that it would be easier to manage if it were turned into a git repostory.

SVN is terrible to work with.

And yes, forking would enable regular users to contribute changes and test them and then offer them back to the dev team.

21
General ENIGMA / Use git instead of SVN.
« on: January 01, 2012, 04:47:29 PM »
Because it's better.

22
Announcements / Re: EDL 3 Proposals
« on: December 05, 2011, 05:59:16 PM »
GM will have structures and will compile GML before ENIGMA has a parser.

:troll:
Its funny because its true.
:troll:

GM will cost a dollar for every week it takes us to finish ENIGMA.

:troll:

So, ENIGMA won't ever de done?

23
Announcements / Re: EDL 3 Proposals
« on: December 03, 2011, 11:05:49 AM »
In addition, std::function is polymorphic, meaning that std::function<int(int, int)> can be converted to std::function<int(double, double)>.

24
Announcements / Re: New LGM Backend Map/List
« on: November 21, 2011, 03:18:08 PM »
Fede: Plain arrays just allocate a chunk of memory, whereas the containers that you'll probably use will just constantly add memory when more is needed.  Containers referring to maps, var, etc.

25
Off-Topic / Re: GM9 on Linux
« on: November 13, 2011, 02:34:26 PM »
rofl

26
Proposals / Re: EDL V.Next
« on: November 07, 2011, 03:24:17 PM »
Question: What is the point of a let statement?  Why not just use { } ?

27
Proposals / Re: Laziness Buffer
« on: October 15, 2011, 04:49:39 PM »
Quote
typedef signed char byte;
typedef unsigned char ubyte;
Oh, no you didn't.

byte is(as of newest standards) required to be at least 8 bits, but not necessarily.
For precise sizes, see <stdint.h>(which does include int8_t and uint8_t)

Also, some languages(e.g. C#) have "byte" unsigned, and then have "sbyte", which is signed.
Quote
laziness buffer

Also, I probably would swap those two.

28
Proposals / Laziness Buffer
« on: October 15, 2011, 04:20:27 PM »
typedef signed char byte;
typedef unsigned char ubyte;
typedef signed char schar;
typedef unsigned char uchar;
typedef unsigned short ushort;
typedef unsigned int uint;
typedef unsigned long ulong;
typedef long long llong;
typedef unsigned long long ullong;

29
Tips, Tutorials, Examples / Re: How to properly use OpenGL
« on: October 07, 2011, 02:17:14 PM »
JoshDreamland: VBOs are far faster than lists because things are less generalised.  Because the graphics pipeline doesn't have to go through loads of shit that isn't used (for example, transforming with identity matrices), it's much faster.  Either way, ith 2-D stuff, the performance is practically unnoticeable.

Either way, support-wise, you should always use lists over glBegin/glEnd because it's much faster.  The only case against it would be in cases draw_* functions.

30
General ENIGMA / Re: Builds, Packages, Releases, etc.
« on: September 24, 2011, 08:12:13 PM »
I haven't been maintaining these packages for a really long time.  Unfortunately, the existing repository doesn't work.  There are PKGBUILDs on the AUR (Arch User Repository), but those only work for Arch Linux.  Once I find the time, I'll work on making build scripts for the Ubuntu packages instead of using my previous method, which was a giant hack.