Logo artwork #1
Labels
Comments
|
This sounds hilarious. Count me in! I haven't worked with such a limited colour palette before, so that's going to prove quite a challenge for me. I'll see what I can do though. |
|
This isn't an actual submission, but I couldn't help myself. |
|
Wow, thanks, it's already looking great! Looking forward to the final version. |
nmlgc
added a commit
that referenced
this issue
Mar 4, 2015
nmlgc
added a commit
that referenced
this issue
Mar 10, 2015
So apparently, TH01 isn't double-buffered in the usual sense, and instead uses the second hardware framebuffer (page 1) exclusively to keep the background image and any non-animated sprites, including the cards. Then, in order to limit flickering when animating the bullet, character and boss sprites on top of that (or just to the limit number of VRAM accesses, who knows), ZUN goes to great lengths and tries to make sure to only copy back the pixels that were modified on plane 0 in the last frame. (Which doesn't work that well though. When you play the game, you still notice tons of flickering whenever sprites overlap.) And by "great lengths", I mean "having a separate counterpart function for each shape and sprite animated which recalculates and copies back the same pixels from plane 1 to plane 0", because that's what the new functions here lead me to believe. Both of them are only called at one place: the wave function on the second half of Elis' entrance animation, and the horizontal masked line function for Reimu's X attack animations.
nmlgc
added a commit
that referenced
this issue
Sep 21, 2019
So yes, we *can* technically decompile from anywhere, by splitting the segment after the function we want, then .SEQuentially GROUPing the two segments back together into one virtual segment matching the original one. This gives us one more point where we can slot in new compilation units that emit their code into the same segment, in the order given on the link command line. *But* since all ASM in ReC98 heavily relies on being assembled in MASM mode, we then start to suffer from MASM's group addressing quirk, described in the "Accessing data in a segment belonging to a group" section in the Turbo Assembler Version 5 User's Guide. Which then forces us to manually prefix every single function call • from inside the group • to anywhere else within the newly created segment with the group name. It's stupidly boring busywork, because of all the function calls you *mustn't* prefix. Special tooling might make this easier, but I don't have it, and I'm not getting crowdfunded for it. And while this is faster than porting the entire codebase to Ideal mode, I'll only do this on rare occasions. Like the upcoming, particularly awful piece of reverse-engineering. Completes P0031, funded by zorg.
nmlgc
added a commit
that referenced
this issue
Aug 19, 2020
…tion Why does this suddenly break select_for_rank() in C land?! Part of P0110, funded by [Anonymous] and Blue Bolt.
nmlgc
added a commit
that referenced
this issue
Aug 28, 2020
Nope, not going to figure this one out on ASM level. Completes P0111, funded by [Anonymous] and Blue Bolt.
nmlgc
added a commit
that referenced
this issue
Oct 9, 2021
…ation code There might only be three functions between the second and new third split, but these seem to depend on the entire rest of the code for card-flipping stages… Part of P0160, funded by Yanga.
nmlgc
added a commit
that referenced
this issue
Nov 29, 2021
Well, except for GameCore(), which has nothing of interest. Part of P0168, funded by Blue Bolt and rosenrose.
nmlgc
added a commit
that referenced
this issue
Dec 27, 2021
…oup name The YUME.NEM functions won't be decompilable in their natural order otherwise. Part of P0172, funded by [Anonymous] and Blue Bolt.
nmlgc
added a commit
that referenced
this issue
Mar 5, 2022
… function We have finally run out of letters to remove from the first segment name in TH05! 🎉 But we surely won't have to decompile any other function from the middle of any of these 7 segments soon, right? Right…? Part of P0185, funded by [Anonymous], -Tom-, and Blue Bolt.
nmlgc
added a commit
that referenced
this issue
Apr 30, 2022
…unction Part of P0192, funded by [Anonymous], nrook, and -Tom-.
nmlgc
added a commit
that referenced
this issue
May 29, 2023
That's it, no more letters left in the front… Gotta clean this up soon. Part of P0240, funded by JonathKane.
nmlgc
added a commit
that referenced
this issue
Feb 3, 2024
… Room Yup, TH02 as well. Part of P0264, funded by [Anonymous] and Blue Bolt.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
(@Shinmera, would you be up for doing artwork for this project as well? I've even got a more detailed description this time around.)
Now that all the doubts about the feasibility of this project have been removed and I'm slowly starting promotion, it would be nice to have some custom artwork to go along with it.
The basic concept I've been having in mind is Richard Stallman cosplaying PC-98 characters (or the other way round, whichever you think looks better or funnier). There would be 6 main versions in total: one with Reimu or Marisa (again, up to the artist) to represent the project as a whole, as well as the final boss of each game (Sariel, Mima, Yumemi, Yuuka and Shinki) to represent that specific game.
Stylistically, I'm looking for something similar to Touhoumon sprites, that is, a whole-body drawing of the given character striking a random pose. Bonus points if the 5 Magic Stones are included in the artwork, since I just love using them to mock Touhou character discussions. ☺
I'm not asking for entirely separate images per game. It's completely fine if the costumes of the 6 characters are merely layers on top of a shared base pose.
Since these will be mainly used as icons, you should be going for a square aspect ratio. Apart from that, draw as high-res as you like. (Of course, SVG is always preferred, but it's not too important.)
That said, the future ports will also introduce new in-game menus for mod selection, and I'd like to reuse some of the character artwork as message box or status icons. I think I should be able to create low-res sprites from the high-res promotional images by myself, but it would be great if I could get some help there as well. In that case, we could even add a small waiting animation or different expressions for the various types of message boxes (information, warnings and errors).
Just note that these images need to match the constraints of the PC-98 graphics hardware, and can thus only use a maximum of 16 different colors.
However, we're still about one year away from that point, so I can't give any more specifics on that right now.
The text was updated successfully, but these errors were encountered: