A project that has already been done as a learning thing is fine vs jumping in to something random and new.
Generally you will want to understand how the original code works, what it leans into and what it has underpinning it, as well as what language and whether a usable compiler is available for the target system.
You will probably also want to understand the strengths and weaknesses of the system you are going to.
For instance Quake was ported to the DS, fair enough but Quake uses a lot of floating point numbers in its calculations. The DS has no abilities in hardware to handle them at all (has some fixed point stuff but even that is minimal) which means you would need slow as sin software methods to handle them (think doing long division rather than using a calculator that does it for you and probably add a bit more effort on) or rewrite the code that uses them to use something like the fixed point it does handle, or something else in more general signed/unsigned that it handles quite well. Given what floating point excels at though (and you are making a 3d game where positions can be quite complicated, and represented exceedingly well by floating point) then that can be easier said than done. Even if your new system has floating point you then get to wonder a) what precision it has and b) what the performance of it is when handling such things.
More generally processor speeds, memory bandwidth, memory amount, graphics memory amount, bulk storage and characteristics thereof (CDs store a lot, take time to seek, ROM chips store less for the same price back in the day but take way less time to grab data, back in the day is not not flash cart today where an unthinkable 16 gigs for a game back in Doom era is pretty modest today and nothing for the average flash cart/modded system setup where storage can be multiple times that and still be vintage/lower end). The bigger the difference in power, the less you will have to redo code to make it fit and run in a timely manner.
If it is an older game like original Doom then it might also be coded in older styles*, in addition to games generally not being noted for their super tight code (game crashes, nobody cares, bug in radiation machine zaps people more than needed... bigger problem and thus code is built to handle it, even if it slows things down
https://hackaday.com/2015/10/26/killed-by-a-machine-the-therac-25/ ), or indeed sometimes actually some super tight code designed for the PC to keep things fast there. Fortunately other devs know this and often one of the first parts of a project is to bring the base code up to either more modern or better standards, or take things away from leaning into hardware to allow them to be ported around more easily to different hardware. This is also why above you were asked what you would be using as a base; some versions were aimed at keeping things lean, original, some improved things (and might since have become the base most know the game for)... and afraid I don't know what all of them are built for in that regard.
*even in the same language. If you are even pretty decent at K and R C or some of the oldest vintages of C then recruiters will probably beat a path to your door put a piece of paper in your hand "is that a phone number? No, that is your salary offer", know a modern flavour of C to similar standards and you will probably get something as it is still a valued skill but nothing like the former, in both senses of the term. Now Doom was a bit later, and while I don't know if it was built to be ported and it is generally held that engine sales were a bit of an unexpected revenue source then it never the less remains a fact it was so there is that too.
Anyway this sort of thought process, in addition to the usual
https://gbatemp.net/threads/can-i-aka-you-as-i-cant-wont-code-port-this-game-to-this-device.576997/ , is what most looking to port something will have going on in their head. Some might blaze a bit more of a trail; if something is doable but not done, or needs some additional effort in porting libraries or hammering out baseline understanding of hardware, then so it goes but also tends to be the better coders contemplating such a course of action.
@
Sicklyboy:
