Language…
5 users online: autisticsceptile1993, fsvgm777, Gasterus155, jferrerfaj, LotuaStation - Guests: 43 - Bots: 323
Users: 66,328 (2,268 active)
Latest user: mazouzei9

Level Constrain v3.4

SMW Patches → Level Constrain v3.4

Submission Details

Name: Level Constrain v3.4
Author: HammerBrother
Added:
Version History: View
Tool: Asar
Requires Free Space: Yes
Bug Fix: No
Featured: No
Description: Unlike screen constrain, this patch constrains the player and sprite's interaction with blocks within the level (properly, check out the first gif to see why).

V3 update: Now works properly with LMv3.00 dynamic levels patch.

Tester's Note: Does not work with Morton, Roy, Bowser, and Reznor.

3.1 update: now you can disable the patch's effect via a RAM if you want to have only specific levels not to have this effect.

3.2 update (removed because crashing): freeram is now bit-side-based, to make disabling each individual of the 4 sides possible.

3.3 update: fixed potential crashing issue.

3.4 update: fixed a bug that Super/Cape/Fire mario, when not crouching, interacts with the 2nd-bottomost row when he should only interact the bottom row. It now uses fastrom (happens when JMLing back to SMW code).

Github: https://github.com/GhbSmwc/SMW_LevelConstrain
Tags: anti-cheat lorom physics player sa-1 sprite
Comments: 19 (jump to comments)
Download 219.19 KiB | 413 downloads

Screenshots

View all

Comments (19)

Pink Gold Peach Link
This doesn't seem to be compatible with the custom power-ups patch
SJandCharlieTheCat Link
I can't begin to explain it, but for some reason this seems to cause the biggest performance hit to my baserom, in terms of exacerbating sprite lag. (Alongside the screen-scrolling pipes fixes patch, incidentally.)

This is the case even when I have !Setting_LevelConstrain_RAM_Based = 1 and haven't set the RAM in a level. (The RAM isn't being set by anything else, either.)

I first tested on FastROM with... well, nearly 150 other patches. Yet sprite performance is actually fine even when every single other patch is applied, even in situations with heavy sprite usage. When I add this patch, though, it quite noticeably takes a dip. When I add this + the screen-scrolling pipes fixes patch, it can be almost unplayable in situations with heavy sprite usage.

Even just on their own on a clean rom, there seems to be a significant amount of new lag when using these two patches in situations with heavy sprite usage. It becomes much worse when used with other performance-intensive patches, like NMSTL.
 Kevin Link
Tested with: Lunar Magic 3.11, asar 1.71, SA-1 1.32, Snes9x 1.60, bsnes v115. Now the update works as intended, so accepted.
 MarioFanGamer From older version: Level Constrain v3.1 Link
Originally posted by HammerBrother
The 4 directional can be emulated via having blocks that enable/disable the flags and the player triggering it at specific locations of the level.

I'm aware of that but it's a global change i.e. sprites also are affected by it.
HammerBrother Author From older version: Level Constrain v3.1 Link
Originally posted by MarioFanGamer
Moderated with:
  • BSNES v115
  • Asar 1.71
  • SA-1 Pack 1.32
  • Lunar Magic 3.11
  • UberASM Tool v1.4

Replaced the very specific tags over the level and under the level with physics, fixed a missing SA-1 conversion.

Definitively a useful patch in certain cases. Having it dependent on RAM also fixed incompatibility with Mode 7 bosses and is a useful addition in general (as you sometimes want to go above the level but not always).

Possible suggestions: Use two or even four flags: One for each direction as e.g. you sometimes want to go above but not below the level. The code also could be improved a bit as you can only change the data bank with PLB whereas neither JML nor JSL can change it.


The 4 directional can be emulated via having blocks that enable/disable the flags and the player triggering it at specific locations of the level.
 MarioFanGamer From older version: Level Constrain v3.1 Link
Moderated with:
  • BSNES v115
  • Asar 1.71
  • SA-1 Pack 1.32
  • Lunar Magic 3.11
  • UberASM Tool v1.4

Replaced the very specific tags over the level and under the level with physics, fixed a missing SA-1 conversion.

Definitively a useful patch in certain cases. Having it dependent on RAM also fixed incompatibility with Mode 7 bosses and is a useful addition in general (as you sometimes want to go above the level but not always).

Possible suggestions: Use two or even four flags: One for each direction as e.g. you sometimes want to go above but not below the level. The code also could be improved a bit as you can only change the data bank with PLB whereas neither JML nor JSL can change it.
HammerBrother Author From older version: Level Constrain v3.1 Link
Originally posted by AnasMario130
Okay, thanks a lot!

A better way to do this is by “defaulting” the value to #$01 on the overworld init (gamemode $0E), and only in levels you want this off, you use STZ !Freeram_LevelConstrain (don't forget to have !Freeram_LevelConstrain = $60 at the top).
Anas From older version: Level Constrain v3.1 Link
Okay, thanks a lot!
HammerBrother Author From older version: Level Constrain v3.1 Link
Originally posted by AnasMario130
Hmm, and I assume that in order to do that, you do something like STZ !Freeram_LevelConstrain in the UberASM code? Just making sure.

Yes, but remember that for levels you do want its effects in other levels, you set this to #$01. This means if you go to a level that doesn't have this effect, then go to a level that is intended to have that effect, it remains off if you leave the RAM set to #$00.
Anas From older version: Level Constrain v3.1 Link
Hmm, and I assume that in order to do that, you do something like STZ !Freeram_LevelConstrain in the UberASM code? Just making sure.
HammerBrother Author From older version: Level Constrain v3.1 Link
Originally posted by AnasMario130
One question: how do you call the RAM that turns the patch's effect off in your level via UberASM? I don't think the readme explains it, so people will get confused and frustrated by that.


To turn the effects off, just have the RAM it's using set to $00. It's explained on the ASM patch:
Code
!Freeram_LevelConstrain = $60
 ;^[1 byte] (not used if !Setting_LevelConstrain_RAM_Based = 0)
 ; RAM address that applies the level constain (block interaction
 ; applies off-level) when nonzero.
Anas From older version: Level Constrain v3.1 Link
Hmm, the first GIF is pretty odd 'cause the screen doesn't push the player but I can see why you did that. Anyhow, thanks for the update! Now I can use this per-level! One question: how do you call the RAM that turns the patch's effect off in your level via UberASM? I don't think the readme explains it, so people will get confused and frustrated by that.
HammerBrother Author From older version: Level Constrain v3.0 Link
@Telinc1 Thanks. I've seen lots of hacks suffering a limitation that you cannot put barriers such as walls beyond the top and bottom of the level, rendering lots of hacks vulnerable to players exploiting and skipping parts of the level.
 Telinc1 From older version: Level Constrain v3.0 Link
This is a really useful patch, even if you're not using it for interesting setups, so having Lunar Magic 3.00 support for it is more than welcome. During the moderation, I removed the "needs remoderation" tag from the patch because it already meets the standards of the remoderation.
HammerBrother Author From older version: Level constrain Link
Thankfully, this patch is lucky that none of its hijacks clashes with LM v3.00's dynamic levels patch.

However, because the patch assumes that horizontal levels always have a bottom border at Y=$01A0, this is not the case if you change the “Horizontal Level Mode” in “Change Properties in Header” to other than the first option saying “Level height=01B tiles, Max H-Screens=20”.

Therefore if the player or sprite is below Y=$0190 (2D Y-positions values increases as they descend), the player/sprite will only interact with blocks at Y=$01A0, causing the bottom of the newly expanded area useless. Currently, I'm trying to find a RAM value that is based on the level dimension setting.


This is what needs to be changed:
Code
	..HorizontalLvl
	REP #$20
	LDA #$0190
	CMP $96				;\Check if bottom boundary is is above mario
	BMI ..SetYPosCollisPoint	;/(mario is too far below)
	
	..NormalYPosition
	LDA $96

	..SetYPosCollisPoint
	CLC
	ADC $00E89C,x
	STA $98


Code
Sprite_HorizLvl_blk_interYPos:		;>$0194D4
	LDA #$0000			;>Top of level
	CMP $0C				;>Collision point Y position
	BPL .Exceed			;>If top of level below collision point (collision is above)
	LDA #$01AF			;>Bottom of level
	CMP $0C				;>Collision point Y position
	BMI .Exceed			;>If bottom of level is above collision point (collision is under)
	SEP #$20
	JML $0194DD			;>Continue on with code

	.Exceed
	STA $0C

	.Align16x16
	SEP #$20
	AND #$F0			;\So it doesn't glitch out with blocks ($0194C5)
	STA $00				;/that need 16x16 alignment
	JML $0194DD			;>Continue on with code
Mogu94 From older version: Level constrain Link
Seems in the past there were different options for the same effect but they were quite....terrible. Thanks for this good solution.
lx5 From older version: Level constrain Link
This is a good patch, I really liked testing it! Turnblocks are very interesting with this patch, because you can pass through them and that also applies to the top of the screen, I can think of some interesting set ups with this.

Good job.
HammerBrother Author From older version: Level constrain Link
Show me a GIF.
Gamma V From older version: Level constrain Link
This caused my hack to softlock in a very specific spot.