Banner
Views: 864,458,413
Time:
20 users online: AnisSaouliBH,  Anorakun, autisticsceptile1993, brickblock369, Doug Walker, edgar, Fullcannon, Golden Yoshi, HammerBrother,  JamesD28, Kusrry, MarioriaM, MaxwelHacks, Mediocre Espurr, Mirann, Mr Esc, SubconYoshi,  Tamaki, The Bluenote X,  Veck - Guests: 63 - Bots: 90 Users: 47,860 (2,068 active)
Latest: SadayOJ
Tip: Don't put a coin over a question block. It will create an invisible solid block above the ? block if the block is hit first.Not logged in.
NGHE - Yet another potential SMW revolution
Forum Index - SMW Hacking - Resource & Tool Releases - NGHE - Yet another potential SMW revolution
Pages: « 1 2 3 »
Last November, I was working on a hack. This isn't unusual around here, though it's not very common for me.

In this hack, I was making some rather large item I wanted to interact with layer 1. This isn't very unusual either.

The unusual part starts when I decided I didn't want to write a huge code to check all tiles this item should interact with. (No, I can't remember what this item was.) Instead, I rearranged the tables at $7xC800 to remove all traces of the term "subscreen", since that makes large interaction codes easier. I also decided to make the level sizes more dynamic, because when I'm already rewriting half of SMW, why not go all the way?

And then I got tired of it. This isn't very unusual for me either, I've cancelled plenty of projects (mainly large ones).

A few weeks ago, I picked it up again. This is very unusual for me, I can't remember any other instance of picking up a canned project.

This patch rearranges the level tables to allow them to go up to seven screens in each direction, or over 50 screens in either direction if you sacrifice scrolling in the other. It's mostly finished, but right now, it just addsA few thousand lines of ASM later, the project is mostly finished. I say mostly, because it currently does nothing visible at all except adding a couple of bugs and incompatibilities (I think I've killed most of the bugs, but please tell me if you find any that aren't mentioned in the readme).

It does, however, make it (relatively) easy to make levels with the new shapes; take a look at !105 and !106 in loadlevel.asm for details.

You can get it here (requires Asar 1.30), but please read the readme before applying it. Blindly adding it will just shred your ROM sooner or later.

If you prefer a couple of screenshots instead, here you go. Or if you prefer watching the pains I had to sit through to make this, I've got some stuff for you too. (It's much easier to take screenshots of bugs than stuff working correctly, bugs are so much more varied.)


Two weeks later edit: As I expected, lots of talk and nothing done. I can't really say I expected anyone to use it with all of its incompatibilities, but is finding that Donut Plains 2 and probably a couple of others paint the background red during Mario Start too much to ask for...?

--------------------
<blm> zsnes users are the flatearthers of emulation

You sir are a SMW ASM god.#smw{<3}
Layout by LDA during C3.
Here's hoping skilled enough people will take the time to iron out the remaining bugs so FuSoYa can eventually add this to LM. As it is now, it seems kind of... impractical.

Breathtaking nonetheless, though - what I assume is one of the oldest dreams of SMW hackers has just come true.

--------------------


 
wait... diagonal levels? Once i asked if this was actually possible in Advanced SMW Hacking forum, but now i see this came pretty true! I was waiting for this, actually, now SMW is getting even more complete. I suppose this isn't going to work with ZSNES properly, hoho, i'm going to see people are happy of this so they'll stop using ZSNES

Jokes aside, that's awesome!!! I'm sure people will be glade of this!

Also nice way to promote this subforum.

--------------------
My deviantART
My Youtube channel
My avatar
Watch, i made a Super Mario 64 level
Oh hey that's pretty neat! Though it seems like it would be a bit overcomplicated to use, I couldn't imagine designing a level that can't be rendered properly in LM x.X

Oh well, hopefully a new version of LM will be made that can render it properly within the next few years. But as of right now, as WYE said, it seems really impractical to use in its current state. Impressive work, though.
Oh God, Alcaro, you are a SMW master! #smw{-_-}
Well, lets start making diagonal SMW levels.

Sorry the bad english
While I admit that this is GOD-like, it's something that won't be used too early.

--------------------
You can download my VLDC12 entry Here - final update
Originally posted by Dinomar
I suppose this isn't going to work with ZSNES properly, hoho, i'm going to see people are happy of this so they'll stop using ZSNES

Except it does work in zsnes; tested it myself
Pretty awesome Alcaro.

Question: There are any limitations right now?

--------------------
https://www.youtube.com/watch?v=3xkRkaXPN_A
---
GitHub - Twitter - YouTube - Blog - SnesLab Discord
Originally posted by Dinomar
I suppose this isn't going to work with ZSNES properly, hoho, i'm going to see people are happy of this so they'll stop using ZSNES

Holy crap, what's up with the central wanting to make everyone stop using ZSNES? Some people prefer ZSNES because it's much more simple and user-friendly, let us be #w{:s}



Also Alcaro, that's completely badass, now I can finally make MMX-like levels :D
LINKS Twitter | YouTube | SoundCloud | Fortaleza Reznor
to hear birds and see none.
This looks very incredible, although I've think of the same thing when I was developing the Super FX patch but I hadn't time enough to create and test the patch but anyway, it's a very nice patch.

Good work.
Originally posted by Vitor Vilela
Question: There are any limitations right now?

  • Minimum width 16 tiles, minimum height 15 tiles
  • Maximum width and height about 2040 tiles (may remain stable a bit higher higher, but I don't think it'll work once the positions hit #$8000)
  • Maximum of 14336 tiles in total (width multiplied by height) by default, extendible to 32768 if you move stuff to SRAM, or 65536 if you use a bsnes-only XML mapping and edit macro CalcTileID in scrollvars.asm (why the hell is $2134 signed?)
  • Only one of layers 2 and 3 can be interactible
  • Layers 1 and 2 must have the same dimensions, unlike a couple of unused level modes in the clean ROM (Smallhacker once made a proof of concept of that in the ASM showoff thread, but it was very limited)
That's all I can think of, if we ignore solvable limitations.

--------------------
<blm> zsnes users are the flatearthers of emulation
NICE!, this patch will probably solve various limitations in making SMW levels!, looking forward to it!, still, what about the backgrounds and layer 2?, it could be tricky to put a background or layer 2 tiles that won't break with the scroll
LM expands the backgrounds to 512x512, which should be easy to integrate with this patch and simultaneously solve your problems. Just poke a couple of lines around CreateInitialVRAM, they're marked with a long string of semicolons.

...but I think I forgot a spot in loading the backgrounds into VRAM, making it garble if the initial Y position is wrong. It's fixed, please redownload.

--------------------
<blm> zsnes users are the flatearthers of emulation
Oh cool, you finished it (sort of)! Those bugs and limitations do look pretty significant, though...I suppose they'll be fixed in time. If FuSoYa does implement it in Lunar Magic (maybe that's what level modes 12-1D could be used for...), then shouldn't we update certain blocks, sprites, and patches to work with it? Also, I have a few questions:
1) Does it work properly with interactive Layer 2/3 levels? What about scroll sprites?
2) Could the level space theoretically be made larger if we were to move the relevant tables, such as placing them in SRAM (or BW-RAM)?
3) Do you know which patches are incompatible with it and why?
4) Why were you using $211B/1C for math anyway, just because of the lack of delay? Because the product can be 24 bits long?
5) How big of a jump would it be from this to a level that changes from one size to another, and possibly one layer interaction setting to another, partway through? (Something like level modes 03-06, such as, say, a horizontal Layer 2 background level that changes to a vertical Layer 2 foreground level after 8 screens.) Or, for that matter, from one that isn't rectangular (like 5-9 in SMB3) or is composed of many separate contiguous rooms (like levels in Mega Man games).
6) What should we do to help make this path work and make things work with it, besides the list of things in the readme?
This is incredible! O.O

--------------------
Are you an ASM coder and want to trade "resources"? Private Message me for details.
(I also offer SMW Custom Songs in exchange for ASM! I don't do ports though unless it's to remix.)

Want progress on 100 Rooms of Enemies: The Nightmare Edition? Go here to see.

Are you a sample porter and wanna help with 100 Rooms of Enemies: The Nightmare Edition? Private Message me or Mellonpizza for details. Expect trading "resources" in exchange. 4 more left.




This....is just....beautiful
#smw{T_T}

--------------------
Later.
Originally posted by imamelia
words

1. Yes and yes, that works fine.
2. Yes, there's a couple of defines in scrollvars.asm. I'm not sure if BW-RAM is big enough, though.
3. All patches that tries reading or writing $7xC800 using any routine that I haven't patched, and any patch that tries editing my patched routines. An example of the latter is this (edits $00BEB0); an example of the former is this and about twenty other blocks.
...actually, I seem to be bypassing the hijacks the custom block codes uses (good thing they all hijack JSL $00F545, easy to find). Fixed, please redownload.
4. Lack of delay, and because 8bit*16bit twice is faster than 8bit*8bit four times. You can edit it in scrollvars.asm if it makes you happier.
5. That sounds like it would explode very quickly and very badly. The width is in a single RAM address, and it's used for every interaction calculation. If you change it, you'd need to upload completely new data to $7EC800, or you'll find yourself walking on the direct page or something.
6. Testing. I'm pretty sure I forgot patching up a long list of objects; reporting stuff that looks glitched or paints the screen red during Mario Start is helpful.
It may also be helpful to make sure FuSoYa sees this thread, so he can decide if this one deserves LM support or not. I don't really care personally; I rarely use LM, and when I do, I usually use 1.65.

--------------------
<blm> zsnes users are the flatearthers of emulation
Originally posted by MaxodeX
Originally posted by Dinomar
I suppose this isn't going to work with ZSNES properly, hoho, i'm going to see people are happy of this so they'll stop using ZSNES

Holy crap, what's up with the central wanting to make everyone stop using ZSNES? Some people prefer ZSNES because it's much more simple and user-friendly, let us be #smw{._.}



Also Alcaro, that's completely badass, now I can finally make MMX-like levels :D

ZSNES is not user-friendly. 20-year-old UI (it's dos, not windows, idiots), it often glitches my mouse so bad I need to open task manager to barely escape, and the interface is overall counterintuitive. "So WHERE do I change the kepy mappings? Oh! THE SAVESTATE KEYS? THE SCREEN RESOLUTION? #smw{T_T}"

--------------------
Your layout has been removed.
Pages: « 1 2 3 »
Forum Index - SMW Hacking - Resource & Tool Releases - NGHE - Yet another potential SMW revolution

The purpose of this site is not to distribute copyrighted material, but to honor one of our favourite games.

Copyright © 2005 - 2020 - SMW Central
Legal Information - Privacy Policy - Link To Us


Menu

Follow Us On

  • YouTube
  • Twitch
  • Twitter

Affiliates

  • Super Mario Bros. X Community
  • ROMhacking.net
  • Mario Fan Games Galaxy