 |
|
 |
|
| Posts by Nicol Bolas |
|
|
|
|
|
|
|
|
I need to perform a logical NOT on register A. That is, if A is non-zero, I want to set it to zero, and if it is zero, I want to set it to something non-zero.
There's a very obvious way to do this through branching that I can use. But is there another, cleverer way to do it?
|
|
| (restricted) |
|
|
OK, so the original Block Tool used .bin files rather than assembly. I want to figure out how some of its blocks work. However, since they're not in assembly, I can't read or follow their code.
Does anyone know how to convert these files back into assembly language?
|
|
|
|
|
So, I have a byte who's value I want to have persist not just between levels, but between save/load cycles. Does anyone have any ideas as to how to best accomplish this?
|
|
|
|
Quoteso there is no way to just take a jumping routine for example and put it in my code......if not, then what is the point of disseseblys!!!
So what exactly were you expecting? Even if you had the actually source assembly file, it's entirely possible that there would not have been a comment saying "jump routine starts here." Once you strip assembly of its few niceties and convert it into binary, you're not getting back certain information about it.
Disassemblers exist so that you don't have to sit there looking at a patch of binary; you can look at it in something remotely resembling human readability. They do not exists to explain exactly how the code works, or to find a particular routine, or what have you. Those are things you use a disassembler to do, but they don't do it for you.
|
|
|
|
So, let me make sure I understand this correctly.
I increase the size of byte 0x81D8 (0x200 less if an un-headered ROM). This expands the size of a save game file.
I can then directly access this memory using addresses starting at 70:0800 (after all of SMW's save game stuff). Should the code that accesses this memory be in a particular place? That is, are you only allowed to write to this memory during game saving, or can you write to it at any time?
|
|
|
|
Quoteyou can write to it *any* time although if you only want data commited to sram during the player's game save, you'll have to hook the save routine.
Oh. So, if I wrote to this memory at any time, and the player didn't make it to a save point before they ran out of lives, the data would be saved anyway?
I might be able to live with that. However, in case I can't, would anyone happen to know a good place to patch into the save/load routines?
|
|
|
|
Here is how pipes/stars work.
SMW has a table. Each entry in the table can refer to a pipe/star. That is, a particular location on the overworld. This is the "Exit Index To Use" field. When you select a pipe/star and bring up that dialog, you are telling LM to put this particular position in the table.
So, if you have a pipe in one location, you can set it's exit index to 0x00. If you have two pipes, you set the exit index for one to be 0x00 and for the other to be 0x01.
Now, you need to say where that pipe/star should go. To do this, you select it and set the "Destination Exit Index". This value is an entry into the same table; it is the entry of the location where you want to go.
So, if you have the two pipe example above, and one is set to index 0x00 with the other to 0x01, here's what you do. You select the 0x00 pipe, and set its destination exit index to 0x01. And then you select the 0x01 pipe and set its destination exit index to 0x00.
If you move either pipe, you need to redo all of this, as it is based on locations, not the pipe itself.
|
| Last edited on 2009-04-14 04:24:19 PM by Nicol Bolas. |
|
| (restricted) |
|
|
|
It seems to me that the first thing you need to understand is how graphics works in SMW. This ought to be a reasonably decent primer on the subject.
|
|
|
|
QuoteI would like simple noob straight forward instructions specifically for npc 3.0 as to how to make it show toad and not half a chuck with a fire guy.
That's the problem; you don't need a "noob straight forward instruction" for doing this. What you need is to understand how images get built into things like sprites, where images come from and so forth. Once you do, you will understand exactly what you're doing wrong and how to fix it. More importantly, when the time comes to do other things like custom block graphics or custom sprite graphics, you will likewise already know what to do.
However if you don't want to understand what you're doing and just solve the problem for now, your problem is that you have not loaded the particular ExGFX into the correct SP bank for that level. In order to use any sprite, the correct GFX must be loaded into the correct SP bank in that level. Since your GFX is in an ExGFX, you need to use the Super GFX Bypass under the Level menu. Activate the bypass by pressing the checkbox button, and then load the inserted ExGFX into either SP3 or SP4. I can't tell you which one, as it depends on the sprite.
|
| Last edited on 2009-04-15 02:48:30 PM by Nicol Bolas. |
|
|
|
Small point about the creating/eating blocks.
The direction specifies where the creating block goes. The eating block is programed to simply devour any block that is adjacent to the current block. So you must make sure not to have the path of the creating block do anything that would confuse the eating block. Like:
In this case, if the creating block goes up first, and loops back around before the eating block has gotten to that first turn, it may not eat the correct block. Always make sure that there is only 1 block the eating block can eat.
|
|
|
|
The creating block follows a path, but the eating block does not. All the eating block does is look at the four adjacent blocks. If there is a brown block in one of them, then it eats it.
Therefore, you must ensure that at no time are there two brown blocks next to it. Unfortunately, the code blocks on this forum won't display text with a fixed-width font, so I can't draw you a picture. Try to imagine this.
The creating block moves 3 to the right. Then it moves up one, right one, and down one. Then, it goes back to moving 3 to the right.
The eating block eats 3 blocks, each one to the right. Now, there is a brown block above it and a brown block to the right of it. Which block will it eat? You can't be sure. The algorithm the game uses will pick one, but there is no guarantee that it will be the one above it rather than the one to the right.
So you must ensure that the creating block won't create situations like this.
|
|
| (restricted) |
|
|
QuoteWait...you mean I have to use the same four GFX/ExGFX files for all seven maps? If that's true, then that could be a problem.
Technically... no, that's not true. You can do what you want as long as you're careful.
Lunar Magic allows you to have different GFX combinations for different submaps. However, as LM is kind enough to tell you, this is not the normal state for SMW. Therefore game will only load the new GFXs if either:
1: Enter a level and exit it in some way (death, end of stage, etc).
2: Enter a pipe/star.
That means that the "bridge" path tiles that send Mario to different submaps will not load your new GFXs for that submap. So you should make sure that the only way to get to/from different submaps that use different GFX sets is with pipes/stars.
|
|
| (restricted) | | (restricted) | | (restricted) | | (restricted) |
|
|
Originally posted by Cehkcan someone give me an answer?
No; you have not told us enough about what you have changed in your project from the original SMW ROM. What patches have you applied, blocks you have inserted, GFXs you have changed, etc.
|
|
|
|
|
|
|
|
|
|
 |
|
 |
The purpose of this site is not to distribute copyrighted material, but to honor one of our favourite games.
Copyright © 2005 - 2013 - SMW Central
Legal Information - Link To UsTotal queries: 27
|
|
|
|
