Thanks for the detailed explanation, it was very interesting to read. And glad to hear you've cut down your total time (still a lot of time but much less). That is really nothing short of amazing, given the quality that is shown. Again, great work.
I'm glad to hear you found a workable solution! It's nice to see how you cut out the nice-to-have bits and ended up with a much more efficient process. Thank you for all you do here.
Very nice to hear there is a more workable process. I guess FFCC with efb2tex and the patch is now just a perf boost if you are using 24 bit color. Are any other notable improvements known?
Also is your conversation with pokechu about Luigi's Mansion public? I would be curious to read it.
Quote:Also is your conversation with pokechu about Luigi's Mansion public? I would be curious to read it.
It is not public, but I can write up a gist on what Luigi's Mansion does when rendering.
Luigi's mansion renders in multiple passes. The first rendering pass is all solid objects as well as any bloom behind ghosts. Then the game RGB565 EFB Copies that into Main Memory. Also "it keeps depth around" so it can have ghosts behind objects and stuff, not sure how, pokechu didn't go into that. Luigi's Mansion then clears the screen (so the EFB is all black), renders transparent objects (such as ghosts) in half-scale mode (320x240). Then it RGBA8 EFB Copies that into Main Memory. Then it does another pass to combine the two together.
Quote:I guess FFCC with efb2tex and the patch is now just a perf boost if you are using 24 bit color.
Pardon? Force 24-bit Color is unrelated to performance and should not affect it at all.
(02-10-2024, 10:28 PM)MayImilae Wrote: [ -> ]I'll dive a bit into how the sausage is made.
Spoiler:
Well, it's less about me being amazingly smart or good with the new process, and more a sign of just how terrible the old process was.
So like, in the previous creative process, I would try to maximize everything, the best demonstrations, go over any history involved, tell the full story, etc etc. The complete and best attempt at every section. For Reports from years ago, that was important since much of the emulator hadn't been explained yet, and I was learning a ton. But now, I know SO MUCH and can do so much that the maximum version of the story was overwhelming. It had already ballooned significantly even when JMC was able to regularly contribute. I keep track of my time with an app, so with the previous creative process and JMC also pitching in, Progress Reports as of 2021 or so took me personally around 50 hours. Honestly that was already not what I'd consider -a lot-, but it was not terrible. Now that JMC is too busy and can't contribute much, that has basically doubled, 75-100 hours was pretty much the norm in 2023. That's the kind of time I'd want to put into high quality feature articles, that was not sustainable! But then we had the really rough previous Progress Report, where that maximize everything approach was met with a change where they had done very little if any testing. By that maximize philosophy, I had to get the details, so it was time for me to test their entire change for them, and I did. That Report totaled almost 200 hours of work just from me. It took over a month of me focusing on it exclusively. That was extremely unhealthy and wrecked me physically and mentally. It was definitely a wake up call that the entire creative process needed a redo.
So this new creative approach that I used in this Report is fundamentally different. For this Report, I wanted to get to the point and focus specifically on only what was directly related to the change. No long winded stories about the past here, just talk about the changes as they are and the things that are related to them. Then, I wanted to demonstrate those changes with as little effort as possible. For example, the maximized way to show the widescreen hack differences would have been two videos, synced to eachother of course, one with the widescreen hack and one with an action replay code, and of course looping perfectly and edited nicely and all at the same speed and that's like 6 hours of recording and editing by itself. This report? Two side-by-side images, bam, done in 5 minutes. It still does the job, and it's WAY easier and faster. For Luigi's Mansion, maximized would have been dissecting all of the EFB copies and showing them one by one, talking about all I learned from pokechu taking the game apart, then ending with a high quality screenshot of luigi's mansion without banding. Instead, I talked about the change and the change only, used the existing fifolog, and did a hold to compare. Does the job. For libaesnd, I could have gone on and on about those microcodes and why we supported them and the challenges of supporting a changing format, instead, I just introduced the microcode, how it was broken, and what the fix was - fast and to the point. So yea, it's just choices like these accumulating into making this Report WAY faster.
So in total, this report took 20 hours of my personal contribution to make, with a section written by Jos and a little help from JMC. About 4000 words from me specifically. It would have been 16 hours, but I had missed the EFB Copy change and once I saw luigi's mansion I was like, ok we got to cover this, and I gave it a single day (maximum 4 hours) to do a highly technical section. Fortunately pokechu bailed me out and dug into what the games were doing and explained it to me - I didn't have to probe into how or why it worked, I just learned from pokechu and wrote a section about the change. A big and highly technical section, but hey, 4 hours for that is not bad for that!
So I think this creative process change was a success. It's most of what the Report would have in the old process, but I can actually make this on my own and not kill myself doing it. And it's also just more too the point and less meander-y. We'll see what the reception of that is as the Report gets comments over the next day or two. I'll keep experimenting with it over time of course, and we'll see what happens. And maybe I'll get some help, who knows! But honestly, this is so much easier, I'll probably stick to this method even if we get help.
One thing I'd like to do is return to bi-monthly updates, so we can have shorter reports and faster betas. We'll see how that goes!
Thanks for this very good write up. It was super interesting gaining an insight into your process. I haven't read the Report yet but rest assured that if I have a problem with it when I do, I will let you know. Although I'm confident it's still amazing
(02-12-2024, 01:34 PM)MayImilae Wrote: [ -> ]Pardon? Force 24-bit Color is unrelated to performance and should not affect it at all.
As in, the options for not crashing FFCC are either turning efb2tex off or leaving it on while using the game patch right? The latter is more performant but causes more EFB copies to drop to RGB565.
You keep nagging about it in inappropriate places, but it already had a review which identified a potential problem, and the author never came back again to fix it or explain why it wasn't a real issue, so it needs someone who knows how it works to remake and resubmit it, or the original author to come back.
I believe it has been idle long enough that if you want to, you can clone and resubmit that pull request yourself. However, you would have to take responsibility for it and handle all the testing and any changes requested yourself.
