A new and improved Donkey Kong port

Put this video up yesterday, and completely forgot about sharing it here.

It's a little hobby thing I've been working on recently. Not too creative, since I've just been translating an existing game to the NES, but I started this after a drunken conversation with my friend about how much the original NES version of Donkey Kong sucks, and whether it would be possible to actually run an accurate version of the game on the NES hardware, playing exactly like the arcade original.
My claim was of course, that if you rotate the monitor like a lot of shmup ports tend to do, you could replicate the gameplay with 100% accuracy, but it would be a ton of work and there's no way I'd ever want to bother with it.

...Less than a month later I have a fully working release as shown here >_>


https://www.youtube.com/watch?v=dhRoe44Dg54

Not sure if it's "safe" for me to share the ROM file, since it's messing with Nintendo's property, but I just wanted to share the result with you guys.

That's pretty cool!

For one thing, portrait/upright screens means quite a big change to how the 8 sprites per scanline rule works in practice, and the looks would be different of any game due to the pixel assymetry being the other way around.

One word of warning, though - screens may overheat if they don't have venting holes facing up. For a permanent installation, i'd drill some holes or make a new chassi.

CRTs usually have venting in the back, so that's rarely an issue. In this case, all I was blocking off was a speaker.
If you're into shooters, rotating your screen like this isn't a foreign concept, commonly referred to as "tate mode" (I'm actually surprised I haven't seen any other NES or SNES homebrews with a tate mode), but it's a good idea to unplug it for 10-15 minutes before turning it on, just to avoid the magnetism causing weird colors. I've done it a billion times in the past with the same TV.

The original DK arcade game was created for this orientation, with roughly the same resolution (as you can see the graphics go all the way to the sides of the screen - arcade games didn't have to think about overscan), which is why this version looks like it should, while Nintendo's original NES/Famicom port looks horribly stretched.
You're obviously right about the sprites per scanline limit, which was actually my biggest issue, since the game likes to have stuff above eachother, such as the rivet screen where Pauline is right above Donkey Kong, and a hammer spawns below him. There can easily be a few firefoxes and a Mario down there, too, turning the game into flicker central I don't think it looks that bad on a CRT though, and if you've played stuff like Batman Return of the Joker, you're used to it
On the elevator screen I had to turn to some pretty creative solutions to avoid the flickering being too bad on the left column of elevators though.

Firefox is flicker central when Discordapp.com makes changes to its web app and doesn't test them thoroughly in anything but Google Chrome. (Source: reddit)

Where did you get that name for the fireball enemies in 100m? As far as I can tell from MarioWiki, only Atari came up with that name. The different-looking fires in 25m seem to be called Trouble Bugs.

"Firefox" is the common word used by most Donkey Kong players. Probably taken from the atari version, I guess?
"Pie factory" obviously isn't the official name for the screen with the cement trays either, but it's what everyone calls it.

They are technically exactly the same as the flame enemies on the other stages, just with a different sprite.
EDIT: Oh yeah, the game also sets the hitbox a pixel larger when initializing the stage, making them harder to jump over, I guess? The other thing mentioned on the page you're linking to is dead wrong, though. They never multiply, they just spawn on a random platform opposite to the one Mario is standing on. The common strategy is to save the bottom hammer until you're done with the left side, so that any enemies you kill while going right will respawn on ther other side where they can't get to you.

I didn't react to "firefox" because it has a very familiar ring to it, idk from exactly where but it's definitely mario universe. Something from the childhood.

So for the NES shmup I've been trying to design calls for a 3:4 ratio in vertical orientation (Mainly for gameplay structural reasons). I've considered tate mode as the scanline limit would nicely align with the bullet stream, but I worry that there would be no motivation for the common person to physically rotate their TV set. It's barely possible with emulators by having the OS rotate the entire screen.
I'm currently considering pillarboxing the already low resolution of the NES, That would somewhat help with the bandwidth of the background animations.

I guess you could hook up an NES to a flat screen and orient it however you like if placed on a table.

One of the most interesting screen configurations i've ever seen was at the soviet arcade museum filial in st:petersburg. It was mounted flat down like a board game, and a wheel and a foot pedal (and maybe a brakes pedal iirc... there was some means for braking anyway) was mounted in each corner on the broad sides. The wheels were stepless and infinite (i think they must've measured the delta-velocity).

It was basically a free-range obstacle course racer with a capture the flag element. The cars would wrap around the screen. 100% addictive with a full party of 4 players competing for the flags. (Hm... maybe i'll attempt a simple port-from-memory one far-away day when i have fewer project involvements...)

Holy cow, that's fast. I'm impressed. Well done, it looks really great.

The dreamcast version of Ikaruga had a menu option to play in tate mode or normal mode (pillarboxed)

Iterating on that idea, you could possibly design the game primarily for tate mode, but with a menu option that rotates just the controls and any text, so that the game can be played horizontally as well? That way you don't have to sacrifice your design goals, but you can still make it accessible for the common folk?

But does your port use more than 16KB of PRH-ROM ? Remember that for Nintendo it might have been unacceptably costly to use 32KB at the time.

Also you couldn't expect people to rotate their TV by 90° at home, obviously ^^

I seemed to recall that the original had 4 levels and the NES port only 3 levels (which is way worse than graphics resolution changing as a change), however I only see 3 levels in your youtube video.

This is awesome, Sumez!



The pie factory is in there. Skip to ~8mins. It doesn't appear in the first few loops, but that's how it was in the arcade too.

Having a completely developed game working already helped immensely.
The bulk of the work was just translating Z80 instructions over to 6502. Pretty boring work, but I enjoyed seeing the entire insides of the original game as I did it, and some times I had to get a bit creative with the 6502's advantages (X/Y indexing mostly) over the features it lacks (16 bit registers). But the most original work came from dealing with the hardware limitations of the NES, and balancing compromises against what I felt was essential to retaining a completely accurate arcade experience.


It's 32KB, though a large part of it is used by two samples, the DK grin and the boom sound, which I felt needed to be DPCM samples to respect the arcade version.
The idea was never to build a "better version" using the same hardware limitations, and I also ended up using ekstra work RAM from the cartridge, though this is mainly because of #1. I wanted the game to remember high scores, and #2. The arcade game does collision detection by reading from the "nametable" in video memory, something the NES obviously can't while drawing a screen, so I opted to use work ram to buffer the entire video memory of the arcade game. I could probably change a lot of things to work around it, but it was more important for me to have the game logic work as close to the original game as possible.

However, I'm pretty happy, and relieved, that I was able to fit the game's graphics (which has a lot more potential space in the arcade game) into a single 8KB CHR-ROM without using any bank switching. It's extremely tightly packed.



Exactly, rainwarrior The original stage sequence is "barrels"->"pies"->"elevators"->"rivet", but the US arcade release changed it around so the pie/cement factory and elevator stage were both skipped on the first level, and only added on the third and second levels respectively. As you'd get further into the game, barrel stages would also appear every second screen, as they are the hardest.
While working on the game, I got to try the level 1 versions of both the pie factory and elevator stage, and those are extremely easy compared to the other screens, so I can honestly understand why they changed it, even though the new stage order makes very little sense.
In general, the US final revision of the game is considered the true competitive version of the game, and with good reason.

Very cool!

I'd throw the ROM up somewhere. The worst thing that can happen is you might get a C&D (but even that seems unlikely).

The ROM is available here

When I make future changes (provided I dodge a C&D as I'm going) I'll update the file in that URL.

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.

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.

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. 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.

Very cool! Thanks for sharing this!

My approach was just to lie down on the couch.


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).

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).


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.

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).

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.


Absolutely and very intentional!


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.


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.

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 -
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?

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.


Yes.

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.

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.

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.

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).
$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)

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.

Haha, I always define labels for all control registers immediately and forget the original values.

Yes because Luigi wore red clothes during the time when the "Donkey Kong" games took place:

(Luigi is the left one.)


Great job, by the way. I would have never thought to see such an authentic arcade port on the NES.

This is a brilliant idea and I can't believe you made it all happen.

Yes and Trouble Bug is a funny name. Although in Japanse mushi, a word that are normally used for small animals like insects, worms, snails and sometimes spiders, actually refers to a person in this saying. Ojama is the bother part.

Haha I never thought that Luigi was in Donkey Kong Jr. I just thought it was some random colleague helping Mario and happened to look alike. So in that case player 2 in Donkey Kong could actually be Luigi and not some parallel universe created for the multiplayer purposes? They both can save Pauline separately but I think they could do that with Peach in several SMB games as well.

How do you know who are who?
Edit: OK I just checked the intro in mame and the right one ends up standing where Mario stands in when the game starts (unless they swap positions during the screen transition just to confuse everyone).

That was most definitely the case, but for retroactive story purposes, declaring him to be Luigi is probably the best thing.


Nope. Two player mode is still just two instances of the same story. Otherwise you also have to invent a second Donkey Kong Junior.
Also, the NES verson of the first game called the number of lives "M", for "Mario". It doesn't switch to "L" for the second player.

It could be that the other Mario look-a-like turned into Luigi in Mario Bros when they needed them to have unique sets of colours in order not to confuse players who are who. Luigi didn't even get his name until NOA came up with it for Mario Bros and Miyamoto heard of it and accepted it.

Yeah that doesn't really work with Donkey Kong Jr or Donkey Kong 3 (unless Stanley has a twin).

Ask and you shall receive:Not quite finished yet but it was simple enough to implement, though I don't expect to fix every little detail (e.g screenshots aren't going to be in the correct orientation because the rotation is done in hardware, etc.). Filters, scaling and aspect ratio options work correctly, which seems good enough for this.

Awesome job, Sour!
How's the input lag in Mesen?

Usually I'd recommend Nestopia to people, as it's the most lag-free NES emulator I've tried, and with the level some people are playing Donkey Kong, even the tiniest bit counts. Would be cool to recommend one that actually supports the orientation.

Retroarch has a rotation option (in the Video menu, but only if you enable advanced options in the User Interface menu), and it has a Nestopia core.

I couldn't really tell you - I never tried to measure it, and I don't tend to notice these kind of things too much. I've seen people on random forums say that Nestopia & Mesen both have low input lag (compared to some other emulators), but that's about all I can say.

Unless you enable vsync. Then the lag is really noticeable. I know that because I noticed the lag before I even knew that something like input lag exists.

This doesn't have anything to do with the emulator, though, but with Direct3D. I made extensive tests and found out that Direct3D with vsync has input lag where DirectDraw doesn't (or at least it's much less).

The way I checked this:
I mapped one of the buttons to Shift Lock.
Then I held a camera with a 60 fps recording function in front of the screen, so that it records the screen and the keyboard at once.
I press the Shift Lock key to make Mario in "Super Mario Bros." jump. Then I check the video.
Since pressing Shift Lock is mapped to an LED on the keyboard, I can count the number of frames from the LED lighting up to the moment Mario jumps on screen.
This way, I can measure the difference in input lag between different configurations. And Direct3D in fullscreen with vsync always loses against the other configurations.

How much is variable, but vsync is absolutely bound to cause input lag, no way around that. I would never enable it on an emulator designed to emulate a system that sends progressive signals to a CRT screen. I didn't even realise Nestopia had it.

In non-scrolling games, this is not so much a problem, but if you play "Super Mario Bros." without vsync, you always have a stripe moving from the top to the bottom when you move.
That's the reason why I never use emulators for actually really playing games, only for trying stuff out.

It's called "tearing".

For fun, I tried this (with a 30fps camera and an IPS monitor - so a terrible setup) and couldn't see any difference between FCEUX, puNES or Mesen (with or without vsync). Couldn't test on Nestopia since it doesn't let you map buttons to any of the caps/num/scroll lock keys. In almost all the jumps I recorded, there's a 3-frame delay between the caps lock LED & mario jumping on the monitor (so ~100ms delay since video is at 30fps). Not the most reliable results, but at the very least, it seems like all 3 emulators perform very similarly on my setup.

I finished up the rotate feature. In the end I did it in software, so it should work properly everywhere (screenshots, avi recording, etc).
If anyone feels like trying it, there's a Windows-only build here: download
The rotation option is in Options->Video->Advanced

At the very least, video output in Mesen occurs in a separate thread, so vsync might slightly delay the image being shown on the monitor, but it won't have any actual impact on the emulation itself.

The problematic issue comes when you use a Direct3D-based emulator in fullscreen. Windowed mode seems to be fine, but you don't really want that for serious play, would you?
And fceux is DirectDraw-based anyway. (And their vsync doesn't looks as clean as the Nestopia or MAME one.)
So, yeah, try out the fullscreen version with an emulator where you know it's Direct3D and see how it adds three additional frames of lag.

My test emulator was MAME. This one lets you switch between DirectDraw and Direct3D.

I'd rather want windowed mode than three extra frames of input lag for "serious play". Three frames is a LOT.


Don't take this personally, but 100ms input lag is beyond awful for playing any kind of action game. No one would accept it.

I think it's very likely that you have some sort of common source of lag in your setup that affects all three emulators though, most likely the monitor.

The game looks great. I hope that soon there is some emulator that allows to modify the screen orientation to play games like this.

EDIT: I just saw that "Sour" has already done something with the source code of the MESEN emulator.

Well, the obvious solution is: Play the game on the console.


But I don't think there's anything that he can do. It's the same number of frames on MAME: Mario jumps after three frames with the most basic configuration.

MAME is famous for adding a lot of lag, too. Try out the shmupmame build, it's one of the more popular low-lag builds of the emulator, and it's not only for shmups.
I tried playing Rainbow Islands on MAME once, and being a huge fan of that game, having played it for countless hours on arcade as I own the PCB, the input lag completely ruined my chances of playing the game well. You probably won't notice it if you aren't as familiar with the game - it isn't obvious, but there's a clear effect of "for some reason I just don't play as well as I should". On shmupmame, my play was almost as good as on arcade.


Absolutely, and preferably on a CRT. I'm a bit of a hardware purist myself, and only use emulators for development purposes

I don't know in how far that is true, but if "Super Mario Bros." has three frames of lag in any NES emulator and also three frames of lag in MAME, then the problem probably doesn't originate with MAME itself.


Fortunately, I don't have to deal with that anymore. The only arcade game that really interests me is "Street Fighter II" and I circumvented this by finally buying a good old Super Nintendo.


Exactly. But an NTSC TV and console. Not PAL.


And for making screenshots or recording videos for YouTube etc. Anything but the actual "Let's sit down and play a round of "Mega Man"."

Like I said, it's a 30fps camera + a non-gaming oriented 2k monitor - I don't expect it to have low input lag in general.
To be perfectly honest though, I've been playing games on this kind of setup for years, and it doesn't bother me in the slightest.

A ~100ms measurement in this case is not as bad as you might think. Mario itself has a full frame of delay before jumping - depending on the timing of the button press, it can be up to almost 2 full frames, so 32ms. Then you have to keep in mind the camera is 30fps, which can easily add another 15+ms of delay. So you can already trim off 30-45ms, which leaves you with ~60ms of lag more than what you might have gotten on a CRT TV in 1985.

Yup, using exclusive fullscreen + vsync adds another 2 frames of delay on the video (so 3-4 real frames). Mind you, I don't get any screen tearing in windowed/fullscreen window modes, so I only ever use exclusive fullscreen when a game forces me to.

Funny thing is: DirectDraw does not do this.


Did you set the screen to 60 Hz? Because if it's at 75 Hz, you indeed don't see noticable tearing, but the scrolling isn't that smooth either.

Set the screen to 60 Hz and then run through the first level of "Super Mario Bros." without stopping, wautching the blocks on the ground and any objects that are not the blue background. There's really no screen tearing?

My monitor actually only supports 59 & 60hz. In windowed fullscreen, I see no tearing, whether vsync is on or off. In exclusive fullscreen, the tearing is very easy to notice with vsync off, and disappears with vsync on. I can only assume Windows is doing some sort of voodoo magic to prevent screen tearing in windowed mode.

Real hardware, aspect ratio and proper orientation : https://www.youtube.com/watch?v=4tUhcluHZfE

Heh the Trouble Bug is so easy to smack in the arcade version while I think I never hit him in the original NES version on the first stage. I have probably done it on the cement factory stage in the red Wii version though, don't remember exactly.


I remember I had tearing with my old computer in many emulators but on my newest I don't see any in Mesen even in full-screen mode and vsync off. No noticeable input lag either.

BTW I don't really get the point of vsync. It's to avoid tearing which happens because unfinished frames are displayed. Isn't that why you use a constant framerate? With a constant framerate the game is consistent on all systems that are up to spec, while with vsync all computers run it at different rates and it isn't consistent at all.

Might depend on the graphics card.


I'd really like to know how long it takes from pressing the button on a real NES controller to Mario jumping. Maybe the number of frames that it takes is equal to the number of frames in an emulator (without vsync).


Yes.


But even if the framerate is constant, you still might have the problem: If the emulator starts rendering the new frame while the physical screen is in the middle of updating, you get tearing.


True, but scrolling either stutters or you get tearing.


That's why you need to set your monitor to 60 hz.

However, vsync doesn't have to mean that the game runs faster with a higher monitor hz value. Vsync just means that the game display will only update the image during vertical blank.
So, if your monitor runs at 75 hz, the game will still run at 60 fps and without tearing, but the scrolling will stutter since sometimes frames are updated twice and sometimes they're only updated once.

(In MAME you can actually choose whether the speed should adjust to the monitor frame rate or whether you still want to keep the original speed even if you force the game to update only during vertical blank although the monitor has another hertz value.)

Since Aero was introduced (i.e. Windows Vista) the Windows UI manager has had the ability to vsync the display of composited windows for you. In this mode there's no way for the application to control whether or not vsync applies. As always with Windows, if the application is not in true exclusive fullscreen mode any use of a vsync API is a placebo. (This includes the popular "borderless window that covers the whole screen" alternative to true fullscreen.)

If you've ever seen "do you want to change the color scheme to improve performance" pop up, that fallback mode lacks a global vsync, and you can see tearing there, if you like.

As for whether Direct3D adds 3 frames of lag, I mean, it's quite possible that it does on DRW's system right now, but it doesn't have to and it's not designed to (I've measured very good latency with it in the past), but there's a bunch of links in the chain between application and display (keyboard > keyboard drivers > windows > application > windows > GPU drivers > GPU > monitor) and any of these could be configured in a way that adds unnecessary lag. Most of these aren't directly under the control of the application at all.

If the situation on your system is that true fullscreen performs more poorly than Aero's globally vsynced windows compositing, something is sadly out of order. The whole point of fullscreen is to allow the application direct and low latency control of the screen. Most likely I'd suspect the GPU driver here, but like I said there's a lot of links in this chain.

We have had a discussion very close to this a few times before, here's one I remember:
https://forums.nesdev.com/viewtopic.php?f=5&t=14743 "Please explain to a layman: input lag"

Yeah, dialing the conversation back a bit, I was exclusively talking about lag introduced in one emulator compared to another.

I never did anything to measure each emulator's amount of lag, and I have no idea how much lag is implicit in my system, which is a cheap work laptop. But what I can tell is that no matter what video settings I've tried, I haven't been able to play games in FCEUX without enough lag that it influences my performance, and quick experiments with a bunch of other emulators showed similar results until I tried Nestopia which actually surprised me by being the best out of the the ones I tried, and playing Ninja Gaiden felt completely like playing it on a real console/CRT setup (even though in reality there's probably at least one extra frame of lag, if only due to the LCD display).
As such, it's hard for me to recommend playing this DK port in anything else. I don't know what emulator Wes Copeland (the current world record holder in Donkey Kong) is playing here, but he's constantly complaining about the input lag. At least he's well aware that it's caused by the emulator:

https://go.twitch.tv/videos/188731450?t=2h38m

When you're playing Donkey Kong on this level, one extra frame of input lag does make a difference.

I tried it out on several systems and I had people in the MAME community do the same.
Believe me: The three additional frames in Direct3D fullscreen with vsync is definitely a constant value compared to all other configurations.
(DirectDraw with fullscreen and vsync doesn't have it. Direct3D in windows mode with vsync doesn't have it either. And non-vsync doesn't have it anyway.)
Or don't believe me. Try it out. I described a simple method of validating it above.

According to a few minutes before the time you linked, Mednafen.

I've never said that I don't believe that you've experienced this lag. I've never said that.

What I said was Direct3D as an interface is capable of low-latency behaviour. On this, you don't seem to believe me. D3D is designed to be able to do this, and it very much can, and yes I've measured it on many occasions past and present.

If you're talking specifically about MAME's particular Direct3D code, that's very different than talking about Direct3D overall. I have measured many programs, but never specifically MAME. Tried a quick measurement of MAME right now, and yes for me it does have a few extra frames of latency when "video = ddraw" vs "video = d3d". This is not the same as Direct3D vs DirectDraw though. Clearly MAME is also doing a lot of stuff in D3D mode that it isn't in DDRAW, and there are like 30 more options that are specific to D3D in the ini file. I'm not about to dive into MAME's source code, or try a billion permutations of ini settings in order to have an argument about what MAME is doing wrong with its Direct3D implementation, though.


Anyhow, sorry, I didn't want to increase the off topic discussion here. Obviously you can't do better than a CRT + hardware that's directly synched with it. I just wanted to respond to the statment that D3D adds "3 frames of lag", which is just not true as a statement by itself. It does seem to be true that MAME's D3D mode adds 3 frames of lag. I'd gladly agree to that.

And I didn't claim that you said it. I just wanted to encourage you to try it out yourself and don't take my word for it.

All in all, I don't know whether it's Direct3D itself or the emulator or whatever. I just noticed that the same issue happens in MAME and in Nestopia and they're both based on Direct3D while I never saw anything like that in fceux (DirectDraw) or the DirectDraw mode of MAME. So, I assumed it's Direct3D itself.

But ultimately, I don't really care. I have my NES, my Super Nintendo and a CRT TV. Input lags of emulators don't concern me anymore.

Which are all bound to fail some time in the next, hum, 20 years? I do think now is the time to think about alternative ways to keep playing and developing the games we like, because all this 30 year-old tech isn't gonna last much longer.

Oh, yes, all the mechanical parts in my SNES are really starting to show signs of fatigue. This stuff isn't going to last forever (neither are we until the government ever pours money into research about stoping aging, "wink wink") but can we really give any sort of meaningful estimate? Most of the time people complain that their old electronic device has stopped working, it's just that the capacitors have gone bad, which is relatively easy to fix.

A few months ago I had a bunch of friends over to play Street Fighter 2 on my SNES. Halfway through a match, there was a POP sound, and the SNES was dead. Such a sad day.

(I really need to open it up and look for any obviously blown caps, but haven't gotten around to it yet)

To be honnest, I expect my NES and SNES to still have a much longer lifespan starting today than any iPhoneX just being released ^^

Or any current video game console, for that matter... Things really aren't built to last, and no game company wants you to hold on to old consoles and games instead of continuously buying consoles, collections, remakes, or their own emulated versions of games you used to own.

Crap, I just noticed this discussion is taking place in the Donkey Kong thread! I'm really sorry for continuing the off-topic talk in the thread of such a cool project!

It's cool

The Analogue Nt Mini's 16 sprites per line option removes virtually all flicker in the barrels and rivets stages. The irony is that the game does not work with its built-in flash cart feature (due to the Mapper 0 8KB of SRAM most likely, 4KB was the maximum used by a licensed cart (Family BASIC v3.0) without other memory controller hardware). Fortunately an EverDrive N8 or NES PowerPak solves that issue.

That's a good thing to know! I'm not even using anything close to 8KB. Haven't seen any emulators giving problems with it.

Next version will probably have some sort of actual mapper though, as any major addition will require more CHR ROM.

I got it to work in the Nt Mini by changing the mapper to 1 and copying the CHR-ROM three times over. It is good enough to work with the Nt Mini! I would suggest that if you decide to add more CHR-ROM, you should use a mapper that ordinarily supports save RAM like 1 or 4.

Sumez, thank you very much for this great port. It must have been a lot of work.

I just got it to work on my Analogue Nt mini with the instructions provided by Great Hierophant and I'm really looking forward to your next version of the arcade conversion.

As already mentioned, it would be nice if the sounds could be made even more Arcade accurate. Furthermore, the flickering could be reduced by using tiles whenever possible instead of sprites.

Maybe you would also be interested in porting the inofficial sequel, Donkey Kong II: Jumpman Returns, which is based on the same hardware as Donkey Kong. The Arcade rom is included in the MAME romset (dkongx.zip).

We have a few things we want to fix, but I'm not too focused on the project right now. Everyone who's been playing it has been praising how close it plays to the original, so surprisingly there's not really anything I'd classify as a bug left in the code.
However, the two most important aspects to fix right now is #1: The hammer music resetting every time the smash effect plays, doesn't sound too important, but it can affect people's intuitive idea of when the hammer is about to end, and #2: The point display appearing when jumping over or next to an enemy is slightly misaligned. Both of these issues confused Wes Copeland, the current world record holder of the arcade game. They were the only "major" issues he had, so gameplay wise I feel those are the only things that need to be fixed.

Conversely, no one has had a problem with the flickering. It's definitely not a high priority for me to "fix" it, and I have gone into details explaining why earlier in the thread. Or maybe it was in this thead. Anyway the gist of it is that there are very few sprites left that can still potentially be translated into background tiles. The only thing that could truly help the sprite count is Donkey Kong himself, and turning him into background tiles will cause a lot of additional issues, since he's not aligned to the background grid, and is aligned differently between the barrel/elevator stages and the rivet stage. And on the pie factory stage (probably the most flicker heavy) it wouldn't even be possible.
Furthermore it would require CHR bank switching (or CHR RAM - and probably PRG bank switching too, since I'm approaching the size limit as it is, due to the sounds and DPCM samples) and require me to move around almost every graphic in the game to make room for multiple versions of Kong. Not a problem as such, but the game would require mapper chips which is an issue for people wanting to build carts with it. If you're playing the game on a CRT screen the flickering honestly isn't jarring.

Anyway, thanks for the feedback and the support. I'm glad you're interested in the port.

If you use a common NES mapper board, such as MMC1, UNROM, CNROM, GNROM or MMC3, you can easily find donor boards or reproduction boards that support these mapping schemes. You can get 64KB with CNROM (easily expandable to 160KB), 128KB with UNROM (easily expandable to 512KB), 160KB with GNROM, 384KB with MMC1 and 768KB with MMC3. Lots of people, myself included, use flashcarts, so that issue is irrelevant for us.

Yeah I know my own dev cart is MMC3 (tkrom) too so I actually made an MMC3 version of the rom... Just with a bunch of blank banks

Using a "tate mode" can also work for a NES port of Pac-Man with a pixel-perfect single screen maze. The other objects would need to be rearranged, but there are just enough pixels within the frame to do it :

https://photos.app.goo.gl/dZWrJq5t1bPclUq82

Just in case anyone else gets inspired to code such a thing

I thought you might appreciate knowing that someone else loaded the game up on an Everdrive and flipped their CRT on its side!

The TV is some mediocre Sanyo, nothing special, just something I got from a friend that's been sitting on my floor doing nothing, so I figured why not give it a try? Donkey Kong isn't my favorite game, but I played for a little while and it controlled nicely. I spent more time playing and got farther in the game than I ever have before. This was a very cool little project and I hope we see some more NES games made this way.

I think pretty much any CRT is gonna cut off some of the top and bottom of the image, though, unless you adjust overscan in the service menu. Would you find it too unfaithful to the arcade original to scoot the score display down and/or shift everything else up? Looks like there are nine blank pixels between the score and the level indicator. My TV is cutting off 2-3 pixels that show content and aren't just black from the top and 3-7 pixels on the bottom, depending on curvature. If, say, the top were shifted down four pixels and everything else were moved five pixels up, that would make more visible to more people at the cost of an almost unnoticeable-unless-you're-specifically-looking-for-it loss of faithfulness to the spacing of the HUD elements.

But maybe it's not worth bothering or losing that accuracy for the tiny number of people who will ever actually see this played on a CRT TV. Either way, congratulations on this project and thanks for your high quality work!

This rules.

This is impressive! Respect to you, Sumez for all your work on what i already consider one of the best looking donkey kong arcade "ports" available! I can confirm the rom supplied works on GBA hardware using a flashcart (M3 Perfect Lite) and the "pocketnes" nes emulator for GBA. My testing on the aforementioned hardware has led to an obvious hardware restriction which is when playing the rom on gba and turning the console on its side, it presents the issue of the d-pad not being mapped properly for the hardware. This has lit my fire so to speak on making an attempt to wrap my head around hex editing with no luck to this point on coming up with a fix (I have yet to find $4016,$4017 location in HxD so I haven't gone through the trail and error of modifying these locations.... im a hex newb). I then started to brainstorm on ideas that may further improve your homebrew, such as a possible settings menu giving the option of multiple screen rotation configurations with the buttons properly mapped and rotated according to the display option selected (possibly hidden, only accessible from title screen by multi button input, e.g. start+select simultaneously to keep genuine to the "arcadesque" presentation of your homebrew). There could be 4 modes, including upside down for the option of playing with your left or right hand controlling the d-pad/a&b buttons on a GBA. This would also give those playing on real nes hardware the option of which vertical direction they can chose to turn there display. Another nice touch to the idea would be the last configuration selected could possibly be saved in sram, which would help those who may like to have a dedicated hardware setup to your homebrew. I am a novice at best in regards to this stuff, so im not sure what your restrictions would be in implementation of any of these features. If proper "gba support" is far from the top list of project priorities, it would be completely understood as this is a NES project and i'd imagine im on the very short list of those trying to play this on the GBA, although the more versatile your project, the more eyes and hands will see and play it. Suggestions aside, Thanks for all your work on this, cool stuff indeed!

Thanks a lot

Adding an options screen would probably be a bit annoying, as the code is very closely based on the original arcade Z80 structure (with whatever overhead that might result in) - I did do something similar when testing the game, on the "push only 1player button" screen, where I replaced the text with two options (starting level and starting screen/board index) that could be changed by pressing up/down or left/right, coincidentally saved in the saveram similar to what you suggest.
As it is, it's a little hard to add any more code to the game without moving into bank switching, as I used as much space I could for the sound data - the PRG rom is completely packed

If you want to remap what buttons are checked for left, right, up and down in the game, I think it would be easier to just identify the areas where these directions are checked, as opposed to the controller reading routing - however it's worth noting that in Donkey Kong left/right isn't just used for controlling Mario, but the barrel AI and the jump detection (when jumping "over" an item) also check for the direction pushed.

Great work!
I also want you to make me the original version of Japan! (The construction of the stage is different from an American edition.)

Donkey Kong JR also wants you to make me!