SeaFoodAndButter
New member
Does anyone have the script from Mystic Searches that allows your character to walk waist high when you walk through water? I would like to use it in my game.
darkhog said:I'm pretty sure they just replace player object with another one functionally identical, but having lower hit box and animations that makes the player character look waist high, could be wrong though. Still would need some custom coding but it wouldn't be too difficult if you can get your hands dirty with asm .
FrankenGraphics said:The easiest way to make something appear as if behind the background is actually pretty straightforward. You toggle the priority bit of each sprite in your metasprite. That's bit 5 in byte 2 of a sprite object. (remember, in programming we start counting at 0, not 1. So byte 2 is the third byte in normal-speak).
Each sprite object consists of 4 bytes, ordered like so:
yposition, tileID, attributes, xposition
Attributes holds both the palette ID and a short range of special attributes, responsible for flipping the sprite horizontally or vertically, and for drawing it behind the background.
in my defines, i keep convenient aliases for the attribute bits:
VFLIP = %10000000
HFLIP = %01000000
BEHIND = %00100000
That means if i want to set some attribute independently of palette for example, i can use the OR sign (that's | ) to logically OR palette with attribute, like so:
01 | BEHIND
that means palette 1, draw sprite behind.
to assign that to a sprite, i can for example load the accumulator with that value:
LDA #1 | BEHIND
and then store it to the attribute of my sprite OAM buffer.
STA AddrOfMySprite + 2
the +2 is because your sprite has an address, whatever that may be, and adding an offset of 2 will target byte 02 rather than byte 0 (which would be the y-position - you don't want to overwrite that!)
Remember that colour 0 of background palettes aren't really part of the background. It's the splash/fill colour behind the background. So sprites with the BEHIND attribute set will get drawn on top of colour 0, but behind colours 1-3.
As for the original question... yeah, just remove the legs. Maybe with some nice watersplash/shadow tiles below, if you want the extra finish.
Houses, trees, and other background things don't have hitboxes. Typically for any 2d game, backgrounds have coarse collision maps, which is easier to compute, especially for the poor old NES.
Yeah that statement is only true in the technical sense as far as i'm concerned. As in you can do it, but then what? It's almost in the same way you can make a game without coding in GameMaker, but soon encounter things where you wish you could do this or that. So sooner or later, there's the threshold where you have to dive into some coding to achieve the results you want. That threshold is bound to happen a lot sooner in NESmaker than in GameMaker - not so much because of NESmaker itself as because the NES is a machine that 1)has very few and limited resources 2)use them very efficiently 3)making a game for the NES is all about careful resource management and bean counting and there's no way around it. An app on a modern computer is mostly software driven. Something on the NES is mostly hardware driven. You literally tell the hardware to do things, instead of telling software to tell other software to do things for you as is the case on a PC. That can take a little time getting used to. The good news is that NESmaker takes care of a lot of the structure, you can focus on getting a feel for using individual instruction here and there to alter the game in some ways and grow from there. I think it ought to be pretty organic.You have to remember, one of Joe's MAJOR selling points to NESMaker was you didnt need to know code to make a game.
You have to remember, one of Joe's MAJOR selling points to NESMaker was you didnt need to know code to make a game.
Quite off topic, but you may be interested in following the development of wiz-lang: https://twitter.com/eggboycolor/status/983993348276006912darkhog said:Anyway, I'm kinda sad that Brian's Provinciano NESHLA never went anywhere. I mean, asm6 is way better than ca65 or NESASM will ever be, but NESHLA was a beauty IMO.
darkhog said:Again, I'm pretty sure Mystic Searches is just replacing player object with different one that has "in water" animation when player is on water tiles.
Anyway, I'm kinda sad that Brian's Provinciano NESHLA never went anywhere. I mean, asm6 is way better than ca65 or NESASM will ever be, but NESHLA was a beauty IMO.
Where did you get that idea? i mean, which each and everyone prefers is a matter of personal taste, but i don't know who'd argue against ca65 being the most versatile of the two. asm6 is a little simpler to set up the first time (ca65 requires reading a bit in the manual or following a tutorial or template the first time unless you come from a similar assembler already), but that evens out quickly.I mean, asm6 is way better than ca65
No public commits doesn't mean dead. You can join the discord and ask questions if you like:darkhog said://edit: Wiz looks dead too, though - last commit was over 3 years ago and the official site has big "coming soon" that welcomes to check "work in progress source" so it isn't even like it's feature-complete, just abandoned.