News: 11 March 2016 - Forum Rules
Current Moderators - DarkSol, KingMike, MathOnNapkins, Azkadellia, Danke

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - Revenant

Pages: 1 2 3 4 5 6 [7] 8 9 10 11
Personal Projects / Re: Kirby's Dream Course editor (version 1.12)
« on: June 14, 2014, 03:44:50 am »
Just another small update, 1.12 fixes some goofy display issues that the rewritten 2D display in 1.11 introduced. Links in the OP as usual.

I got lazy for a few weeks, then I suddenly got productive for some reason after that. Then this happened.

Almost everything I wanted to be in this editor is now done. There are a few things left (mostly UI polish) but this is quite nearly a finished product now until someone finds some crazy showstopping bugs or whatever. Have fun!

Code: [Select]
v0.90 [2014-06-12]
- new HTML documentation
- full tileset, BG palette, and sprite palette editing
- editing of "stage clear" and star switch reveal areas on overworlds
- some text changes ("level" replaced with "room" or "stage" when appropriate)
- allow pasting beyond 64 tiles in either direction; this was a limitation that managed
  to survive being copied from KDCEditor without being updated for the real maximum
  height/width of Kirby's Adventure maps (thanks DarkMatt)
- more new icons (by Reimu)
- sprites and exits outside of level bounds are no longer shown, saved, or editable
- tile edit window displays tile numbers in hex
- opening non-Kirby's Adventure ROMs now displays an error instead of continuing

Script Help and Language Discussion / Re: Japanese text
« on: June 10, 2014, 05:54:46 pm »
Yep, that looks like Japanese text alright.

Small correction: HiROM (almost always) maps banks $C0-$FF and mirrors to $40-$7D, although obviously that same size limitation still applies.

ExHiROM (aka the Tales of Phantasia way) is probably the best/easiest solution - keep banks $C0-$FF at the beginning of the ROM file like normal, then expand the ROM to add more 64kb banks that will be mapped as bank $40 and up.

You'll also have to relocate the header from offset 00FFC0 to 40FFC0 in the ROM file, since the ROM portion of bank $00 is mirrored from bank $40, not bank $C0.

Programming / Re: Any easy to use side scrolling game creators?
« on: May 27, 2014, 08:32:29 am »
Do you expect there to be something easier than Game Maker?

Programming / Re: [SNES] Is CMP #$00 necessary in this situation?
« on: May 21, 2014, 08:20:23 am »
AFAIK it is wrong to expect that Squaresoft's games are all masterly programmed (just because they are masterly concepted).

I find this is true of big-name software in general, not just Square games :P

Programming / Re: [SNES] Is CMP #$00 necessary in this situation?
« on: May 20, 2014, 01:18:08 pm »
Nope, peepholes optimizers are supposed to remove this kind of things.

Although bad code produced by a (badly configured ?) compiler could be a valid explaination.

Most/all of EA's SNES sports games were written using a compiler, and it routinely did stupid things like explicitly allocating 0 bytes on the stack for functions without any arguments or local variables, so I wouldn't be surprised to see something like the OP either.

Then again, my first assumption was that this is a bit of code Mauron wrote themselves for feedback, rather than something found in an existing ROM (and if I had time, I'd let bgrep check for me  :D)

Programming / Re: Tales of Phantasia SRAM
« on: May 13, 2014, 12:39:25 pm »
I was able to read an extra 4kb of SRAM from B16000-B17FFF just fine using bsnes, though in Geiger's it (incorrectly) mirrors B06000-B07FFF instead.

I don't know if snes9x 1.52 or 1.53 fixes this. It's a shame that (imo) the best SNES debugger is based on such an old and inaccurate emulator version.

Programming / Re: Tales of Phantasia SRAM
« on: May 09, 2014, 11:36:26 pm »
How are you accessing the SRAM? I believe ToP maps SRAM slightly differently than most HiROM cartridges so that the original 8kb is at $806000, and if you added a second 8kb it'd be at $816000 (as opposed to the more typical $206000 / $216000).

Or maybe I'm misunderstanding the issue and Geiger's just isn't reading/writing the SRAM from/to disk correctly at all, in which case I have no idea.

ROM Hacking Discussion / Re: Changing rom size of snes rom
« on: May 09, 2014, 09:30:55 pm »
The rom size value in the cartridge header is completely ignored by actual cartridges and SNES hardware, and is in fact inaccurate in a few commercial titles. (I can't name any off the top of my head, but I know who to ask to find out...) If it's being polled by a flashcart, then that's a flaw in the flashcart's read logic and isn't a problem with the translation patch.

Super Noah's Ark 3D is one, if that counts (and most other unlicensed/bootleg carts I've seen don't bother with valid size info in the header either).

ROM Hacking Discussion / Re: Final Fight 3 NES MMC3 Hack Possible?
« on: May 05, 2014, 12:02:32 pm »
That said, MMC3 was not the upper limits of storage. The largest game to use an official mapper was Metal Slader Glory for the Famicom, which maxed out the MMC5 with a 512 KB PRG and a 512 KB CHR.

That's actually only half of the MMC5's maximum capacity for both PRG and CHR, though there certainly aren't any 2MB licensed games out there (and even the NES PowerPak, which supports the MMC5, doesn't support PRG or CHR ROM sizes larger than 512kb, unfortunately).

Personal Projects / Re: Kirbys bizarre adventure [Demo out!]
« on: April 30, 2014, 01:20:50 am »
Great to see people putting my editor to use so soon :D

I haven't had much time to try the demo yet, but it looks like a pretty interesting challenge from the video you posted. The KDL2 sprites are a nice touch too.

ROM Hacking Discussion / Re: Screenshots
« on: April 30, 2014, 01:14:59 am »
Results of last Sunday's romhacking stream:

Oh fuck yes

(That reminds me I found this debug mode a while ago, which could prove useful as far as dialogue testing goes, but I dunno how much of that end you've done already :P)

Not that I can think of, apart from being less intuitive to look at.

What you're seeing is a case of integer overflow with signed numbers. The offset in instructions like lw and sw is a 16-bit signed integer, meaning that 0x0000-7FFF represent positive values and 0x8000-FFFF represent negative ones.

If you just want to load the value at 0x8003E414, try this instead:

lui $t8, 0x8003
ori $t8, $t8, 0xE414
lw $t8, 0($t8)

The lui instruction causes the upper 16 bits of the target register to be loaded and the lower 16 bits to be zeroed out, so it's not uncommon for it to be loaded by an ori (bitwise OR immediate) instruction to load the lower 16 bits with the second part of a 32-bit value.

I don't know about armips, but several MIPS assemblers also support a pseudoinstruction called "li" (load immediate) which simplifies the above:

li $t8, 0x8003E414
lw $t8, 0($t8)

("li" isn't a real MIPS instruction, but an assembler that supports it will essentially convert it to the lui/ori form when you assemble the code.)

Tile and palette editing are still in progress, since I haven't had a lot of free time to work on this in the past week or so, but here is a mostly-bugfix release which also adds to the exit editor (which can be used in case something got messed up by the bug that this release fixes; see the changes for details)

Code: [Select]
v0.83 [2014-04-18]
- fixed the limit on # of exits being too high, easily leading to corruption
  (due to some incorrect info on datacrystal)
  this was capable of affecting boss battle info (for the "next world" doors) which
  can now be edited as part of the normal exit data, as well as part of the tileset
  data, which the editor will now repair automatically until the actual tileset editor
  is added (soon, hopefully.)
- added the ability to change boss battle locations when editing a door with type 0x1F
  (the "next" overworld doors)
- fixed a bug where the music track and "no return on death" settings in the level
  properties dialog didn't take effect unless other settings were also changed
  (thanks J^P)
- new "edit exits" and "level properties" menu/window icons (made by Reimu)

(Also, I looked into the issue that J^P posted about above, and it turned out to be more or less some kind of unreplicatable weirdness that happened when saving the ROM to disk; it hasn't happened again since or to anyone else as far as I know.)

April 20, 2014, 12:11:39 am - (Auto Merged - Double Posts are not allowed before 7 days.)
In my haste to release the v0.83 bug fix, I broke something else. Please forgive my idiocy and enjoy v0.83b.

Code: [Select]
v0.83b [2014-04-19]
- only write some tileset info for ingame tilesets, not every single one.
  this was causing crashes as of v0.83 (thanks again J^P)
  once again, this update will automatically repair any ROM damage caused by v0.83

Personal Projects / Re: eDKit - Donkey Kong '94 (GB) Level Editor
« on: April 10, 2014, 01:04:11 pm »
I sent a pull request with a couple of other tiny Qt 5 fixes, but otherwise I can confirm that it builds and runs on Windows (with MinGW), at least.

That's strange. Would you mind sending me an IPS patch or something so I can check it out?

Like I found out before releasing v0.81, it may be caused by some stupid detail of the way the game handles sprite data that's currently being overlooked. Hopefully it should be easy to fix once I can actually see it happening.

Another minor update this time, just to fix a stupid bug with the double sized view that I thought I had taken care of a while ago (I'm a great software tester, aren't I...)

Code: [Select]
v0.82 [2014-03-29]
- fixed double size mode leaving sprites/exits in the wrong place
  (thanks Darkdata)

I uploaded both the full release as well as the update by itself, for people who already downloaded it and didn't feel like downloading all the dependencies again.

Barring any other stupid oversights on my part, the next major update will probably introduce some other stuff like tileset/palette editing. I've also been experimenting with a MMC3->MMC5 mapper hack to address the very small amount of free ROM space in the game as it is (and the complete lack of unused CHR-ROM banks); if I can get that working without any issues I may either build it in to the editor or add support for ROMs that are patched with it separately or something.

Claude, not Carl.

Pages: 1 2 3 4 5 6 [7] 8 9 10 11