Berserk (NES) mockup

[kullenberg]

Here is a quick overpaint of the tree, might give you an idea or two:

[Kasumi]

Scary questions abound. Maybe one day I'll make some actual pixel edits...

My new version below I counted in at 52 sprites, which is a lot, but it's not too much, right? ;] I want it to fit the restrictions, but will push the limits whenever possible.

My sole question is... do you push the limits to the epic cartridge (MMC5) only a few games used? With its 8x8 region background palettes instead of 16x16, its hardware multiply, and its ability to draw from 16384 tiles at the same time? (Also extra audio and a bunch of stuff... it's kind of a monster.) It's why NES restrictions questions are so tough. There's what NES can do on its own, and then there's what MMC5 can do. And then there's what a bunch of less terrifyingly powerful boards can do which are somewhere in the middle.

I digress. 52 sprites isn't really bad for the whole scene. Depending on how many animation frames you want for each character, those unique sprite tiles could begin to add up in ROM space, though. Assume without MMC5 that you've got 256 KB for all graphics (sprites and backgrounds) in the game. 256 tiles is 4 KB. There's always more to it, but it's not really worth being concerned until a game is actually being made.

However, I must admit defeat on the 8 sprites per scanline rule. This one hits hard and I don't know any way out of it, I know I basically can't with the way they are posed. Can you tell me about any magic that might would make me feel any better about this?

Nope. Flickering is all you get, 8 sprites per scanline is a limitation even MMC5 can't beat. You could draw one of the characters using the background, but then you can't really have an actual background. Depending on how iconic his fighting stance is, the really easy thing to do is just have him hold his sword at a 45ish degree angle. Then all the sprites of his sword won't be occupying mostly the same scanlines even disregarding whether or not there are overlays.

I would intend to have mutliple enemy portraits that would show in a similar fashion. Would this mean that all of them would have to be on every tileset? Only Griffith would appear on this background, but many different enemies would appear on multiple different backgrounds.

If you are using tile ROM, the answer is yes. Any time a portrait needs to appear over a background, it needs to be stored with that background. Because the background and the portraits occupy the same scanlines in your mockup. (Unless you're using MMC5, which is often the exception to, "You can't do that.")

You wouldn't need to store the portraits multiple times if the game were using tile RAM. Every portrait could appear with every background with no redundant tiles, even. BUT, if you did that you would have to be much more careful about using ONLY 256 tiles for the entire screen. (I don't know a cartridge offhand that gives you both tile RAM, and the ability to swap out tilesets on a specific scanline. I guess it's a thing that could be built if it doesn't exist, though. )

You mentioned that variable width fonts are possible, how would that be done?

The NES in general doesn't care if it's accessing ROM or RAM. ROM is obviously ROM and can't be written to. RAM can be edited, so you could generate and edit tiles on the fly (with many caveats).

Here are some tiles from Tetris (4X for clarity):

Nintendo decided that for their copyright notice that would look nicer, so they used the extra six tiles despite there also being 26 letters+punctuation+number tiles in that same set. Tetris' tile data is ROM, but if one used tile RAM, one could generate tiles like "Nintendo" above at runtime. Essentially you load the letters from CPU ROM, mash them together and write the result to tile RAM which is then displayed. It's not easy to program, not many commercial games did it, and there are other caveats too. But it's doable. See RHDE. Some translation patches have actually done a simpler thing where common sets of letters that look bad monospaced just have their own tile. <ll>, <. >, <'t>, <'d> or things like that. RHDE straight up generates everything, which is hardcore.

More specific to your case, assume you have a single row dedicated to pre battle trash talk. (which is actually not quite the case right now, but it makes the example easier.) That's 32 tiles across. It's a good idea to not draw things on the leftmost/rightmost pixels either. (Err... I just realized that sort of affects a lot of your mockup as well >_>. That's the thing about non handheld consoles. Television Safe Area) So 30 tiles. When you draw the screen, you'd draw that row with blank tile, tiles226-255, blank tile.

You then draw C to tile 226 one frame. You draw a single pixel of A to tile 226, and the rest of the A to tile 227 on the next frame. You draw half of N to tile 227, and the other half to tile 228 on the next frame. And you continue like that. Because you are editing tiles that are already being used to draw the background, they'll appear. For a single row, it's even better that storing the alphabet and looks nicer. 30 unique tiles reserved for variable width font row, vs 26+?!.,'etc.

I also wanted to ask you about the 8x16 sprites. Could they be of any use here or no? I read your description of them in the restrictions guide, but it soared right over my little head.

I basically never recommend 8x16 sprites. That sword is not even a full tile tall. Using 8x16 sprites would ensure that every part of it is now two tiles tall, making even parts of it that would be fully transparent eat into the 8 sprites per scanline limit of things below it. (or above it.) As well, you'd have a significant amount of redundant fully transparent tiles eating up space in your set.


On the top are the tiles you'd have to use in your set of 256 to display the sword parts I removed. Note the 3 totally blank tiles. All those orange and green pixels represent space the sword sprites might occupy in regards to the 8 sprites per scanline limit.

If you hit the 64 sprite limit they can be worth looking into, but they tend to use more tiles in the set to display the same thing as in 8x8 mode. The other benefit of 8x16 mode is they can use less CPU time to draw the same scene. (Half as many "Is this sprite offscreen?" checks, provided all the space is actually occupied.) Hitting the 64 sprite limit isn't necessarily the end of the world anyway, you could "flicker" which sprites are displayed in the 64, the same way you could as if you hit the scanline limitation. (Though it's much harder to reasonably do.)

Admittedly the 8x16 sprite explanation in the post is lacking, but it's really not simple. At some point I want to make an interactive ROM that people can play around with to see the limitations, but it's very low priority.

Of course the dream would be to have a little playable demo on the actual hardware.

[Ryumaru]

Kullenburg: Thanks! That definitely shows it's form off a lot more. I will probably try to make a version similar to that, that doesn't use too many tiles.




Kasumi: I think to be safe, I push the limits of of the standard, non epic cartridges. The 16x16 region is a unique restriction that I would like to learn to work under, rather than throw in the towel and go for the epic.

That seems like it would be enough. There would probably only be a few different enemy types and a boss or two. But yes, let us not get ahead of ourselves there x]

Man, I really thought you could help me out on that one. His stance is pretty is pretty iconic for the scene. Maybe during the cutscene only he would be a combination of background and sprite, and then during battle he could change to all sprite with a better positioned sword? Or this could just be a net presentation version and I alter the sword angle for the sprite in the " real" version.

I was actually going to ask you if you had an easy to use tile counter for images like this? I also would like to make things fit in the 256 tile limit ( I would probably make a version with  text done the easy way to run through it). If I can get the screen to be 256 or less always, then the handling of the portraits would be much easier.

I made a more Television Safe version, the sides aren't too much of a problem. Please don't make me move anything else though  The health and stamina bars going off screen don't matter too much as you would still have the numerical readings easily in sight.



I wasn't so much asking for the sword alone using 8x16 sprites, but rather the characters themselves. But it does sound very complex and other than the scanline limit, amount of sprites is not currently a problem, nor would it be the way I would intend things.

From doing a lot of GBC mockups, I've always wondered how sprites and tiles work. Are they essentially the same except sprites are transparent? Or are there any interesting differences/ limitation that one can do and not the other? Also related, I've seen some games actually utilizing a screenshake effect. How is that done exactly? If I remember correctly, i've seen it done two ways, where the sprites stay still, or also move along with the screen, but I may be  making that up in my head.

I don't know if that wink is just the standard " isn't it always" wink, or an invitation, but if you might happen to know a berserk fan/ NES programmer, you should definitely link them this thread

Thanks again for chiming in. I plan to make a boss encounter scene which should be chock full of issues as well.

[Probo]

Cool mockup man, love the mountains and the colour.

quick edit of your guts icon



i removed detail in the nose, gave him a more robust jawline and made his eyes a bit angrier, amongst other little tweaks

i dont watch/read beserk so i dont know the character very well and my edit might be bad, but to me thats closer to the dude in the google image search i did

[Kasumi]

I made a more Television Safe version, the sides aren't too much of a problem. Please don't make me move anything else though 

Remember the palette regions are 16x16 not 8x8. It's possible to have your portraits arranged like that by offsetting the scroll 8 pixels to the left. But that also affects the palette boundaries of everything sharing those scanlines.

It would, as an example, break something like your sword up top which uses two different different palettes for each half. If the boundaries were shifted 8 pixels, the same palette area would then affect both halves... Now, that part of the sword is above the portraits, so you could change the scroll on the scanline the first portrait begins, and change it again after. You'd still have to make sure the each piece of the scene that shares scanlines with the portraits obeys the shifted palette boundaries. Ain't NES fun?

I was actually going to ask you if you had an easy to use tile counter for images like this?

For Single Screen mockups, NES Screen Tool will get you there. It can import indexed BMPs and create tiles out of them. However, it expects them to already have their indexed palette arranged in a specific way. Basically a 16 color palette with each 4 colors representing one set of colors an area could be. If the same color (besides the universal one) exists in multiple palettes, this can be tricky to work with. It also can't be trained to recognize cute things like offsetting the palette boundaries for X scanlines.

Pyxel Edit can also get you a fairly decent count with much less work, but if you happen to have tiles that are the same except for their palette, it won't detect that. (And the free version will merge tiles that are mirrors of each other.)

That fact that NES has 16x16 palette boundaries with 8x8 tiles means most tools won't really give you what you want with it... I feel like I've seen a post here with a script for Pro Motion that forces the tilemap to be palette proper, and the program already has actual tiling support. But I can never find that post. My current workflow is mostly Pyxel Edit. When I get close to the tile limit, I convert everything to four colors and have Pyxel Edit remove duplicates to see how many I really have left.

Are they essentially the same except sprites are transparent?

For the NES, they're nearly exactly the same. You know that whole shared color thing? Imagine the screen filled with a color. If you don't draw anything on top of it, the color is never changed.

So when you're drawing tiles, you're really still getting three colors+transparent. It just so happens that transparent ends up being the shared color, because that's the color the screen is filled with before the background itself is drawn. 

Or are there any interesting differences/ limitation that one can do and not the other?

The tiles themselves are stored exactly the same, and you can actually use the same 256 tile tileset to draw both the background and display the sprites if you wanted. Sprites can be flipped, placed arbitrarily, colored individually but there are only 64 of them. You can fill the screen with tiles, but they're aligned to a grid. Nothing more to it, really.

Also related, I've seen some games actually utilizing a screenshake effect. How is that done exactly? If I remember correctly, i've seen it done two ways, where the sprites stay still, or also move along with the screen, but I may be  making that up in my head.

Sprites have zero knowledge of the background's position. You can offset the position of the background map, and the sprites won't move at all unless you add logic for them to as well. You can offset the positions of all the sprites and the background won't move at all unless you add logic for it to move. No tricks to this one. You'd move the background for a screen shake the same way you would to scroll, you'd move the sprites the same way you would to move them any other way. If you think it looks best for sprites to move a few frames after the background shakes, you can do that. If you think it looks best for them to move opposite to the background's direction you can do that. And if you think it looks best for every sprite to move in a different direction you can do that.

I don't know if that wink is just the standard " isn't it always" wink, or an invitation, but if you might happen to know a berserk fan/ NES programmer, you should definitely link them this thread

It was a, "This photo is halfway done." wink.

Forgive the dusty TV.   I'm capable of doing it, but not for free, heh. I think that's the case with most of the programmers who do this, since it's certainly not easy. For what it's worth, that's 251 tiles without the text or the icons below. The text and stuff doesn't make the scene impossible, but I wasn't about to write scanline tileset swapping just for this.

Hopefully you can see what I mean about the top getting cropped, the top of the sword is straight up gone. The left and right seem to have not lost much at all, but it does also depend on the TV. No sprites, because I don't have a way to do that even slightly automatically. I used the old version because there are no spriteless new versions, and I don't have a way to do sprites even slightly automatically. The sword is also very slightly messed up (the issue I mentioned where the same color in multiple palettes can be hard to work around with the tools I use. NES handles it fine).

One more wall of text completed.

[Ryumaru]

Probo: Hey, thanks! Your edit would be perfect for the older version of him, but he's actually relatively young in this scene. Me and Cyan were talking about it a bit back. Not only does his face change as he ages, but the creator takes so much time off inbetween chapters, that his style changes as well! Either way I like how you minimized the scar a bit, will have to put that in.

Kasumi: AH I FORGOT. I should've known it wouldn't be that easy. Regardless, The new version should fit the rule, I don't mind the artifact-y nature of the new border.

Oh man, that is the best kind of wink ever. Seriously thanks for doing that, too cool!It feels so official on that dusty TV ;]

251 tiles is much more than I hoped. I might get around to redoing the background with more clever tiling.

It's crazy how much it takes off the top and bottom, I'm probably cutting it at the bare minimum with the single tile clearance, but that's ok with me, as long as the names can be read.

Here's the latest version, without sprites ( wink)



And here's where I'm at with the boss encounter. The idea would be that you would have a special option to hide behind the foreground pillar to get a chance to see how his moves work. He would strike it, and deal damage to it ( taking 2-3 hits to break) and then you would be left to battle him on your own. I honestly have no idea how I would go about justifying the boss. He would almost have to be a combination of tiles and sprites, and it would be about trying to reuse as many 8x8 assetts as possible while still maintaining an organic look.



This is the encounter that the battle is meant to replicate:

Spoiler