Sideview smooth scrolling prototype.

[blue_knight]

For my AOL quest I was experimenting with smooth side-view scrolling (Left/Right only like AOL). Anyway here is a quest (unpassworded) with my current experiments. I used the default Zelda1 tileset with some small imports, rather then my AOL tileset since I'm not ready to release that yet (its a mess :). I have to get collisions working with ffcs so I can do steps, ledges and all that, I need to get enemies working properly and fix some minor artifacts. I just wanted to get opinions before working on it too long: Is it cool or am I just trying to push ZC in directions I shouldn't be? Would you like to see a quest with smooth scrolling/sideview sections similar to AOL, probably allowing screens about as big as 3-4 screenwidths?

This requires beta 15.

http://www.filefactory.com/file/f1c185/

[C-Dawg]

Is it cool or am I just trying to push ZC in directions I shouldn't be?

This must be the Zelda Classic version of the "I had sex" thread. You know, the one where someone posts a long pointless story, the only purpose of which is to communicate to the internet that the poster has succeeded in having sex.

That being said, this script idea is pretty bad ass. I suppose you did, indeed, have sex, blue_knight.

[blue_knight]

Thanks (I think). It was more a question of whether people thought the effort of setting up the sideview scrolling screens was worth the result. While I'm currently planning on pursuing this, it is a good amount of work (and tilespace) to setup the screens. Also I wanted to give people ideas of how to get scrolling to work in a limited but controllable way.
Anyway thanks for the response :)

[jman2050]

I suppose if we ever get layer offsets working this would take up a lot less tilespace. Don't know if that'll get into ZC 2.5 though.

[blue_knight]

Actually if ffcs could be bigger than 4x4 and if ffcs could scroll off the screen more and just be culled from rendering rather then disappearing then it would be alot easier. In addition there should be some way to detect that an NPC has died, I can check the number of NPCs but that doesn't tell me which one died, if I'm controlling their motions similar to Link and the ffcs. But once I figure out the enemy problem (and fix collisions with ffcs), using this for an AOL quest should be doable, the screens are simple enough I think. So the sideview areas will scroll but the overworld will still be screens.

Edit - actually I should be able to do a Screen->GetNPC(x) [or whatever its called] and compare pointers to tell if something has died. Of course I'd only do that when GetNumNPCS() changes. So that should fix the enemy problem :)

[Master_of_Power]

Feakin awesome! You win! FOR SURE!

[C-Dawg]

Edit - actually I should be able to do a Screen->GetNPC(x) [or whatever its called] and compare pointers to tell if something has died. Of course I'd only do that when GetNumNPCS() changes. So that should fix the enemy problem :)

Careful. If you use Screen->LoadNPC(x) when there is no enemy on the screen, you'll crash ZQuest.

[blue_knight]

That is why I have to check GetNumNPCs() first and just consider all npcs dead if it is 0. Thanks for the tip though. Its too bad that a script can actually crash the program, maybe a handle based approach would have been useful. Or a pointer validation function: IsNPCPointerValid(npc) or something like that.
And yes I learned about the crashes the hard way :( before reading about it with your sideview demo quest / showcase.

[*b*]

Very cool. The bricks along the top and bottom animate funny when you stop or jump, but otherwise, it's very, VERY well done

Hint hint, jman

[C-Dawg]

Scripting - The best thing to happen to over-worked devs since ... ever.

Now that the community can take care of the new features, you boys get all the bugs fixed.

[blue_knight]

I agree 100%. We just need a few small features here and there to make scripting and ffcs more robust (like larger then 4x4 ffcs, the ability to move them more offscreen, text from scripts [this is coming already], etc).

[blue_knight]

There is a new version of the script. It fixes the animation weirdness when stopping or jumping, allows for an arbitrary number of ffcs to be scrolled (you pass in the number) and has some glitchy support [which I'm going to fix] for both non-solid and solid scrolling ffcs in the same room. This will allow people to make platforms, walls, ledges, etc. You also pass in the combo for the floor and ceiling (which can be different). Also the script is cleaned up and is actually shorter now :)

**Please note the file name is now scroll_test2.qst, if you see the old glitch with the ground and ceiling then you're running the wrong verson :) **

Next up is fixing the collisions and getting enemies to work properly.
And if anyone's interested when this one is finished I can make a verticle scrolling version too. This would be great for Metroid 1 style quests where you can have left/right scrolling OR verticle scrolling

http://www.filefactory.com/file/f1c185/

[jman2050]

I won't reveal how, but in beta 16 I'm pretty sure with some clever thinking you'll be able to take care of the sidescrolling part of the quest using a mere single FFC script, or heck, even a global script. How? You'll see :)

[blue_knight]

Will this technique be able to handle collision detection and enemies? If so then cool, maybe I should just wait for Beta16. No chance of you telling me when its coming out right? And just out of curiousity, not that it really matters, did my script inspire a new feature or was it a planned feature that was being kept under wraps?
Anyway, how did the scrolling work for you, was it seamless?

Thanks for the info, I look forward to B16.

[C-Dawg]

I sincerely hope Jman is talking about true solidity on FFCs, including pushing npcs and pcs out of the way. That'd be really handy.

[jman2050]

unfortunately, no :(

[blue_knight]

I was going to wait before working on this more until I got the new DrawCombo/Tile stuff working. But since I have to wait I decided to work on some things. Anyway there is an update with fixed collision detection and some minor obstacles that you can collide with and jump on top of. The previous download links have been updated, it'll be Scroll_test2.qst. Only tested with b16.
The jump needs some work, especially figuring out why the animations look so weird, its a custom jump as part of the script. With the new DrawCombo/Tile stuff these screens will become easier to make and be more populated and shouldn't have all graphics on screen for the first frame (hopefully).
Anyway let me know what you think.