Language…
13 users online:  Ahrion,  AmperSam, bucketofwetsocks, Darolac, Green, Guido_Keller, Isikoro, JezJitzu,  Linkdeadx2, Metal-Yoshi94, Sweetdude, timothy726, tOaO - Guests: 268 - Bots: 371
Users: 64,795 (2,377 active)
Latest user: mathew

Generators

So I noticed how the generator sprites are becoming UberASM[tool] codes and such, but I would like to voice my opinion on this issue. Basically what I'm saying is that we should not have done this in the first place, because with generators, you could place a generator in screen 00 (let's say its the SMB1 ratchet scroll) and about halfway, you think the generator should be gone. Since the "turn off generators" sprite doesn't work, you decide to make a massive unscalable wall and have a pipe leading to the other side. That's using the same level with two different playstyles. Now let's say we used UberASM[tool] for this same level. UberASM code runs every time you enter the stage, no matter what. So you have to split levels in half, and force yourself to make another sublevel, which could've been another whole stage. And it doesn't end there, oh no. Instead of "insert sprite, add sprite, done", you now have to endure the stupid process of "create init code, paste asm into asm file, insert with UberASM[tool]", and with UberASMTool, you have to have a trillion levels point to one file where you could've just done
Code
D0 generator.cfg
GENERATOR:
D0 generator.asm

in PIXI and it would've done the same thing, yet better, with less effort.
And this concludes my post, this idea of going to UBERASM for this needs to stop (in my opinion) and to think using Uber would've been a better idea is good on paper and thought, but not in practicality.
Hi, I'm a signature!
Hack Thread
Hack Testing Status: Available.
Layout by Koopster.
I agree with you. And half the generators have been removed, and something nobody's converted them, because they are as simple as, "find the code that runs, paste into ASM". I really think they should leave the generators in the Sprites section until they get the uberASM codes posted. For instance, I need the constant v-scroll Layer 3 Tide generator, but it's been removed and I'm forced to wait until some angel will post it in the uberASM section.
please click this!
The problem regarding splitting a level into two sublevels can be worked around by putting some RAM check in the uberASM code, so, depending on its value, it'd run a different code, or simply return. And it's not that hard to do - all it takes is, like, three or four lines of simple code and leaving a bit your comfort zone.

As for TheJullasicFox's issue, you don't even need an uberASM or generator for this. You have LM's 'Change Layer 3 settings' dialog, #lm{props}. Just check 'enable advanced bypass settings for Layer 3', set the vertical scroll to Constant and modify its initial Y position to suit your needs.
MK2TDS
There isn't a setting that puts Layer 3's tide in the correct position. I've checked. Also, some people don't have enough ASM knowledge to do what you said. Plus, that, "RAM value" would have to be set in the first place. Well, how do you do that? With a custom block that you have to code, as opposed to inserting a sprite easily.
please click this!
To every single person concerned about generator genocide:

There's a good reason this was authorised to happen in the first place, and this is code category: 99% of the killed generators were meant to run in the entire sublevel (admit it), especially considering how most of them had the famous "place at all entrances" warning. This progressive death of generator is necessary to:
1) Free sprite slots in general
2) Transfer content to a better suited section
3) Correct extremely buggy codes, and add customization to them (which means extensive testing)
4) Make code better by taking advantage of the possibilities of INIT

Regarding the argument of generator triggering and stopping, I'm currently elaborating a controller which allows to run multiple generators per level easily via a simple table: think of it as two tables, with one controlling the location of the generator codes themselves (a table of pointers), and one controlling how these codes are called (that is, for each screen, a byte that says what should be turned on, turned off, or stopped definitively for the entire sublevel). Besides, as this code uses Asar, it should be easy to control via macros (literally functions with a certain number of arguments).

As an anticipation of future counter-argumentation, I'd like people to remember that if simplicity is at one end of the scale, versatility is at the other. Would you prefer a code that's simple and violates the submission rules, or something that may need at most 1 minute of intense define reading but ends up being a much more customizable product ?

In addition, while there are indeed people that don't have enough ASM knowledge to proceed to full customization, not only do we ASMers try to come up with something that's simple enough for you guys, but on the other hand you shouldn't say that ASM is that complicated. As Blind Devil rightfully said, a simple code controller can fit in four lines alright:
Code
LDA $1463|!addr
CMP #$08
BCC LabelOfCode
RTL

What does this do, you may ask ? The first line loads Layer 1 X position's high byte. That is, the highest screen number on-screen. The second line compares that number to 8. The third line branches to the code if the number we loaded first is strictly inferior to the number we loaded last. When that condition is false, the fourth line is executed, and returns.
In four lines, I made code run only on screens 00 to 07, perfectly replicating a regular generator's way of activating.
And all the instructions used here are literally the basis of ASM, that is to say, what lots of tutorials that are available here on SMWC treats first. Before complaining about people doing volunteer work to fix and better already existing stuff for you, please make a little effort. 😉



TL;DR: We remoderators know what we're doing and are working for the entire community to optimize hacking in general.
So please be courteous and patient, especially considering how remoderation has already been going much faster than expected thanks to everyone's efforts.




Side note for TheJullasicFox:
1) There's a way to place the tide and have it interact with the player correctly. That is, the following setup:
  • Water, low tide only
  • Enable advanced bypass
  • Vertical scroll : None
  • Horizontal scroll : Constant
  • Initial Y offset : 190

Be sure to test every possibility and tell it to us before saying "I've checked." next time, thanks.
Using these settings causes lots of slowdown, and you can't even set the Initial X Position to 190, so I set the Init Y position to 190. And there's more; I have to deal with a giant, opaque (I'm using my own water graphics.) box sitting at the top of the screen while I make my level. I also set the leftward Horizontal Autoscroll, and the status bar pops up and scrolls with it every once in a while.
And here's a note: I know how ASM works and I write ASM. And I never even said ASM was complicated.
please click this!
You make a lot of valid points Mathos, but your and Blind Devil's "it's just 3 lines of ASM" argument holds very little value.

Even after your explanation, people who don't know ASM will look at that code and it'll look like garbage to the ones who've never seen a programming language before, while those that can sort of figure things out will still (rightfully) question how the fuck they were supposed to figure out all of that. Where's this "$1463" come from, what's "|!addr", why "#$08" if it runs for screens 0 through 7, what exactly do those 3 letter things even mean?

This isn't to say your explanation is insufficient, but rather that even if someone were to learn ASM right now (a task that takes a few hours at minimum), they still would not magically posess the intuition to know how to actually apply it, or what "high byte" means, or that the Layer 1 position is synonymous with the camera position, or how SMW even handles positions, etc..

It's not about the complexity of the code, it's about the barrier of entry to being able to actually devise these 4 lines by yourself, which will take a good few days of figuring stuff out just for something that didn't use to be a necessity.
I've seen both of you actually mention and take into account that non-ASM people will have issues recreating what seems like a simple edit to ASM folks, but I think you haven't quite grasped the huge wall there is between people who can't code and even just the simplest tweaks, a big part of which is that coding is always a big memorization fest regarding syntax and keywords.



That all being said, the better solution here probably is to just revise your workflow.
Just split levels up instead of cramming it all into one! That actually reduces load times a little and barely wastes any space in the ROM. Unless you actually have an issue with hitting the level limit there are no upsides to having 3 sections running different global code in a single sublevel.
There's more reason the UberASM approach is much better, and that's not only because custom generators were limiting in their own right; go try and make an autoscrolling level that uses a generator and report back how well that worked.

It's also less error prone because you aren't going to forget placing the generator at every single entrance the level has, as well as being more optimized and running in a far better place in SMW's code that allows for far more access to hardware stuff.
Your layout has been removed.
why don't you just convert it back to a generator lol

for Romi's Sprite Tool, the process was more or less this:

Code
dcb "INIT"
dcb "MAIN"
;paste the uberASM code here

It's easily the best thing I've done
So why the empty numb?
How do we convert the uberASM to generators if said uberASM code isn't posted yet, and the generators are nowhere to be found?
please click this!
There is some value in keeping distinct sections of a level on the same sublevel. It's obviously a smoother transition than a door or pipe and more intuitive to transverse. Many games over the years have touted their lack of screen transitions, and the same logic applies here.


As for the actual topic, well, if people want the generator functionality then they can convert their uberasm or whatever to a generator. "But that's too hard for newbies!" doesn't really hold weight either; much of SMW hacking has always been too difficult for someone who only uses user friendly tools, and the only thing that has ever changed that is giving them another user friendly tool. Make a script that converts uberasm code to a generator. I doubt it would take very long. And heck, you could even implement it site-side and include both the uberasm and generator versions in downloads.
Originally posted by Mathos
1) Free sprite slots in general

That's wrong as generators are their own sprite type. The only exceptions are these which are inserted as sprite but then again, unless they have got an init code they can be converted into a generator (or as an UberASM code).

Now, everyone had explained why we're killing of the generators. That being said, it still makes sense to still keep generators as generators and not UberASM. One of the biggest advantages (if not the only one) of generators are to use them in an area on a level, most prominently enemy generators. Although one can use UberASM for that, the programming can be quite difficult (though converting an UberASM code to a generator is easier and one can use the converting argument again...).
This also is the reason why I disagree with the aimed enemy generator as an UberASM code since some level requires it to be placed after a specific screen and not the whole level.
In fact, that's possibly the reason why the Cave-In Generator is still in the sprites section instead of being an UberASM code.
Adding to this discussion, wouldn't it have been a better idea to transfer everything over to UberASM and *then* delete the generators? As it is, there's a bunch of stuff that's not particularly feasible right now if you suck at programming (Like a certain person making this post).

I do realize that fixing buggy code is probably the reason why you went about it the other way, so it's probably just my luck that I came back to ROM hacking while this was going on. Oops!
Originally posted by Darkbloom
I do realize that fixing buggy code is probably the reason why you went about it the other way, so it's probably just my luck that I came back to ROM hacking while this was going on. Oops!

pretty much ya looool

Mods are in the process of remoderating sprites for PIXI sooooooooooooooooooooooooo
HackPortsASM"Uploader"

Welp, just so you know...
Originally posted by Mathos
Regarding the argument of generator triggering and stopping, I'm currently elaborating a controller which allows to run multiple generators per level easily via a simple table: think of it as two tables, with one controlling the location of the generator codes themselves (a table of pointers), and one controlling how these codes are called (that is, for each screen, a byte that says what should be turned on, turned off, or stopped definitively for the entire sublevel). Besides, as this code uses Asar, it should be easy to control via macros (literally functions with a certain number of arguments).

...this bad boy is 40% done.

Originally posted by MarioFanGamer
Originally posted by Mathos
1) Free sprite slots in general

That's wrong as generators are their own sprite type. The only exceptions are these which are inserted as sprite but then again, unless they have got an init code they can be converted into a generator (or as an UberASM code).

My bad. Didn't know that. But then again, a large portion of "generators", as you said, weren't actual generators and existed in sprite form because they needed INIT code...

Originally posted by Darkbloom
Adding to this discussion, wouldn't it have been a better idea to transfer everything over to UberASM and *then* delete the generators?

Originally posted by TheJullasicFox
How do we convert the uberASM to generators if said uberASM code isn't posted yet, and the generators are nowhere to be found?


*inhales*

Generators (and all other sprites) are perfectly safe.
These are to be packed in a giant archive after sprite remoderation ends, just like what happened with the music remoderation some time ago.
Contrary to any popular belief or rumor, everything "deleted" is backed up with the utmost precaution AND accessible by anyone with no hosting time limit.

For eventual bad .zip naming, blame the authors.

PS: Just to add another argument pro-UberASM: keep in mind that generators certainly occupies slots in a sprite list. They come in limited number in a hack.




I truly hope you guys are convinced now. If not... then, I don't know.
👏 preach queen

y'all are bae for hosting old stuff btw, i have huge ocd over archiving shit

HackPortsASM"Uploader"