 |
|
Main
| FAQ
| Uploader
| IRC chat
| Radio
| Memberlist
| Active users
| Latest posts
| Calendar
| Stats
| Online users
| Search
| |||
| Views: 88,440,938 |
Main
| FAQ
| Uploader
| IRC chat
| Radio
| Memberlist
| Active users
| Latest posts
| Calendar
| Stats
| Online users
| Search
|
04-20-24 07:07 AM |
|
| Guest: Register | Login | |||
| 0 users currently in ROM Hacking | 2 guests |
| Main - ROM Hacking - I wonder if this has been attempted by an editor programmer | New thread | New reply |
| Cellar Dweller |
| ||
 Snifit Level: 39 Posts: 124/287 EXP: 384998 Next: 19773 Since: 02-19-07 From: Arkansas Last post: 4045 days Last view: 3213 days |
I remember thinking about this idea back when I was working on YI hacking. One of DahrkDaiz's recent posts brought it back to my mind. It is possible that I read about this idea in the past, but if I did, I don't remember when or who was discussing it.
Instead of manually writing routines to render object commands to tiles, the game's own routines are used. The editor contains a minimal emulator that only emulates the parts of the hardware that are used for processing the level commands. First the emulator is initialized with the minimal amount of state that is expected by the rendering routines. Next, the editor feeds the object commands to the rendering routines either one at a time or a level's worth at a time. While the emulator is running, its activity is monitored. During development, such monitoring might be used to find out what the rendering routines depend on, and in the release version, detect known illegal states caused by bad object use. Finally, the editor renders the tiles to the screen using the level's tileset. Tiles that do special things, like spawn sprites when struck, would be identified by the resulting tile type. I wonder if any editors do this, or if it is considered a worthwhile approach to rendering levels. |
| MathOnNapkins |
| ||
 Super Koopa Level: 62 Posts: 443/842 EXP: 1934559 Next: 50127 Since: 02-19-07 From: durff Last post: 4482 days Last view: 4005 days |
Stop stealing my ideas 
That's right... I see you on IRC in #rom-hacking But seriously we've discussed this before and I've considered it in the past when writing my Zelda editor (that has like 500 different object types). It could work, I guess, but I've never sat down and tried. ____________________ Zelda Hacking Forum hobbies: delectatio morosa |
| blackhole89 |
| ||
 The Guardian Moloch whose eyes are a thousand blind windows! Level: 124 Posts: 1767/4196 EXP: 21522376 Next: 314225 Since: 02-19-07 From: Ithaca, NY, US Last post: 465 days Last view: 78 days |
|
| DahrkDaiz |
| ||
 Nipper Plant Sandwich Artist Level: 46 Posts: 126/417 EXP: 674120 Next: 37654 Since: 02-22-07 Last post: 3480 days Last view: 3400 days |
As Math said, we had actually discussed this on IRC. It would conceivably work, but the amount of work that it would take to get it to work and effeciently would be incredible. Just loading information from a ROM such as offets used to load data tables which are used to load palettes, levels, sprites, etc takes a lot of work. |
| interdpth |
| ||
 Buzzy Beetle Level: 44 Posts: 238/383 EXP: 593374 Next: 17911 Since: 02-22-07 Last post: 4093 days Last view: 4066 days |
I actually tried this once, but my ASM knowledge didn't work so well and I was unsure how to translate between when the game was trying access memory, or from the ROM. 
It could probably easily work. o.o ____________________ lawl blog http://interdpths.blogspot.com/ |
| Sukasa |
| ||
 Red Birdo Level: 92 Posts: 805/2112 EXP: 7685592 Next: 71345 Since: 02-19-07 Last post: 4442 days Last view: 3213 days |
It wouldn't be that hard, just use the game routines to load the palettes as well!
In a way, all you'd need is a standard emulator core (heck, ZSNES' core would probably work), and just a single file to say where x data is, and where y data is, and so forth, that you could load from afterwards, by reading out of the snes' "RAM" |
| MathOnNapkins |
| ||
|
Super Koopa Level: 62 Posts: 446/842 EXP: 1934559 Next: 50127 Since: 02-19-07 From: durff Last post: 4482 days Last view: 4005 days |
I think in most cases it would be far easier to retool the format of the data to be more "script"-like *then* write an editor for it. The problem we have is that the data is unfriendly and tedious to write an editor for. If the idea is to make things flexible and easy I think that's a better way to go. ____________________ Zelda Hacking Forum hobbies: delectatio morosa |
| Trax |
| ||
 Yellow Stalfos Level: 71 Posts: 395/1145 EXP: 3034273 Next: 132841 Since: 07-06-07 From: Québec Last post: 3620 days Last view: 2872 days |
That's *almost* what I'm doing with some of my editors' functions. I had to reproduce in C the algorithm used to fill the PPU to come up with the proper tiles in my (WIP) Contra editor...
And when I was working of the scrolling areas in Zelda II Game Editor, I had some functions coded to layout different types of decor parts before knowing how it was done in the ROM. Later when I disassembled this part in the ROM, surprisingly I realized that it was almost identical in principle of functioning... So, it's not exactly assembly, but it's damn close sometimes and we can say some algorithms are basically doing an equivalent job from the ROM data... |
| frantik |
| ||
 Red Koopa Level: 28 Posts: 68/139 EXP: 127340 Next: 3998 Since: 10-09-07 Last post: 4483 days Last view: 4476 days |
SMButility works more or less like this.. it makes it really easy to edit hacks it's not perfect for everything but 99%. and of course the program contains an emulator inside of it as well for play testing which rocks. it's the model other editors should follow imo  if other games had editors as powerful perhaps we would see more interesting hacks.. not that there's anything wrong with smb hax XD
in this image the platforms and the upsidedown pipe are custom asmed in. the editor also displays all of the correct custom colors  |
| Main - ROM Hacking - I wonder if this has been attempted by an editor programmer | New thread | New reply |
© 2005-2023 Acmlm, blackhole89, Xkeeper et al. |
|
MySQL - queries: 72, rows: 100/101, time: 0.017 seconds. |