Romhacking.net

Romhacking => ROM Hacking Discussion => Topic started by: M-Tee on December 28, 2013, 09:39:48 pm

Title: Work flow
Post by: M-Tee on December 28, 2013, 09:39:48 pm
So I've mulled around the idea of putting together some beginner's-oriented tutorials covering graphics, text, palette, etc. that are focused on workflow. This would be a slow-building back-burner project, and in the meantime, I would like people's input as to how other people work.

So I guess this would be a pretty open-ended,"how do you do what you do efficiently?" thread.



Title: .
Post by: Chpexo on December 29, 2013, 06:02:48 pm
.
Title: Re: Work flow
Post by: Pennywise on December 29, 2013, 06:31:33 pm
I use Atlas to insert various kinds of data.
Title: Re: Work flow
Post by: FAST6191 on December 29, 2013, 07:37:07 pm
Hmm. I agree we often risk getting too "here is computing science, you need to learn it before you make an infinite ammo cheat" around here and in a lot of hacking circles I like being part of (which is to say general hacking circles and not so much the game specific stuff, exceptions there being for those that lean back towards general hacking even if they have a lot of the games they deal in decoded). Unfortunately whenever I or someone does then explain the ideas of a table (01=a, 02=b.... the numbers do not have to be the same but something will correspond to something else), basic pointers (the device can not read text and it has to be told where things begin and end, think contents page in a book) and limits (just because it fits on your PC does not mean it works on the rather more limited console) we seem to get them crawling out of the woodwork with games featuring crazy custom compression, things woven as tightly as possibly into the binary, wanting it to be as easy as using a word processor......
That said there is definitely some merit the "best person to teach things is the one that just went through it" idea.

My workflow.... somewhere along the lines I got the ability to decode ASCII in my head as well as do OK for random tables, better for shiftJIS and found similar things for when I need to decode data structures, figure out the values for tile sizes and so forth. Similarly I have done 20 minute ASM hacks to spare myself a lot of aggro and I can trace things (including formulating a good plan of attack there) rather than spend the 4 hours it would take to find it by other means. All of these are skills that are somewhat able to be learned. Add on some learning of the obvious/common tells in a system (though how much of that is ASM knowledge) and you get the apparent ability to skip 9 stages thing. In some cases each of those play out in similar fashion to the "you are moving too fast for me" you might have had if you fixed a computer for a less than computer savvy person (I will dismiss garbage/false positives from a strings search at about the speed it takes the screen to focus).

However the biggest one I often see new hackers overlook is to simply watch the game play and try to see something there, I see something that could be text markup and I will exclude it from my searches or at least account for it, I see something that is doable in just a material colour and I will go there rather than launching into finding a texture.....
Actually thinking more the biggest one I see is probably still the desire translate a 90 hour RPG right off the bat or a very specific game before they gained the skills but that is more easily worked around.

"efficiently"
I am never so efficient as when I am working with someone else (translator, artist, musician....) that can handle a bit of ROM hacking cruft. The old last 10% rule bites me hard if I have to completely sanitise something before passing it on to be worked on and worse when I get it back.
On the other hand if I am working by myself... well despite my rather slapdash/winging it approach most of my worst troubles have come from times when I did not bother to completely understand a format before I started trying to inject "finished" grade work back into it.
Title: Re: Work flow
Post by: Pennywise on December 29, 2013, 07:57:38 pm
No offense, FAST6191, but you write too much. I have a feeling you could write an essay to an answer for a simple question. ;)
Title: Re: Work flow
Post by: FAST6191 on December 29, 2013, 08:10:45 pm
It is not the first time I have been accused of being overly verbose and I would even agree with the assessment. Unfortunately I like to contemplate edge cases too much as well as lessen the ambiguity of whatever core points I am making. Though I have got to the point in life where I can get past it* if I need to get something done in the real world I have yet to make it there when it comes to writing anything.

*I still routinely get bitten by thinking "the person before me can not have hosed it up that much".
Title: Re: Work flow
Post by: Kiyoshi Aman on December 29, 2013, 08:17:47 pm
The best way to be unambiguous is to pick your words carefully.
Title: Re: Work flow
Post by: FAST6191 on December 29, 2013, 08:44:50 pm
Though I am not trying to decide whether ambiguous was the right term for me just then I suppose it is more I always hated the "remember what we taught you last year, well it was an oversimplified model and this is the real deal" (rinse and repeat for every year, usually around 15 of them, until you hit the state of the art or learned the thing that underpinned it all) thing in schools. I suppose I could make more of an effort to write along the lines of "for the most part", "In general" and ".... except when it is not" though, possibly even forcibly cutting myself off at such a point.
Title: Re: Work flow
Post by: Kiyoshi Aman on December 29, 2013, 09:18:54 pm
Seriously, dood. Write only what you need to say, no more. It really isn't that difficult.
Title: Re: Work flow
Post by: Drakon on December 29, 2013, 10:00:44 pm
No offense, FAST6191, but you write too much. I have a feeling you could write an essay to an answer for a simple question. ;)

Word.  I'm never going to bother reading a post that big.
Title: .
Post by: Chpexo on December 30, 2013, 02:17:57 am
.
Title: Re: Work flow
Post by: M-Tee on December 30, 2013, 02:33:01 am
Yeah, there's very little available for Newbie's using today's available utilities.

I've managed to put together a fairly specific workflow for graphics using photoshop and yy-chr, and plan to be graphics-oriented in the document. However, graphics can't be done without palettes, no one wants to hack a game and not touch the text, and even simple graphics hacks can benefit from something like TSA hacking.

Also, it'd be nice to have a fairly reasonable and all-ages appropriate, simple PPU documentation (for title screen hacking) without linking people to Badderhacks. As fantastic and clear to understand as Dr. Floppy's guides are, I know I was 13-14 when I first got into the hobby, so we can expect a lot of newcomers to the site to be that age or younger, and the less white trash toilet humor, ironic or not, that folks are exposed to, the better.
Title: .
Post by: Chpexo on December 30, 2013, 03:33:45 am
.
Title: Re: Work flow
Post by: M-Tee on December 30, 2013, 06:34:48 am
Would be nice offerings. I haven't tried to use the debugger/trace logger of FCEUX. I also don't do anything other than NES work, and like I said, focus mainly on graphics.

This thread could also serve as a call to arms for new documentation for beginners.
Title: Re: Work flow
Post by: STARWIN on December 30, 2013, 01:00:47 pm
I'm not sure how you differentiate between a tutorial and a tutorial that focuses on workflow?

As I see it, a tutorial assumes a goal and then describes the steps that have to be taken to reach the goal. Following such steps then generates a workflow for the one being tutored. In the "worst case" or "simplest case" the tutored will then be able to do only what was told. For any potential question, you could create an explanation, thus increasing the chances of the tutored figuring out an even better workflow (than the one provided) or even allowing the tutored to tackle problems that you didn't assume. Continuing to this direction..

"here is computing science, you need to learn it before you make an infinite ammo cheat"
..something like this will be the end result. A "perfect" model of the environment being dealt with. Personally I know nothing about graphics as I so far have only wanted to change program code, but the few PPU related pieces of text I've read have been rather difficult to grasp.

Basically my opinion is that a good guide explains a lot of the concepts related, while staying concise enough to be easily readable. I wouldn't give terribly much value for specifying some exact workflow, unless it explains the concepts nicely along the way. I don't know if you'd call it a tutorial at that point though.

..how do I do things efficiently? By asking questions and having the intelligence to answer them myself. This eventually builds the "perfect" model in which I can navigate in. The learning process isn't efficient however, only what happens after it is.

However broad or exact goal you will set, it may be a good idea to post drafts of your tutorial(s) to the forum.

As a side note, why are posters Pennywise, Kiyoshi Aman and Drakon suddenly pretending to be illiterate, bullying FAST6191 for providing a relevant addition to the discussion and derailing the thread while only adding one-liners with no measurable content? If you really want to seriously discuss your lack of ability of reading FAST6191's posts, perhaps you should open a new thread for it in general discussion instead? replies to the new thread please..
Title: Re: Work flow
Post by: KingMike on December 31, 2013, 06:14:20 pm
I don't think such a thread is a good idea.
Title: Re: Work flow
Post by: Drakon on December 31, 2013, 09:43:57 pm
It wouldn't hurt to have a little introduction to how:
  • to use a hex editor
  • FCEUX debugger and trace logger works and how to use it (ex. how to add more lives to a game, increase speed of a character)
  • pointers work and how to repoint
Though covering how to hack beyond the NES might be a wise choice. I recall that a Gameboy emulator called bgb (http://www.romhacking.net/utilities/412/) has a debugger that's worth checking out. I'd also like to see more Nintendo 64 hacks that aren't simply texture hacks.

You can't make some universal guide for a lot of these things.  Every game is programmed differently.

I agree debuggers are anything but user friendly.  Luckily once you learn one they're all pretty much the same thing, just the asm language changes.
Title: Re: Work flow
Post by: Pennywise on December 31, 2013, 10:05:13 pm
FCEUX's documentation is pretty good I'd say. Enough to teach you debugging fundamentals? Well, for beginners probably not.

Quote
As a side note, why are posters Pennywise, Kiyoshi Aman and Drakon suddenly pretending to be illiterate, bullying FAST6191 for providing a relevant addition to the discussion and derailing the thread while only adding one-liners with no measurable content? If you really want to seriously discuss your lack of ability of reading FAST6191's posts, perhaps you should open a new thread for it in general discussion instead? replies to the new thread please..

I was just making an observation, I wasn't attacking him like your attacking myself others. And for the record, my initial post speaks for itself. I use Atlas to manage most of my workflow. I've gone from manually doing everything in a hex editor to automating data/code insertion/extraction with the only exceptions of inserting uncompressed graphics through TLP etc and making quick/small changes.
Title: Re: Work flow
Post by: Kiyoshi Aman on December 31, 2013, 10:59:45 pm
As a side note, why are posters Pennywise, Kiyoshi Aman and Drakon suddenly pretending to be illiterate, bullying FAST6191 for providing a relevant addition to the discussion and derailing the thread while only adding one-liners with no measurable content? If you really want to seriously discuss your lack of ability of reading FAST6191's posts, perhaps you should open a new thread for it in general discussion instead? replies to the new thread please..

I don't think that word means what you think it means. I don't want to read a wall of text, and i don't think anyone else does either. I pointed out, in two different ways, what he could do to improve his writing. I don't understand how my, Pennywise's, and Drakon's statements could be interpreted as 'bullying' except by creative reinterpretation.

Incidentally, I think you're guilty of the exact same issue he is, and I think both of you need to learn to be concise.
Title: Re: Work flow
Post by: Drakon on January 01, 2014, 09:09:26 am
FCEUX's documentation is pretty good I'd say. Enough to teach you debugging fundamentals? Well, for beginners probably not.

Not that long ago I was a beginner.  It took a lot of asking around to figure out what all the things in a debugger mean.  It's not just learning debuggers, you also need to read documents on how the software works and talk to people with experience to understand the programming.  Someone should make a tutorial about the general things that all debuggers and asm languages share.

I don't think that word means what you think it means. I don't want to read a wall of text, and i don't think anyone else does either. I pointed out, in two different ways, what he could do to improve his writing. I don't understand how my, Pennywise's, and Drakon's statements could be interpreted as 'bullying' except by creative reinterpretation.

Incidentally, I think you're guilty of the exact same issue he is, and I think both of you need to learn to be concise.

Yeah what I was hinting at was that he can find a way to either make the wall smaller or break it up into multiple posts over time.  The point of a forum is people interact with the conversation one man rants tend to be...well....one-sided.  I guess next time I'll just say nothing and let him continue making posts that nobody will want to read since I get insulted for suggesting a better way to post.
Title: Re: Work flow
Post by: BRPXQZME on January 01, 2014, 03:34:36 pm
Alright, I cannot be the only one who’s looking at this and thinking FAST managed to (http://i.imgur.com/cyvG9z3.gif) troll y’all hook, line, and sinker. That said, if you expect that statements including such phrases as “It really isn't that difficult” and “I'm never going to bother reading” are not likely to set people on the defensive, your expectations are dumb as hell.* :P

That also said, FAST, you use a lot of run-on sentences and omit many important commas. This, more so than the voluminosity, is exhausting to read. Well organized writing is skimmable writing.

ONE MORE THING: I’m not so sure anything I do is efficient. I always try to see if I’m repeating some action the computer could do better, or taking too long between steps when it’s avoidable. If you are familiar with kaizen (https://en.wikipedia.org/wiki/Kaizen), well, the idea is kind of like that. Being able to adapt your process is arguably as important as the process itself.
Title: Re: Work flow
Post by: M-Tee on January 02, 2014, 01:46:46 am
I'm not sure how you differentiate between a tutorial and a tutorial that focuses on workflow?

I wouldn't give terribly much value for specifying some exact workflow, unless it explains the concepts nicely along the way. I don't know if you'd call it a tutorial at that point though.

However broad or exact goal you will set, it may be a good idea to post drafts of your tutorial(s) to the forum.

Yes, specifying a fairly exact workflow with explanations is the plan. Quite personally I don't like tutorials, and using that term to describe my intention was a poor choice of words on my part.

I plan to make this available as a series of activities in a thread in the Newcomer's forum and
instead of offering a follow-by-number like typical tutorials, it would be intended to have them choose a small project of their own which includes graphics, palette, text, and title screen alteration, with the steps laid out along the way.

The difference between it and a traditional tutorial is that the end result should be unique for each reader, The difference between what I have planned and typical documentation is that it will have the reader learn by doing.

Basically, I'm going to provide what I would have liked to have had to begin with. The intended audience will be limited, as it will be targeted towards graphics hacking, and specifically to those that hold aesthetics in high regard. That being said, I intend it to teach how to use Photoshop as the backbone of the project, and the resulting resource would also prove useful for indie game artists or anyone else attempting retro-game-art.

The scope of what I have planned is something along the following lines:

So far, I plan to include a hex chart for pasting into and identifying graphics, a PSD file for identifying PPU addresses and palette attributes of the screen, custom tile-based graph paper to design graphics away from the PC, and a palette file for Photoshop.

Someone correct me if I'm wrong, but games that never load different banks of graphics are the mapper 0 games? If so, I believe I would  begin with a list of Mapper 0 games to choose a project from, putting an emphasis on the creation of new graphics.

Hopefully it would result in some more creative attempts from first-timers and less "OMG, it's  characters and items from game X, but they're in game Y!" hacks.

@BRP: If you would be so kind as to remove the obnoxious GIF you have chosen to place ToTP not related to the topic of this thread, it would be appreciated.
Title: Re: Work flow
Post by: KingMike on January 02, 2014, 02:33:54 am
I think it is necessary at this point to ask for an end to discussion of FAST's writing style. :police:
Title: Re: Work flow
Post by: M-Tee on January 04, 2014, 02:24:31 pm
Alright,  thread started (http://www.romhacking.net/forum/index.php/topic,17513.msg254621.html#msg254621). I'll build it up, piece by piece, modifying from feedback, etc. and will finally collect the lot, post on my site, and submit as a document.

Judging from its length, I feel I may be the one more prone to long-windedness.