Personal Projects / Re: Ninja Gaiden Studio: A Cut Scene Editing Utility for Ninja Gaiden (in progress)« on: July 27, 2018, 12:00:06 pm »
As far as animating, I think I would be content to set a frame count and then manually advance the scene that many frames every time I click a button, if that is more easily accomplished than real-time animation.
I don't quite understand what you mean with the transparent overlay and sprite editing. Do you mean you adjust the transparency slider to restrict what tiles are edited, then edit/replace just those tiles? Also, are you referring to editing in terms of swapping tiles, or at the pixel level within a tile?
Your Deadpool example raises another question: Is it possible to export an image from a scene? This would make small tweaks easier (such as changing Ryu's head to Deadpool's in your example), and otherwise help the user stay within some desired frame size. Perhaps it would be enough simply to take a screenshot of the application with the desired image shown, then edit outside the program and reimport the whole image.
I have gone through the cutscenes to see what additional questions might come up. With the parallax scrolling and panning that happens, is this handled differently for backgrounds vs sprites? Can the speed and duration be changed?
Is there any adjustment possible for the "earthquake" effect, such as the amplitude, frequency or duration? (Unrelated to this application, how feasible do you think it would be to create the earthquake effect during gameplay? Something I have thought about for a long time.)
Thinking about this tool, I went ahead and sketched some dialog and scenes for a hack I'm working on.
The transparent overlay is only for the BG portion of the images, not OBJ. So you are only really editing the OBJ/sprite layer, and the transparent BG image is just there as a reference. It's useful for situations where instead of having a sprite moving around on the screen, you just want to add some color to the background to get around the 4 colors per tile limitation. This sort of thing is commonly something that you see for title screens in NES games, but it can be used to great effect in a lot of the NG cut scenes as well. Editing is going to be done at the pixel level from within that image, as I didn't make a separate editor for individual tiles on the sprite editor. The reasoning for this is that sprite tiles can overlap, which can make them difficult or annoying to select manually.
I want image editing to be simple enough to do from within the utility itself rather than relying on importing/exporting to external images, but you will be able to use the clipboard or the "load image" button to get sprite data from an external image. Are you talking about exporting the whole image including both the BG and OBJ layer and importing that back in? That's a lot more complicated, as it requires generating a new background image and sprite image at the same time, and all the difficulties involved in color-matching both parts within NES palette limitations. When most people draw a picture in an external editor they aren't thinking about those palette limitations. Also, depending on the size of the image and the locations of any color-fill OBJ tiles, multiple sprites may need to be generated, since there are only a fixed set of locations within a single sprite where tiles can be placed.
Scrolling for sprites and backgrounds is handled differently yes. Sprites can have different movement patterns: fixed, linear, "shake", or accelerating. These are set from within the SPRITESET command, but there is another MOVESPRITE command that can change it afterwards. But each movement pattern except for fixed has its data defined separately, so you have a limited number of movement patterns available. The editor can resize the number of movement patterns at will, with a maximum of 64 unique ones for each type. Each type of movement pattern has different defined properties, such as X/Y velocity both coarse and fine, and acceleration. The "Shake" effect cycles through a list of pre-defined sprite offsets and loops when it reaches the end. So it doesn't necessarily need to look like the sprite is shaking, but that is the way that it is used in the original.
For backgrounds, there is a SCROLL_SETUP command that defines the number of scrolling splits and the properties of each. The location, size, and speed of the parallax scroll splits can be changed, and is handled similarly to sprites in that there is a limit of 64 different unique sets of scrolling parameters that you can define. The earthquake effect is handled differently and there is a command defined specifically for it. Similarly to she "shake" movement pattern for sprites, earthquake cycles through a list of predefined scroll positions at a specified rate. For both parallax scrolling and earthquakes, the effects continue until you manually stop them by calling another command such as SCROLL_SETUP, EARTHQUAKE, SCROLL_STOP, etc.
I sort of made an earthquake during gameplay for the bomb effect in Deadpool, but I cheated a bit by disabling collision for the player and freezing enemies during the effect. The scroll position is directly tied to environment collision calculations, so environment collision sometimes fails during earthquakes. It might be fixable though.