Language…
21 users online: akawo, Alex No, CroNo, DanMario24YT, Fullcannon, Gemini0, Golden Yoshi, Gulaschko, Hammerer, kurtistrydiz,  MarioFanGamer, MarkVD100, Maw, mtheordinarygamer, NewPointless, rafaelfutbal, Rykon-V73, Spedinja, steelsburg, superbot12, Tulip Time Scholarship Games - Guests: 289 - Bots: 456
Users: 64,795 (2,370 active)
Latest user: mathew

w7n's Advanced SMB1 Engine (Plan)

As I said in another post, hacking SMB1 using only SMB1's own mechanics has no future, and I'm making this project.
Check this post for details.
If anyone knows how to program in Delphi, probably you can provide some help on programming the level editor.
I always appreciate any movements forward for smb 1 hacking. But I wouldn't say there is no future, A good start is getting the rom editor smb ultility to utilize the sxrom mmc1 hack by dr. floppy. Not to mention a website where .asm files can be moderated and stored.



Also at somepoint I felt the way you do and I modifyed the smw engine to similar to smb, I never released it, it needs fine tuning.however my super mario arcade demo is by product of this work would you try it and tell me what you think. In the mean while I will keep ears/eyes open for people who can help you.
have you ever considered using the disassembly to port to a new system, that would give you more to work with?
Originally posted by zacmario
have you ever considered using the disassembly to port to a new system, that would give you more to work with?


Sorry but no, it'll take time to get familiar with a new system, and one of my goals is to achieve the unthinkable with such old hardware and based on a somewhat primitive engine.
snes is preety close in asm terms, however I certainly respect the fact of sticking to nes with original engine. I did look at your rhdn post and was preety impressed.
That's cool, How about adding support for these:

-Optimize the PRG-ROM (see ShaneM's posts from NESDEV and Board 2)
-Make the Scroll Engine use One Screen instead of two (frees a whole name table!)
-Different Color Attributes per Metatile!
-Skidding and Wind Sounds
-Ice Flower
-Poison Mushroom
-Wind Generator (On and Off)
-Spinning Shells
-Mapper IRQ Support
-Title Screen inside PRG-ROM
-Separate Palette RAM to another buffer
-Give Peach and Toad Separate Palettes
-Improve the Ending
-Extend the Music
-Capping lives, Up to 99
-Add P-Switches, Bricks <-> Coins
-8x16 Sprites
-New Sprite System (similar to how No More Sprite Tile Limits works)
Originally posted by Hamtaro126
That's cool, How about adding support for these:


-Optimize the PRG-ROM (see ShaneM's posts from NESDEV and Board 2)
Could you provide me with a link? I had rearranged the program before and did a few optimizations to save processing time.

-Make the Scroll Engine use One Screen instead of two (frees a whole name table!)
Not now, it could be possible though. Right now my engine uses 4-screen mirroring since it supports H+V levels. This creates a problem since now the mapper is an arbitrary 'VRC7 4-screen (fixed)' which is not supported by many emulators. FCEUX does support it.

-Different Color Attributes per Metatile!
Only available on the MMC5 mapper, if I understand you correctly.

-Skidding and Wind Sounds
Possible but I don't intend to add them, if anyone wants to he has to hack the engine.

-Ice Flower
Planned.

-Poison Mushroom
Possible but not planned.

-Wind Generator (On and Off)
Wind is planned, generator is possible (good idea here)

-Spinning Shells
Visual effect only? As of now the CHR ROM arrangement is a bit of an issue so probably no.

-Mapper IRQ Support
Already implemented.

-Title Screen inside PRG-ROM
Title screen uses new mechanics on its own, including a load game feature.

-Separate Palette RAM to another buffer
Uh, what?

-Give Peach and Toad Separate Palettes
All enemy processing will be given much more freedom.

-Improve the Ending
And something like, cutscenes and dialogues? Already implemented.

-Extend the Music
And use VRC7's FM synthesis chip? Already implemented.

-Capping lives, Up to 99
That's a minor edit.

-Add P-Switches, Bricks <-> Coins
Planned. I actually want to extend on the idea: ALL bricks (including those with powerups) will turn into obtainable coins, and some coins, when turned into bricks, are actually bricks with powerups (or vines). This will create more ways to design hidden paths and hide unique powerups.

-8x16 Sprites
Implemented.

-New Sprite System (similar to how No More Sprite Tile Limits works)
Implemented, but due to the 8-sprite issue it needs to be fixed.
hm p-switch gimmick is an excellent idea.
The Palette in the original SMB1/SMB2J use the same buffer used in the Stripe Images.

SMB2USA/SMB3 does one better by uploading via a seperate buffer, consists 3 of seperate palettes (Back Color, Nametable Palette, and Sprite Palette)

In SMB1, The system makes sure to still seperate the main palette from the back color, which is set depending on RAM variables AreaType and BackgroundColorCtrl

This can be changed to be per-level by modifying SMBDIS easily!
Originally posted by Hamtaro126
The Palette in the original SMB1/SMB2J use the same buffer used in the Stripe Images.

SMB2USA/SMB3 does one better by uploading via a seperate buffer, consists 3 of seperate palettes (Back Color, Nametable Palette, and Sprite Palette)

In SMB1, The system makes sure to still seperate the main palette from the back color, which is set depending on RAM variables AreaType and BackgroundColorCtrl

This can be changed to be per-level by modifying SMBDIS easily!


If you check the link I posted in the top post, you can find this section:

Level header:
> TTTT AAPP   T: Time setting (0=do not set), A: Area type, P: Initial Y position
> TTTT TTTT CSLT TTTT  C: Ceiling judgement (0: Ceiling hollow; 1: Ceiling has same attributes as the highest metatile of the same x position), S: Safe zone, L: Landform(terrain) GFX type, T: Terrain bits
> LSSS SSSS  L: L+R level, S: GFX settings type
> One byte for BGM
> One byte for starting BG
> VPPP PPPP  P: Palette, V: H+V level
> One byte for local map ID
> One byte which determines the level's position on the local map. YYYX XXXX
> TTBB BBBB   T: Time flowing speed setting, B: Player to background collision setting (used for moving background)
> Two bytes depending on the area type:
--If H+V level: The starting terrain bits of the lower area.
--If not H+V level: The two routine IDs for preloaded data.
> Finally a null-terminated string for the name of the level.

In fact, the palette is not only meant to be user-defined for every single level, it can be changed mid-level.
I was wondering, can you give me a brief explanation of a smb 1 gimmick.
The gimmick is when you jump of a spring you're above the screen and fall down eventually. Does this use a timer sprite?
Originally posted by zacmario
I was wondering, can you give me a brief explanation of a smb 1 gimmick.
The gimmick is when you jump of a spring you're above the screen and fall down eventually. Does this use a timer sprite?


I don't quite get what you mean (my native language isn't English), the closest I can think of is the green springs in SMB Lost Levels.
In SMB and 2J, the engine basically treats the space above the screen as totally without blocks. So the physics engine still executes normally, just that the player is not visible.
ok, thanks.