 |
|
Main
| FAQ
| Uploader
| IRC chat
| Radio
| Memberlist
| Active users
| Latest posts
| Calendar
| Stats
| Online users
| Search
| |||
| Views: 88,512,292 |
Main
| FAQ
| Uploader
| IRC chat
| Radio
| Memberlist
| Active users
| Latest posts
| Calendar
| Stats
| Online users
| Search
|
05-02-24 11:59 AM |
|
| Guest: Register | Login | |||
| Main - Posts by NetSplit |
| NetSplit |
| ||
|
Level: 32 Posts: 141/178 EXP: 188122 Next: 18320 Since: 02-26-07 Last post: 2223 days Last view: 2148 days |
No worries; I'm just thrilled that you've learned from it.  |
| NetSplit |
| ||
|
Level: 32 Posts: 142/178 EXP: 188122 Next: 18320 Since: 02-26-07 Last post: 2223 days Last view: 2148 days |
"Sprite orientation" is actually sprite attributes. It handles x/y mirroring, palette number, and background priority. The other 3 bits are unused. |
| NetSplit |
| ||
|
Level: 32 Posts: 143/178 EXP: 188122 Next: 18320 Since: 02-26-07 Last post: 2223 days Last view: 2148 days |
No. It's vhbuuupp, where v is vertical mirroring, h is horizontal mirroring, b is background priority, u is unused, and p is palette number.
When b is set, sprites will be drawn behind the background and thus will only be visible in places where the background color is transparent (that's the first color for every palette). Air Man's stage is an example of a stage where it's set for nearly all onscreen sprite tiles. |
| NetSplit |
| ||
|
Level: 32 Posts: 144/178 EXP: 188122 Next: 18320 Since: 02-26-07 Last post: 2223 days Last view: 2148 days |
The pipes are fine. I love the ceiling; all of the ceiling tiles are spot-on. However, I dislike all of the floor tiles, and I feel that the blue background doesn't fit in very well. The floor tiles are way to bland and simple, in my opinion; the ceiling tiles really put them to shame. They seem to really lack detail and have way too much solid color for the kind of blocks that they are.
Those barrels and ceiling tiles, though...I really like them. They're definitely keepers. The fire's also pretty good. |
| NetSplit |
| ||
|
Level: 32 Posts: 145/178 EXP: 188122 Next: 18320 Since: 02-26-07 Last post: 2223 days Last view: 2148 days |
Awesome. Secret of Mana is one of the only RPGs that I find fun because of its real time battle system, a surprisingly uncommon thing in the genre. Very good work; the amount of features is pretty staggering. I look forward to seeing a release. |
| NetSplit |
| ||
|
Level: 32 Posts: 146/178 EXP: 188122 Next: 18320 Since: 02-26-07 Last post: 2223 days Last view: 2148 days |
Very cool. Gimmick's a neat little game that not many people know about. Perhaps this can get it some more attention. I look forward to seeing more progress on this.
It's been a few years since I looked into data for this game, but I recall it having a really nice (and simple) level format. Wish more games were like that. Compression's such a pain.  |
| NetSplit |
| ||
|
Level: 32 Posts: 147/178 EXP: 188122 Next: 18320 Since: 02-26-07 Last post: 2223 days Last view: 2148 days |
Ufouria would be an awesome game to have an editor for. It's interesting because of its Metroid-esque non-linear design, and it offers more freedoms than Metroid because of its more modern engine and greater ROM space. Definitely a damn fine game. |
| NetSplit |
| ||
|
Level: 32 Posts: 148/178 EXP: 188122 Next: 18320 Since: 02-26-07 Last post: 2223 days Last view: 2148 days |
Been out for a while on hiatus. Back with a video of a WIP stage in my MM1 hack.
|
| NetSplit |
| ||
|
Level: 32 Posts: 149/178 EXP: 188122 Next: 18320 Since: 02-26-07 Last post: 2223 days Last view: 2148 days |
This is incorrect; it's possible that your sprites are out of order, but that's unlikely (you'd probably have to have your sprites set up pretty weird for that). Sprite ordering is one of the potential triggers for what is probably causing the bug, though, which is that moving platforms each look for sprite #$2C in a specific sprite slot. Basically, when the game comes across #$2C, it will activate the moving platforms that are associated with that by going through a moving platform list and comparing for equality the #$2C's sprite slot to the sprite slot value for each platform in the list. If equal, it activates that platform.
Your problem sounds like two things. Firstly, you think that #$2F is the sprite for moving platforms, but it's not; it's just for the sound effect. #$2C is the moving platform initializer sprite. Secondly, for the Guts stage moving platforms, #$2C needs to be in sprite slot 0; that is, it needs to be the very first sprite on the first screen. I don't remember if its vertical position matters or not, but it might. Its usual vertical position is #$FF (the very bottom of the screen). If it winds up mattering and you can't set that in Rock and Roll (if you can, I don't know how or I have an outdated version), go to $1A4C6, reverse those two bytes (in the original game, they are 41A8, so you'd get A841), add 10010 to it (in this case, A841+10010 = 1A851), and go to that address. That's the location of the start of Guts Man's sprite data (sprite slot 0). That is the one that needs to be that #$2C sprite. First byte is the screen number (should probably be #$00), second is the x coordinate (#$80, by default. I highly doubt it matters), third is the y coordinate (#$FF by default. I don't know if it matters, but I'd keep it #$FF just in case), and fourth is sprite ID (#$2C). So, in the original, slot 0 would be 0080FF2C. Set it up like that and it should work fine. You will almost certainly run into trouble if your moving platforms aren't in the first scroll area of the stage (the first corridor) and you have sprites before then. I'm pretty sure the #$2C sprite must be on the first screen of the scroll area that has the moving platforms (although I might be wrong. The original game definitely sticks to this reasoning, though). So, if the scroll area starts on screens 1 or 2, then change the screen number of that #$2C sprite accordingly. Having sprites beforehand would mean you'd have to change the sprite slot for the platforms you want to appear. Also, assuming you don't know much about sprite slots: The sprite slot is determined by the ordering of sprites in ROM, not based on the apparent ordering in-game or in the editor. You can put sprites in any order in the ROM, but that can have undesired effects. Basically, when the game is going through the list of sprites to place them in the game, it goes through them in order, expecting that the next sprite it places is the next one Mega Man will come across. That means that if it isn't, then sprites that should be the next one Mega Man comes across (based on how it looks in the editor) won't be placed because the game will be waiting for the later sprite before placing the earlier ones. When it does get to that sprite, it will then see that it should have placed the others, so they'll appear on the screen at their proper locations at the same time (read: enemies will probably appear out of nowhere in the middle of the screen). As far as I know, Rock and Roll doesn't support automatic sprite ordering (meaning you need to be mindful of the ordering of these things yourself), though it probably should; it's the most common problem I see in Mega Man hacks because no one cares enough about fixing it. Fx3's Mega Man 1 and 2 editor, visine, supports automatic sprite ordering as an option when saving (as it should); out of order sprites can be a useful advanced feature if you know what you're doing. The drawbacks of visine are that it's DOS and that it might be a tiny bit buggy or, at least, intolerant of extensive changes to the game (beyond just straight data changes, so you're probably fine). For the most part, though, it's a good editor that I recommend in addition to Rock and Roll. I hope that all helps. Edit: Also, it sounds like you might not know much about hex editors.. Basically, all files on your computer are made up of bits (0's and 1's - binary) that encode everything, where most things are some number of bytes (1 byte = 8 bits). They mean different things in different places, and what matters is how they're interpreted. A hex editor lets you open up a file and view the binary that makes up file, viewed primarily in two-digit hexadecimal (hex) numbers instead of binary (so base 16 instead of base 2. That's 0-F (0-9 followed by A-F) instead of 0-1), since it's easier for people to deal with a lot of this stuff in two digit hex numbers than it is in 8 digit binary ones. In short: they let you view and edit the data in a file as hex numbers. Each byte in a file has an address associated with it. So when we give you an address, we're telling you which byte you can change to change some aspect of the game. Rock and Roll does all of this under the hood; when you change something, it's really making one of these changes that you can do on your own with a hex editor. It's just making your life easier by making it visual and giving you an interface that's usually better than just changing numbers in a hex editor. If you don't have one already, you should go grab a hex editor so you can fiddle with the bytes in your ROM (though make sure to make a backup before doing this, especially if you're inexperienced. It's easy to mess something up if you don't know what you're doing, but don't let that deter you). I use Hex Workshop, but I'm sure there are good free solutions available; you'll have to try some out for yourself or ask around. You can find a lot of them at this page on romhacking.net. You might want to check out WindHex32 or Thingy32 first. |
| NetSplit |
| ||
|
Level: 32 Posts: 150/178 EXP: 188122 Next: 18320 Since: 02-26-07 Last post: 2223 days Last view: 2148 days |
I'd just put it back if I were you. Also, wow; changing the numbers in the game name to roman numerals is not only picky as hell, but it breaks Mega Man convention where numbers are NES games and numerals are the identically-named Game Boy games. |
| NetSplit |
| ||
|
Level: 32 Posts: 151/178 EXP: 188122 Next: 18320 Since: 02-26-07 Last post: 2223 days Last view: 2148 days |
Nice to see someone else figuring this out. The MM1 water really bugged me, particularly considering the behavior in later Mega Man games, so it was definitely on my list of things to update when I was working on my Mega Man hack (video of my water here: http://www.youtube.com/watch?v=z4bIxaIkH3M). Unfortunately, it's been a long time since I worked on my hack, so I don't really know the specifics of how I made it work (though a quick glance confirms that $94 is definitely the way to go for Mega Man). This is also the way you'd handle custom block types, yes. That was something I intended to work on, but I never got to making the levels in my hack that would've benefited from the new block types, so it was never worth pursuing.
The real problem comes when you want to make enemies interact with specific block types. Your solution is nice, but it doesn't make enemies have lower gravity when underwater. Mega Man 2 solved this by making gravity lower universally depending on Mega Man's water status, which is a simple change. You'll want to approach this by changing the gravity that affects things rather than changing Mega Man's jump height. That'll achieve a more water-like feel and mean you only have to change the gravity routine rather than jumping velocities for everything. Water got a lot more complex with later games, where each sprite was checked for water status rather than just doing it all based on Mega Man. I know little about how general collision works for MM1, so my solution was to make another #32 byte array for sprites to check what block they're currently in. Regarding free space to hold such a huge array, I used the top of the stack space, since if your stack is ever getting that high, you can realistically expect a crash, anyway. Then, the gravity routine can be modified so that it uses either the normal or underwater gravity values depending on the sprite's array value. Further benefits of this method are that you can then easily make any sprite react to any block type. If you watch my video, you'll see I made sprites with the bg collision flag explode if they touch spikes, which is just a matter of checking if that array is set to the spike value or not. You can further generalize this and make more unique block types for different levels that affect enemy sprites in addition to Mega Man. Just be conscious of free space for the additional code, as well as the additional overhead (read: more cycles used). Oh, and if you do all that, you'll also want to further improve the water by fixing the occasional delay that occurs in water. MM1's version of water was slowing down Mega Man a bit when underwater, so it turns it into a play control hazard. It's a pain in the ass and feels much better with that feature disabled. If I recall correctly, the game does it by using a counter that all sprites have that says for how many more frames that sprite is frozen in place. This is located at $06A0 and is used for when you freeze enemies in place with the Ice weapon. I think the game sets Mega Man's to 1 every few frames when underwater, or something like that. Definitely worth disabling, in my opinion. Anyway, it's great to see MM1 developments. I hope to see more coming in the future. |
| NetSplit |
| ||
|
Level: 32 Posts: 152/178 EXP: 188122 Next: 18320 Since: 02-26-07 Last post: 2223 days Last view: 2148 days |
You seem to have learned a lot.  Always nice to see people go from knowing little to knowing much.
I seem to recall bg collision being a bit irritating to mess around with in MM1, but I imagine adding custom blocks shouldn't be too bad. You're doing a check for water right now. You could just do a check for another value and have code somewhere that will see that and decrement MM's health every now and then, or something like that. You get the idea.
I think my implementation of the 32 byte array was actually fairly intelligent in trying to decide what is and isn't important information. Basically, sprites are big, so they can be touching a lot of different kinds of blocks. I decided to give blocks priorities, so my implementation says that spikes (#$03, I think?) are the most important value, so if it's #$03, then don't update the value anymore, and water is the second more important, so if it's #$05, don't update it anymore unless it's #$03. This lets you get the most significant information for a given sprite. It won't do any good if you want 2 special effects at the same time, but so it goes. You could make it use both nybbles to try to get multiple effects at a time, so one nybble is air-like blocks (like water and 'poison' air), while the other is special wall blocks, or something like that. There are lots of ways of achieving this sort of thing.
At some point, I intend to sit down and make an MM1 editor. I have so much information about this game lying around in notes, but there aren't any really good editors for the game; they're all so limited. We'll see if I ever get around to this, but hopefully it'll happen! |
| NetSplit |
| ||
|
Level: 32 Posts: 153/178 EXP: 188122 Next: 18320 Since: 02-26-07 Last post: 2223 days Last view: 2148 days |
Alright, so, the foreground stuff in MM2 is on for the entire Air Man stage and not on for any other, so in finding this, looking for a check against the stage number would be a good idea. So, I needed to know what RAM address the current stage was. I fiddled around on the stage select screen in FCEUXD and figured out it was $2A, though there are other ways to do that. With that, it's a matter of either watching $2A during gameplay to see what reads it and checks if it's Air Man's stage (stage number 01), or just searching in a hex editor. It's safe to say it's probably doing a load and then compare, so if you searched for LDA $2A CMP #$01, you'd probably find it. In this case, that works, though I was easily able to locate it during gameplay by watching that address, as well.
So, now that I've given that explanation: $3CCF8 is the #$01 in that CMP. That defines which stage has things entirely in the foreground. You can mess with that routine to change how the game does foreground stuff, or just change that value to make a different stage have foreground (you can make no stage have foreground by making the value a non-stage value). |
| NetSplit |
| ||
|
Level: 32 Posts: 154/178 EXP: 188122 Next: 18320 Since: 02-26-07 Last post: 2223 days Last view: 2148 days |
Given that FSNASM seems to have fallen off the face of the planet, I've uploaded my copy: http://acmlm.kafuka.org/uploader/get.php?id=3213
I might be remembering wrong, but I think this one is slightly newer than the Hyrule Magic one, allowing you to use tabs without exploding. I don't have a readme for it; I'm not sure if I ever did. The author doesn't seem to have a readme anymore, either. So, I'll go ahead and note down everything I know about it and what I could get from the author last time I talked to him.
Running it on the command line yields: FSNASM (C) 1999,2001-2002 Sephiroth of Gigasoft Usage: FSNASM [option] srcfile Options: -l: Produce LO-ROM -o You can use .b, .w, and .l to be explicit about what version of a particular instruction you want (so, for example, LDA.w). If you don't use those, the assembler will make its best guess. Commands are: charset, defchar, endb, base, data, block, align, end, code, global, zram, incbin and org "block" corresponds to resb in nasm data, code, ram, zram and org define sections I believe 'end' ends these segments. defchar "EXAMPLECHARSET" "AZ"=1,"az"=27,"09"=118," "=0,s".'!?:,-;&/"=63,"\n"=129 charset "EXAMPLECHARSET" ;You can use \ to escape, for characters like " ZRAM corresponds to addresses 0-$1fff i think, or maybe it's 0-$ff the base directive tells it where the code really is endb ends the base directive If you're coding for the NES, you can use org $c00000 to put the code at the beginning of the ROM. With -l (the LoROM option), that would be org $808000 You can use incbin to include data. For example: incbin "NESFONT.dat" to include some NESFONT.dat file, which would presumably be your font graphics. Use dc.x to include data, where x is b, w, or l. Data can be a mix of numbers (hex ($) or dec) and labels (or operations on labels, such as yourlabel-1) I've used this for NES development before and it works well. I had to do org $c00000 at the start, define the header (example: dc.b "NES",26,2,1,1,0,0,0,0,0,0,0,0,0), base $8000, and then you're ready to code (just be sure to endb, end, and set up your interrupt vectors at the end of the file). You can do variable = $blah to set up your variables. I think labels require a colon after the declaration unless they're naming a table, in which case it's just yourlabel dc.x yourdata. Hopefully someone finds this useful. |
| NetSplit |
| ||
|
Level: 32 Posts: 155/178 EXP: 188122 Next: 18320 Since: 02-26-07 Last post: 2223 days Last view: 2148 days |
This one's been a problem for people for a long time, so I went ahead and figured it out just now.
In a headered ROM, the warp locations are stored at $6020. There are 8 of them, ordered by dungeon number. These locations are all one less than the place they drop you off in-game, likely because of the rightward scroll that occurs to bring that screen onscreen. If you want it to warp you to screen #$3C, you use #$3B. If you want it to warp you to screen #$00, you use #$FF. And so on. The y locations of where it drops you off are at $6129. Again, there are 8 of them. I point this out because there is code immediately following this 8-byte table that starts with the opcode #$AD, which looks suspiciously like the values in the table. Don't change that byte. This table is just like the table for warp locations, except that the values are the actual y values. I recommend only fiddling with the first half of each byte, which specifies which row you'll be dropped off in, leaving the second half as D.
Also, in general, this is the one document you need when hacking this game. Hope that all helps! |
| NetSplit |
| ||
|
Level: 32 Posts: 156/178 EXP: 188122 Next: 18320 Since: 02-26-07 Last post: 2223 days Last view: 2148 days |
It's not entirely clear from the post, but I'm guessing he's talking about Mega Man 1.
While somewhat reasonable, Kawa's suggestion would've been a time sink and gotten you nowhere, since the value you were looking for is actually #$05, not #$03. The byte you're interested in is at $16762. This byte is 2 more than the maximum number of shots Mega Man can fire; you'll want to set it to #$04 to allow only 2 shots. The game will allow unreasonably large values, and Mega Man can shoot up to 28 shots onto the screen at one time without changes to the bullet speed (maybe more if you abuse zipping?), but the behavior of shots beyond the 14th will likely be wrong because those will be placed into enemy slots instead of friendly slots (there are 16 of each). I don't recommend making it even that high because other things may use friendly slots, as well. The code for this is in the MegamanWeaponFire_P routine in the Mega Man 1 commented disassembly located at http://bisqwit.iki.fi/jutut/megamansource/maincode.txt. I located it using the FCEUX debugger by checking to see where some values in RAM (velocity, IIRC) for Mega Man's shots were coming from, and looked at code in the area. I hope that's helpful! |
| NetSplit |
| ||
|
Level: 32 Posts: 157/178 EXP: 188122 Next: 18320 Since: 02-26-07 Last post: 2223 days Last view: 2148 days |
Ah, whoops; I saw this thread in isolation and wasn't aware of his Mega Man 3 and 4 questions. Good catch. |
| NetSplit |
| ||
|
Level: 32 Posts: 158/178 EXP: 188122 Next: 18320 Since: 02-26-07 Last post: 2223 days Last view: 2148 days |
I posted my copy of FSNASM at http://acmlm.kafuka.org/board/thread.php?pid=132091#132091 a while back, with some instructions on how to use it. I don't know much more about it than what is in that post, unfortunately. |
| NetSplit |
| ||
|
Level: 32 Posts: 159/178 EXP: 188122 Next: 18320 Since: 02-26-07 Last post: 2223 days Last view: 2148 days |
Posted by Zieldak If it's of any help, here's what I have in my notes about checkpoints: $153B0 - Checkpoint scroll byte numbers $153D3 - Table of values defining the slot number of the last enemy on the checkpoint page (start, mid, end) $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 These tables should be a multiple of #$0C bytes long, with 1 entry for 12 stage slots in order, and up to one set of 12 entries for each of the 3 kinds of checkpoints, in order. Not every table has a set for every checkpoint; for example, the table at $15422 doesn't have data for the startpoint. Setting the data in all of these tables properly should be enough to make edited checkpoints act correctly. Edit: I updated the table for enemy slot numbers to include the startpoint data; the address previously started at the midpoint data. For the enemy data, the byte is the slot of the last enemy of the page; if there have been no enemies in the stage so far, that should be FF. I also seemed to think that changing $150F7 to 4CF690 was a good idea when I wrote this many years ago, but my notes aren't clear on why, and glancing at bisqwit's disassembly doesn't make it immediately obvious. I wrote: "the game calculates the data itself that it needs if you're hacking the ROM. If you don't make this change, it ignores its calculation and uses a table elsewhere in the ROM. Has to do with checkpoints". In the disassembly, I see that all my change does is skip past this chunk of code: $90E7> A5 AB: LDA LastRestartPointType $90E9> F0 0B: BEQ + ; $90F6 $90EB> 18: CLC $90EC> 65 31: ADC CurrentStage $90EE> AA: TAX $90EF> BD 0694: LDA Label9412-12,X $90F2> 85 28: STA CurrentEndScreen $90F4> E0 08: CPX #$08 I'm betting LastRestartPointType contains #$00, #$0C, or #$18 (Edit: This seems to be the case), representing the 3 checkpoints (start, mid, end). If not 0, it uses it plus the stage number as an index into the table at $15422 (treating the start of the table as $15406 so the midpoint data starts at the actual start of the table). This is used as CurrentEndScreen, so the meaning does match up with the table from my notes. Looking a bit before this code, there is some stuff that does indeed calculate a value for CurrentEndScreen. This strikes me as silly; either they should add an additional 12 bytes to the table and read from that every time, or they should do the calculation every time and do away with the table. You could try making that change and seeing if it means you don't have to do anything with $15422 anymore. I see two potential problems with this. First, the table may exist because their calculation code does not work properly for mid and end points. Second, there is a compare at the end of this code; I don't know if it's used for anything, but it may have some significance that makes bypassing it a problem (Edit: Following the code briefly in a debugger, it doesn't look relevant anywhere). I'm not planning to dig through the code any further now to see if those actually are problems; I leave it as an exercise to the reader! Edit: As an additional note, if you're specifying the index in the scroll data for this corridor and the screen at the start of the corridor, you shouldn't need to include the screen the corridor ends on because it's easy to calculate. This table doesn't seem like it has much of a real point. My curiosity won out and I wound up putting this to the test. At every checkpoint I tried (Cut Man mid and end, Fire Man mid and end, Wily 1 mid and end, Wily 2 mid), the table always yielded the same value calculated by the routine. I'm pretty sure that you can just do that 3 byte assembly change and ignore that one table, but feel free to check up on this yourself. Good luck to you. |
| NetSplit |
| ||
|
Level: 32 Posts: 160/178 EXP: 188122 Next: 18320 Since: 02-26-07 Last post: 2223 days Last view: 2148 days |
I check the forums every now and then, though I don't usually post unless I have something useful to offer up.
Scrolling is 1 byte per corridor, where the top 3 bits represent the scroll type and the bottom 5 bits represent the screen length (00000 being 1 screen, and so on). The type bits, from highest to lowest, are up, down, and right, and can be mixed and matched so a screen can be exited through any of the 3 directions. When going backward, I believe (haven't checked) that the game will allow you to return to a corridor through the reverse of any of the allowed exit directions for that corridor, and if an edge of the screen is an entrance to both the previous and next corridors, presumably one of them wins out. You can probably figure that out easily enough from Bisqwit's MM1 disassembly or simply testing it out. Having multiple directions set and taking advantage of whether the previous or next corridor has priority can let you build mazes. If the type bits are all 0, the room is a boss room instead of a standard corridor and will spawn the boss of the current stage. I believe the length bits are ignored if it's a boss room. Note that going backward through a right scroll has some issues, so the game doesn't allow it by blocking the backward scroll with a solid special object, though solid background tiles will work, as well. The real problem with the leftward scrolling is that the game will snap you to a specific location after completing that horizontal scroll, which will warp you to the left side of the screen if you're coming from the right. This can be disabled pretty easily in the code. Also, the game doesn't like if you enter the stage in a location that isn't the leftmost side of a corridor. I don't remember if it has any other bad behavior, but the graphics when you scroll to the left aren't loaded correctly, and fixing this requires some assembly. In case it's of any help with setting up checkpoint scroll data, you can find scroll data for stages at $C81 for Cut Man / Wily 1 and multiples of $4000 beyond that for each of the other 5 pairs of stages (much of the levels' data is in a very standardized location, consuming the first $1000 bytes of each of the first 6 banks). For setting checkpoint enemy data, you can locate the standard enemy data for each stage using the two-byte pointers at $1A462, which are in the standard stage order. Taking the pointer, reversing the bytes (they're little endian), and adding $10010 to it will get you the ROM address of the enemy data for that stage. The enemies are 4 bytes a piece, representing the screen, x coordinate, y coordinate, and enemy IDs, though I don't remember the order of the bytes (but it shouldn't be hard to figure out). With this information, you may be able to more easily count the number of enemies up to the last one on the checkpoint screen than going by an editor, which may have overlapping enemies, enemies on the edge of the screen, or something like that that makes it difficult to count. Note that a stage's enemy data is terminated with #$FF, and you really should keep the enemies ordered by screen and x coordinate, since enemy spawning probably won't work how you want if enemies are in the ROM in a different order than they are in-game. The rest of the checkpoint stuff should be easy enough to figure out from an editor, I'd imagine. If you need anything else, feel free to ask and I may be able to help out. |
| Main - Posts by NetSplit |
© 2005-2023 Acmlm, blackhole89, Xkeeper et al. |
|
MySQL - queries: 39, rows: 71/71, time: 0.222 seconds. |