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
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.
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.