While it is a risk to the popularity of a release, the emergence of a few tate mode nes titles might encourage emulator maintainers to go in that direction.JRoach wrote:It's barely possible with emulators by having the OS rotate the entire screen.
A new and improved Donkey Kong port
Moderator: Moderators
- FrankenGraphics
- Formerly WheelInventor
- Posts: 2064
- Joined: Thu Apr 14, 2016 2:55 am
- Location: Gothenburg, Sweden
- Contact:
Re: A new and improved Donkey Kong port
Re: A new and improved Donkey Kong port
Yeah, you can't just wait for emulators to take the first step.
I was actually considering making a deciated thread for this subject a while ago, since it seems it hasn't really been discussed before.
I also considered making an original tate game for the SNES from the ground up for a while. If the game is good enough, people are gonna flip their monitors. They did it for Dodonpachi in 1997, and they did it for Ikaruga, and any other shooter port since. :3 Try releasing a vertical shoot'em up today, and you'll hear people whining if it doesn't have tate. Even if it's originally created for consoles.
I was actually considering making a deciated thread for this subject a while ago, since it seems it hasn't really been discussed before.
I also considered making an original tate game for the SNES from the ground up for a while. If the game is good enough, people are gonna flip their monitors. They did it for Dodonpachi in 1997, and they did it for Ikaruga, and any other shooter port since. :3 Try releasing a vertical shoot'em up today, and you'll hear people whining if it doesn't have tate. Even if it's originally created for consoles.
- rainwarrior
- Posts: 8731
- Joined: Sun Jan 22, 2012 12:03 pm
- Location: Canada
- Contact:
Re: A new and improved Donkey Kong port
Two very nitpicky suggestions:
1. Writing the palette displays colour immediately on the screen even when rendering is off. During transitions you appear to have one frame of "rainbow" lines in the middle of the screen because of this. (Avoidable by only writing to the palette during vblank.)
2. It seems like the flickering has exactly 2 orderings (looks like you're drawing the sprites in reverse every second frame? except for the oilcan?). The appearance might be improved by having more orderings than that so it isn't in locked 30hz patterns where the same pixels are always dropping. It's good for sources like YouTube that often display at 30fps, but can also help with visual coherence if there's more rotation to break up the effect.
1. Writing the palette displays colour immediately on the screen even when rendering is off. During transitions you appear to have one frame of "rainbow" lines in the middle of the screen because of this. (Avoidable by only writing to the palette during vblank.)
2. It seems like the flickering has exactly 2 orderings (looks like you're drawing the sprites in reverse every second frame? except for the oilcan?). The appearance might be improved by having more orderings than that so it isn't in locked 30hz patterns where the same pixels are always dropping. It's good for sources like YouTube that often display at 30fps, but can also help with visual coherence if there's more rotation to break up the effect.
Re: A new and improved Donkey Kong port
1. Didn't even think about that. That's a stupid mistake, thanks for pointing it out. A lot of screen updates are blended into the "original" code as it is, so when I eventually "cleaned up" screen transitions it was kind of a hack job.
2. Yeah, I noticed that immediately after watching a guy streaming it on Twitch yesterday, and people watching thought the sprite flickering was much worse than it actually is. Kinda annoying that you have think about those kinds of things...
The sprite handling already causes quite a performance overhead, since I'm keeping the game's original sprite buffer and converting them all to 16x8 (8x16) NES counterparts. The oilcan isn't the only thing that's fixed either - Donkey Kong has to be drawn in a specific order, the barrel he's holding must always be in front of him, and a few sprites are used for masking, etc.
So it's already a relatively demanding routine, and I should probably be able to fit in a third kind of ordering into it without making it much heavier on the game.
2. Yeah, I noticed that immediately after watching a guy streaming it on Twitch yesterday, and people watching thought the sprite flickering was much worse than it actually is. Kinda annoying that you have think about those kinds of things...
The sprite handling already causes quite a performance overhead, since I'm keeping the game's original sprite buffer and converting them all to 16x8 (8x16) NES counterparts. The oilcan isn't the only thing that's fixed either - Donkey Kong has to be drawn in a specific order, the barrel he's holding must always be in front of him, and a few sprites are used for masking, etc.
So it's already a relatively demanding routine, and I should probably be able to fit in a third kind of ordering into it without making it much heavier on the game.
- *Spitfire_NES*
- Posts: 306
- Joined: Fri May 21, 2010 4:10 pm
Re: A new and improved Donkey Kong port
Very cool! Thanks for sharing this!
- rainwarrior
- Posts: 8731
- Joined: Sun Jan 22, 2012 12:03 pm
- Location: Canada
- Contact:
Re: Tate mode in NES
My approach was just to lie down on the couch.JRoatch wrote:It's barely possible with emulators by having the OS rotate the entire screen.
I think it's a pretty easy mistake to make. I've certainly shipped a ROM that does this before. A lot of emulators don't even show the immediate palette colour anyway (e.g. FCEUX default old PPU).Sumez wrote:That's a stupid mistake
Re: A new and improved Donkey Kong port
This is amazing Sumez! So you coded it from scratch it seems. I never was a fan of the messed up level order in American Donkey Kong machines though, kind of wished there was an original version as well.
Audio sounds fine, didn't hear it in the video but it's there, nice.
Start button only used for starting the game, no pausing! Real arcade game heh.
Saving high scores could be considered an upgrade from the arcade version, but on the other hand arcade machines weren't supposed to be turned off so I guess it can also be seen as a way to replicate the arcade experience in a NES. If you haven't already, you might want to include a way to delete the save data so that people don't have to take out the battery.
A few other suggestions:
Only one player?
It seems like you are ignoring the Famicom expansion port bits (bit 1 of $4016 and $4017) so I can't play this game with my arcade controllers (I only tested this in Mesen so far though, and Famicom multitaps doesn't work). I suggest to read $4016.1 and $4017.1 as well and merge them with player 1 and 2 button data respectively, so that external controllers works as player 1 and 2 as well (NES Donkey Kong is doing this).
It always annoyed me that the ghost enemy in the final level doesn't have a name, or at least they are never referred to separately from what I remember. But if their behaviour is really identical to the trouble bugs I guess they are the same guys just in a different shape.
Audio sounds fine, didn't hear it in the video but it's there, nice.
Start button only used for starting the game, no pausing! Real arcade game heh.
Saving high scores could be considered an upgrade from the arcade version, but on the other hand arcade machines weren't supposed to be turned off so I guess it can also be seen as a way to replicate the arcade experience in a NES. If you haven't already, you might want to include a way to delete the save data so that people don't have to take out the battery.
A few other suggestions:
Only one player?
It seems like you are ignoring the Famicom expansion port bits (bit 1 of $4016 and $4017) so I can't play this game with my arcade controllers (I only tested this in Mesen so far though, and Famicom multitaps doesn't work). I suggest to read $4016.1 and $4017.1 as well and merge them with player 1 and 2 button data respectively, so that external controllers works as player 1 and 2 as well (NES Donkey Kong is doing this).
Trouble Bug? That's a funny translation of the original Japanese name ojamamushi (ojama = hinderance, mushi = bug), but I like it. I think ojamamushi is a word used for people that gets in the way all the time, in English you might say "third wheel" I guess. It has nothing to do with bugs though, it's just common pattern in Japanese for sayings like this. For example crybaby is nakimushi (naki = crying). In the Swedish NES Donkey Kong manual (most likely translated from the English one) I think they where simply called fireballs.
It always annoyed me that the ghost enemy in the final level doesn't have a name, or at least they are never referred to separately from what I remember. But if their behaviour is really identical to the trouble bugs I guess they are the same guys just in a different shape.
- FrankenGraphics
- Formerly WheelInventor
- Posts: 2064
- Joined: Thu Apr 14, 2016 2:55 am
- Location: Gothenburg, Sweden
- Contact:
Re: A new and improved Donkey Kong port
incidentally, bug could mean that in english too, Bug = bother, not only as a verb but also a noun. You have it in bogeyman, hobgoblin (letter reversion), and the modern-time invented D&D monster Bugbear. Compare to low-german bögge (equivalent to hobgoblin/goblin).
Re: A new and improved Donkey Kong port
It would be very easy to allow for both level progressions, as well as various other modes or settings (such as a dedicated 1-1 challenge mode, a caravan mode, etc.) - First of all I just wanted a complete replication of the US arcade version. But I don't think I'm at version 1.0 just yet.Pokun wrote:I never was a fan of the messed up level order in American Donkey Kong machines though, kind of wished there was an original version as well.
Absolutely and very intentional!Start button only used for starting the game, no pausing! Real arcade game heh.
That's a good idea. Having to reset the scores on my dev cart was actually a bit of a bother, so might as well make that a feature available to anyone.If you haven't already, you might want to include a way to delete the save data so that people don't have to take out the battery.
Most of the code handling two players is already there, so it would be a simple addition. Once again though, I settled on just "releasing" the current state as it is. Another thing I didn't include was inserting (fake) credits. I'm not sure if anyone would ever care if that was there, so it's likely I won't add that at all. More likely, I'll just replace the "push only 1player button" with an options screen. I already had one for testing which allowed selecting the starting level and screen index.Only one player?
I also considered adding a green "luigi" palette for the second player... would that be sacrilege?
Guilty as charged. I do have a Famicom, but I don't have any valid expansion controllers for it, (or a famicom compatible dev cart -It seems like you are ignoring the Famicom expansion port bits (bit 1 of $4016 and $4017) so I can't play this game with my arcade controllers (I only tested this in Mesen so far though, and Famicom multitaps doesn't work). I suggest to read $4016.1 and $4017.1 as well and merge them with player 1 and 2 button data respectively, so that external controllers works as player 1 and 2 as well (NES Donkey Kong is doing this).
my only adapter goes the other way around) so I wouldn't be able to test it out either. But I guess emulators could help me test.
Do the $4016 and $4017 registers interfer with the DPCM channel, same as reading from the normal P1 and P2 controllers?
Re: A new and improved Donkey Kong port
If you subscribe to the Game Theorists's "two Marios" theory, then there's no green plumber at all in the time of Donkey Kong. It takes place prior to Yoshi's Island, meaning the Mario Bros. as we know them (Mario Mario Jr. and Luigi Mario) haven't been born yet.Sumez wrote:I also considered adding a green "luigi" palette for the second player... would that be sacrilege?
Yes.Do the $4016 and $4017 registers interfer with the DPCM channel, same as reading from the normal P1 and P2 controllers?
If you want to go the easy way, the controller routine I've been using since Concentration Room correctly handles both DPCM glitches and combining Famicom controllers 1 and 3.
Re: A new and improved Donkey Kong port
I guess you could have a special menu screen that has all these extra options like clearing the high score, or selecting regional version. Either accessed by a special button combination or a menu that simply runs before the "arcade game" starts like in the VS Super Mario Bros hack for NES.
$4016 and $4017 are the same registers used for reading the internal controllers, only bit 1 instead of bit 0 is used for external controllers ($4016.1 is "controller III" and $4017.1 is "controller IV") so yes I assume you need to consider DPCM bug for these as well. Commercial games that use DPCM seems to do this as well. The way I do it is just read $4016.0 and $4017.0 until two reads match and then I read $4016.1 and $4017.1 until two reads match but save them into separate variables, I then merge the variables using ORA so that controller III works like controller I and controller IV is same as controller II . There are more effective ways of doing it (check the wiki), but it works on real Famicoms and some commercial games does it this way too. Also I can confirm that Tepples' Concentration Room controller routine works with my Famicom.
(Edit: Ninja'd by Tepples)
Considering you have been very carefully in replicating the original arcade game accurately, yes. But it could be a fun option to put in the previously mentioned special menu.I also considered adding a green "luigi" palette for the second player... would that be sacrilege?
Yes emulators that supports Famicom multitaps should be able to help you test it, even though you would want to test it on a real Famicom as well in the end (I will probably not be able to help you testing it for a very long time after I have moved, I don't plan to bring my Famicom to Japan).I do have a Famicom, but I don't have any valid expansion controllers for it, (or a famicom compatible dev cart -
my only adapter goes the other way around) so I wouldn't be able to test it out either. But I guess emulators could help me test.
Do the $4016 and $4017 registers interfer with the DPCM channel, same as reading from the normal P1 and P2 controllers?
$4016 and $4017 are the same registers used for reading the internal controllers, only bit 1 instead of bit 0 is used for external controllers ($4016.1 is "controller III" and $4017.1 is "controller IV") so yes I assume you need to consider DPCM bug for these as well. Commercial games that use DPCM seems to do this as well. The way I do it is just read $4016.0 and $4017.0 until two reads match and then I read $4016.1 and $4017.1 until two reads match but save them into separate variables, I then merge the variables using ORA so that controller III works like controller I and controller IV is same as controller II . There are more effective ways of doing it (check the wiki), but it works on real Famicoms and some commercial games does it this way too. Also I can confirm that Tepples' Concentration Room controller routine works with my Famicom.
(Edit: Ninja'd by Tepples)
- FrankenGraphics
- Formerly WheelInventor
- Posts: 2064
- Joined: Thu Apr 14, 2016 2:55 am
- Location: Gothenburg, Sweden
- Contact:
Re: A new and improved Donkey Kong port
I don't think they mentioned it in that game theory episode, but it would explain why Mario the 1st has a bald spot, and Mario II Mario has not.
Re: A new and improved Donkey Kong port
Haha, I always define labels for all control registers immediately and forget the original values.Pokun wrote: $4016 and $4017 are the same registers used for reading the internal controllers, only bit 1 instead of bit 0 is used for external controllers
Re: A new and improved Donkey Kong port
Yes because Luigi wore red clothes during the time when the "Donkey Kong" games took place: (Luigi is the left one.)Sumez wrote:I also considered adding a green "luigi" palette for the second player... would that be sacrilege?
Great job, by the way. I would have never thought to see such an authentic arcade port on the NES.
My game "City Trouble":
Gameplay video: https://youtu.be/Eee0yurkIW4
Download (ROM, manual, artworks): http://www.denny-r-walter.de/city.html
Gameplay video: https://youtu.be/Eee0yurkIW4
Download (ROM, manual, artworks): http://www.denny-r-walter.de/city.html
Re: A new and improved Donkey Kong port
This is a brilliant idea and I can't believe you made it all happen.