My art showcase (Character Portraits - April 03)

Hi everyone, new to these parts of the internet. I was talking to Kasumi who told me some stuff about NES gfx I did not yet know and that inspired me to start a new mockup which is true to the NES restrictions.



This is 55 8x8 tiles right now and uses 3 palettes (I am sure that is obvious).
I plan to chip away at this and add more things when I have time (which I do not have too much of atm, because I have quite a lot of work.)



Latest:


New mockup action:


Health displayed with sprites. Less HUD = better


------------------------------------------------------------------------------------------------------------------------------------

Other stuff:


4 tile palettes per face.

Hey ptoing, nice to have you here. I'm a big fan of your work, have been following it for a couple of years. It's actually quite a coincidence that just a couple days ago I was checking/updating the "ptoing" section in my sprites folder!

Very cool graphics you have there! You're pretty good at dodging color limitations, nearly everything you make appears to have more colors than it actually does. Welcome to NESDEV, hope we can see more of your art here!

BTW, I'm kinda wondering what could Kasumi have told you about NES graphics that made you want to do mockups for it again... care to share?

We were just talking about the U-Head stuff I made and talking about palettes as well as the 32x32 pixel metatiles stuff most games use. I have not kept an eye on the 32x32s super much on this one yet (A but though), but it should be fine.

Also the U-Head stuff was made with some PAL palette, not sure how accurate that one is, but it seems to be a lot nicer than the NTSC one (which this is). The thing about the NES NTSC palette is that you basically have 6 values, more or less. meaning black, white, and then each row of colours being one value with the greys at the left and right being offset by one up and down. All the colours in from 30 to 3F are more or less the same lightness and it is pointless to use them in the same 4 colour palette, as they blend, in 99% of all cases. This goes for the other rows as well, but a little less so. There are some cases I can see using 2 colours of the same row in the same sub palette, like for example if you have a palette to spare and just want some details in the back where shading does not matter, such as techy lights for example.

The PAL palette does not have this problem, it actually has some contrast within the different rows, and not just between them. But it is good fun to pixel with the NTSC one too, extra challenge. I certainly enjoy it.

Wow, your work is amazing. Certainly hope to see you stick around these parts of the internets.

Hello and welcome! Your graphics look very nice. If you ever want to start working on an NES game project and need a programmer, hit me up. Have to throw that out every time something exceptional shows up, because we don't get too many graphics guys in here.

Thanks everyone.

thefox: Sure, I am up for that. if you got a cool idea for a game, let me know. If I like it chances are I will make art for it (prototype with gameplay would help). But I am very busy working right now, so I do not have a lot of time for side projects. But I definitely want to work on NES game someday. (Don't even have a NES atm, derp)

Just want to say that this mookup looks very great. We can immediately see you're very skilled.

Pretty.

EDIT: you might be able to get away with just using a single dark cyan and freeing up a color as the two shades of dark cyan are not likely to be very distinguishable among the black on a CRT display.

That Kasumi person, always spreading lies. Nah, but I wouldn't worry too much about the 32x32 thing. It's a thing that happens in my game and some others, but keeping 16x16s in check will work fine.

I made a super quick rom of the desert scene in this. Don't worry, he already knows what things in those scenes won't truly work, no need to tell him. (Can I post that rom, ptoing? I normally don't share stuff like that without asking, but uh... I guess now I'm shadily asking you publicly.) One other thing that may be worth posting is the fixed U-Head scene, but I'll leave that one to you.

He's pretty serious about some kind of NES collab (though in the future, not right now). I'm working on some epic project (which you know nothing about, got it ptoing?), but if it ends up stable in some months you can bet I'm calling dibs on this collab.

Hehe, sure, I got no problem with you posting that rom. Perhaps add a little credit thing on it or something, dunno.

sonder: Not quite sure I get what you mean. I take it you are speaking about the blue palette I am using for the rocks and sky and some bg stuff on the black (more rocks) as well as the water. If I make either of those cyans the other one that looks fugly as hell to me, at least on an LCD. Don't have a CRT to check here.
Feel free to make an edit to show me what you mean, if I am missing something.

The mockup Kasumi was talking about. This is retooled to have less than 256 8x8 tiles, still quite a lot though.

PAL palette I originally made it in. No clue where this one came from.


Retooled to NTSC palette from Joel Yliluoma's webapp.

Assuming you care about how it would look coming out of a real NES (just hooking up your computer to a CRT monitor wouldn't get the full effect) then the next best thing would be to import your graphics into a program like NES Screen Tool by Shiru, recreating the palette and setting the attribute data, then get all the data into an NES program that shoves it onto the PPU, and then run it in Nestopia with the NTSC filter enabled. I did this exact thing to test out my graphics "as it would look". I could help if you have any interest.

You'll find out that some detail is lost and some is actually added, just because of how the NES cuts corners to get the display signal out. A "pixel" doesn't really exist in CRT technology, is a big reason why.

I find these images inspiring. Thanks for sharing them.

Thanks everyone for the nice comments.

sonder: Yeah, I know about CRT vs LCD difference and the analog nature of it all. Can you link me to the tools needed to do this? I would be very thankful. I hope I can get my head around it and it's not too code-y :/ I'd really like to see what it looks like with proper NTSC emu.

Very much so! It reminds me of FF6, as well as Tsugomo's So You Want To Be A Pixel Artist.

I made an NES drawing program that ended up morphing into exactly this. You specify a 32-hex-digit NES palette, and savtool builds a .sav file containing the pattern table, nametable, and palette so that you can view it on an NES or in an emulator. You'll need to install Python and Python Imaging Library first.

Bushes/leaves added as well as some man made blocks. And a poopy knight duder.

75 tiles, 108 16x16 metas


Haha, thanks, that tut by Tsugumo is pretty classic, there are a lot better reads on pixelart nowadays though.

tepples: I have to play with that sometime, thanks.

I just wanted to say that all of what you've drawn here is amazing.

This is AWESOME! You are very talented, to make such visuals with NES limits.

Thank you

Big Nestopia screenshot.

tepples: So I did some importing with your editor thing, which kinda worked, but not as intended. For some reason there is a massive black area at the top of the image as you can see. It kinda got shoved down. The input image was 256x224 pixels, which should be fine, no? Any ideas.

Try a 256x240 image and see if that works any better. I might have made a boo-boo in the converter.

Thanks, that worked.

I think this looks pretty nice. I guess you'd have to have a pretty dark TV to not see the darker blue/cyan colours. Seems like the palette I am using is a bit hueshifted compared to Nestopia's default.

https://dl.dropboxusercontent.com/u/15588722/post/nesmock4part.sav

Did you enable the ntsc mode? The screenshot looks like standard bilinear filtering. Make sure it's set to composite.

Yeah, I am not using computers since yesterday. I set filter to NTSC and set it to composite. Looks good to me. Feel free to download the .sav file I linked and open it in tepples editor to check for yourself.

Some way, some how, this stuff needs to end up in a homebrew game. Hard part is creating the game play that could do it justice. Not sure if we've ever seen anything on this level before around these parts, it'd be a crying shame for it to never see a completed game that it deserves.

Would be cool to make some action platformer out of this. But right now I do not have enough time. But sure. If a good coder would be up for it, I'm game.

And about me being pretty good at pixelart, I've been doing it for almost 10 years, 8 years professionally, so I'd hope that I was decent by now

Lots of people have been doing it longer, and are not nearly as good (me included)!

All I can say is keep up the good work. I like most of your pixel art, but being a NES programmer I'm obviously excited about seeing more NES stuff!

That is some very nice work. Hopefully your schedule clears up so we can see more, in a game...

tokumaru: The important qualifier you missed was 'professionally'. I think any artist doing pixelart for 8 years to earn his bread should be pretty good with this kinda stuff. Also an added bonus with me is that I absolutely love working with restrictions, I find them fascinating and fun.

never-obsolete: Here's hope

EDIT:


And old mockup I made, changed it to the NTSC colours. Should confirm to limitations. 3 tile palettes, 2 sprite palettes.

Very cool art, ptoing! I've seen your work on pixelation, etc. before. The reason this would fail in an NES screen editor is that your global BG colour is obviously black, but you have cyan from one palette overlapping with orange bushes in the top-right of your pic. Can't be done that way on the NES, I'm afraid.

How many shades of orange are there in the bushes? It looks like those could be done with black, dark orange, light orange, cyan.

ccovell: I know exactly what does and what does not work. There are 4 tile palettes now and one of them is what tepples stated. 2 reds, teal and black. If you scroll up and get that .sav I made for tepples editor you can actually have a look at it and see that it works.

Update with new knight:


And something completely different:

Your works and style are amazing! Especially given that it is created with all nes restrictions. Also, Blue Knight looks more interesting imo.

I prefer the bronze knight.

Thanks

I mainly made him orange to stand out more. If this was to be a proper game I would probably change player colour on a per level basis, slightly anyway, to go with the atmosphere. Also how well he reads would also have to be tested on fullscreen NTSC with emulation or real CRT.

Oi, replying to old post (didn't check the forum in a while it seems).


Something must be wrong with me, because I only see two tilemap palettes (the one with orange shades for the foreground and the one with blue shades for the background). Which palette am I missing?

EDIT: just saw it... that 8-pixel wide staircase =S (stupid 16×16 boundary limitation)

Because of the 16x16 thing it needs a palette with the sky colour and the 2 oranges for the ladder.

Yeah but there are some ways to get around that, or make better use of the third palette.

Using sprites or a double wide latter would cut down to two palettes.

Even better might be to keep the third palette and use that palette more often in the 'sky-surface' transition areas. The dark brown patterning would have to move out of those immediate areas of course. But you could round off in the corners and vertical ridging of the ladders and such. Doesn't work everywhere as the background isn't always white. But areas where it was made white could add to the detail and make better use of the palette instead of only for the ladders.

True. Though I made this quite a few years back, did not really think about restrictions and effective use that much. It has more 8x8 tiles than my knight mockup as well.

Yeah 55 Tiles is extremely impressive for all that detail. Honestly if you're creating something that'd be desirable for a homebrew I'd say make use of as many of the 256 tiles in a pattern table as you'd like for a given level/scene. The only reason to limit total tiles in a game is if you're using CHR-ROM, but CHR-RAM is the clear choice for a larger than NROM homebrew. Even if it's just UxROM. Only thing worth leaving room for is an HUD, maybe 30-50 tiles or less? Since it's RAM you wouldn't even need to store the entire alphanumeric alphabet, just use a tile per character.

Pattern tables compressed into PRG-ROM are relatively cheap. I'd go as far as to say they can be made effectively free in many cases.

My point is, feel free to use up the majority of a PT for a scene! If you're not using them, they're effectively being wasted IMO.

Yeah totally. My current tilecount on the lastes knight one (not posted yet) is 99 tiles. I think the one with the statue is close to that, but I also killed 2 unnecessary tiles which are almost the same which slipped by earlier.

And of course I will use most of the 256 tiles in the end Want it to look as good as I can make it look.

You'd also want to limit tile usage if you have textboxes poping up in the playfield. If texboxes using both japanese katakana and hiragana show up, close to 128 tiles could be used only for that, leaving only 128 tiles for background graphics.

HUD and text boxes always could be done as raster split with CHR bank switch at certain scanlines. Not too good with 8K CHR RAM, though, as there are only two banks, so HUD will either take space from background tileset or sprite tileset.

Glad to hear it!

That'd be a horrible waste if ptoing was to operate with half the tiles to have Japanese text. Even if japanese were desired you could do as I said previously: Or just black out the background while displaying large japanese texts, don't limit graphical art of this high quality.


Pretty easy/free to have >8KB of CHR-RAM with a homebrew.

Faxanadu (licensed), Super Bat Puncher (homebrew), and RHDE (homebrew in development) reserve a bunch of tiles for text boxes. Faxanadu does so because the Japanese version displays kanji. Super Bat Puncher does so to display a 4-pixel top and bottom border on a 32-pixel-tall text box. And RHDE will do so for a proportional font.


It still pays to conserve tiles to an extent, as that allows for easier pattern replacement when scrolling from one scene to the scene next to it. Battle Kid loads only the tiles needed for one screen, and that's why it doesn't scroll.

200-220 tiles per level/scene is still conservative as I see it. You could have even more via bank switching without much trouble, my suggestion allowed the graphics to stay on UNROM. Battlekid's tile use isn't so complex that it couldn't scroll. It was just a design/style decision sivak made which removes the complications involved with scrolling, I can't imagine it was due to tile limitations...

In theory yes, just use larger SRAM chip, which is normally 32K these days, with any CHR-ROM mapper. However, practically - is there any emulator that supports CHR-RAM bankswitching, to be able to develop software for this hardware configuration?

That can work for a status bar. But for using more tiles within a scene, you'll need either separation of tiles into horizontal bands (to allow for mid-screen changes) or ExGrafix.


Any emulator that supports Videomation or Oeka Kids supports large CHR RAM. Any emulator that supports Pinbot or High Speed supports splitting the address space between CHR ROM and CHR RAM. And I'm less than a week from releasing a multi-mapper test ROM that looks for (among other things) NES 2.0 support with 32K CHR RAM.

Been a while since I worked on this (jeez, over 2 years D:) and felt the urge to get some NES action going today so I updated this and added quite a few things. I am at 221 chars atm. Hope I'll find more time this year to work on this project more and be a bit more active on here in general



Also I wanted to ask, I am basically playing pretty loose when it comes to meta tiles. There are not many, because I use a lot of the dirt tiles (and actually some others as well) in multiple spots to break things up a bit, not really making stricts 16x16s and sticking to those.

Also, the chars can have 256, and then another 256 for sprites, right?

You've got only 183 unique 16x16 areas. The reason to not go over 256 of any given structure (besides 8x8 tiles) is data size, not really difficulty.

It's 256 8x8 tiles for the background, and 256 8x8 tiles for sprites. (Assuming no scanline stuff)

Yes.

If you're doing CHR RAM, you can have more than 256 background tiles if some tiles are used only at the start of a level and others are used only at the end. There just has to be a 264-pixel (33-tile) gap between one tile and another tile that reuses its tile number.

If you're worried about metatile bloat, you can have the game randomly pepper tiles in specific positions with alternate versions as the engine draws the map to video memory.

Thanks for the info.

I was wondering about the swapping of tiles during the level. For example the part between the mountain sky and the demon statue is wider than 256 pixels. So that would work to optimise out the unused sky stuff for example.

I just wanna chug along doing gfx for this until I have a lot more time, and then get someone to help get it done. thefox actually already did some test stuff back in 2013. And I know some really good Japanese chip musicians, too. But yeah, time.

Edit:
Kasumi, how do you get to that number. ProMotion tells me I have 341 unique 16x16 tiles.

Don't necessarily assume your programmer will want to handle mid level tile switching, though. What Tepples described precludes using CHR ROM which has benefits that may better suit the game, for instance. (Similar things can be done with CHR ROM, but there are more conditions than the single tile swap that can be done with CHR RAM)

I got the 183 tile count with Pyxel Edit by forgetting I had it set to hex. $183 = 387. They still don't match, but if it's not counting two 16x16 regions that are the same except for their palettes, that would probably explain it. (Different palettes should matter for metastructures.)

Ah, I see. I did the check on a 2bpp version.

What are the benefits of CHR ROM over CHR RAM?

Pre knowledge: If the player is not looking at a solid color screen (like during gameplay), most graphical things can only be updated during a very, very small period of time before the frame starts being rendered. This limited bandwith is the source of most NES graphical trouble. Updating tiles for scrolling or the HUD must be done in this time, updating sprite positions must be done during this time, palette updates etc.

CHR RAM allows you to freely change tiles, but if you want to update tiles this must be done during that tiny period of time. So if you're scrolling and want to update a lot of tiles, you might run out of time. You lose the ability to do midscreen scanline swaps of tiles. You can dynamically edit tiles at run time. Solstice uses this to hide the characters behind an isometric background by changing the pixels of the tiles that make up the characters transparent as they move behind the background.

CHR ROM totally lets you do midscreen scanline swaps of tiles, and you can swap all of them even while the game is drawing. This is because when swapping tiles on CHR ROM, you're not using the ports you can't talk to while the game is rendering. Instead you're talking to the mapper. Smash TV uses WAY more than 256 tiles for its title screen, and that can't be done with CHR RAM at all. You can also do significantly more background animation (including animating all 256 tiles on screen), and it's basically free. To do the same in CHR RAM is literally impossible. You can only update as many tiles as is safe with all of the other stuff that must be shared in the tiny time talking to the graphical ports is allowed. (How many is okay depends on a bunch of stuff like what sorts of scrolling you plan to do, since that also needs those ports. Also how fast the code that does those things is. Very fast code tends to take up lots of space, so there's enough in play that it's hard to throw out a number)

Haunted: Halloween '85 does this dynamic tile replacement thing, and its engine allows replacing up to eight tiles in CHR RAM per frame.

With CHR ROM, you can get a similar effect by using a basic set of 128 tiles throughout a level and different sets of 128 tiles for different parts of a level.


Videomation and Oeka Kids use WAY more than 256 tiles for the painting screen, and that can be done with a CHR RAM larger than 8K. My current project uses a 62256 (32Kx8 SRAM) as its CHR RAM.

Worth noting CHR RAM also allows variable width fonts, then. Which is another Tepples special.

Love your work, ptoing, it's easily among the best on the NES.

As for CHR-ROM vs. CHR-RAM, ROM that's switchable in small chunks (1KB or 2KB) allows you to easily achieve that "late NES game" feel, since you can instantaneously swap large amounts of tiles at any time, but without HAVING TO change the whole thing, which means you can animate only a few background elements or some sprites without the need for prohibitive amounts of CHR-ROM.

A competent programmer can achieve similar effects using CHR-RAM, but managing the PPU bandwidth becomes a much more complex task, and very large pattern changes are simply impossible from one frame to the next, such changes must happen across several frames.

If you need a lot of pattern changes during gameplay, CHR-ROM will make things easier, but there currently aren't many people selling recreated versions of mappers with fine CHR bankswitching for making cartridges (the MMC3 would be the most logical choice), while CHR-RAM cartridges can often be built from common, cheap electronic parts, so that's one reason for going that route.

Interesting. I guess if I wanted to do something on real cartridges (which would own and make me super happy) will need to be taken into consideration when making this.

ATM I am optimising the meta tiles. As of this post I am at 340 down from 388. Let's see if I can get it to 256 or less *cracks knuckles*.

Edit: 274 right now. 256 should be doable. maybe even less \o/



And here is a really big image with colour variations of the current optimised one:

Clicky.

I'd always take bank switching over CHR-RAM for such a change, honestly. The biggest problem is that you need to switch multiple tiles at once (mappers don't have that much granurality usually) but you can usually figure something out regarding this.

Also: palette changes mid-level can be just as useful. Maybe even moreso, in fact.

Jurassic Park is one example of a game that does mid-level tileset switching. When the first level starts, the tileset for the park gate is switched in. After the player moves far enough down or to the right, another tileset is switched in. This can be seen in FCEUX PPU viewer (set "display on scanline" to 32, otherwise it will display all black because the game switches to an all-black tileset at the top and bottom of screen to display black borders). Jurassic Park uses CHR-ROM.

As for the 256 metatile limit, it's true that having that limitation makes programming easier, code slightly faster and less space is used for the level data, but I feel like it's probably not the end of the world to bump up the limitation to 512 metatiles (by having two sets of 256 metatiles, and an extra bit in the level data for each metatile to select between the two sets). I plan to try to implement this in my engine at some point. Nice thing is, that if a level ends up using only 256 metatiles, you could point both the upper and lower metatile pointers to the same data, and the "9th bit" pointer to any garbage data, and it would work, wasting no space. Only the code would run slightly slower.

thefox: That would be same difference to me as an artist, since I still have to make sure to have 2 separate sets, right? but having more variety in a level would be cool either way. Also, is there any way to store the colour data separately from the bitmap, so that the colours could be disregarded when counting metatiles. As in have the colour stuff stored in the level data or something.

Also made a new little mockup, actually got some game mechanic ideas for this.



Player variants for different health levels.

Yes. Color Attribute data is commonly stored as part of a metatile. (2-bit)

My (cancelled) NES game used something like this:
.db $T1,$T2,$T3,$T4,%PPSSCCCC
T = Tile Number
P = Palette Attribute
S = Special Attribute
C = Collision Data

I take it Special was for stuff like damage and slippery and the likes? And more bits for collision because slopes?

Special was for spikes, pitfalls, and ice, yeah.

My game was a Zelda 1 clone, with quadrant-based tile collision. Each 8x8 tile had it's own collision.
For a platformer, I would recommend an extra byte to handle the slope data more accurately.

This could be handled by a conversion tool. So you'd feed in the 512-metatile level and it would handle the rest.


It's possible. Whether it would be beneficial comes down to the level layout. Although I believe that most people would be inclined to store the color data in the metatile (just as a general rule).

thefox: Just checked. In the case of my reduced mockup that is 274 metatiles it comes down to being 247 if colourdata was stored separately. And that imo is worth it, because I am not using some of the possible metatiles in the 274 one, so what you could do would amount to a lot more. For example the rocks look cool in all of the 3 monochrome palettes I am using, but I don't use all of those possible tiles.

Bunch of faces, each face uses 4 tile palettes of its own. Will do more until I reach 16 faces.

Awesome stuff as always, ptoing! I love how bold the attribute borders are in the more organic characters. It's not something I'd ever be able to do, but you pulled it off quite nicely.

Very impressive! Much more colorful than anyone would expect from an NES!

These are majestic, dude. Instant fan of what you've got right here.

You've done an awesome job at dodging the attribute borders (I particularly like what you did with the bat ears)

However, the third face over and one down looks a little... questionable...

Who? Dickface?

Yeah...

Any worse than the Ballchinians from Men In Black II?

You should have seen earlier iterations of him, without the hat.

A head on a head?

Damn, you're good!

Thanks

More or less final version.

Just thinking though, where will these be used? I'm just wondering because you said they take up 4 palettes, but no sprites.

They will be used nowhere, I have been making these kinda face collections using various restrictions, such as EGA, CGA, MSX among others, just for fun.

But it would be quite easy to have a rastersplit below them and use them as some kind of shop/conversation portraits in a game scenario. On top of that the palettes could be optimised so that there are only 3 or even just 2 for some of them, and then you could use that for stuff right next to them, like some item stuff for a shop or what have you.