Battle Kid 2 - Releasing on 12/14

[Jeroen]

You can also do it zelda style. Whenever a player reaches a new screen. Stop. Turn off backround rendering. Upload new screen. Scroll. And turn it back on again.

[tepples]

The thing with [loading one screen ahead] is the new screen could conceivably be in ANY direction, left, right, up, or down. It'd be impossible to tell what way for sure the player is going to go.

Then how does Metroid Prime predict which door Samus is about to shoot to open? Try a heuristic:

1. Find to which screens it is possible to travel. For example, if there is no path up or no solid ground within a jump height of the top of a screen, don't consider loading up; if there is a solid wall to the left, don't consider loading left; if the entire floor is solid, don't consider loading down.
2. If the player is standing or above solid ground at the moment, demote down.
3. Promote the side closest to the player.
4. Promote the side that the player is facing.

I'm just putting in my 2 cents that even if you do keep the flip-change, freezing the screen to load when you mispredict is probably better to look at than blanking it. At least it gives the player some reference when jumping off the top and immediately falling back down.

[Dwedit]

People really don't mind a lag under 1 second before the screen scrolls to the next area. Zelda and Mega Man 2 delay for about a half-second before they start scrolling on the next area.

What they DO mind is the game repeatedly changing areas when you jump against the top of the screen, and don't have enough power to make it very high on the next screen, so they immediately fall back to the previous screen. One possible solution: If you know the player won't have enough jump height on the next screen to get anywhere, don't change areas. Instead, just have the player jump into the status area. But even then, that's kind of misleading because it doesn't clearly tell the player that they can go upward, and people might get frustrated at the game if the area change rejection kicks in when they don't want it to.

[tokumaru]

Since you have no scrolling, couldn't you try to render the new screen to the hidden name table, keep the old screen visible while that happens, and only switch to the new name table when it's ready?

The thing with this is the new screen could conceivably be in ANY direction, left, right, up, or down. It'd be impossible to tell what way for sure the player is going to go.

Why is that a problem? The NES has two name tables, and during your game you always have one of them visible and the other one hidden. Whenever a new screen is to be loaded, it's drawn to the hidden name table within the time of a few Vblanks while the other name table remains visible (avoiding the black flash). Once the hidden one is ready, swap them so that it becomes the visible one and the old one gets hidden. The positions of the screens in the map have no part in this.

EDIT: Oh, you meant you don't know which one to decompress, is that it? Well, you don't have to. When the player touches any of the 4 edges of the screen and triggers a screen switch, game logic will stop running, right? There should be enough CPU time in a frame to decode 1/4 of the new screen, so that this portion can be sent to VRAM during VBlank. I believe that a 4-frame pause will hardly be noticed.

[tepples]

Oh, you meant you don't know which one to decompress, is that it?

Correct. That's why I recommended the heuristic.

There should be enough CPU time in a frame to decode 1/4 of the new screen, so that this portion can be sent to VRAM during VBlank.

Is that just the nametable, or also CHR RAM data?

[tokumaru]

Correct. That's why I recommended the heuristic.

I think the heuristics complicates things unnecessarily if the delay is only 4 frames.

Is that just the nametable, or also CHR RAM data?

I was obviously calculating for the name table only... If too much CHR-RAM has to be updated, the delay isn't the only problem, since the tiles being overwritten might be in use in the current screen. If this is the case then I see no way other than blanking the screen.

Another thing suggested in this thread was to keep at least the status bar always visible. I like that idea, it should help reduce the impact of the effect.

[Jeroen]

Of course another way to make going up/down less annoying thanks to falling back is elevators etc in the game.

[GradualGames]

Cool. I'm almost through the first game. Enjoying it very much! Of the six guardians, I think I found the color mancer boss to be the most difficult (so far).

[Banshaku]

The game update chr-ram on every screen change. This is why the screen was blanked.

I see 2 or 3 possibilities to make the transition more friendly to the eye:

1) Keep status bar on screen and blank after it to allow loading the CHR-RAM that require to be updated (someone could explain the way to do it, I don't even know myself yet)

2) Keep the background data the same for specific sectors in the game. The chr-ram is only updated when you change sector. This apply for the background only, characters may require to be loaded on a per screen basic. The downside is that you have to be more creative with less data for that sector.

3) This one I'm not sure if this is do-able but you could, hmm how I can explain that, "remove" pixels from the chr-ram to gradually remove the map data and put back in the data that way. It would give some kind of fade in/out effect but I'm concerned that the transition between screen would be too long for a twitch action game.

Option 1 seems the simplest to make (once you know how to do it) and less restrictive.

Second one seems the better for transition since you could allow to scroll between screen, a nice plus. There would be the issue about raster effect for the status bar but still, that could be something interesting.

[tokumaru]

A very simple thing to do is quick fade outs and fade ins. I mean regular palette fades, without CHR-RAM tricks or anything.

[strat]

Is a good sprite zero hit enough to keep the status bar on when loading a new screen?

[Sivak]

Well, I'm starting the controls today. In response to all the blanking screen concerns, I really don't see a way around it.

I need to use time to update all the BG, CHR RAM, and other PPU stuff. If the status bar was left on the top, then the PPU would be left on and that'd make the room loading take way longer.

I'll hopefully have an engine test demo for all to play in the near future. Thanks.

[tokumaru]

If the status bar was left on the top, then the PPU would be left on and that'd make the room loading take way longer.

You could do like strat said and use a sprite 0 hit to detect the end of the status bar and disable rendering at that point, so you'd still have a lot of the frame's time left for VRAM updates. Well, it's up to you.

[InvalidComponent]

What they DO mind is the game repeatedly changing areas when you jump against the top of the screen, and don't have enough power to make it very high on the next screen, so they immediately fall back to the previous screen. One possible solution: If you know the player won't have enough jump height on the next screen to get anywhere, don't change areas. Instead, just have the player jump into the status area. But even then, that's kind of misleading because it doesn't clearly tell the player that they can go upward, and people might get frustrated at the game if the area change rejection kicks in when they don't want it to.

I would just design levels in such a way that the big jumps are not inbetween screens.

[thefox]

I would just design levels in such a way that the big jumps are not inbetween screens.

Yes, I think this is the best solution.

Or (this is almost the same) do it like Cave Story does it. When you jump upwards changing screens, it will automatically guide the character to the platform that's on the left or right. So you'd have to have some extra parameters for levels, like "if entered from below, move player here".

You can see it here: http://www.youtube.com/watch?v=ZaZMGNwG0pY#t=5m15s (don't watch it all if you don't want to get spoiled