11 March 2016 - Forum Rules
Started by ShadowOne333, March 15, 2018, 01:29:52 PM
Quote from: dACE on January 31, 2019, 01:00:05 PMWhat would happen if you moved the boss health-bar up by one tile (Y-8)?Wouldn't that solve it?/dACE
Quote from: Vanya on January 31, 2019, 06:49:20 PM:pops head in:Or you could just eliminate the pop up numbers entirely?:runs back home:
Quote from: Trax on January 31, 2019, 10:04:44 PMThe white bar trick is not dark magic, it's just because sprites always use two tiles, n and n+1. What IcePenguin did is, he set the white box graphic as the top tile (the n tile) and an empty (transparent) graphic as the bottom tile (the n+1 tile). It's clever, it works for the HUD, but since it has a side effect elsewhere, it's not ideal. The reason the Boss Meter is displaced is because it's made of sprites, and not part of the background. The white meter portion uses the same offset as the magic box, so it's shifted up.The original code lays out the red and white boxes as the same Y position, but different X positions. What we want here is exactly the opposite: same X, different Y. Likely, the code could be modified without even having to bridge.
Quote from: IcePenguin on January 31, 2019, 11:36:36 PMDo they have a Y position value? I'm not doubting you, or anything, since you're extremely knowledgeable when it comes to Zelda II. In an earlier post I made, I even mentioned something about the magic tile and health tile sharing the same Y value, but I'm not so sure it works that way. Please correct me if I'm wrong. With every element in the HUD, there has only been data to indicate an X position. For things like the life stat, magic meter, etc. if it goes beyond a certain X position, it is shifted down to the next line in the HUD. However, with the magic tile and health tile, it simply wraps to the other side of the screen without shifting down. So I'm thinking there may be no Y position in the traditional sense, and they would instead have to be changed to work the same way as everything else, and shift down when exceeding a certain X position.
Quote from: Trax on November 28, 2018, 01:18:45 AMAs for the white Magic square, it's actually a sprite that is drawn in the background (there's a sprite attribute for that), and serves as the last container that is not full or empty. Full and empty containers are drawn as background tiles. Same for the Life square. These sprites move leftward as you take damage or consume magic, and rightward as you gain them.I checked the code starting from the offset you gave me, and the code that sets the two sprites is a little further, starting at $17BB. There are 4 values written in sequence starting from $02F8 (this address is in a 2-byte table just before this routine, at $17B9), using the command STA ($00),Y. First value is 0F, which is the Y position of the sprites. This is your problem. The original game uses the same Y position for both. Your setup doesn't.Second value is the tile code, taken from $1689 (70) or $168A (6E), depending of whether you're drawing Life or Magic. Third value is 0x21, which is the sprite attributes, and it sets the palette to 01 and activates the flag to draw the sprite in the background. Fourth value is the X position, taken from $168B or $168C, plus the value of the last unit of the meter.Ideally, you'd have to rewrite the routine in a way that swaps the operations for X and Y positions. Your case has X position the same for both, so it would be hard-coded, and Y position different for each meter, so it would be taken from the table.
Quote from: ShadowOne333 on November 30, 2018, 12:08:09 PMThis is a quick comparison of what I could do in-game compared to what my mockup was: In-game / Mockup Now there are some particular problems in this:The same issue with one of the meter bars moving only in an X positionThe PPU tilemap for the life meter is tied with the Exp zeroes. This is why they always tend to show up right next to each other.The PPU tilemap for the magic meter is tied with the number for the Life level, hence why the magic bar begins at the very edge of the screen in my test.Given the previous issue with the Magic meter, the "M" might disappear due to overscan and on CRT monitors.I tried to locate the part of the code where it loads the tables for the tile mappings, and found it at $16BD and $172E.So, went ahead and reimplemented the tilemaps for those two in free-space, and tried separating them into proper tile maps in the AA BB XX format for each section, but i think this goes way beyond that, since the code I believe expects them to be right next to each other and with a set number of bytes, otherwise they won't be separated from each other.
Quote from: ShadowOne333 on February 01, 2019, 12:11:56 PMHere's the latest beta patch:https://www.dropbox.com/s/5dbq6pl321fj2dh/Zelda2Redux.ips?dl=0
Quote from: darthvaderx on February 01, 2019, 12:45:22 PMOpss, wrong patch, the rom remains unchanged.
Quote from: ShadowOne333 on November 30, 2018, 12:08:09 PMThis is a quick comparison of what I could do in-game compared to what my mockup was: In-game / Mockup Now there are some particular problems in this:The same issue with one of the meter bars moving only in an X positionThe PPU tilemap for the life meter is tied with the Exp zeroes. This is why they always tend to show up right next to each other.The PPU tilemap for the magic meter is tied with the number for the Life level, hence why the magic bar begins at the very edge of the screen in my test.Given the previous issue with the Magic meter, the "M" might disappear due to overscan and on CRT monitors.
Quote from: IcePenguin on February 01, 2019, 03:33:09 PMLooks great for sure! Here is a simple solution to the sprite zero.Tile edit it! It's what I did in Shadow of Night. I just tested your new HUD with it (quickly recreated it), and it works.Simply reduce sprite zero to 1 pixel. It will still overlap with the "E" in your "-EXP-" so it works as intended, all while being hidden. Again, I did this in Shadow of Night, and there were no negative side effects. Edit: Just to clarify a bit on what you said, you don't necessarily need anything in position 6D. As long as something in the HUD has collision with sprite zero it will work. So luckily, sprite zero is positioned in such a way to be in position 6D and 6E. I'm sure there is an X position for sprite zero, but I think it'd be risky to move it as Trax said not to. So a simple tile edit will get the job done, without all that extra work and testing.
Quote from: IcePenguin on February 05, 2019, 07:06:18 PMOne thing I noticed in your latest update is the shield icon (life) in the file select menu is different than the one in the game. Didn't notice that in previous builds. Is this intended? Seems odd, but it's not a big deal.Also, I have one major recommendation for your hack. It's simple enough to change, but it makes a huge difference. Increase the speed of the sword beam and fire spell. They share the same data for speed, so you'd have to increase both - which is great thing.The data for this is at 0x1829.20 E020 is the right-directional speed, and E0 is the left-directional speed. I suggest changing it to 30 D0. It'll move much faster, and as a result travel a bit farther. A much desired improvement, I believe. Also, like the new triangle tile for the "-" in the HUD. Fits well!
Quote from: njosro on February 05, 2019, 07:36:37 PMGreat work! I noticed in the second two screenshots that the arrows surrounding EXP and LEVEL both point to the right. Not sure if that matters. Edit: Oh I see IcePenguin has spotted it too!As for the cursor on the file select screen, I looked at the code in that area, and it looks like you'd need to jsr to free space if the up button is detected and copy the existing section of code into the free space but tweak it so that it moves the cursor up. I say this because the code to move it down contains instructions for skipping inactive files, wrapping back to the top after the elimination mode option, etc. It's all for the downward direction. With the space limitations, it's easier to add separate code for up than to add additional branching paths to the existing code. Imho, it's more effort than it's worth, but maybe someone could find a different approach...
Page created in 0.056 seconds with 20 queries.