I would like to ask, is there any game engine that can run good looking games at very old hardware? I mean PS2-3 era of hardware. The graphics capabilities don't have to be all modern, i just want to run half decent looking games on older hardware.

Also, i am not really a beginner as the channel may suggest. I just can't really fit this post into any other forum.

The question is hard to answer. It almost doesn't make sense, but in the spirit of the question, sure, you can absolutely do it.

Nothing about it will be easy. “Can I do it” is yes, but “should I do it” is a firm no unless you're really set on making niche products that only play on vintage equipment that very few people can help you with, and even fewer people will be willing.

First the timeline, you can pull old systems from anywhere in that 14 year timeframe. PS2 was about 2000 through 2006. PS3 was about 2006-2014.

Second, the tech wasn't widely available as third party engines at the beginning of that timeline. While they existed, engines as middleware didn't really become popular to the general population around 2006 or so. Before that, game engines were the domain and property of the largest companies.

Unreal Engine existed that entire time licensed to studios that entire time. Unreal Engine 3 was first publicly released in 2009, which is in that time window. Earlier than 2009 and you'll need to get other unofficial sources, but it is within your timeline.

Unity has been publicly available since about 2005, but it wasn't up to that quality able to handle the performance of games you are talking about until around 2008 or so. Even so, you can find it within your timeline.

Valve's Source Engine, originally GoldSrc because it was pulled from Half-Life's “gold” master existed as a licensed product the entire time, and was first publicly released in limited form around 2008, that fits within your timeframe.

GameMaker (now GameMaker:Studio) and RPG Maker both existed that entire time as engines and were publicly released the entire time.

Before the “engines as middleware” era games would pull together their own libraries and functionality.

Probably your biggest difficulty would be getting both the old hardware, software, and documentation.

Hardware would probably be from garage sale specials. Modern graphics and audio hardware run quite different from old hardware. While there are emulation layers for it, the hardware behaves differently in many subtle ways.

Software will be harder. Windows 2000 and XP are easy enough to find, as are old licenses to Visual Studio 5 and 6, or Borland's compilers that were just starting to wane in popularity. The old tools generally still exist, and for publicly released tools there are digital archives of source code, old copies can be found at SourceForge and the old surviving download sites.

And once you've got the old tools, you'll need documentation. You might find it. I know old copies of MSDN exist, although I tossed all my old MSDN Library CDs and DVDs decades ago. Asking questions about the long-dead systems would be limited to groups who are active in the vintage hobby development. Asking for help in general forums may range from hostility to exclusion unless you're clear up front why you're working on vintage, unsupported systems and with zero expectation of hand-holding. You can find plenty of old-timers who worked on the systems and can help answer how or why things were the way they were, but probably not much more than that.

Don't expect to mix old and new, though. The hardware is different, the software is different, even the programming languages are different. At the beginning of the timeline C++ was just barely standardized in very late 1998 and compilers at the beginning of your timeline didn't even have support for the then-new C++ standard. C-language compilers had the C99 standard, but C89 was the language standard mostly supported back then.

Even if you know what you're doing and are trying to mix old and new, it is quite difficult. For example, trying to use older fixed-function graphics systems with modern programmable pipelines usually doesn't work at all, or requires significant processing to try to emulate. As Microsoft's D3D pipeline became predominant on Windows during that time, the transition from D3D8 that was entirely fixed function, D3D9 that was a mix of FF and programmable pipeline, and D3D10 that was entirely PP, that's a transition many people found as an insurmountable barrier. It was generally easier to completely rewrite graphics systems. Audio also transformed, but as most people during the timeframe already relied on third-party libraries for audio the transition wasn't as severe, replacing one library with a rewritten library following the same external interface or an adapter interface.

On top of all the challenges around hardware, around software, and around documentation and a community to help you out, you have the difficulty of actually making your game.

Older versions of enginers are tuned for older hardware. Modern engines will not work well (or at all) on old hardware. The generic engines in the era of SM2.0 were pretty crappy in regards of capabilities/graphics quality and performance, so don't expect anything to suit your needs.

If you want to develop something for dx10/dx11//opengl2.1+ era (2006 and newer) hardware, thats still supported and works without the problem. In fact thats the main target platform of steam games (win7 era) till 2024 january, when they discontinue win7 support on steam, effectively paving the road for newer versions of windows and directx. Even if there are no teachnical reasons or any real benefits from doing so.

I worked with old school UE2 that ran on the kind of hardware you describe.

The guts were crammed with pretty old school OOP fatness that most would consider archaic and definitely not performance minded. Optimized isn't a word I would use for anything of it but a few specific bits of it. It's more content tailoring and just outright not being able to do this or that, that makes it work in that time period. Amusingly, lots of UE2 and UE3 bits live on in UE4/UE5 in some bastardized form or another.

You didn't have tall grass everywhere … because you simply couldn't. You didn't have post-process effects that weren't simply color filters … because you simply couldn't. You couldn't have some bonkers free destruction because you couldn't rebuild the static nav-tables, you could turn some nodes on/off, but that was about it. It goes on and on. UE2 you could have IIRC almost infinite terrain texture layers though … you would get absolutely wrecked for doing that though on contemporary hardware.

At this point, access to compilers that can target OS's that run on hardware that old is probably the more serious problem.