Downloading the Lite Version right now.
Might get the paid one if I like it and play through the Lite one.

I've never seen this particular price for an application in the App Store before.
Looks like a good one. Affordable, and will probably earn you a lot if a lot of people get this game (and it looks like one many people would want to get!).

I'm curious, so I have to ask. How many downloads a month (or week or whatever) do you get, and how much money does it earn you?

Qt!

Windows.

I have this tileset now:



Here's what I've been able to make so far with it (and I actually like this simpler style):

Don't worry. I've been refusing to do graphics for a long time, even though the composer is whining, and I've been focusing solely on the programming and getting the engine to work. That is my main purpose, and hopefully we will find somebody else to do the graphics.

Any way, this is more of a... style test, I guess. We'll probably not use this house exactly as is, since we want to have the game levels tiled. I've made a simple tileset out of the bricks in this image now, and already there are differences, as I have rescaled them to fit the tileset:

Well, the house isn't done either, after all.
The wall looks very clean now. It is going to get some imperfections and darker spots.

After weeks of having a fucked up bug in my platform engine, disabling my character from jumping properly in slopes, I now finally got it working after making a selection a bit longer. It doesn't look good, but it works.

ok well now youve just used a paint daub filter 

Never heard of it.

I sharpened the lines by extracting an outline of a copy of the image, which I put on top, then changed the blending mode and lowered the opacity.

For the outline, I just made, well, an outline.
At least I've made that house on my own. ]:

You are very right, st33d.
To check before moving and to see if one _will_ have an impact on the next frame is also a good solution.

This looks quite okay to me. Just a bit sharper graphics, and a simple outline (no, that ugly, purple circle, the almost circular thing within it and the number in the top-left corner are not part of the final HUD; I'm just playing around with fading and animation code; likewise the white "ground" and triangular "character" are just for testing, and the background is obviously not to be grey in the final game):

Further playing around:

You are probably right, and I got carried away.

But would black lines look nice if I actually added a bit of my own touch to it?

And here I was just talking about getting collision blocks to mash up against walls nicely, dohohoho

Well, rectangular collision is obviously far more easy, and doesn't require this load of trigonometry which took me a week to figure out since I'm not exactly an expert on mathematics.

What I'd to is to simply check whether your collision block has bumped into a wall, and if so, check whether this wall is in front of you or behind of you, and then just move your collision block so that it isn't inside the other block but right next to it.

I'm the programmer and currently the only artist (since the other one decided to dedicate himself to other things in life) of a 2D platformer in the works.

A pretty long while ago, I made this (still not entirely complete) house for the game:



Now, though, I've been playing around, and I actually like this:



Which style would you prefer?

Like I wrote in another topic:

The system I have developed for my 2D platformer doesn't deal with square collision objects, but polygon collision objects, which are split up into triangles to check for perfect collision within these triangular shapes.

I obviously have quite simple collision polygons, but they still give more precision and look nicer than just square collision blocks, and as the collision polygons are obviously invisible, and all that's visible are the tiles and the sprites, this gives you a pretty good illusion of an almost pixel perfect collision system.

This also allows for slopes of all angles very easily.

To make sure that I don't blow out the RAM just to check for collisions, I make sure to have as few block objects as possible, and I make sure that as few blocks as possible are checked at the same time. For this system to work, it is important that I add the blocks in the right order, from the beginning of the level to the end of it.

To make sure that I have as few blocks as possible, I simply allow every block object to have a repetition parameter, so that the same block can actually be as many blocks as I want to. The reason I do this is because the collision algorithm works much better when using several small blocks than huge ones.

To check for collisions, there is a for loop that goes through all the blocks of the course, but it breaks itself if the next block it checks is out of range, so that it doesn't have to check more blocks than necessary, and there is a variable to keep track of how far you are into the level, so that you do not loop through any blocks behind you either. So, mostly, thanks to the repetition parameter, mostly just one block or two is in the loop at the moment. Then there is, of course, another for loop within this one to loop through the repetitions, but like I said, this only happens for one block and then the loop will break, so it isn't slow either.

My next goal is to also deallocate any blocks not used anymore (as you can't go back) and not to allocate any blocks long before I need them.

Is nobody willing to give an example of how their custom formats were built up?

For my current project, I've been using the STL vector just because of lazyness and currently I don't need anything fancy, but I've actually constructed my own vector class (as well as working on strings, file handling and a lot of other basic but important things) just to get my tools exactly the way I want them. One can easily shuffle the elements of my vectors, for example, and the string class has explicit C string conversion, and a shitload of member functions (such as split, splitting into a vector of my own class, join, find, count instances of letters or words, reduce duplicate characters and a lot of stuff).

That's also an option.

[the original super mario]

I teach kids in primary school aged 6-9, and and when I asked them once, about a quarter to half of them played the original super mario.

I assure you that these kids think that the original Super Mario game is Super Mario Galaxy, or, at best, Super Mario Sunshine.

That might be true.

Not Super Mario 64?
I know a lot of people my age (at least I'm 18) who think Ocarina of Time is the first Zelda game. It's just awful.

UDK came along and I was delighted, and probably one of the very first to download it.
Then I found out that its resulting games would be Windows only.

Impossible is right -- your player/camera/NPCs should be moving through the world, the world shouldn't be moving at all!

All the objects and tiles should "live" in worldspace; tile positions are fixed and the camera/player/NPCs move around. To draw the world, you determine the screenspace position by calculating the position of each object relative to the camera's position.

This way, by moving the camera around you create the *illusion* that the world is moving, without actually having to make the world move. The benefit of decomposing things like this is that many difficult problems become sane -- i.e you can now treat NPCs and player uniformly, since both are just rectangles moving around the fixed tile shapes.

Isn't it obvious that the world should have a fixed position and that there should be a viewport moving around?