Lttp scrolling screen style?

[lucas92]

Is that possible to make the screens scroll like in Lttp? Has anyone thought of this before?

[Joe123]

No.

[lucas92]

No for the second question?

Let's do it then! :p

[Joe123]

No for the first question, yes for the second one =P

I've thought about this, short of making the entire area be one screen, where everything is moved and created via ZScript it is impossible.

And doing that would just be ridiculous anyway.

[pkmnfrk]

Yeah, this is simply impossible in scripting, and not likely any time soon as an official feature. Really.

[C-Dawg]

Oh, it's not IMPOSSIBLE in scripting. You'd just be remaking the entire damn engine from scratch, that's all. And the slowdown would probably be monsterous.

But someone whipped up a scrolling thing with scripts awhile back, as I recall.

[pkmnfrk]

Where would you get the extra map data? As far as I know, you can't read combo data from other screens, and you would have to draw the whole 17x12 grid yourself (without any arrays).

I think it's impossible.

[MasterSwordUltima]

If I recall correctly, LTTP didn't have the entire map as one screen. It had clusters of maps connected via scrolling. For example, Hyrule Castle's exterior. You get to the southern area, and it stops scrolling and loads up the southern map [with Link's House].

[Jigglysaint]

That's right actually. The area doesn't nessicarily end at a scroll boarder. Dungeons are similar. In dungeons, one room can consist of 4 smaller rooms, 2 small rooms and a big room, or one big room. It still won't work in Zelda Classic, because one the one room = one screen engine. I suppose that with creative warping and animated combos, you could simulate scrolling. Autoscrolling simulation is possible, I know that. It just won't be as good as the real thing.

[C-Dawg]

Well, pkmfrk, you couldn't use the normal map system. That's why I said from scratch. You'd either have to come up with some way of encoding "map" data in integers without arrays (hahahahaha) or translate map data from other screens in some way.

Like, Map 2 could be a single scrolling screen. When the player moves in a direction, unless the player is at the edge of the scrolling area (keep track of it through artificial x and y coordinates) the game reads map data from screens on Map 2 and updates accordingly. Each push of a direction tells the game to go and get the appropriate tiles and draw them on the screen.

Like, say you're "virtually" on Map 2 screen 0,0. (Actually on an empty screen elsewhere). The script goes to Map 2, screen 0,0, reads the tiles, and draws them on the current screen. When the player presses left, it reads Map 2, screen 0,0, and the first collumn of Map 2, screen 1, 0, and draws the tiles on the screen with a little offset. See how that would work?

The big problem is that combos have to be locked into the 16x16 grid as is. So using this setup you could not use any of the innate combo types (or you could, but they'd act wierd).

So yea, totally possible. Just time consuming, processor hungry, and requires starting from scratch.