Been a while since I posted, so here are some (more or less) recent things.

The terms are not inherent to, or dependent on, using C2.

If you're making a game on your own, then you are both.

People have been doing this since forever. It's not something exclusive to the C2 community. Nothing inherently wrong about it either.

One of my biggest gripes when wanting to make a game that isn't 720p or higher, but closer to retro resolutions, but still in 16:9, is finding a resolution that fits and works.

I was testing some dialogue stuff (mostly just menu graphics and positioning, to see how it looked visually) and had settled on 768x432, using this list I found: http://pacoup.com/2011/06/12/list-of-true-169-resolutions/ (better than calculating the resolution every time you do something).

However, when I run the project the image wasn't stretched to the edges and had huge black borders around it. I tried every scaling mode and switched the browser(I mostly use webbkit, but it performed the same in chrome). No dice.

So I load up an example and change the resolution to 1280x720 at first, same deal. Poke about a bit, and suddenly it works as it should. Switched it to my desired resolution of 768x432, and it worked as it should. I have no idea why this is.

Not submitting this in the bug section because I'm not convinced it's a bug.

My test file:

https://dl.dropboxusercontent.com/u/22615804/lia-diag-test.capx

The example I tried:

https://dl.dropboxusercontent.com/u/22615804/platformer-example-768x432.capx

EDIT: After some sleep I returned to the issue and took another look. I was using the browser object to request fullscreen and it doesn't seem like the request fullscreen action actually changes the scaling mode.

The only way to really limit yourself is by subscribing to the idea that any one medium is inherently better than any other. You can do great stuff with pixels and you can do great things with vectors.

What is best to try is really only up to how comfortable you feel with your own skills. Tons of links to tutorials have been posted to these forums already, just search and browse through them and you'll find some good stuff.

What I would suggest though, is to not fixate on merely learning "pixel art", but learn the concepts that are important to pixel art. Namely, drawing fundamentals, volume and color theory. These apply no matter which style or medium you end up using, so learning that and then moving on to pixel specific techniques like proper AA, avoiding jaggies and proper dithering, will go a long way.

Beaverlicious - I can argue with you about whether or not vectors give more possibilities or not (my stance is, nor more or less than pixel art) but that's not the topic, so I don't know why you brought it up in the first place.

He means that you place sprites behind your image for the joystick that you can have "player touch sprite X" events for, which you then use to control your player.

• Player is touching "joyUp"

+ Simulate control "up"

Something like that. If you need more granularity, and actually want it to be analog (how weird isn't the concept of a digital analog joystick, btw) you'll have to do something else, like determining if the player is touching within the area and using lerp to get the values.

1) I'm not sure how custom collision masks per-tile would fit in to the editor. How workable would it be just to place sprites on top and use them for collisions as well? It seems to be a good middle ground.

In a way yes and in a way not really. Using separate sprites will indeed work, but there are a few caveats. If you want to do anything like an ingame level editor (which the Tilemap is perfect for), such "hacks" makes such a thing less likely to work decently, if at all. Another one would be how it affects the workflow, it plays into the next thing I wanted to address.

inkBot:

You can't move the tilemap if you have any tool other than the select tool chosen. You can also stamp sets of tiles by selecting a larger area of tiles with the pencil tool.

The Tilemap object takes up the entire layout field, and I have to have it unlocked in order to edit it. Naturally I'm going to have other things on the layout as well, like the player character, pickups, enemies, collision sprites and so on. People have already talked about how objects overlapping can be a hassle (mitigated some by the addition of the Z order bar, but not completely so), now throw a huge object that takes up the entire field on top of that and I think you see the issue.

Also, sometimes you just mess up and accidentally move something because you forgot you had that tool selected or that layer unlocked etc. That's just the reality of software use and I think minimizing the need for the user to switch between layers, lcoked layers and tools will only help in that respect. So a way to lock the Tilemap object without making it uneditable would probably be a good idea. I was thinking that maybe it could serve better as a type of layer than an object. Dunno if that would be doable (and probably not completely easy, if so) but it might be a better solution.

I'm so tired of XInput issues. I get that people use it because "hurr durr 360 pad" but it's limited to 'only' that. *groan*

I'm currently using a DS3 with Motioninjoy emulating a 360 pad. Hopefully the next generation will help combat this XInput nonsense with the DS4 being Windows compatible out of the box.

Joannesalfa - That's the whole point. The Tilemap object is currently completely binary in regards to collisions, and it kind of needs to not be. If we have to resort to adding separate sprites to add slopes, not to mention jump-through platforms, you might as well go back to just using sprites for everything. The exercise becomes pointless.

The collision polygon method is most likely not suitable for the Tilemap object and it's not accessible in the image editor for the Tilemap object. Whether that is because Tilemap doesn't use it (to prepare for per-pixel collisions maybe?) or if it's just using a predetermined, unchangeable, polygon, I can't tell.

If the Tilemap object is intended to be purely cosmetic, then that's what it is. But I really truly hope that that's not the case.

Edit: The first paragraph came ut harsher than intended. It's not intended as a dig at the effort of putting in the feature at all, merely a concern about the future potential of the feature.

Joannesalfa - That doesn't really adress the concern about slopes though

— - Regarding question #2. I obviously can't speak for Ashley, but I'd hazard a guess that as far as C2's innards and runtime efficiency is concerned, a Tilemap would have the same effect as if you used several small sprite objects instead of one big one. The Tiled Background object works on the same principle, just that Tilemap allows for more than one tile.

I have some thoughts about the Tilemap as well.

First off, love it. C2 has needed this kind of feature for a while now and I'm happy to see it. That said, improvement is always an option.

1. While trying out the Tilemap object I found myself accidentally moving the object around at times. Locking the layer makes you unable to edit the tilemap. I think a way to lock the Tilemap object in place, but still be able to edit it, would be a good idea. Maybe even necessary.

2. I second the idea of more "advanced" editing tools. Copy/Paste, select and drag, and being able to make stamps of a certain set of tiles would be nice features to see in the future. Of course, Tiled has some advanced features we could use in the meantime (or instead?) but it would be nice to see it in C2 down the road.

3. Speaking of Tiled. It has a feature that lets you add properties to the tiles. This could be usefull for a wide range of different things. Having tiles be of different materials for instance, changing the sound effects when walking on them and such.

4. Loading and editing tilemaps at runtime. I'm guessing the use for this is pretty self-evident. Ingame level editors, animated tiles, etc.

Last one, but with more easily distinguished logo. Right now it's a bit messy.