Printable View
As usual, [LEFT] Original MD game; [CENTER] GnG ARCADE MD; [RIGHT] Original arcade game:Quote:
Originally Posted by aMaru
https://i.imgur.com/35t8z20.png
https://i.imgur.com/TM0aFcE.png
https://i.imgur.com/tJbllxQ.png
https://i.imgur.com/gbxMXri.png
https://i.imgur.com/LtyCe6R.png
https://i.imgur.com/0kjt1uA.png
https://i.imgur.com/Sh67IJ1.png
I don't always have the best eye for spotting the differences in these kinds of hacks, but of course even I can see at a glance how much more faithful and vibrant the revised work is. Looking good! :)
Holy crap! That looks great! I love this game and can't wait to see the finished work.
Looks amazing! I never noticed how much detail was missing from the home version.
Yeah, this is super impressive work.
Wow! Beautiful. Can't wait to see more, stage 2 is even worse in terms of cut grafix.
It's amazing how the hacked version looks better than both arcade or the original MD port. Great job!
IMHO, it looks even better than the arcade version!
If aMaru can pull it off till the end then this one is going to be truly epic.
The Genesis 'killer app' getting a 'killer upgrade'. Simply Outstanding.:rock:
Thanks everybody. Just reposting the pics for stage1-part1 (Link) in this new thread (Thanks Barone for helping me create a new one).
I'm still playing aroung with the clouds, so this will likely change.
More pictures coming soon
LEFT: original MD game -- CENTER: modified MD game -- RIGHT: original arcade game
https://i.imgur.com/YyXVVS8.png
https://i.imgur.com/01qp1gr.png
https://i.imgur.com/ECOIhF0.png
https://i.imgur.com/de5K9qx.png
https://i.imgur.com/nwbgiRX.png
Looks much, much better than the original Genesis version, this is what it would've looked like on an 8 Meg cart? All I can say is, HOT DAMN! I do hope the sound effects, like hitting the gravestones with your weapon are improved, they are just a little too harsh on the Genesis, they have a softer sound on the arcade/Saturn/PS1/PS2 versions.
This is what it could have looked like on a 32meg cart. Very impressive!
Not to nitpick - but some of the assets are using the same aspect ratio as the CPS1, so when viewed side by side they will look wider on the Genesis.
I don't know if that's the artist's choice or if it has to be done to line up with the level structure.
Just amazing sir! What ROM size are you using up until now?
Thanks for your job!
The assets preserve the correct aspect ratio. Which ones were you referring to?Quote:
Originally Posted by axel
Consider that in many cases the assets are heavily modified: to reduce the number of tiles I'm hand drawing a lot of tiles (on average I'm using one third of the original arcade game tiles).
I believe the assets you are referring to might just be different from the original, and thus might appear "fatter" because of how I have redrawn them.
Some more updates and comparison pictures.
The bridge and the swamp. Although I can use a very limited number of tiles for the swamp I believe I can still improve it, which I'm currently trying to do.
Anyhow this is where I'm at at the moment.
ORIGINAL MD GAME
https://i.imgur.com/e2dCsu9.png
MODIFIED MD GAME
https://i.imgur.com/1axzumi.png
ARCADE GAME
https://i.imgur.com/YPFqGXp.png
And here is the background for the boss battle.
The original MD game really simplified the graphics, both for the lush tree canopies in the foreground and for the suggestive lightning animation in the far background.
I have now restored both, which took a lot of work because nearly the whole content of the VRAM needs to be updated in very limited time.
I'm pretty satisfied with the result, however. What do you think?
Here's the forest with a dark background
ORIGINAL MD GAME
https://i.imgur.com/rnSICBe.png
MODIFIED MD GAME
https://i.imgur.com/CeOJmBX.png
ARCADE GAME
https://i.imgur.com/iTsCSDJ.png
and here the animation of the lightning
ORIGINAL MD GAME
https://i.imgur.com/5gpaRhC.png
MODIFIED MD GAME
https://i.imgur.com/fXhIQBk.png
ARCADE GAME
https://i.imgur.com/DwL7Mpp.png
I think he means that the CPS-1 aspect ratio (the PAR) is 0.76 where as the Genesis PAR is 0.914 but in the pics some/most of the assets aren't scaled to compensate this, so they're going to appear wider than how arcade system shows them.Quote:
Originally Posted by aMaru
Looking at the screen shots you posted so far, I already was quite surprised, how much you've been able to improve the graphics over the original MD version. However, this new boss battle background just blows my mind. So beautiful.Quote:
Originally Posted by aMaru
It looks phenomenal IMO. Fantastic work.Quote:
Originally Posted by aMaru
For the forest with a dark background maybe you could try something along the lines of what Quackshot used (but with greens and browns you have available there) if you don't want to have it in pitch black only:
https://i.imgur.com/L1yC1EX.png
But IDK if that would work and if realistically (tiles, RAM) you have any room for improvement.
Yes.Quote:
Originally Posted by turboxray
But to be fair, the original MD port also didn't account for that for the most part. The artwork was heavily watered down but it seems that it derivates from the the original arcade, with the CPS-1 PAR.
Thanks for the comments and the support.
Now I am dealing with a problem related to the GUI. This is implemented using the window plane, which renders color 0 as solid black rather than the transparent color.
This causes the portions of the plane A underneath the GUI to disappear, as you can see from these pictures.
https://i.imgur.com/TtGWMR1.png
https://i.imgur.com/0PysreU.png
The plane explorer shows the entire tilemap for the clouds in the upper parts of the sky and for the swamp in the lower part of the screen, but this is overwritten by solid black bars.
This is particularly problematic in stages 2 and 3, where the scrolling creates a really weird effect, but also in stage 1 we don't want the beautiful background tiles to get lost.
And I have completed the new swamp, which now looks like this:
https://i.imgur.com/6RDjh0c.png
Here's the original for reference:
https://i.imgur.com/xHL58m4.png
This is much brighter than the original arcade counterpart, but overall I like it better than the previous B/W rendition.
I also prefer the current tile selection, the gnarled tree on the right better conveys the spooky atmosphere.
Let me know your thoughts.
Thanks a lot!Quote:
Originally Posted by Barone
This stage in Quackshot is really gorgeous...Quote:
Originally Posted by Barone
Unfortunately I don't have a single spare tile to modify the background, nor a color that I can add to my palettes (the trees could use a gray shade, rather than the pitch black)
However, to make the trees stand out a bit more in the darkest frame I can modify the background color to a dark shade of blue, rather than black.
Here it is (plane A only), along with the other two animation frames.
https://i.imgur.com/nnUDlJw.png
https://i.imgur.com/7gxxo7c.png
https://i.imgur.com/9aeDJ4r.png
Sure this is nowhere near the level of detail of Quackshot, but maybe it's a bit better (and closer to the arcade).
What do you think?
You've got dark greens and dark browns in your palettes. Maybe you could try replacing the black with any of those? You'd get a background contrast closer to the arcade version.Quote:
Originally Posted by aMaru
While not aMaru, Pyron and Stika are working on an arcade edition of Sunset Riders for the Genesis, and I must say, it looks to be a massive improvement over the lazy job Konami originally did for the console.
https://www.youtube.com/watch?v=iHR2DhfFhT4
Your version for me looks better than the original because has more contrast and makes the art stands out much better.Quote:
Originally Posted by aMaru
Congratulations for your amazing work
This is brutal.
If anything, you are showing very good taste on color selection.
Most, if not all, of the different approaches you show actually work. So it is a matter of throwing dices for selecting one.
Do you plan to release any beta with the current stuff?
What is that black line between the water and the background, is there a way to fix that??Quote:
Originally Posted by aMaru
watching at this thread makes me appreciate the Supergrafx port even more, if this MD hack ends up looking closer to that I'd call it a success.
This is the most complex hacking job i ever seen. You load new tilesets/tilemaps during the gameplay, huh? IMPRESSIVE!Quote:
Originally Posted by aMaru
The Window plane cuts all the gfx in the BG_A area since it shares the same plane with the difference that scroll don't affect it.
You can easily noticed this "problem" during the start of the stage 2. For me this is not a big problem.
I'd prefer if it could be a little less saturated.Quote:
Originally Posted by aMaru
Capcom used to shade to grey-ish tones to favor visual separation, regardless of parallax.
Yeah, the original tones (especially the MD ones but the arcade's too) sucked (also 'cause some of those choices were made to overemphasize foreground contrast and saturation as screens needed to be as attractive as possible to catch arcade players' attention and coin$$$) but now it's a bit too vivid to be in far somber plane IMO. Again, IDK if you have less saturated colors available in the palette.
I think it looks better now, thanks.Quote:
Originally Posted by aMaru
I thought you're already on the limit given the insane amount of details you're already pushing.
Incredible work. Of anything WIP MD-related, this and the Shinobi port are the ones I'm really anxious to play.
Totally brilliant aMaru!!!!!
How the project goes?¿
Sure I do!Quote:
Originally Posted by dr apocalipsis
I still have some things to fix before I can do that but I'll definitely release a beta for stage1.
Many thanks Linkuei. Yes, I load new tilesets/tilemaps and change palette entries during the gameplay.Quote:
Originally Posted by LinkueiBR
Correct. It actually turned out to be not so straightforward to fix, thus. The window plane renders color 0 as solid black rather than transparent, so the only way I see to fix this is to entirely disable the window plane and draw the GUI using sprites.Quote:
The Window plane cuts all the gfx in the BG_A area since it shares the same plane with the difference that scroll don't affect it.
You can easily noticed this "problem" during the start of the stage 2. For me this is not a big problem.
Currently I'm following this approach, but drawing the GUI with sprites in this game poses very tricky tradeoffs between number of sprites (and the games is already plagued by flicker at places) and VRAM space/tile replication.
Some updates on my GnG ARCADE project.
I've been doing quite some progress, although most of it can't be shown with pictures.
1) The problem with the GUI and the black bars at the TOP/BOTTOM of the screen
I have described this problem in a previous post (HERE the link).
The only way I see to get around this problem is to completely disable the WINDOW plane and to draw the GUI with sprites.
Concerning the first part, I have succeeded in disabling the WINDOW plane, which - as you can see in the pictures below - solves the issue of the black bars.
This was per se not straightforward, as being the GUI split between top and bottom parts of the screen the WINDOW plane was dynamically reconfigured mid-frame, which took me some time to figure out.
Concerning the second part, I got to the point where I understand how to hook the routines that handle the sprite table, but I haven't found a satisfying solution to implement this, yet.
This is because this game already uses quite a lot of sprites to avoid tile replication in VRAM (many small sprites rather than few large ones), which sometimes results in sprite flicker.
Thus, I need to come up with a scheme that minimizes the number of sprites I need for the GUI, while at the same time not increasing significantly the space needed in VRAM.
More on this very soon (I hope).
https://i.imgur.com/gZoJgin.png
https://i.imgur.com/H1IJnHH.png
2) The windswept tree animation
In the second part of stage 1 there is an animated sequence where wind and rain appear, and the tree in the foreground is bent by the wind.
The original MD game relies on two animation frames drawn on a very narrow rectangle.
This requires a smaller number of tiles to change horizontally, but visually makes the animation less effective compared to the original.
I restored a closer animation to the original game, albeit with a much smaller number of tiles (I could not afford more).
This required to completely rewrite the routines that control the animation, and thus a lot of time :)
Maybe at a later time I will consider including the missing third frame of animation (if I manage to draw it using the tiles I already have)
https://i.imgur.com/CTPZyuX.png
3) Some graphical improvements
As pointed out by Barone, during the boss fight one of the frames of animation for the lightning in the distant background is too dark, to the point where it is difficult to spot the trees.
I had attempted already to improve this, but I was not happy with the result.
This is how the animation frames look now.
https://i.imgur.com/PxxJBtG.png
Finally, there were a few spots where the assets in the foreground shared colors with assets in the background, with the result that it was not always easy to distinguish the graphics from one plane to another. Also, the overall look was kind of monochromatic.
I replanned a bit the organization of the palettes and managed to squeeze a few more colors to repaint some assets in the foreground (the cross and the guillotine) to give them more contrast.
Here are a few pictures highlighting the difference.
https://i.imgur.com/nGWEfRe.png
https://i.imgur.com/WYElCLc.png
Quote:
Originally Posted by aMaru
About the HUD's VRAM usage, placement, impact on flickering, etc:Quote:
Originally Posted by aMaru
- Have a look at the SuperGrafx version. It's a good starting point IMO (https://youtu.be/TQoYVNZGFi8?t=1574).
- The original arcade HUD is extremely wasteful and obnoxious. This is a personal perspective, but I think the HUD should be low-priority and minimal in terms of screen space, VRAM allocation and sprites usage since this game is already a juggernaut in terms of sprites, tiles, map design, etc.; in that sense, there's a number of things that can be made:
- In order to mitigate sprite flickering you want to reduce horizontality in favor of verticality. So, starting with the SuperGrafx HUD (which already gets rid of the Top Score thing), I'd bring the player score below the time counter. Now both of those counters could also be reduced to
P1: _score_counter_
T: _time_counter_
By reducing the labeling to P1: and T: (but I'd probably keep them colored in orange-ish tones) you could also reduce the lettering loaded into the VRAM. Actually you could store them as unique graphics in the ROM with an specific size so that each one of those static labels would fit in a single sprite and you could leave the font-based text stuff only for the end of level messages and whatnot as you'd only need to have the numbers loaded into the VRAM for the counters.
That lives counter is also idiotic and wasteful af. It also uses a unique graphic; I'd get rid of that as well.
If you want to keep the unique graphic, at least use somethin like:
_wasteful_image_ x _number_of_lives_ instead of repeating sprites horizontally 'cause that would be a flicker fest and consume slots in the sprite list for no good reason.
But I'd rather move that to be below the score and time counters.
P1: _score_counter_
T: _time_counter_
_wasteful_image_ x _number_of_lives_
That image also uses a head and part of the torso. I'd reduce it a bit by using just a head. You could also use the player character's current head instead; that could reduce the footprint in the VRAM even further.
And I'd flip it horizontally to be heading to the right instead of to the left as it does originally.
- Now, you still have that weapon charge meter which is also wasteful and horizontal as hell.
The SuperGrafx version mitigates its footprint by using identical circles and placing them very close to each other. I'd go with that as well.
You could also make them a bit more oval by stretching them vertically; that would reduce your horizontal footprint which could be nice to reduce flickering.
Regarding the sprite flickering:
- The MD game doesn't seem to order the linked sprite list in an optimal way in terms of avoid flickering of characters and even the player's sprite. Ideally, you want the more important stuff in the beginning of the list, so player's sprites and the projectiles should be in the beginning. Effect/non-playable elements should be last, such as the explosion effects.
In this game you see stuff like the explosions being drawn correctly while the player sprite flickers badly, that's poor sprite list organization.
- Bosses should be using a scroll layer to most of their bodies instead of just sprites. It's plain stupid how they used the hardware in the boss fights.
This one is aggravating: https://youtu.be/TQoYVNZGFi8?t=963
This is what Darius (2019) on the Mega Drive does to have those massive bosses with minimal flickering: use as much background layer and tile animation as possible instead of sprites.
There's also Final Blow which uses tile animation to render the referee (Samurai Shodown also uses that but for comparison here I think Final Blow is actually a better example). Depending on the background you have in the scene, that kind of technique can be useful.
- The explosion effects overdraw a lot of sprites and make them permanent over the scanlines. That's also stupid.
Non-gameplay elements like that could be flickered at 30 fps, so if you have 6 explosion sprites you'd show only 3 for each frame; one group for even ticks and other group for odd ticks.
Another technique is to move the explosion sprites away from the originating y coordinate as the time passes, so you avoid crowding the same scanline. Have a look on what Bio-Hazard Battle does on the Mega Drive. There's probably no better example of sprite flickering mitigation techniques on the MD than what that game does.
- In terms of VRAM space optimization on the Mega Drive, the best examples you can find are probably Darius (2019) (the ROM can be found easily on the Internet) and Joe & Mac. You can probably draw some additional tricks and ideas from analyzing those games.
- A sort of "last resort" technique would be sprite-multiplexing as Stone Protectors does for the snow effect. It fills the screen using like 2 hardware sprites. Not useful in all cases and requires midframe trickery but you could probably use that for the static labels on the HUD. Stuff which is not in the same scanline should be less difficult to use with that.
Thanks a lot Barone for sharing your thoughts and suggestions
Indeed the way I am dealing with the redesign is totally in line with what you are suggesting, so it's very good to see that these choices are reasonable.Quote:
Originally Posted by Barone
I won't need to shrink the PLAYER and TIME writings, as I have laid out the letters in VRAM such that the writings can be respectively drawn as two sprites (including part of the actual score, which is immutable zeroes) and a single sprite.
I have dropped the TOP SCORE, no way I can afford to keep that.
Also, the TIME indicator will probably lose its nice frame (just as in the PCE version)
Concerning this, I am still not sure whether I will be able to keep it or not.Quote:
- Now, you still have that weapon charge meter which is also wasteful and horizontal as hell.
The SuperGrafx version mitigates its footprint by using identical circles and placing them very close to each other. I'd go with that as well.
You could also make them a bit more oval by stretching them vertically; that would reduce your horizontal footprint which could be nice to reduce flickering.
In any case, when the magic is fully loaded the weapon icon flashes, so the player will have anyhow the indication that magic is available.
I'm not happy to drop it, but I'll see where I can get.
Indeed the main sprite is NEVER top of the list.Quote:
Regarding the sprite flickering:
- The MD game doesn't seem to order the linked sprite list in an optimal way in terms of avoid flickering of characters and even the player's sprite. Ideally, you want the more important stuff in the beginning of the list, so player's sprites and the projectiles should be in the beginning. Effect/non-playable elements should be last, such as the explosion effects.
In this game you see stuff like the explosions being drawn correctly while the player sprite flickers badly, that's poor sprite list organization.
This is a consequence of how they have engineered the HUD itself.
They have used planeA for the background (to prevent the WINDOW plane with the HUD from cutting foreground graphics), inverting the standard priority order with plane B.
So all tiles in planeB and the main sprite must be kept in HIGH prio, and the only way to have it drawn below other stuff (e.g., when you pass through the guillotines) is to draw such stuff with higher prio sprites (hence, the sprite draw order).
For this particular example you show I agree they could have nonetheless used a totally different ordering.
Another problem (which is the one I am tackling first, as I've seen it is already quite effective at reducing sprite flicker) is sprite count.
To reduce VRAM space usage for sprites, they heavily reuse the same tiles (particularly for explosions -- which is the reason why they are ugly).
This has obviously the downside that for a single explosion you need to draw a lot of individual sprites, where you could have used one or two.
This has multiplicative effect where multiple instances of that explosion appear on-screen.
These all are very useful suggestions.Quote:
- Bosses should be using a scroll layer to most of their bodies instead of just sprites. It's plain stupid how they used the hardware in the boss fights.
This one is aggravating: https://youtu.be/TQoYVNZGFi8?t=963
This is what Darius (2019) on the Mega Drive does to have those massive bosses with minimal flickering: use as much background layer and tile animation as possible instead of sprites.
There's also Final Blow which uses tile animation to render the referee (Samurai Shodown also uses that but for comparison here I think Final Blow is actually a better example). Depending on the background you have in the scene, that kind of technique can be useful.
- The explosion effects overdraw a lot of sprites and make them permanent over the scanlines. That's also stupid.
Non-gameplay elements like that could be flickered at 30 fps, so if you have 6 explosion sprites you'd show only 3 for each frame; one group for even ticks and other group for odd ticks.
Another technique is to move the explosion sprites away from the originating y coordinate as the time passes, so you avoid crowding the same scanline. Have a look on what Bio-Hazard Battle does on the Mega Drive. There's probably no better example of sprite flickering mitigation techniques on the MD than what that game does.
- In terms of VRAM space optimization on the Mega Drive, the best examples you can find are probably Darius (2019) (the ROM can be found easily on the Internet) and Joe & Mac. You can probably draw some additional tricks and ideas from analyzing those games.
- A sort of "last resort" technique would be sprite-multiplexing as Stone Protectors does for the snow effect. It fills the screen using like 2 hardware sprites. Not useful in all cases and requires midframe trickery but you could probably use that for the static labels on the HUD. Stuff which is not in the same scanline should be less difficult to use with that.
Plenty of new stuff to look into! :)
Time to re-draw some sprites, fitting color schemes to the palettes I've come up with.
To the left you have the original MD game art, to the right a simple recoloring of the originals with new palettes (top sprite from each pair) and a recoloring+tweaking of the arcade assets (bottom sprite of each pair).
https://i.imgur.com/ZUiXbe4.png
Here you have the arcade sprites for reference:
https://i.imgur.com/WNsqFl1.png
Amazing artist, great choices.Quote:
Originally Posted by aMaru
Thanks.
Wonderful work!
However, we can assume the ROM will be a 32 Mbit one, that is not a problem today
More sprites redrawing/recoloring.
To the left is the original MD game art (top) and the redrawn/recolored MD art (bottom).
To the right the arcade game art
https://i.imgur.com/Ve8FHXc.png
Doing the best I can to be as faithful to the original as possible with the palettes I ended up with.
The Pig Man is one notable case where the MD sprites have been scaled down in size to reduce the number of tiles used.
I have converted and recolored the original assets.
https://i.imgur.com/AE2Uurg.png
I hope I'll manage to restore the larger original sprites.
The only way I can do that is by overwriting the tileset used for the tornado weasel sprite as soon as we leave the part of the stage where they appear (and copying that tileset back in if we move back to that part).
I'll try that at some point.
Keep in mind that the Arcade has a different aspect ratio, so doing a 1:1 conversion would result on fat sprites.
Doing the conversion to MD screen ratio, and saving tiles at the same time, would be a good thing, I guess.
You are doing an excellent job here. Amazing to see this conversion without ROM limitations, even when the original game engine is not the best to start with.
aMaru, incredible work!!!!
Keep going, looks terrific!!!