As I alluded, this is hardly relevant and productive and it'd be nice if mods could split the offtopic discussion elsewhere.

Kinda trivial but i bought myself a new computer. Got a long weekend of getting a sane dev env set up on it but so far it's pretty nice. We'll see how long the honeymoon lasts.

Of course, you could look to Scandinavia for a reasonable, successful implementation of socialist ideals but I'm assuming you're way past that, what with dumping a multi-paragraph political tirade as a response to someone's story about overcoming their wish for suicide.

Congrats on the kid, eyeliner; glad to hear your life is looking up.

Have a look at this: http://androidarts.com/pixtut/pixelart.htm
Glad to see you applying yourself to this regardless of background we all have to start somewhere!

The Microsoft Visual C++ Redistributable Packages for Visual Studio 2013 are required (noted on the lutr install section).

I'm pretty sure I can't statically link against it, so it is just something that needs to be installed for it to run. I could recompile under MinGW or Cygwin to remove this dependency.

I'm just happy someone tried to use my little tool. 

Fun stuff, got it working with arne's 64

Above is from a year ago
Below is recent

Trying to figure out a new art style for my game.
Rip this apart so I can get through this faster

Honestly the top has a lot more character even if it's blatantly GBC zelda.
The new stuff is in a weird middle ground between jrpg, zelda and noise - there's too much going on, not enough readability, and the colours are lacking unification and borderline muddy.
I think you're trying to do too many things at once in the new piece, and you seemed more comfortable with the GBC-ish spec art.

I could do an edit if you were interested, but I'd just say do some studies of some higher-detail GBC games (star ocean is one that springs to mind) and maybe some snes or GBA stuff - golden sun, secret of mana, maybe some final fantasy. See how they weave detail into their sprites without harming the iconic readability important at these resolutions.

Please be gentle. I'm very new at this...

the idea is interesting but there's a lot missing from the basics
- if you're going to upscale, it's generally best to use nearest neighbour and not go to such a huge percent - this looks like about ten times, and then downsampled and sharpened by whatever you uploaded to. Use a host that doesn't interfere and unless you're going for something "fancy" (eg cell will often overlay noise) stick to simple clean nearest neighbour scaling.
- lighting is... confused - the hat seems to be shaded at the top to indicate the lightsource, but what you've drawn is actually rim-lighting which is missing on a lot of the other materials and probably done mistakenly.
- material definition is lacking. There doesn't seem to be much distinction between how you've treated metal, cloth, or leather (what I assume different parts are meant to be made from) - differences between the way different materials interact with lighting, what sorts of edges they form and so on have a big impact on how you should go about pixelling them.

I've done a quick edit, the lack of a clear resolution + blurring made it hard to ensure colour identity.
It's by no means perfect but hopefully is informative enough.



Haven't played with the contrast much but it could use a lot more, you've got a lot of very similar shades in there.

Looks fun, Carrion, keen to see where it goes. Are the background rocks turnips or do they have little birds on them?

@Geti - Cool robot. Did your palette come from somewhere?

I think it was 3 level posterisation and one of the default photoshop colour gradings Couldn't get Josh's .cube generator working so just worked with what I had. I think the grading was called candlelight.

Done using Josh's index paint thing for Cellusious. Very rushed but it's quite a fun technique.

Just FYI the windows version doesn't work without additional dlls. You could fix this by statically linking against the standard lib or including the necessary dlls or redistributable installers alongside.

---------------------------
lutr.exe - System Error
---------------------------
The program can't start because MSVCP120.dll is missing from your computer. Try reinstalling the program to fix this problem.
---------------------------
OK   
---------------------------

Some reading about how DCVS in general work (even just reading the wikipedia page on git) could probably have cleared that up though The whole idea is that there's no forced, central state, and that operations are generally non-destructive. Revisions are explicitly kept separate until brought together manually.

@BorisTheBrave Re: sitting on changes - to each their own, but at THD we've found that keeping more in-sync means we get fewer headaches, haha. Often we're working on reasonably closely related code though, so that's probably a factor.

@Sik Re: cli interfacing with these tools - honestly I gave up on that pretty quickly and grabbed any of the working gui tools (currently using sourcetree, previously used tortoisehg/git) as then I get reasonable feedback if/when I do something wrong. I can appreciate wanting to understand how they work and being cli-proficient and whatnot but it's easier to make technical mistakes and unless you're requesting status output often it's easy to lose sight of the current state of the repository.

Re: your specific issue - DVCS are usually very robust in the face of merging because it's such a common operation.

The error message you might have been getting was that you'd be pushing a new head to the repo (I see no merge there in your example workflow), which is problematic as it means you're creating a branch in the repository rather than contributing development - if one of you had pushed before, the other would need to merge before pushing (or force the push and push a branch into trunk/default/whatever).

Edit: ninja'd by boris

Speaking from mainly-hg experience (still distributed but might not map 1->1)

Touching the same part of the same code at the same time will (almost) always lead to merge conflicts, and you're either going to need to meticulously merge things each time, or communicate better to avoid that happening. Working on different parts of the same file (or different files) will work (unless git freaks out more than hg about that sort of thing), as long as you aren't making mutually incompatible changes.

Developers have to form habits: pull, merge and push often (in that order) to avoid code getting too out of sync. Our revision tree generally looks more like a chain than a tree or path when two or more people are working concurrently.


On the left you can see "nice" collaboration between two people. Each commit is generally much less than an hour apart.
On the right you can see as-yet-unresolved collaboration on a few branches. I've cheated and included the release head to make it wider, but when 3 devs are working and pushing test builds at the same time this isn't an uncommon situation

How to deal with a merge conflict - communicate! Every time someone tries to deal with a merge conflict on their own, something bad has happened. It's hard to take into account all the little things someone else may have done with their code, especially when the conflict it only on a handful of lines. Talking with the team about the best way to reconcile changes is the only way we've found to reliably get around conflicts happily.

The communication also helps avoid merge conflicts happening in the first place: if developers are aware of what else is being worked on, they can avoid creating conflicts by working on other parts of the software.

Hope this helps, let me know if anything isn't clear.

Honestly moving from SVN to mercurial was one of the nicest things we've done, but that was probably partly due to the fact that the move was spurred by a head crash on the machine holding all the svn history eating all of our version history and the idea of a distributed system quickly becoming very attractive. We chose hg because its verb naming is closer to svn's.
I kinda like the staging stuff git has got going on but like hg more overall.

Debugging some engine<->box2d issues with moving stuff out of the map if it gets jammed through walls and the like. Every time I touch this part of crimson I dislike box2d more and wish we'd gone with simple home-rolled physics that were more tolerant to things changing on-the fly, with fewer things to update and copy around. The fact that the implementation sucks doesn't help either.

its definitely busy, and its hard to read at a glance if the lights are on or have been whacked, I guess they're always on when you come up to them but could still be nice to add a background "halo" around them in some light colour.

Got something done for ludum dare this time around. Just a little card/board game for 2 players, but it was refreshing going from nothing to something in a weekend again.

http://ludumdare.com/compo/ludum-dare-31/?action=preview&uid=2001

What's this? Procedural facial animation and lipsyncing in Unity on a character?

niiiiice

I thought this was going to be about like, the qualification side of education. Was going to say: if you're in games, a game design degree isn't worth much to many people; do compsci, or art, or something else applicable outside of games.

On the actual topic:

Honestly, I've largely found internet tutorials to be a waste of time - you often learn how to do something, not why, or any particularly widely applicable skills - this is particularly true with programming though.

Some art tutorials/ramblings from Arne that have helped me with reasoning about things:

http://androidarts.com/pixtut/pixelart.htm
http://androidarts.com/art_tut.htm

Best way to learn (imho) is by doing, of course.

Well, here's the protagonist sprite at least!

Hahaha, I liked the knockback undies nice touch

@Prinsessa: good luck, gamepads can be a pain!

Working on a little homage to Commander Keen.