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 - Arne
Pages: [1] 2 3 ... 44

General Discussion / Re: Choosing Colors and Color Theory
« on: January 27, 2017, 04:41:48 pm »
Since 1990, when I got my Amiga 500 and Deluxe Paint II/III.

When it comes to choosing colors for a ramp:

Is it for a sky or smooth sphere? Then I might want to consider a very even, linear ramp from dark to light with a gradual hue shift.

Is it for a figure, tree or rock? Here I might start with a linear ramp, but it usually looks boring so I go in and change the hue and value of colors slightly until it looks interesting. See this tree, where I also added a parallel ramp of alternative browns.

Sometimes if a piece isn't working, it could be as simple as changing the colors, and sometimes the palette is just fine, and the problem lies in pixel adjacency (how colors look next to each other).

Working with a neutral gray-ish background helps when setting up darker colors.

I started on a tutorial once but never finished.

General Discussion / Re: Choosing Colors and Color Theory
« on: January 26, 2017, 05:50:14 pm »
I didn't spend much time adjusting the colors/palette here... most palettes have some room for expression and if you're sort of happy with the general colors and the atmosphere they create, then it comes down to what you do with pixel placement and figure/construction. I did reduce to under 16 colors because it saves time. I don't like to work with colors that are too similar, and I prefer the look of smaller palettes over smooth gradient stuff. More colors, more little AA dots to place, and that just makes things blurry, to my eye.

For the figure, I just erased the pants to move a foot back, and consequently, hip out. Reduced texture/folds on shirt. This allowed me to fit in some actual detail, like buttons. He could also have a stripe running down the shirt sleeve or something. I was thinking vintage navy/air force for theming. Added a gold accent near foot to suggest detail and some form of regality.

It looks a bit colorized, doesn't it? By that I mean, some objects/parts appear to have been painted in grayscale, then just given a simple colorizing pass. It makes things look disjointed and dead. I'm especially concerned by the ramps of some of the greens and dog-pee yellows. I quite prefer the look of a more limited palette as it really forces a sort of homogeneity in (colors looking like family), as well as some dither which can bring in some variation in texture. Minish Cap hardly seems to use dithering as a tool at all, insisting more on banding, giving it a color-reduced look here and there... texturally one-dimensional. Dithering can be really subtle, and I liked how they used it on the road-lumps, less so on the bushes, yeah. I also think that, in some cases the grass looks a bit ... gritty with the diagonal near-orphans.

General Discussion / Re: Grid-based paradigm
« on: May 04, 2016, 03:58:47 am »
I was just going to mention the Amiga. A lot of the little games I did back then used "BOBs" - Blitter Objects. The Amiga doesn't have a tile PPU like the NES. There were drawbacks to using BOBs floating about. It makes level / collision data a bit harder to manage.

 When you're in a grid, you can know right away what is at 140, 204 (bitshifted by 4 for 16px tiles). It's could be a block, or air. Solving collisions is super easy.

When your objects do not have a simple shape and are just coordinates, they become hard to find. You might have to do something like:

Split the playfield up into a grid. In each cell, store a linked list of objects inside the cell. However, because some objects overlap into adjacent cells, we might have to check neighbour cells as well, or make sure overlapping objects are stored in the cells they spill into. Then to see if the player have collided, iterate all relevant lists and call the collision method for each object and check against player shape. This could rely on a bitmap, vectors, or perhaps a bounding box or radius check. But because the shape might be irregular, we might need to do special angle math so solve things like bounces/pushback. If we want to do an AI with pathfinding, we probably need to set up a mesh of nodes... but will the setup routine identify those barely-squeeze though cases?

For single screen games (e.g. Sierra adventures) we could use a pixel-level collision map, but for massive side-scroller game maps, it's a bit... ugly. Lemmings used brushes for the level design and a pixel level collision map, but those levels were pretty small and the lemmings were so small they probably only had one or two collision spots to check. At any rate, all this is a lot more work than using a simple grid where we absolutely know most of the facts and structures instantly.

On the Amiga, because it used Bitplanes, there were also some issues with drawing things on non-multiples of 8 or 16 I think. If a byte spilled over into the next, you (the GPU) have to read both bytes and mask your new byte onto those and write both back. If you draw on a multiple, you can just write over and forget unless you have transparency. I think... The Blitter would plop down 16 bits (pixels) regardless, in each bitplane, with a custom or global mask, or no mask. When I worked on a thing with 12px tiles a while ago I had to manually poke a special transparency bit mask somewhere in memory so the tiles didn't overdraw the next.  On a modern GPU this stuff doesn't matter, but the collision problem still needs to be solved and analog situations can be tricky to deal with.

In Aquaria and such it's all done by magic.

Pixel Art / Re: Drawing a pixel spruce
« on: May 04, 2016, 03:03:47 am »
Here's a few things to think about.

What's the mood and color of your scene? Movies for example, often use teal and orange palettes nowadays. The advantage of palettes is that it forces the look to be consistent. If you have trouble coming up with a palette, you can grab a photo or a few stills from a movie, then index those and try to make something with the resulting palette.

What is the background and light situation? Simplified silhouettes work fine, if that's the expected light because we see it elsewhere in the scene. Dusk colors also work fine if expected. If it's a sunny day with light coming from top-front-left, some more contrast is definitely needed.

If you search for spruce images, take your time. Look at 100-200. What do they have in common? What is the essence of the ones which appeal to you? Some are very noisy without much structure. Others have lumped up branches and deep shadows in-between. They come in different colors, too. Branches can sag, or point up, etc. Decide on one variant and draw several sizes of it.

I ended up with a noisy turd.

I wanted a different brick size for the background (smaller to suggest distance), but this added extra noise. Could probably throw in more blank/flat tiles.

I didn't want to do leaf blobs for the plants, so I started dithering, thinking it might work on a TV.

Tried to keep the tile count and 4*4 layouts somewhat low, but sort of creeped away doing a few decorative tiles.

Tried to keep the original 3 palettes to the end, but had to lighten the sky to reduce noise and replace GUI palette red with brown as I used that for the lit ground tiles.

*Edited in some more flats. Plant dither still a mess.

General Discussion / Re: Resizing Practice Thread
« on: February 15, 2016, 06:10:33 pm »

Usually when I upscale (or want to remove noise/artifacts) I apply some median noise to blobbify the image.

General Discussion / Re: Resizing Practice Thread
« on: February 15, 2016, 04:10:39 pm »
I think Helm's 2x texture would work great in a raycasting or scale down+rotation engine, as the lack of single pixel detail would reduce noise (unlucky samples). I experimented some with down sampling (here from 5x) and rotation (and certain edge cases) back in 2004, as I was annoyed by how noisy (or blurry) rotated 1x graphics would look in most engines.

I'd be tempted to change the highlight color of the thorns especially. Ramp highlights shouldn't make everything look like metallics (do an image search on metallic car or metallic purple to see what I mean). More suitable for the brass metal architecture I guess (if that is metal and not wood).

Pixel Art / Re: [CC][WIP]Superhero Girl
« on: May 17, 2015, 01:41:45 pm »
... I... went overboard.

But, the thing with yellow, skintone and purple is that they are useful together. Our minds read yellow as skintone when used on faces, and skintone as yellow when used on... bananas. It's sort of how a paper will almost always look white, outdoors, indoors or deep in the forest. The brain calibrates.

Purple is a good way to shade skintone, so if you have say, yellow, brown and purple, you can use brown to shade something like a banana, and purple to shade faces (and share the yellow for the lit areas). Now the yellow will look even more like yellow in one case and skintone in another.

Because you mentioned GBC, I went ahead and used only 3(4) colors. I don't know what I did with the hair. Derailed, I guess. It's now a cap (probably magical and talking).

Pages: [1] 2 3 ... 44