Maybe if you exchange the position of the left window (the one which is visible, not the one which is suggested) and the chain it would look better, because it really look like the left window is at 45° angle from the viewer, which is strange since it's just next to the central window which is parallel to the viewer.

(That's what I tried to say before but I probably wasn't clear...)

I agree -- the window angle suggests a stronger curve of the outer wall than would make sense. Moving it left would make the whole thing work better.

I find it slightly easier to show the scrolling concept than try to elaborate it in words, but i'll attempt both.

But basically this tower would force-stop a horizontal scroll quite early in both directions. There would be no vertical scroll in this particular case (even if it is a vertical climb. It means each screen is presented instantaneously just like in a non-scrolling game. I think that's a nice thing to diversify the experience the camera provides, as opposed to NES metroid for example where a vertical shaft will always have vertical scroll and so on - no surprises there- CV3, by comparison, has a number of perceived camera modes: upwards ratchet, downwards ratchet, auto-scrolling, coarse scrolling.. helps diversify the various towers. Scrolling/non-scrolling in the general direction the player is heading would be the simplest form of diversification and i think that's a good start to present different challenges tied to either condition).

Besides, this cross-section:ed concave form doesn't lend itself to vertical scrolling, because it's concave in two dimensions. It'd have to one-dimensional for it to work together OK with scrolling along the length of the tower.

In a real game situation, i'd like to think that the camera would "want" to be at the center but you would be able to drag it out to the side/s by moving close to the wall, sort of like pulling away a magnet.

Those are my thoughts at least.

This mock-upped visualization contains a few demonstrations:-Tile selection-based parallax (eats a considerable portion of the chr table. Animates tiles by pointing to left/right shifted tiles that are pre-rendered and kept in the table, Pushes in the opposite direction of the scroll to maintain a fixed position.)-Some sort of foreground object in the form of a backlighted chain (i don't feel too sure if it's look is final - it might need a bit of polish and maybe another shade of blue/bluish).-Trying out some semi-independent movement of the same.

How does it all fare?

Oh, and i reworked the windows so the left one isn't at such an extreme angle. I saved the 45-degree one for reuse in some similar screen so the level design can play around a bit with components like windows an chains and not always keep them identical, screen for screen.

celius wrote:

EDIT: Woops, missed the part where you said this was more "doodling".

Maybe doodling is the wrong word, idk - I almost always have a goal of some sort when drawing, but basically i've found this setting to be unusually relaxing and recreational to draw. At times it's almost like being 9 years old and draw faux stages to some favourite game.

Sumez: Well i'm pretty sure you can make stuff i can't (like that avatar you have), so maybe that's even? Btw i tried to search for graphics you had done, but couldn't find any OP in this subforum. Do you have a blog or something?

Diskover: I'm sorry i forgot to reply - thanks for the demonstration! I'll certainly consider it. For one thing, it's a good effect to simulate clouds of the low-hanging, dense type floating by; affecting the overall ambience. It might also work as a nice (maybe somewhat quicker) fade-in, which would be a bit more subtle, i think. Btw, what tool do you use to mockup those palette shifts?

That parallax scrolling looks great but it looks like it will "eat" a lot of sprites. If the background was just made of horizontal lines, it would need no sprites, but then you can use sprites only for example for the trees, and leave the sky only with horizontal lines.

Having the left wall not purely vertical-shaped also requires more sprites, so does that chain. So as long as all those objects (trees, chain, non-perfectly-aligned-left-wall) are not on the same scanline, it's fine to have them, so that the effect overall just takes one sprite per line. Incredibly clever

PS: Since that chain is a sprite, you could also made it swing one or two pixels, just because.

That parallax scrolling looks great but it looks like it will "eat" a lot of sprites.

I was hoping to have a technical discussion on that matter. The way i planned it, it would not eat any sprites at all, because it's not "true" parallax. For the lack of a better term, i'd call it "tile select animation" or maybe "tile select parallax".

What you have there (or rather a mockup of) is a background tile animation. Basically, something like a third of the the whole chr file used for this scene is filled with left/right shifted variations of the same few treeline tiles. That's what i meant by "brute-forcing it".

The map would have a property that made certain areas' tile ID:s an index, and then while scrolling, they would shift to a another tile to make it seem like the far-field background is still, when in reality, it is not: It's just animated at the same pace as the scrolling to counteract it.

That solves the problem with the windows' indentation, too.

That would never fly back in the day, but since it's no financial problem to have a 512kB cart these days, one could afford the extravagance.

It would also only work because you cannot scroll longer than two tiles away from the tower, and the tower itself is hiding the fact that the far-field background has a very short report; 2 tiles wide (in a virtual sense: 3 tiles, if you take the full contents of the tile select animation into consideration).

It never occured to me the sky gradient could be sprites, but regrettably, i don't think that's an option here because we'd need a sprite based HUD. On the bright side, tile-select fixating the gradient wouldn't require as many tile variations as the forest: Counting, i see 2 of them needs 2 tile variations to be kept still, and the 2 others need 4 tiles. so, 12 tiles in total is the price for a spriteless faux parallax sky gradient in this case. The price for the spriteless forest is more like ~80 tiles

And just to be clear from the start: There's no continous chr ram loading, since everything is stored in chr ram at the same time. It means i can't add too much extra/unique details into this scene beyond what i've already done. I'm a bit confined to just play with their placement from room to room.

--

Oh yeah, i was thinking the chain could perhaps dangle a bit in a pendulum like fashion; just maybe, if it isn't too much attention grabbing. It might be enough that it masks the player/an enemy and moves while scrolling. But if it did dangle, it would make sense for it in that case to left-right-move a bit link for link in inertia, if it can be pulled off along with all the rest of the stuff a real game would need to do.

Diskover wrote:

I made that show with Photoshop.

Same here. In PS, i would open a copy of the image, ensure the colour mode was indexed, then use the colour replacement dialogue. Then copy them to different layers in a new psd file, rince and repeat three times, and lastly animate the visibility of the layers using the timeline window. I'm asking because i have a feeling that's maybe not the best way to do it.

Well, having the side trees rendered multiple times and changing the tiles on the fly when scrolling makes sense, this avoids eating sprites. However I do not think having that dithering on the sky gradiant scroll makes sense, especially after applying NTSC filter. I don't think it should eat that many tiles, why do you mention a 512kB cart ?

I do not see how a sprite-based HUD is conflicting with it being a sprite, as long as it's never on the same scanlines.

Leaving the sky-gradiant dithering as it, but scrolling with the main background might work but it might be obvious it scrolls at the frontground's pace and look weird. So I really think the optimal would be to stick with horizontal lines. Wasting tiles to represent a scrolling dither pattern really doesn't make much sense.

Same here. In PS, i would open a copy of the image, ensure the colour mode was indexed, then use the colour replacement dialogue. Then copy them to different layers in a new psd file, rince and repeat three times, and lastly animate the visibility of the layers using the timeline window. I'm asking because i have a feeling that's maybe not the best way to do it.

You do not have a CHR? Everything you've done with Photoshop?

Well, then I'll try to recreate it. . .

The truth is that with the few colors that have the NES palette, this effect is difficult to do well.

That's the thing. Ideally i'd have the sprite HUD in the upper left corner of the overscan safe zone, so i don't want to cause too many sprite overflow conflicts there. The chain adds 1 per line, the player going up the stairs adds ~2...

Quote:

However I do not think having that dithering on the sky gradiant scroll makes sense, especially after applying NTSC filter.

Since they would appear as still, i didn't think it'd be a problem (ie if it was moving, we'd see dancing artifact colours)? But i should probably check how it looks on hardware sometime soon and verify this as good as i can (both my units are PAL).

Quote:

Leaving the sky-gradiant dithering as it, but scrolling with the main background might work but it might be obvious it scrolls at the frontground's pace and look weird. So I really think the optimal would be to stick with horizontal lines. Wasting tiles to represent a scrolling dither pattern really doesn't make much sense.

This got me confused (i hope i'm not missing something crucial?) I wonder how it can be obvious it scrolls at the backgrounds' pace? The tile animation should be able to completely prohibit the gradient from appearing as scrolling (even if it techically is).

An analogy might be in place: If you drive a car on a big treadmill, and the treads of the mill scroll backwards, and you drive forwards at the exact same speed, you remain in the same place in the eyes of anyone observing. That's what the tile animation should be able to do, towards the result as shown in the mock-up.

Quote:

I don't think it should eat that many tiles, why do you mention a 512kB cart

If the tree lines are using 80 tiles alone* in this tower section of a level, that's a trickle. In my previous mockup (the one with the castle and the low, flat stage), that scene alone is using up all 4kB:s, so it's a somewhat bigger trickle. Together (if they were strung together), they do not really make up a complete level of average actionvania length. So imagine many trickles adding up to a stream that makes up a level, and then add together a bunch of levels and you have a river wide of graphics and level data. Getting detailed and custom like this for a complete game would require those 512kB:s, and using 512kB prg-rom was mostly not in the budget of most historical NES games (128-256kB seems about average?).

*actually, it can maybe be made with some fewer than 80 tiles and still look roughly the same, because i just might be able to reuse some same tiles in different attribute cells. That's for another day to experiment with.

Thanks, i really appreciate that you've taken the time to discuss this.

Diskover wrote:

You do not have a CHR? Everything you've done with Photoshop?

No, that's not it. Everything is done in NESST, except the rendered camera movement and sprite layering of the chain, which is done in PS, in this case. Sometimes when i want to get fancy, i use AfterEffects instead, especially for sprite animation reviews.

I could never draw that thing as seen from scratch using PS - it's too far away from how the NES graphics are laid out, + NESST helps me keep track of my tile budget.

Sorry, i sometimes feel hesitant sharing the chr:s of works in progress because i don't want too many "incomplete" versions floating around. It's just me being a bit sensitive while in the process.

However I do not think having that dithering on the sky gradiant scroll makes sense, especially after applying NTSC filter.

Since they would appear as still, i didn't think it'd be a problem (ie if it was moving, we'd see dancing artifact colours)? But i should probably check how it looks on hardware sometime soon and verify this as good as i can (both my units are PAL).

It doesn't shimmer unless you move, yes, but that's not the only problem. The NTSC rendering has a repeating colour-error emphasis every 3rd pixel of a scanline, and then shifts diagonally one pixel each line. If you make a checkerboard dither, there will be a repeating diagonal wave of emphasis 6 pixels wide across that dither. (Whether this is visually acceptable is a judgement call, though.)

FrankenGraphics wrote:

Quote:

Leaving the sky-gradiant dithering as it, but scrolling with the main background might work but it might be obvious it scrolls at the frontground's pace and look weird. So I really think the optimal would be to stick with horizontal lines. Wasting tiles to represent a scrolling dither pattern really doesn't make much sense.

This got me confused (i hope i'm not missing something crucial?) I wonder how it can be obvious it scrolls at the backgrounds' pace? The tile animation should be able to completely prohibit the gradient from appearing as scrolling (even if it techically is).

I don't think anything is obvious but...

My initial assumption was that a tower level would have vertical scrolling (and thus vertical parallax). So I was surprised when you showed with that GIF that you meant to shift the parallax background only horizontally. Is this screen meant to be static vertically then? Your estimates for tile permuations sounded like you only meant for 1 dimension of parallax, not 2. (Incidentally, using sprites could make both feasible at once?)

The NTSC rendering has a repeating colour-error emphasis every 3rd pixel of a scanline

Would i be able to properly view how this looks on an AVS on a HDTV in Europe? I've been thinking about treating myself with one (to be able to play N.American releases properly, but also to be able to test things like these out).

But yeah, these two mockups are so-far pretty heavy on dither in places I think it just might be the style i want, but i may want to revise it if i find it godawful on HW.

Quote:

My initial assumption was that a tower level would have vertical scrolling (and thus vertical parallax). So I was surprised when you showed with that GIF that you meant to shift the parallax background only horizontally. Is this screen meant to be static vertically then?

Yes

I figured there's some merit to it being the other way around (not as a general rule for the game, but as a mode among others you can have in some level segment to vary the overall experience).

will provide very different opportunities to present platforming challenges, enemy behavior and so on. Think about Battle Kid 1/2 and how much the gameplay relies on a scene/screen being set up all at once for its platforming puzzles to work. It's also different from the church tower in Warakiya village in CV3, where the pit of death is constantly changing depending on your elevation because of the ratchet scroll, but in my mockup, pits of death are fixed-point.

Another reason i wanted this segment to scroll horizontally is because i'm thinking of ways the player could interact with the outside (i don't want to spoil how at this point).

<Digression>Another study case i find interesting is the clock tower of untimely death in CV3: You go up, and after defeating Grant DaNasty's monster form, you go back down. The scrolling mode is ratchet scrolling which herds the player character in the right direction. The part i find so interesting is that they change the direction of the ratchet, so first when you scale the tower, if you fall down, you fall to your death. But on the way down, you can take plenty of shortcuts by simply falling. Besides the obvious point that it lets you get back to the door, i think they made it this way so that the downhill travel would intentionally take a lot shorter time and feel different (which makes a lot of sense since the level is reused). The fact that Grant is faster, jumps longer, can control his trajectory while jumping/falling, and climb walls also plays part in the shortcut taking/quick backtracking, all while keeping it fresh.</Digression>

Of course, you can do some timing-based platforming puzzles in a vertically scrolling tower, too. Above mentioned clock tower in the digression, for example, has a few instances where the spawning of a medusa head is triggered based on player elevation (you set it off by a jump that forces the scroll upwards). The puzzle here is to sync the enemies' appearance nicely with the cycle of constantly spawning medusa heads to make life a bit easier while maneuvering through the building.

Quote:

Your estimates for tile permuations sounded like you only meant for 1 dimension of parallax, not 2. (Incidentally, using sprites could make both feasible at once?)

This is also correct, i intended it for one dimension. Plus the way i'm using different attributes in the forest horizon should prohibit vertical parallax... I'm having a hard time wrapping my head around how sprites would help with 2-minensional parallax, though?

Would i be able to properly view how this looks on an AVS on a HDTV in Europe?

I don't think so, since one of the main points of these new consoles is to generate video that's more friendly to modern TVs. If they even have composite video out, it's probably "cleaner" than the original, without the hacks that made the old video signal so peculiar.

Who is online

Users browsing this forum: No registered users and 1 guest

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot post attachments in this forum