 |
|
Main
| FAQ
| Uploader
| IRC chat
| Radio
| Memberlist
| Active users
| Latest posts
| Calendar
| Stats
| Online users
| Search
| |||
| Views: 88,511,792 |
Main
| FAQ
| Uploader
| IRC chat
| Radio
| Memberlist
| Active users
| Latest posts
| Calendar
| Stats
| Online users
| Search
|
05-02-24 10:01 AM |
|
| Guest: Register | Login | |||
| Main - Posts by NetSplit |
| NetSplit |
| ||
|
Level: 32 Posts: 41/178 EXP: 188121 Next: 18321 Since: 02-26-07 Last post: 2223 days Last view: 2148 days |
I recognize that city background anywhere; it's the Top Man beta background, albeit modified. I recreated it for my Mega Man 1 hack.  Nice work.
It's nice to see some more Mega Man hacks being made, but also a little disappointing to me that they're all crossovers (the only crossover hack I've seen where the crossover just felt 'right' is Extra Mario Bros.). Not to complain or anything; I'm definitely looking forward to the stage design! Keep it coming. Oh, and Googie, remember that if you run into any issues with Mega Man 1 while doing that hack, feel free to let me know and I'll be happy to help you out. |
| NetSplit |
| ||
|
Level: 32 Posts: 42/178 EXP: 188121 Next: 18321 Since: 02-26-07 Last post: 2223 days Last view: 2148 days |
Gah, Dr. Mario, you unwittingly convinced me show off my own use of the background.  This here is from my own Mega Man 1 hack:
This is Bomb Man's new level, and is my current task in the hack. I've finished about half of the stage's level design. In order to fit all of the graphics, I'm having to do some background swapping later in the stage. The stage also makes use of several very cool new features that are unique to this stage (3 in all, 2 of which are finished). The graphics aren't 100% finished yet, but what's there in this screenshot is a pretty good representation of what the final will look like (I might fiddle with shading a bit, and possibly the palette). The sun in the background is actually a sprite that I've programmed in, and the fence up at the top of the stage is in the foreground, so all sprites go behind it. The number under the lifebar is the lives indicator, which replaces the lives indicator that used to be on the pause menu. Overall, I'm pretty happy with how this stage is coming along. There's still a lot of work to be done on it, but most of the difficult stuff is complete. Unfortunately, after this is done, I still have another 6 levels left to do, plus the title screen, ending, and additional programming. Blah.  |
| NetSplit |
| ||
|
Level: 32 Posts: 43/178 EXP: 188121 Next: 18321 Since: 02-26-07 Last post: 2223 days Last view: 2148 days |
Dr. Mario: Please, step in.  We could always use more Mega Man hacks. Because of the depth of my hack (combined with real life circumstances), mine won't be out for a few years. I'd really enjoy seeing more MM hacks released in the mean time, as it would keep me entertained and motivated. And that Vile sprite looks pretty good; I like it.
AlexAR: Your hack's gonna kick my ass? I doubt that very much. But it does look neat; you're right about that stained glass design, which looks very good.
kuja: I wasn't planning on showing off shots of my hack until it was much closer to completion, but that Top Man background convinced me to do so. Would be cool to see a few shots of your hack. |
| NetSplit |
| ||
|
Level: 32 Posts: 44/178 EXP: 188121 Next: 18321 Since: 02-26-07 Last post: 2223 days Last view: 2148 days |
Yeah, I helped out with some code in his hack way back when, so I got a chance to see how it's been going. He's definitely shattering all of the original game's limitations, which is pretty cool and a huge undertaking. I expect good things when that hack is finally finished, but he's really made it such a huge project that he'll be working on it for years and years to come...
At one point, I had changed the mapper of my MM1 hack and completed a functional saving system (with New Game and Continue selectable on the title screen), but I reverted back to the original mapper and dropped the SRAM aspects because I decided to work within the original game's limitations. This presents a lot of its own challenges, particularly when I'm trying to get my additions to the game to fit. I'm also restricted to crappy formats that are a pain to work with because better formats take up more space. It's challenging in its own ways, but I really admire the fact that kuja is going more or less in the opposite direction (pushing the limits rather than confining himself). I'm definitely looking forward to his hack. |
| NetSplit |
| ||
|
Level: 32 Posts: 45/178 EXP: 188121 Next: 18321 Since: 02-26-07 Last post: 2223 days Last view: 2148 days |
Posted by never-obsolete That's pretty cool. I found the level data for the Contra games way back when; if you've any interest in adding support to the program for Contra Force and Super C, my notes claim that the level data is at 18010 and ~A010, respectively. I'm not 100% sure those are right, since I haven't looked at this data for 5 years (literally), but that's what it says in my notes. Keep up the good work. |
| NetSplit |
| ||
|
Level: 32 Posts: 46/178 EXP: 188121 Next: 18321 Since: 02-26-07 Last post: 2223 days Last view: 2148 days |
I agree; I've been playing it off and on since I got it on Wednesday and have been pretty happy with it. The controls take a little bit of getting used to; some things that used to be easy in previous games seem to be a little harder now, in my opinion, but the overall ease of movement and ability to easily pick off small targets are both just wonderful. I just wish I had finished Prime 2 so I'd know everything that happened between where I left off and the start of Prime 3. Ah well. |
| NetSplit |
| ||
|
Level: 32 Posts: 47/178 EXP: 188121 Next: 18321 Since: 02-26-07 Last post: 2223 days Last view: 2148 days |
From my notes (all addresses headered):
$153B0 - Checkpoint scroll byte numbers $153DF - Table of values defining the slot number of the last enemy on the midpoint page (second checkpoint) $1540A - A table containing the first screen ID in the scroll byte selected for the checkpoint $15422 - A table containing the last screen ID in the scroll byte selected for the checkpoint? $1C2E4 - Screen numbers which activate the checkpoint $1C2FB - Where Mega Man respawns after dying $1C52A - Checkpoint y coordinates "Checkpoint scroll byte numbers" tells the game which scroll byte to use when you start at that checkpoint. If the screen you're starting on is in the second scroll byte, you'd put 01. The "slot number of the last enemy on the midpoint page" is calculated by just counting the sprites in the stage from the first sprite to the last sprite on the page where the checkpoint is (the first sprite in the stage is in slot 00). This tells the game how far into the sprite data to look for sprites that are 'active' when you beam in. Everything else should be pretty self-explanatory. I think there's also something related to special objects, but it's not in my notes (but there is something about changing $150F7 to 4CF690 that might have to do with special objects)... Anyway, with this data, you should be able to get your checkpoints working just fine using a hex editor. The only thing I feel I need to add is that you must start Mega Man off at the beginning of a scroll area; if you start him off in the middle or end of a corridor, the game won't know to load any of the graphics for the prior screen, so scrolling backward will cause background graphic problems (you'd have to add a special case to the background loading routine or rewrite it entirely (depending on what you're trying to do) in order to make that work). If you've any further questions, just ask. |
| NetSplit |
| ||
|
Level: 32 Posts: 48/178 EXP: 188121 Next: 18321 Since: 02-26-07 Last post: 2223 days Last view: 2148 days |
You can determine the location you're putting tiles onscreen by writing a different address to $2006 and then writing the data to $2007. That address determines where in the name tables you're writing your data. Write it to the proper place and it'll display as you want it.
The reason your logo is displaying like that is because the pattern table is only 16 tiles wide, but the screen is 32 tiles wide. You're writing the tiles from the table as one continuous string, which means that you're assuming it's 32 tiles wide. As such, your logo is being split, with every odd row on the left and every even row on the right (since it takes 2 rows of your logo to span the screen). What you want to do is grab 16 tiles and then either do 16 tiles of black or write a new address to $2006, and then you can start on the next row. You can also position your logo onscreen by defining the starting location to be later in the nametable than the address that corresponds to the top left of the screen. I hope that helps. |
| NetSplit |
| ||
|
Level: 32 Posts: 49/178 EXP: 188121 Next: 18321 Since: 02-26-07 Last post: 2223 days Last view: 2148 days |
I have very little experience with this, so I can't give you too much help (it's all based on what I remember from working on Mega Man 1's boss select screen 2 years ago). It's centered in the name table, which is great. See those two lines that intersect at the top left of the main part of the logo? The intersection is (00,00), so that's why what you see onscreen is still not centered. I have no idea how to change where that appears, since Mega Man 1 already did that for me and thus I had no reason to reverse engineer that. Check some documents for information on defining which portion of the name table is displayed onscreen.
Also, your code in the first post for defining the palettes is horribly inefficient, space-wise. Try using a loop and a table, like this: LDX #$20 L_PalInit: LDA table-1,X STA $2007 DEX BNE L_PalInit table dc.b $0D,$0C,$0B,$01,$0A,$09,$08,$01,$07,$06,$05,$01,$2B,$08,$0D,$01,$0D,$0C,$0B,$01,$0A,$09,$08,$01,$08,$07,$06,$05,$04,$03,$02,$01 table is your palette data in reverse (reverse, since the loop is counting down instead of up). This saves a lot of space. |
| NetSplit |
| ||
|
Level: 32 Posts: 50/178 EXP: 188121 Next: 18321 Since: 02-26-07 Last post: 2223 days Last view: 2148 days |
Okay, I've been reading around and I think I figured it out. The address that you put into $2006 looks like it will be treated as (00,00), so if you want to put the logo in the center, draw it there and then try resetting the address.
Additionally, take a look at $2005. This is the scroll register; first write handles horizontal scroll, and second write handles vertical scroll. It looks like this and $2006 together allow you full access to scrolling around the name table. Scrolling using $2006 is jumpy because it goes by tiles, but $2005 is pixel-precise (but doesn't cover the entire 512x480 pixels of the nametable), and the combination of the two allows smooth scrolling over the entire thing. I've not tested any of this, so let me know how it works out. More information can be had here and here. If my guesses are wrong, they'll hopefully at least get you on the right track. |
| NetSplit |
| ||
|
Level: 32 Posts: 51/178 EXP: 188121 Next: 18321 Since: 02-26-07 Last post: 2223 days Last view: 2148 days |
LDX #$00
LDY #$10 LDA #BlankTile L_Write1: STX $2007 INX DEY BNE L_Write1 CPX #LastTile BEQ L_End LDY #$10 L_Write2: STA $2006 DEY BNE L_Write2 LDY #$10 BNE L_Write1 L_End: ;Continue your code here BlankTile = $00 ;If it's not #$00, set this to something else LastTile = $B0 ;This is actually the tile after the last tile of the logo. I assume it's at the end of a row. I don't know how large your logo is. This is probably really inefficient (Sephiroth3 is a genius and can point out inefficiencies in the shortest of code), but it works. This will write 16 tiles, then check to see if it's done. If not, it'll do 16 blank tiles and then 16 more tiles. Lather, rinse, repeat. It's good when people can figure things out on their own, but when they can't, I'm okay with giving the answer as long as you can learn from it; please study the routine I wrote and understand it so you can write things like it in the future. Additionally, you did not read my post carefully enough. As far as I can tell, by writing to $2006, you scrolled the screen. $2005 is not the only way to scroll. It scrolls by pixel, while $2006 appears to scroll by tile. The two of these together allows for access to the entire nametable, since 16 bits can only cover 1/4 of the total pixels in the nametable. Whatever address you write to $2006 is going to be where it scrolls to. By writing an address there to center the logo onscreen, you scrolled the screen, so you need to scroll it back by writing the initial address back to $2006 when you're done drawing. Regarding getting things to compile, if the table isn't in the format of your assembler, use a different format. I'm formatting things for assembly in Sephiroth3's FSNASM assembler, which I've been using to write a Scheme interpreter for the NES. Finally, experiment. Don't be afraid to try random, wild things. If you make a mistake, it doesn't matter because you can always go back and try again. This writing a ROM, not performing surgery. Asking questions is good, but figuring it out yourself is both more enlightening and more satisfying. If the information in this post doesn't work out and fiddling around with the registers isn't doing anything noteworthy, I'll try to lend a hand again. |
| NetSplit |
| ||
|
Level: 32 Posts: 52/178 EXP: 188121 Next: 18321 Since: 02-26-07 Last post: 2223 days Last view: 2148 days |
I'll venture a guess that you're either skipping the first row of tiles when you're writing the logo to the nametable (starting at #$10 instead of #$00), or you're writing the first row of tiles too early in memory. Keep in mind (I think) that the first #$40 bytes for each screen is used for attribute data, so it's possible that you're writing the values for the first row in the attribute data instead of tile data by writing it too early. I can't think of any other reason why the first row wouldn't be showing up. Can you post your code? |
| NetSplit |
| ||
|
Level: 32 Posts: 53/178 EXP: 188121 Next: 18321 Since: 02-26-07 Last post: 2223 days Last view: 2148 days |
Well, my code works. I don't have to test it to know that; I've looked at it over and over and it'll run. It does the same thing as your code, for the most part. Rather than jump ahead 16 tiles by writing a new address to $2006, I write 16 blank tiles every time. Additionally, your code starts on the first tile of the logo for every row and ends on the SECOND TO LAST tile because you compared to xF instead of (x+1)0. You did INX CPX #$xF, so xF was ignored in each and every section. It just turned out not to matter since there are no graphics in that column.
Cycle-wise, not writing the 16 blank tiles is more efficient, but it doesn't really matter, since this is a title screen. You could always modify the write-blank-tiles part of my code so that it just skips ahead by #$10 bytes. If you can't get this code compiled, then I suggest you figure out what the problem is, since it's valid code and far better than the massive stuff you're using.
vwait: lda $2002 bpl vwait lda #$21 sta $2006 lda #$48 sta $2006 LDX #$00 TXA LDY #$10 L_Write1: ;Write logo's tiles STX $2007 INX DEY BNE L_Write1 CPX #$B0 BEQ L_End LDY #$10 L_Write2: ;Write blank tiles STA $2006 DEY BNE L_Write2 LDY #$10 BNE L_Write1 L_End: lda #$20 sta $2006 sta $2006 |
| NetSplit |
| ||
|
Level: 32 Posts: 54/178 EXP: 188121 Next: 18321 Since: 02-26-07 Last post: 2223 days Last view: 2148 days |
It won't show because that was a typo that I didn't see when I was looking through and I'm not using labels like I would normally be using in an assembler because you and "label = _____" don't seem to mix so far. Good catch. Fix that and it should be fine. I'll look at it some more to make sure I'm not making conceptual errors that are resulting in the logo cutting off early on. |
| NetSplit |
| ||
|
Level: 32 Posts: 55/178 EXP: 188121 Next: 18321 Since: 02-26-07 Last post: 2223 days Last view: 2148 days |
I can't figure it out. Please paste all the code you're using, exactly as you're using it. Thanks. |
| NetSplit |
| ||
|
Level: 32 Posts: 56/178 EXP: 188121 Next: 18321 Since: 02-26-07 Last post: 2223 days Last view: 2148 days |
I think the problem is that the code is taking too long for VBlank, so it's not able to finish writing everything. My code was actually good, it seems, but it's trying to do too much during the VBlank period (using too many cycles. Loops are less efficient, cycle-wise, than long strips of code, and my loop writes 16 blank tiles instead of using a new VRAM address. If you want to use a new VRAM address, try loading it from a table using X as the index. ANDing it can get you the useful bits).
I've been speaking with Fx3 about this and here's what he has to say: >usually, he must do the following: >A. Wait for a VBlank (twice) >B. Do the necessary stuff >C. Once it's done, wait for a NMI to trigger >D. The game starts >The B part means a lot of important things >such as "turn off sprites and background" >and setup 2006/2007 registers properly AFTER that >WHY? >because even if the Vblank period is over, the screen is DISABLED, and thus it won't scramble the thing Edit: Additionally, what assembler are you using? |
| NetSplit |
| ||
|
Level: 32 Posts: 57/178 EXP: 188121 Next: 18321 Since: 02-26-07 Last post: 2223 days Last view: 2148 days |
Again, I think it's because VBlank isn't long enough. Listen to Fx3's advice and give that a shot. The A's are there because the screen is probably initialized to 00's. |
| NetSplit |
| ||
|
Level: 32 Posts: 58/178 EXP: 188121 Next: 18321 Since: 02-26-07 Last post: 2223 days Last view: 2148 days |
It's not a table file. 'table' is an arbitrary label that I used to identify the table of palette data. I used syntax that works in Sephiroth3's FSNASM assembler. In his assembler, dc.b is syntax for byte data, so if you want straight data in the ROM, you would use dc.b. 'table' is the label that identifies that data, and I referenced it in the code as 'table-1' (to tell it to load from 1 before the address that 'table' is located at).
Your assembler is seeing 'table' and assume it's an instruction, but it's not. FSNASM treats anything that's not an instruction or special command code as a label. Your assembler apparently does not, so there is likely some special command code for labeling something. Additionally, there is likely a special command code for defining something as pure data rather than as an opcode. Read the assembler's documentation to find out what the commands are for this. Also, it shouldn't matter too much where the data table is defined. Regardless of whether you define it at the beginning of the file, right before or after the code, or at some random place, it will put the appropriate address into the place where the label referenced. I should just caution you to ensure that it's not in a different bank unless you know that bank will always be loaded at the same time that the table is needed. |
| NetSplit |
| ||
|
Level: 32 Posts: 59/178 EXP: 188121 Next: 18321 Since: 02-26-07 Last post: 2223 days Last view: 2148 days |
Background palettes are determined by the attributes table, a set of #$40 bytes that is located after the tile data per screen in the name tables. Each byte affects 4 2x2 tile sections. The first byte will change the colors of the 4x4 tile section at the top left of the screen. Each pair of bits corresponds to one 2x2 tile section, and the 4 possible values for those bits determine which of the 4 background palettes to use. You write to the attributes table by writing to $2007. More information about this can be found in this document. The attributes tables are located at $23C0, $27C0, $2BC0, and $2FC0. I highly suggest reading the attributes section in that document. |
| NetSplit |
| ||
|
Level: 32 Posts: 60/178 EXP: 188121 Next: 18321 Since: 02-26-07 Last post: 2223 days Last view: 2148 days |
A search on Google uncovered a copy of FSNASM linked to in this thread.
The attributes table is a table of #$40 bytes, and each one corresponds to one 4x4 tile section on the screen (starting at the top left). Each pair of bits determines the palette assignment for one 2x2 block of that 4x4 section. 4 blocks per byte and #$40 bytes covers 256 onscreen blocks (ie the entire screen plus the row of blocks that would exist if the screen were 256x256 instead of 256x240). To define the attributes of a specific block, you need to write the proper byte to the proper address in the attributes section of the nametables, and I reiterate that each block tile has a specific entry in that table, just like the tiles that make up the screen have specific ID definitions in the nametables. So to make that text white, you can write bytes to the attributes table that will set the blocks the text is on to the white palette. Note that your screenshot indicates that those letters span 6 blocks, like so: [ L][EO][N ] [ R][OO][F ] Depending on the 4x4 tile sections that those fall into (I'm too lazy to open the image in Paint and figure it out), you'll have to modify a minimum of 2 bytes or a maximum of 4. Note that it'd be easiest if you positioned the text so that it were like this: [LE][ON] [RO][OF] This would put all the text into 4 2x2 blocks and, depending on its positioning on the screen, might cause it all to be within a single 4x4 area, which would mean only modifying one byte and not having to worry about preserving the attributes for any graphics near the text when doing the attributes update. Please try experimenting with this before your next post. I gave you the addresses of the attributes tables in my last post. If you can't get it working right on the second screen that you showed, try making a screen out of a non-transparent solid color (ie covering the screen with a tile that is colored some solid color), making all the palettes use different colors for the color you chose for that tile, and then fiddling with the attributes table. Then any change you make to the table will show up clearly and you'll get a better grasp of how exactly it works. |
| Main - Posts by NetSplit |
© 2005-2023 Acmlm, blackhole89, Xkeeper et al. |
|
MySQL - queries: 29, rows: 61/61, time: 0.246 seconds. |
