Water Script from Mystic Searches

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

darkhog

New member
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 ;).
 

dale_coop

Moderator
Staff member
I would make a different animation.
That is played when the player moves on Water type tiles.
 

SeaFoodAndButter

New member
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 ;).

I think If I did that, it would make me look like I was walking behind the water tile, right? Just like if I made an NPC with a low hit box would make me look like I walked behind him/her. Right. That actually makes me wonder if it's possible to make like a house or something big with a low hit box to make it look like you walked behind it? Like for a hidden way to get somewhere are something like that. Hmmmm?
 

FrankenGraphics

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

SeaFoodAndButter

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

Bro, you're so far above my league when it comes to coding that when I read your messages it's like I'm trying to dicipher ancient Egyptian hieroglyphics.

What this community needs is people like you who know a lot, but people who can just help rookies out rather than assume they can comprehend or do what you're saying. There's no way I could take what you wrote and actually use it. I'm a noob and a rook at this.

Anyways, since I have zero knowledge in coding, I have to look for ways around things. So, if I wanted to make it look like my player went behind, say, a wall or a tree or a house, all I can think of with my limited knowledge is to make said tree or house a monster object with a low hit box. This should make it appear as if my character walks behind said object. Im going to test it tonight and see if it works.

As far as the water animation goes, the only thing I understand is that somehow I need to make a walkable water tile, make an animation of my player that only contains his upper torso and somehow tell the engine to use that animation whenever I touch a walkable water tile. How to do this? I don't have a clue and will simply need someone to help me understand the steps to do it and make it work. Otherwise I'm outta luck.

You have to remember, one of Joe's MAJOR selling points to NESMaker was you didnt need to know code to make a game. That is technically true, but it's not the truth realistically. NESMaker was sold as if there would be literally tons of drop down options that would do all kinds of things. As a result, many people on this forum and in this new community cannot code and don't understand things on the same level as someone like yourself. That's why people like you can actually help a lot. But you have to be a bit more understanding that you're probably far above most ppl here.
 

FrankenGraphics

New member
ok, then let me try to break it down. I understand there is a lot of lingo, and going though it all and getting a feel for the words is a royal pain, but it'll hopefully be worth it in the end.

A sprite = the things that move on the screen. It consists of two things - the tile you see, and some data that governs where on screen it should be (x position and y position, what palette of colours it wears currently, and if it is flipped in any direction, and, lastly... if it is going to be drawn above or below the background. An example of sprites that are drawn behind the background is the piranha plants in Super Mario Bros. Notice how they are drawn in front of the blue sky, but behind the tube? That's because the blue sky is "colour 0". If you watched the NESmaker tutorials, you know that colour 0 is common across all four palettes. That's actually because in reality, background palettes are just like sprite palettes. Three colours and a transparent "colour". What we use to call "colour 0" is simply a single fill colour that paints all of the screen in that colour. Then the background with its three colours and transparancy is drawn on top of that.*
So that's how the piranha plant is on top of the blue, but behind the three colours of the pipe.

I'll stop here before continuing so you have the chance to ask any questions if you want to.



*If we're really pendantic, that's not exactly how it happens, but it is easier to explain it that way, and helps to think of them as two layers in, say, photoshop or whatever. What really happens is that the PPU (picture processing unit) goes pixel for pixel, left to right, line for line and evaluates what it should draw. A pixel from the splash/fill colour (blue in the case of mario's overworld), something from the background tiles, or something from the sprite tiles.


You have to remember, one of Joe's MAJOR selling points to NESMaker was you didnt need to know code to make a game.
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.
 

SeaFoodAndButter

New member
You have to remember, one of Joe's MAJOR selling points to NESMaker was you didnt need to know code to make a game.

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.
[/quote]

Can someone use the NESMaker to make a "game" and not do 1 line of coding? Sure. But the game will suck and won't be anything like the person wants. I mean, right now all you can do is make a start screen, press start, go directly into the game with no cut scene or introduction, and then when the game is finished, there's 1 "win" screen and that's it. I mean, there's no option to make ending screens to finish the story or show credits. So, I agree with you. You can technically make a game if having 1 start screen, some game play, and 1 win/end screen = technically a game. But I think most people are trying to make an actual game that is fun and interesting to play; I know I am.

I totally agree with what you've said about needed to code. When I first found out about NESMaker, I initially was thinking that it was cool if it were possible to make an NES game without code. However, once I decided to be serious about making a game (e.g., taking the time to write a good story, learning pixel art, Famitracker music production, contacting artists and musicians for help, etc.), I quickly realized there was going to be no way around coding. After I wrote my story, did some art, and some music, I quickly realized that there really was no way for me to do the gameplay things I wanted to do in my game because I don't know how to code. Joe would have to make so many "drop down" codes within NESMaker that he couldn't possibly think of everything that people would want.

I'm sorry if I sound like I'm complaining or lazy. I totally understand what you're saying about coding. Trust me, me not knowing or understanding how to code machine language is not a result of lack of trying/researching. For example, in my game I want a melee system like Zelda 1 NES. So, I start with no weapon. Quickly find a weapon, and as the player progresses through the game, he picks up improved weapons that replace the former weapon. Like how in Zelda, you start with no weapon. then you pick up the Wood Sword. Then eventually you pick up the White Sword that automatically replaces the Wood Sword. Later on, you pick up the Magic Sword that automatically replaces the White Sword. I want to do a similar thing. But I have not 1 clue how to code that. I look, and search, and read, and try to learn but I haven't found 1 manual or person that can say, "ok, you are trying to do this 'Zelda-type' thing with your melee weapon upgrades. Here's what you need to look into."

Anyways, right now, I have a start screen and some overworld level design. I'm basically just drawing my overworld with no enemies, npc's, shops, game objects etc. etc. Just drawing out the world, hoping that later on I can 1) get some help with coding the things I want to do and 2) learning how to script things.

I appreciate you responded to me and at least trying to help. THANK YOU :D :D
 

FrankenGraphics

New member
Okay, what next to demystify... let's talk defines.

Defines are something the programmer sets up for their own convenience. It can make code more readable, or make it easier managing settings and options when assembling* the program.
You typically put all of your defines at the top of your main code document, or include them in a separate file, so that they're always easy to find. A type of definition is an alias. That's what i was talking about in my first post.

An alias gives you handles over functions. If you've scouted through the nesdev wikipedia, you might've encountered occult words like $4016, $2001 and so on. These are addresses to hardware functions**. Now, eventually you tend to memorize these if you keep using them, but they can still be a pain especially in the beginning So why not give them descriptive names? That's what aliases is for.

PPUMASK = $2001 , for example. There are commonly established names for each hardware register, based on what they can do for you, and i'm sure these are somewhere in the NESmaker assemblyfiles if you take a peek.

You can also define useful constants this way. Just a silly example

ZERO = 0
ONE = 1
TWO = 2

(zero = 0 is also okay, i just use caps because that's how programmers traditionally know it is supposed to be a constant, unchanging.)

So next time you do addition, you can write 1 + 2, or you can indeed write ONE + TWO. The result will be the same, because you've taught the assembler that ONE equals 1.

NESmaker uses asm6 as its assembler if i recall correctly. then the syntax*** is a little different. You can either write:

one EQU 1

(where EQU stands for equate). or

one = 1

the difference being you can reassign aliases done with the = sign.

so:
one = 1
one = 2

one + one

will result in 4, because you reassigned it. EQU is safeguarded against reassignments. I think the intention is to use = for temporary value holders, like n, i and so on in math. So separating "one" from "ONE" doesn't mean as much here. But meeeh, whatever you can do however you want.

defining constants is also good because you can assemble different blocks of code based on your defines. this is called conditional assembly.

So INCLUDEEXPERIMENTALROUTINE = 1

can be used to later see if you want an experimental code block to be put into your final program or not. How is for another day. I'm just pointing out its versatility.

Now, for the real meat of this post.

BEHIND = %00100000

BEHIND is your new defined constant. % is a prefix that tells the assembler that the following number is a binary string of data. You have 8 bits in a byte. As you can see, there are eight digits in that number. So everything adds up, and each one represents if a bit is supposed to be on or off.

This particular bit, if used in the right place, can be used to toggle if a sprite should be prioritized before or behind the background, because well, check out this reference: https://wiki.nesdev.com/w/index.php/PPU_OAM

With BEHIND you can tell the PPU which of each and everyone of the systems' 64 sprites ought to render on top or below the background. There are still some puzzle pieces missing, but let's stop there for now and see if you have any questions.

*(Side note: when we use assembly language, we call the process of converting our code in text to a binary assembling. There's a technical difference between this, and compiling, which is something you do for high-level languages, but not for assembly).
**again, a lot of the stuff that happens in the nes and especially on the screen, is because of hardware functions. there's little transistors and diodes and what not sitting there, doing very specific tasks for you, and you communicate with them about what to do via something called hardware registers. A register is typically a collection of so-called flags that signal when something should happen, or that something have happened. Sometimes you read them to know what to do next, or sometimes you write them to tell the system what to do next. A good deal of NES programming is about this exact process.
***Syntax is like the grammar or sociolect of the assembler, and because of differening personal preferences and design philosophies, they're not always the same, which means that you can have an assembly program that will work in one assembler but not the other because of programmers not being able to agree on what the best grammar is ;)
 

darkhog

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

Kasumi

New member
darkhog 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.
Quite off topic, but you may be interested in following the development of wiz-lang: https://twitter.com/eggboycolor/status/983993348276006912
 

darkhog

New member
Really cool, thanks. I wish Joe would go with wiz, but probably didn't because he didn't know about it or thought it was too early in development and rewriting entire engine into wiz now would be counter-productive (even though it would make messing with the engine a tad bit easier for people with high level language experience).

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

FrankenGraphics

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

Yes, that question was answered. Then the OP asked about how to hide things behind a house. That question has not been answered just yet. There's even multiple viable methods towards that end.

I mean, asm6 is way better than ca65
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.
 

darkhog

New member
Macros/defines and other "sugar coating" that's not really necessary but very useful is just better in asm6.

As for hiding player behind house/tree/etc most games didn't do that and with a good reason. For one, background needs to be absolutely solid so suddenly grass won't be on top of player and using sprites for trees or roofs is a big no-no as well since the sprite limit is very small on the NES and it can't display more than 8 sprites on a single scanline anyway, without someone writing a flicker routine for the NES (normally if sprites per line are outside of limit, PPU just stops drawing it, the flicker you see in some games is the way programmers worked around that limit and it isn't caused by NES). Speaking of which, a flicker routine would be a great thing for NM even if it would only allowing 16 sprites per line max.

So I'd just make entire tree/house/whatever completely solid, just like Gamefreak did for first Pokemon games (this is also why buildings in Pokemon are mostly square to the point they can be easily rebuild in MC - GameBoy, just as NES, also has only one graphics layer (the ability to have more came only with GBA) and I guess they've decided to make house squares so player wouldn't have any misgivings as to where he/she can go or not, then it just stuck around as part of the style.
 

Kasumi

New member
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.
No public commits doesn't mean dead. You can join the discord and ask questions if you like:
https://twitter.com/eggboycolor/status/1030254232115535874
https://twitter.com/eggboycolor/status/1031401482338414592
And something not being updated in a while doesn't mean useless.
RE: behind a house, I wrote a post on this subject here that might help with understanding: http://nesmakers.com/viewtopic.php?f=24&t=534&p=3277#p3277
 

FrankenGraphics

New member
The crysalis example needent’ be nearly as sparsely decorated with grass details, though. Only tiles that contain a supposed overlap need to flip the priority, and we only need to do that for the actual sprites that cause overlap, instead of the whole meta. Results may vary depending on if you use a 8x8 or 16x16 pixel coarseness of the properties you assign to BG tiles or metatiles (which one is NM:s case? 16x16 is my guess?), but you can still get quite close with your detailed or textured tiles.

Furthermore, you can approach it from the artists’ view and decide that area is a black or blueish, teal or olive drop shadow, and that’d explain the lack of details. A teal or blue drop shadow would have plenty of reuse opportunities in a grassy field.

Even if NM would assign a single priority state to its actors (does it?), you could still modify the OAM buffer to taste afterwards.
 
Top Bottom