Language…
11 users online: 1UPdudes, Cappaque, ForthRightMC, HyperStormH, Outcast, pixlrik,  Selicre, teddy, UTF, Yann, Zavok - Guests: 265 - Bots: 108
Users: 70,557 (2,468 active)
Latest user: eljoako123

Posts by Sonikku

Sonikku's Profile → Posts

File Name: Frost Para Beetle
Added: 2007-01-28 04:53:33 AM
Authors: 682
Tool: Romi's Spritetool
Type: Standard
Dynamic: No
Disassembly: No
Includes GFX: No
Description: I plan to fix the para beetle going down when jumped on.
Like the Frost Giant Goomba, this sprite is just a basic modification to the original sprite and thus I can't find any good reason to keep it. It also has a(n albeit minor) bug that was intended to be fixed upon its release 10 years ago. If a new Frost Series sprite set needs to exist, they'll need more features than this.



File Name: Panser
Added: 2006-10-02 10:52:55 AM
Authors: ALEX
Tool: Romi's Spritetool
Type: Standard
Dynamic: No
Disassembly: No
Includes GFX: Yes
Description: This is just like the ones from SMB2 this will include two types of pansers,
-one that will stay still and
would use pallete D
-one that moves back and forth with pallete C

this will also come with a ExGfx file for them
As far as I understand it, it's literally just a slight modification to the original Hammer Bro sprite.



File Name: panser no jump
Added: 2006-10-02 10:53:01 AM
Authors: 682
Tool: Romi's Spritetool
Type: Standard
Dynamic: No
Disassembly: No
Includes GFX: No
Description: Similar to ALEX's panser's except these can't jump.
This is too small a modification to the Panser sprite by ALEX. The Panser sprite by ALEX is too small a modification to the Hammer Bro by MikeyK.



File Name: Egg Bro
Added: 2006-08-05 08:09:09 PM
Authors: Bloyburt
Tool: Romi's Spritetool
Type: Standard
Dynamic: No
Disassembly: No
Includes GFX: Yes
Description: I've made another custom sprite - an egg brother! Here are the differences from a sledge brother:
- Different Pallete
- Disappears in a puff of smoke
- Takes 5 fireballs to kill
- Can't be killed with a cape
Once again, the egg is simply an alteration of the hammer GFX.
"I've made another custom sprite" aka "I modified MikeyK's Sledge Brother and really only changed some cfg bytes."



within ./extended/boomerang.asm, put this:

Code
	LDA $0E05|!Base2,x
	AND #$1F
	BEQ +
	LDA #$xx		;SFX number
	STA $1DF9|!Base2	;sound bank
+


change xx to your sfx number and change the number of the AND to something else to change the frequency of the sfx playing (ideally #$01, #$03, #$07, #$0F, #$1F, #$3F, #$7F, #$FF; higher values are slower, lower are faster)

it would be ideal to place the code somewhere after the "LDA $9D : BNE Return" similarly to this:



it should be somewhere after the check of $9D because if the screen gets frozen (i.e. mario getting powerup, dying, screen transition) the sfx could possibly get caught constantly playing (which can interrupt other sfx you might want to play during those frozen moments)



I might have significantly reduced free time these days but I'll try to help out as best as I can, given my experience with sprites in particular.



Originally posted by Thomas

You could try maybe fixing it by adding some extra code to the hole sprite (something like, check if Mario is touching the bottom of the sprite and still on the ground, and don't immediately enable passing through if so). I'm not currently able to test that kind of solution, though.

Not possible to do in this method. SMW handles the ghost house floor sprite by setting a flag that disables all interaction with Mario when its set, and clearing it when he's not touching it.

Unfortunately, this means that because Mario is technically touching the sprite while it's a tile above him, he will fall through tiles he's standing on top of.

I can attempt to write a patch to make this sprite function a bit better a bit later today.



(restricted)
File Name: Punchy
Submitted: by Mandew
Authors: Mandew
Tool: GIEPY
Type: Standard
Dynamic: No
Disassembly: No
Includes GFX: Yes
Description: Punchy the boxing glove will fling Mario and sprites upwards and to the left/right by punching them from a wall.

Includes a config file for both facing left and right.

This is a new version rewritten entirely from scratch for GIEPY, omitting the impractical features that the PIXI version had. This one will also interact with most sprites, compared to the PIXI version's limited scope.

Version 1.0.1 comments out four lines of code in the Sprite Interaction section. It should now be able to interact with a lot more sprites, so go nuts!

The old PIXI version is also included in a subfolder.
Screenshots:
As cool as this sprite has potential to be, there's still additional testing that I feel needs to be done before I'd be comfortable accepting it.

1. If two are placed vertically next to each other, the one on the bottom tries to hit the one on top. You will want to find a way to ignore sprites of the same type.
2. Certain sprites that rely on acceleration/deceleration break. The Flying Hammer Bros. platform, if touching the sprite, launches away. Lakitus inconsistently will impact it and get launched even though they probably should be outright ignored, etc.

Bullet Bills, Torpedo Teds, Big Boos, moving platforms, reflecting Boo streams, and even the smoke from Yoshi's house all collide with this sprite. Sure, a few of them are unaffected by the velocity changes (i.e. Bullet Bills and the Yoshi's house smoke), but others are and they either don't work as intended or just break hilariously.

If you can resolve this, I'd gladly accept this sprite. Until then I'm afraid it has too much potential to break other sprites to be truly useful.

If you want ideas on how to fix it, most sprites that are affected don't collide with objects. If you check for those sprites it'll fix the majority of them almost immediately. However, a few (i.e. Reflecting Boo Stream) still are launched at a weird angle. You could create a loop to check through a list of sprites and exclude them; this would give people more freedom in adding their own sprites-to-be-excluded too.



The SA-1 patch more or less remaps all of the RAM related to sprites to other locations within the RAM bank(s), so PIXI will detect if the ROM is enabled for SA-1 or not, and offset the addresses accordingly. $14C8,x will address $14C8,x always. !14C8,x will address $14C8,x if the ROM is not SA-1 enabled, or $3242,x if the ROM *is* SA-1 enabled.

It vastly increases the compatibility of sprites that can be used on SA-1 ROMs.

The reason that the defines are !14C8,x for example instead of !sprite_status,x is mostly for simplicity's sake. However, I believe that !sprite_status,x itself can be also used in place of !14C8,x and it'll assemble identically, so it's your choice.



create an asm file (or place these in an asm file you have reserved for tweaks) and paste this in it and insert it with asar:
Code
org $01D743 : db $80	; rope/saw
org $01DB6E : db $80	; grinder
org $0392B6 : db $80	; creating/eating block


remove the lines you don't want to disable, I that since the three of them all play the same sound at the same frequency (which is extremely grating) you'd prefer to remove them all over just the grinder



I do not feel that an unpatch should be a required inclusion. It should be encouraged but not required, given the tools that exist. I do think that we should have a specialized tag for patches that include one though.

Also, as a general suggestion: can we have all "bugfix"-related patches combined into one? Ideally we'd have defines created with essentially ones marked as on by default and others off. However doing this would probably require an unpatch, so that people can disable fixes if it causes issues or conflicts with other patches down the line.



You may have seen this discussed on Discord and you may have seen this coming (or not).

I've been programming sprites for over ten years now. When I was a brand new hacker, one of my first ASM-related goals was to make a unique sprite -- it would have been a carriable sprite that acted almost identically to a wall triangle in SMW. It was actually an idea I hoped I could bring to life as one of my first sprites.
Needless to say, I was never able to make it come true -- the ability to make a "sloped" sprite eluded me, and at the time I had no idea how to work around some of the unique issues it presented. I thought of maybe making a sprite that would lock into place like the Mushroom Blocks, becoming a wall triangle. That didn't work out because as it turns out anything sloped in SMW requires the "slope helper" tiles below them. I had a lot of plans for the sprite concept but all of the hurdles that I had to overcome were nearly impossible to work around with my skill level of the time.
Anyways, the idea left my head after the multiple failures so it was an idea lost to incompetence in my short-term memory. A while back however, I ended up having a half-asleep that evidenced the fact that it wasn't only a short-term memory and was actually something that was sitting in the back of my head for almost a decade. I realized that with my ability these days, I absolutely could create it now, if not ever before. After trial and error, I think I was able to make it the best that it can be. There might still be a few kinks I have to work out before an official release, but for now let's get to the point:

[DOWNLOAD LINK]

The initial X position will define the default direction.
If the sprite isn't carriable and the Extra Bit is clear, it will not have gravity and instead function basically like the stock SMW blocks. If you set the Extra Bit with this variety, the sprite gains gravity.
If the sprite is carriable, the Extra Bit being clear doesn't really do anything special -- it can be picked up and thrown as needed. If set, it will stick to walls for a while. This can allow some pretty insane puzzle tricks such as this:


I don't anticipate that this will be my only release this C3 unless I get busy with something else. Stay tuned.



I didn't get a chance to finish all of my SMB2 sprites this C3 since I also wanted all bosses and stuff at once as well but that wasn't happening.

In the meantime, have this:

[DOWNLOAD LINK]

A much-needed update to my Angry Sun sprite allows you to configure it to resemble the Super Mario Maker 2 version:



But that's not all! By setting the Extra Bit of the sprite, you can enable the Happy Moon as well:



Like in Super Mario Maker 2, touching the Happy Moon will basically defeat all enemies on the screen. I wasn't sure if the original game did it, but I decided to make it increment score for every enemy defeated too, so you can rack up lives using it.



list of mods/admin behavior that have been "less than exemplary":

- friend of person that had a gripe with the forum, basically gave them admin permissions for a "prank" that resulted in potentially years of lost posts, documentation and resources that were only available here. then somehow maintained their position on staff and tried to get people banned for little more than a grudge.
- sexual deviant (multiple)
- friend of sexual deviant that regularly tried to use their combined weight to get people they disliked banned
- legitimate pedophile that preyed on underage users of this community

add "sale of 'private information'" to this list

in a professional environment, unauthorized sale of data would result in legal repercussions that could bankrupt the owner(s) of the site. in an actual company these types of people would be banished, never to be employed by the company again and, in some cases, be remotely involved with it. i'm shocked this community is still seen as positively as it is despite all of the controversy surrounding it over the years.

i feel it's worth looking into the people that allowed this information to be sold in the first place; why was there nothing put into place to control the flow of potentially sensitive information? that falls on the people above nameless; the other admins and owner(s).

damage control through apology and action against the user after the fact isn't enough because nameless still financially benefited from the sale of that information. either nameless or the admin team/owners should be liable and willing to provide financial compensation to the user whose data was sold and not solely a hollow apology. and then when that has been taken care of, a reformation of mod/admin policy and a restructuring of the staff team should be done to ensure this will never happen again, including stripping rights from those that have no purpose to see this information.

that sounds ridiculous, doesn't it? because it is, any actual company would have to do that. the difference is that this is a mario hacking website and not an actual company, so your data doesn't matter and you effectively have no rights by posting on this forum and nothing is promised or guaranteed to you.

besides maybe a demotion/ban/whatever the staff team decides to do, literally nothing will happen and nobody will remember this or care in 3 days, short of the one person that has no reason to still be outraged.


but i'm just a shitbaby so here's the sole 2020 post i will make



Originally posted by Hobz
i've come to the realization that people really aren't this stupid, and a lot of the demonizing going on is coming from transphobes taking advantage of the situation to attack Nameless.

i dont think a single post was driven by transphobia not gonna lie, pretty sure very few people even know/care about nameless being trans


the original post is literally "i sold site information about a specific user" and nothing else, and that sounds a lot worse than it actually is until you append "...to that specific user" to it; at that point it just becomes hilarious. everyone outraged by it knowing the story are only mad for the sake of being mad which is a sign that they probably don't have a lot going on otherwise


here's my recommendation:
a warning system akin to the classic invisionfree one; shows a gauge that shows a users warning level and is only visible to them and staff; a reason and associated post (if eligible) is linked. if the user is banned for it, the ban reason shows there as well.
now people don't have to resort to buying their own data when their historical record on the site should already be visible to them.

again: posting as a shitbaby that rarely posts and rarely cares so i'll probably forget i posted here as i do




This is a sprite that functions similarly to the Ability Capsule items from the Kirby series.


By default, it can do the following when Mario touches it (or gets close to it, in the case of the egg variants):

  • Gives Mario a Mushroom
  • Gives Mario a Fire Flower
  • Gives Mario a Cape Feather
  • Gives Mario Star Power
  • Gives Mario a Throw Block
  • Gives Mario a Bob-Omb
  • Gives Mario a Shell*
  • Gives Mario a Baby Yoshi
  • Gives Mario an adult Yoshi

Similar to the Kirby series, Mario would not be given an item in reserve if he collects multiple powerups. These are optimal for scenarios where you want the player to utilize a specific item without giving them the ability to farm reserve items or thrown items.


*Green, Red, Blue, Yellow variants, along with the "non-Special world colored" Green shell, as well as a shell that becomes Disco when kicked.




This is a patch that rewrites the Koopa's normal walking tilemap. It adds a functionality that allows the usage of extra 8x8 tiles which can be simply toggled by setting a free RAM address. Make note of when I say "normal walking" tilemap: the shells, shell-less Koopas, and net Koopas are unaffected by this patch.


Included are some graphics files so you can use the Mario Wacky Worlds alternative Koopa sprites.
These new tiles are laid out like so:
Of course, if you're familiar with writing graphics routines for sprites, you can add more 8x8 tiles as needed.






This is a series of sprites meant to more-closely mimic their actual behavior in SMB2. Included -- for the moment -- are the following:

  • ShyGuy (Red/Blue)
  • Snifit (Red/Blue/Grey)
  • Phanto (Brown/Red) + Generator
  • Beezo (Brown/Red)
  • Tweeter (Red/Blue)
  • Trouter
  • Ninji (Jumping/Chasing)
  • Panser (Green/Red/Blue)
These sprites have a few unique things going for them. They use code (found in the /routines/ folder of the ZIP) that gives them "stunned" code similar to SMB2 -- where they will bounce on the ground a few times before recovering. Additionally, you can enable the SMB2 "combo" behavior -- if a sprite is thrown it can combo off of other sprites. Normal behavior can be set though, if you want them to act a bit more like SMW sprites.

The Phanto and Tweeter have new variants as well, triggered by the Extra Bit. A Red Phanto goes disco mode when Mario picks up the key. A Blue Tweeter will simply hang around ledges, similar to Blue ShyGuys/Snifits.
You may consider this "Series 1", as these are the base SMB2 sprites most people think of when they think of SMB2. "Series 2" and "Series 3" will include the following:
  • Vegetable
  • Pidgit (Normal/Carpet solo)
  • Autobomb (+ riding ShyGuy)
  • Ostro (+ riding ShyGuy)
  • Hoopster (Red/Blue)
  • Pokey (Green/Yellow)
  • Birdo (Pink/Red/Green)
  • Clawgrip (Red/Blue)
  • Triclyde (Green/Red)
  • FryGuy (Blue/Red)
  • Mouser (Grey/Brown)
  • Hawkmouth (Door/Boss)
  • Wart (Green/Blue)

I hoped to release Pidgit with Series 1, but I ran into some difficulties getting it to work 100% of the time.
I plan to make the alternative colorings of enemies/bosses slightly harder, assuming that they didn't already have them (like Birdo).

Originally posted by Counterfeit
Funny little troll idea. Kudos!

But remember, the universe always balances itself out. This will one day be used to share the good stuff with ZSNES users while anyone using another emulator is going to get shafted.

on the bright side, if it works on zsnes but not any other emulator it's not worth playing/using



Originally posted by Maarfy

Whatever happened to that Marching Milde, by the way?


GOD


I FORGOT MILDE



Normally I reserve C3 to release some of the ASM I've been working on over the last few months. This time I won't be doing that.

Instead, I'll show off a short video of a few things I have been working on. If you've been paying attention to #showoff on Discord, you've probably seen most of this already:



It might look like SMAS:SMB2 at first glance, but rest assured that it is indeed SMW, albeit heavily modified. Besides a few minor things (i.e. the "kick" SFX playing when throwing stuff) that I forgot to fix when I went ahead and updated it for SA-1 today. You might remember that I was working on a hack in a similar SMB2 style somewhere around eight years ago, which in retrospect looks the part but absolutely does not play the part.

A lot of code -- including the full behavior of the player character(s), was ported from SMB2. Meaning all the small things are implemented: Peach having a slower grab animation, Luigi's kicking jump, or Toad's super speed when carrying an object. This is thanks, in part, to SMB2 being insanely weird with how it handles physics (who thought to push jump height, running speeds, etc. to RAM?).

Of course, I'm not planning to release this as a patch for public usage -- it's actually a mess of code right now. But I might actually decide to work on a SMB2-styled SMW hack. Maybe.



And for the request part -- I'll be allowing a handful of requests sprite requests. I don't normally do ASM-related requests, so consider this a limited time thing.


A few ground rules though:
- 1 request per-person.
- Provide GFX. A .bin file would be cool, but a PNG image would be sufficient. I'm not going to draw it though.
- No blatantly joke or stupid requests.
- The sprite must not contain super complex AI.
- Cannot be a boss sprite (or at least, not a complex boss sprite).
- Sprite cannot have excessive animation frames, or have too many moving parts.
- If sprite is from a game and it should be accurate to the source material, ensure that I don't have to play more than a few minutes into the game to encounter and study its behavior.
- There's zero guarantee I'll actually complete it, but I'll try. That's how things go with me.

I'll be keeping track of those that make unreasonable or blatantly joke requests, blacklisting them from future ASM requests if I do them again.

The first things I think about are most of the SMB2/SMB3 enemy cast up to the NSMB games, or games like Cave Story or Metroid.

Only the first 5 requests made in this thread will be accepted. If I find enough interest in it, I might hand-pick a couple others, so don't be deterred even if all slots are gone.

The list is as follows:

1. Super Mario Advance 4 / Blue Boomerang [?] (COMPLETE)
2. Super Mario Bros. 3 / Goomba/Kuribo Shoe [?]
3. Trenchcoat Ninji [?]
4. Strollin' Stu [?]
5. Yoshi's Island / Ukiki [?]