The BVZ issue is my bad. Again, I copied a 'bad' copy from another directory. It's fixed now. Also fixed a minor issue with taptap, one of the frames of his shoe had a BVZ tile in it.
I honestly don't know what the deal with taptap is. I've never encountered any glitches with it. Well, if I messed up the same way I did for BVZ, it was from the wrong directory. This one has never glitched on me in quite a few tests.
EDIT: If you have no issue with it you can send me a ROM /IPS and if you can, a save state before the crash occurs so I can see what is really happening. I may have overlooked something but I can't find anything wrong that would cause random crashes.
I fixed a few issues, the most serious ones being the sprites hoarding memory (again). It should be fine now. Forgot that the BVZ makes sound too. Also, I added a needlenose (bouncy green cactus) BVZ. It's set for custom sprites, so that particular one can be used as a base for them. again, you have to set it up in the .asm file.
Oh, and A YI Boo is coming next. The 32x32 one that provides a nice gap between a resourcing hogging big boo and the originals.
Change the needlenose one if you want it to drop custom sprites. Change the Goomba one to drop standard sprites.
SPRITE_NUMBER = $02 ;SET THIS TO THE SPRITE OF NEEDLENOSE
SPRITE_GFX = $0E ;Set this to the GFX of the sprite you want it to hold
SPRITE_PROP = $1B ;palette, GFX page etc.
In the .asm you'll find this. SPRITE_NUMBER is the number of the custom sprite you want it to generate. It's the same as the number you put into the input .txt for sprite tool. SPRITE_GFX is a tilemap entry for a 16x16 GFX that it will hold until it's generated. SPRITE_PROP is the general properties in the 'Xyppccct format'.
EDIT: I have to lookup the dissasembly to figure out how the line guided sprites work, but don't count on the circular blue hypno platform since it would be really taxing on GFX space.
I have no issue getting it to hold + generate one of them. So I can't provide any help beyond asking you to redownload it...I don't recall fixing an issue like that but I can't think of anything else. You are reinserting the sprite when you change the variables, right? It sounds silly but there's no other logical reasons I can think of why it would do that.
LDA #SPRITE_NUMBER ;load sprite to generate...
STA $9E,y ;into sprite type table
STA $0302,y ;sprite to gen GFX
These bits take the values in the variables you just posted and put them into action. The variables aren't being changed if it makes the same sprite.
Why does that shy guy hides in the bush so weirdly?
There's actually a flower behind the bush. The flower has BG priority set to be behind the bush. The shyguy has sprite priority to be behind the flower, but BG priority to be infront of the bush, so it gets obscured in a wierd way. It's just a quirk of the sprite rendering, I think.
E: Coming soon:
You'll set a sprite to generate like the BVZ and how many of the generated sprites can be on screen at any given time.
Naval Pirhana isn't happening. If it does, it's not me who's making it.
My take on Egg Plant is done. Extra bit decides on custom / standard sprite and Extra Prop 1 decides what sprite # to generate. Extra Prop 2 is how many can be on screen until it stops generating. THere's nothing to config in the .asm.
That reminds me...I should've put a note in Grunt's file before, so here it is now.
;IMPORTANT: Sprite clipping offset is 9 by default, but may be wider than you'd like.
; Sprite clipping offset 1 is a viable alternative, which is less wide. This will cause the sprite to be unaffected by being
; hit from a block from below.
BVZ_shyguy is fixed (one byte mess up) and eggplant now makes a sound when spitting. No sound for the blowing smoke though. Can't think of anything for that. Did I miss the sprite release from MiOr, or is it just an observation?
I might close pack 2 with a Stretch and start on a shooting pirhana next. Well, whatever I feel like making I'll make.
Boing: I'm getting the stuff in your first post, actually. Shells kill, throw blocks pass through. It seems when you use a shell, it uses it's normal sprite clipping and acts normally. Using a throw block, it uses a different sprite clipping (???). If you throw a block across the floor, it will not harm it. But try throwing a throw block so it comes down on it's head. It'll kill. Makes no sense, really.
Random commentary follows...
I've been shown a problematic taptap that in the ROM I've seen it in, causes sprites to glitch throughout the level. When I've reniserted the sprites with no changes to the cfg, it works normally. What the hell? Taptap has been the most problematic apparently and it's stupid randomness like this that makes creating these more of a hassle than it should be.
EDIT: I confirmed the problem. When tap taps are encountered, all sprites loaded from there on are stuck in initialisation status. I don't think I even have control over that.
I count more than 5 sprites. Don't bet on it. Primary reason I abandoned goonies and poochy. There'd be the tedious task of compositing sprites (and that takes up up alot of GFX space) to fit in the tile count.