Looking for issues with scrolling

Mugi

Member
d69cxml-140aff70-4c7f-4a2a-9eae-c472a04e724c.png
 

dale_coop

Moderator
Staff member
Awesome, jorotroid! Thank you for sharing your progress <3


PS: do you want I moved the topic to another more accessible category?
 

jorotroid

Member
dale_coop said:
Awesome, jorotroid! Thank you for sharing your progress <3


PS: do you want I moved the topic to another more accessible category?

That's ok. I'll just make a new topic in the modules section when I'm done.

I'm so close...
 

jorotroid

Member
Alright. Well objects turned out to have their own set of issues. Over a week worth of issues. But I think I got it. I think it's done... for a beta release. There are probably all sorts of things I haven't accounted for yet, but I've done everything to get the basics of what I wanted. But with a week left of the competition and everybody probably committed to what they are already doing, I'm wondering if it would be better to just wait till after the competition to share it. As I now (finally) switch back to Witch City to port it over to my new core, I may discover more things that I need to address with this core. What do you guys think?
 

AllDarnDavey

Active member
jorotroid said:
I'm wondering if it would be better to just wait till after the competition to share it. As I now (finally) switch back to Witch City to port it over to my new core, I may discover more things that I need to address with this core. What do you guys think?

Can't speak for everyone, but having seen these posts and hoping to use your work for my project. I'm now pretty committed to one way scrolling, at least until some time after the competition. I'd rather you release it when you think it's good enough to distribute, then have you push something out before you normally would.

Plus, you're going to get a lot of feedback when you do release it, and I'd rather you not feel pressured to manically try to fix issues if someone decides to switch this last minute.
 

Mugi

Member
jorotroid said:
But with a week left of the competition and everybody probably committed to what they are already doing, I'm wondering if it would be better to just wait till after the competition to share it. As I now (finally) switch back to Witch City to port it over to my new core, I may discover more things that I need to address with this core. What do you guys think?

I'm down with whatever you decide to do with it.
That said, If you wish, I'm down for trying to implement it now, my game was designed for 2-way scrolling to begin with and the current demo suffers a lot from the lack of it in the level designs et cetera. The compo demo
has it's levels altered specifically for that, and frankly, they're not up there where they should be.
 

dale_coop

Moderator
Staff member
Great news, jorotroid.... my composure entry game don't need scrolling but I will surely use it in the future ;)
 

jorotroid

Member
Alright, how about this? I'll go a head and post it in this thread for now as a sort of soft launch. Then after the competition, I'll make a new thread in the modules section for all to see and easily access.
For that actual release, I probably still need to do some quality of life stuff to the module, like update some Project Labels. I might also make gravity the default on a screen, and you would have to set the flag to turn off gravity since this module has platformers more so in mind.

Anyway, to install, I think all you have to do is put the Joros_Scroll_Core folder in the Routines folder, and the .MOD file in the modules folder. Then you should be able to select the module as you would with any other when starting a new project.

https://drive.google.com/open?id=1eT5cPFcC4OOGbCnhHZvFCuUIrnw4y8Qi
 

Mugi

Member
I will definitely take a peek, though im so pressed with time now that the compo entry will propably have to scroll along with the scribble i currently have parsed together from existing one-way engine. Its doing its job despite being some lightyears behind the polish yours has (object displacement etc is still a thing) i take it yours is still missing the autoscroll function?

If all else fails, that would more or less break my game beyond measure atm :p
 

jorotroid

Member
Oh, right. I probably should explain how it to use it a bit.

Screens start off assuming you want scrolling. For simplicity, I'll be referring to screens as the the screens you set up in NESmaker, and I'll use the term rooms for a group of uninterrupted screen. You just have to set flags to say weather you want a room to stop scrolling by setting the end rooms's flags for right or left. If you want a single screen room, set both flags (the single screen flag does nothing, I need to remove it).
As I mentioned before, I had to remove auto scroll, but theoretically you could set an invisible object as the camera object and have the object move automatically in some direction. I say theoretically because I haven't tested this yet, and it's probably pretty likely that in some places in the code the camera is still specifically looking for the player object.
You should be able to set the screen camera pads even narrower if you want them to be.
There might be some places that it would not be a good idea to place a transition to a screen up or down, I need to double check that.
Paths work expect for between screen edges.
I recommend setting monsters to screen extend for now. When the monster hits the edge of the screen, it essentially goes to sleep. and will reawaken when you come back to it.
Also enemies won't respawn if they have already spawned, and then you scroll back to their spawn location. They will respawn if you leave a room and come back to it.
Enemies and objects in general are probably the first thing that will need further refinement with core. Expect things to not work how you want them to.

I'm probably forgetting something important.
 

dale_coop

Moderator
Staff member
Ok, I am so curious and looks so interesting... That I might be taking a small break and try your scrolling module for fun today ;)
Thanks jorotroid.
 

jorotroid

Member
So I just noticed a fairly sizable bug as I've started to port over Witch City. So while making the core I put the player's movement speed way up to about 100 so I could get around faster to see if everything was loading properly. Now that I'm back to Witch City, I put the player's speed back down to normal and this cause some problems. First of all it make the scrolling sort of jittery. And second, if you scroll left the screen can't seem to keep up with the player. I suspect that for some reason the camera is not getting update every frame. I feel pretty good I can track this bug down, but it is harder to figure out why something isn't happening than it is to figure why something is happening.
 

drexegar

Member
jorotroid said:
So I just noticed a fairly sizable bug as I've started to port over Witch City. So while making the core I put the player's movement speed way up to about 100 so I could get around faster to see if everything was loading properly. Now that I'm back to Witch City, I put the player's speed back down to normal and this cause some problems. First of all it make the scrolling sort of jittery. And second, if you scroll left the screen can't seem to keep up with the player. I suspect that for some reason the camera is not getting update every frame. I feel pretty good I can track this bug down, but it is harder to figure out why something isn't happening than it is to figure why something is happening.

Whoa I didn't know this existed, I just been using the normal scroll on the nezumi game, I realized when too many cycles are used up the scrolling will mess up (I can't use constant pallete swapping during scrolling), other times when I using big sprites for cutscene, the next scene is messed up to (STAGE 3 title card becomes E 3 lol).

Should I wait till you officially post the scrolling core? or is the current one pretty good to use?

and Congratulations on upgrading Witch City!
 

jorotroid

Member
Thanks.

I would maybe wait for me to to do some fixes. I noticed a few more things that really need to be fixed while porting over Witch City. I also noticed a lot of slow down when shooting boomerangs in Witch City. I don't think that has to do with the scrolling code, but i want to make sure I'm not giving people a super inefficient core. And even when I do release it, consider it as a beta version. There will still be a lot to figure out in the way of how the core should function best for everyone in general.
 

jorotroid

Member
Ok, so a small update. Here is a new version with some fixes and (I think improvements). I fixed the jitter at low speed as well as the camera can keep up with player as were issues I mentioned in an earlier post. I also swapped the functionality of the screen gravity flag. This means that screen assume gravity and if you don't want it, you'll have to turn on the flag. Another change is that I freed up the second collision table for use for other things like saving (saving not included). If you do use that memory for saving, just be sure that you don't use that memory for anything that would cause problems if that data were to go away while saving. I moved many of the variables related to scrolling into this space because I figure that it's unlikely that people would want to save while scrolling.

It's been a little slow going with continuing this after the byte-off due to life, wanting to work on my game, and maybe a little bit of burn out from the byte off; but I am still picking away at this. One issue that this core still has is that if you put the player's max speed up too high, it will glitch out the scrolling tile draws. That's what I am working on fixing now. I have written an new NMI update (not yet implemented) that I think should be able to handle updating around 64 tiles in one frame. The current scrolling engines only do 16 per frame. If successful, this should start paving the way for doing a multidirectional scroll version of this core. It could also mean you could have a player character that can move 16 pixels per frame, but I later figured out that the max speed in NESmaker equals about 8 pixels per frame. So if anyone wants such a fast moving character, that's something I might be able to look into.

Here is the new link. Once again, copy the MOD file into the modules folder. And the core folder into the GameEngineData\Routines folder. After that you should be able to choose the core just like any other module.
https://drive.google.com/file/d/1wF7HAVU1zCHkgYqvTbCjrDWKfblusIo6/view?usp=sharing
 

Mugi

Member
jorotroid said:
One issue that this core still has is that if you put the player's max speed up too high, it will glitch out the scrolling tile draws. That's what I am working on fixing now. I have written an new NMI update (not yet implemented) that I think should be able to handle updating around 64 tiles in one frame. The current scrolling engines only do 16 per frame.

ah yes, i remember this part...

it took a moment to get it to do this.
https://www.youtube.com/watch?v=ioaTJF_9iY8

you're doing awesome job with this!

just out of curiosity, did you come up with a sane solution to the monster behavior regarding the scroll ?
 

jorotroid

Member
mongolianmisfit said:
Awesome update! I'll give this a go tomorrow after I get off work and chime in with how it's rolling. :)
Thanks, jorotroid.

You're welcome. I hope it works for you still so much to do and not enough time to do it in. Plus there are some many shiny distractions.

Mugi said:
jorotroid said:
One issue that this core still has is that if you put the player's max speed up too high, it will glitch out the scrolling tile draws. That's what I am working on fixing now. I have written an new NMI update (not yet implemented) that I think should be able to handle updating around 64 tiles in one frame. The current scrolling engines only do 16 per frame.

ah yes, i remember this part...

it took a moment to get it to do this.
https://www.youtube.com/watch?v=ioaTJF_9iY8

you're doing awesome job with this!

just out of curiosity, did you come up with a sane solution to the monster behavior regarding the scroll ?

Haha, yeah. I figure that if NESmaker allows for such a high speed, I should be able to support it.

As for the monster behavior stuff... it's always on my mind. What it does now is it keeps track of up to 16 screens on whether or not a monster has already been spawned. If it has, then the monster can't spawn if you go scroll to that screen. This buffer that keeps track of spawns gets reset everytime you load a new screen instead of scrolling into one. The idea is if you're making a metroidvania, that monsters wouldn't be able to respawn while you are in a room, but if you exit and leave a room, then the monsters would be able to respawn again. Also I've made an edge behavior option that puts an object to "sleep" so that it still exists in memory, but does not update until it is in view of the camera again. I'm thinking I should consider making sleeping objects deactivate if they get some number of screens away from the camera. Alternatively, since I freed up a page of ram, maybe I can use that memory to store minimal data about a sleeping monster, deactivate that instance, and then if the camera returns to that location create a new monster with that minimally stored data. One thing I worry about is making sure that certain objects like a power up item pick up can never be destroyed no matter how many screens you scroll away from it. That's why I over killed by tracking spawning for 16 screens. I'm definitely open to suggestions on how off screen objects should act.

Oh, I also have some glitches when enemies come back on screen sometimes. Usually it happens when an enemy goes off screen while you are scrolling away from it and it's about to hit a solid tile. When it comes back on screen, there is a chance it will be partially stuck in the tile. I've tried to correct this by snapping the enemy to the grid when it comes back on screen. It helps, but I still sometimes get the issue. Also not completely a glitch, but it feels glitchy: the eyeball enemies in Witch City move pretty fast. Fast than the player, so when they run off screen and you catch up to then, they will immediately run off screen again. So I might figure a way to force an object to change directions towards the player when they reenter the camera view.

I get the feeling there won't be a perfect solution for everyone on how to handle offscreen objects. How are things going for you with regards to that?
 

Mugi

Member
well, with the whole deal of having a pretty nasty fight with collision detection and the whole deal with how to manage the "screen clipping" with diagonal scrolling ,we havent really put much though into it, although like you, it always haunts the back of my mind.

im not really that picky about having a large buffer in DS to track if the monsters have been killed or not, but one idea originally was to use the scroll buffer as an area to track whether or not they'd respawn.
that then got thrown out of the window by the fact that the current scroll only loads one column ahead due to how intense the row loading is for resources... so..... it's sorta back at square one at this point.
the current build has no monster handling at all so they cant even be loaded, but once that's solved, i'll propably just resort to the whole destoryMe edge reaction until we come up with some form of sane solution...

it's propably going to be one of the most terrifying parts of this rewrite.

edit: speaking od 4way scrolling on that matter, as you propably already noticed we kept vertical mirroring so it will cause vertical scroll artifacts.
did you plan to switch over to 4screen mirroring for your core ?
 
Top Bottom