QUIRK PATCH: rock solid room switching

FrankenGraphics

New member
I don't know if this also was fixed in versions more recent than 4.1.0, but either way - here's a fix for making screen transitions rock solid. Also marginally quicker (this difference is pretty much imperceptible, but anyway).

Previous problem:
When transiting between screens, you'll occasionally see the contents of the other nametable flash by for a frame, more often than not, depending on timing. That frame has nonsensical content from previous scrolling margin updates or screen flicks.

Explanation:
The original file makes the error that vBlank is always guaranteed before setting PPUMASK [$2001) to disable rendering. So it is doing a spinlock for the duration of up to a frame to pass until it can proceed to blanking out the screen. Normally, this wouldn't matter all that much. Trouble in our case is, the camera code has already decided that you'll be viewing the other nametable, which mostly contains scroll update garbage at this point. That's what you see flicker by for a single frame when transitioning.

Solution:
We'll simply disable rendering right at the start of the screen loading routine, so the player don't have any chance to get a glimpse of that garbage.

I also commented out 13 subroutine calls to WaitFrame since they were redundant at this point - rendering is already off all through the process so we don't need to wait for rendering to be turned off. all that would do is jump right back.

Installation guide:
1) Search and replace HandleScreenLoads.asm with the attached file.

!!: Note that the file may be present at several locations in your NESmaker folder. Replace the one that is relevant to your project (you can check this from your script settings).


Notes:
Note that if you want to implement smooth fadeins and fadeouts, handleUpdateSwitch is not the place to be doing it. You need to do it earlier; before the camera switches what nametable is viewed, and ideally after player object, monsters, and other objects have been locked or otherwise disabled.

edit: removed some typos and rephrased some bits for clarity.
 

Attachments

  • HandleScreenLoads.zip
    4.1 KB · Views: 154
Amazing! I was just noticing this glitch recently and was wondering what was going on. Thank you very much for the fix!
 

dale_coop

Moderator
Staff member
I may speed for myself... but yeah, I find your post always very interesting and useful. You identified (quickly) some fixes or workaround for some annoying issues (this one for example... I always thought, because it's not game breaking , "it's very ugly... but hey, it might be fixed in the next update...").
Thank you FrankenGraphics.
Now you spent a lot of hours using NM, how do you think about it? Still young and bugs... but personally I think it's a good and fun tool for educational purpose with kids or teenagers (ASM programming)?
I know my son love the sessions we do together (he's 6yo)
 

FrankenGraphics

New member
I can imagine! I used to use shiru's NESST tool and asm6 in a workshop for kids. The goals were more humble. They'd design a background image that we'd write a simple program to display on the NES. Had i had NM at that point, the kids could've gotten much more out of their efforts in the same amount of time. But either way they got an approximate feel for how games used to be made and a bit of a notion how computers actually work. More importantly, maybe a taste for making their own content. :)

The best thing about NESmaker is that it is unique. NESICIDE is a similar tool for nes project organization that lets you be more free and open ended, but you need to write every bit of code from scratch. Agnes is a game engine that you can study, modify and use, but it wasn't built for a particular project organizer tool. For other study cases, the source of Brad Smiths' lizard is for free. You can also look at disassemblies of old commercial games, but the comments are usually sparce and you need to figure out some or all of the labels yourself.

The current project i'm doing for the museum had a narrow time frame, so it was either basing it on agnes or nesmaker. Given that nesmaker provides a gui, that was problably the right decision.

The single most limiting aspect of the engine is that it doesn't support a proper metatile system - neither in the assembly code, nor in the GUI. If you make one for yourself, the screen world/screen editor is going bust. The way NESmaker engine organizes tile deployment on screens is very wasteful on chr tilespace and something Nintendo had moved away from as early as games released 1986.

tl;dr and in relation to some other things - The best that could happen for a future big version is IMO thus:

1- the inclusion of a proper meta tile system.
2 - screen editor display being rewritten to be content agnostic (ie not running into exceptions as soon as edits don't comply with the vanilla tile system) and thus more robust.
3- Simplified collision. the same results can be had with radial collision, but more efficiently and with a smaller zero page footprint
4- two-tier object handling. saves ram and cycles alike.

pretty much in that order
 

Mugi

Member
i made some noise in the 5.0 suggestions thread about the fact that the screen painter specifically completely threw the "do what you want with the code" out of the window by locking paths to paths and hud to hud, and im
really hoping that people would read over that and voice their opinion more to the devs as i believe it's propably THE most important thing that needs to be addressed in the way the tool currently works.
it's cool and all that you can modify your engine any way you want but currently modifying the graphics loading code in any way will just instantly render nesmaker's screen tool useless, and it's a real problem.
 

FrankenGraphics

New member
Yeah.. basically, the screen painter shouldn't care what tile is drawn where, by means of internal or external edits, the bundle in codebase or something completely custom written - it should still be able view tit without throwing an error. Rewriting it to sample tile ID:s directly for previewing instead of assuming things about the underlying level format would fix it. The picture needs to be re-sampled each time the user switches tile segments, but it already does that.
 
Thanks!

FrankenGraphics said:
!!: Note that the file may be present at several locations in your NESmaker folder. Replace the one that is relevant to your project (you can check this from your script settings).


Hmm, I see what you mean. In basic2019 there's one version of this in the system folder, and one under adventure folder. I don't see this file anywhere in script settings, which is where I usually call up an edited folder rather than overriding the original.

scriptsettings.png
 

Mugi

Member
handlescreenloads is in the system folder of your currently used module.
in your case i'd assume it is in gameenginedata/routines/basic_021019/system
 

baardbi

Well-known member
Thank you so much Frankengraphics :) It works great, and the game looks so much better because of this.
 
Top Bottom