Probably not really. Maybe some code, for some very basic systems that work perfectly fine, but likely not much. The same is true for UE, like the comment above says. There’s still some original UE code from the 90s in UE5 (and 6), and that’s totally ok. In fact, it’s smart. If it perfectly handles the job with no errors, changing it for the sake of change only creates opportunities to introduce new unknown bugs.
NetImense is late 80s but I digress. It’s the reason we are still stuck with framerate tied physics. (Shared rendering and physics per tic.). About 80% of it has been replaced with newer and better systems not counting the plugins and bolt-ons. But the bottom of the stack is still there supporting the rest of it.
It’s the reason we are still stuck with framerate tied physics.
No, it isn’t. There are plenty of engines that have had that issue and have fixed it over time. Bethesda could. The reason it still exists is because of either incompetence (which won’t be fixed by switching engines; if anything it’ll be worse for a while) or because it isn’t a priority.
I think you do not understand. All of Bethesdas games are frame rate physics locked because of netinense code that has never been replaced. It could be replaced yes but it has not been overhauled as it is a core system that many other systems are bolted onto
Netimense > Gamebryo > Geck > Creation kit same DNA .
There’s a reason all the 3d files are .nif Netimense Format
The point of this conversation is that they have upgraded the engine, as all engines are. It is not limited because it came from Netimerse. It’s limited because they haven’t fixed that issue. It can be fixed is the entire point of the discussion. They should not swap engines just because of the heritage, or all engines would have one version and then are abandoned.
It literally is limited because of the code from netimmense
Which was originally a MMO engine ties framerate to physics
They have updated the engine many times iirc. We are on creation kit 3 now so that’s about 8 major revisions since netinense
This is not an issue with the engine it’s an issue with the netimense code at the heart of the engine.
You have utterly confused me with your last bit, you do realize that the list I used were all engines bethasda has used all built upon the previous right.
literally is limited because of the code from netimmense Which was originally a MMO engine ties framerate to physics
It’s a problem that needs to be solved, but it isn’t a hard limitation. Limitation implies it’s something that can’t be changed. Also, it isn’t because it was an MMO engine. It was incredibly common at the time. It was simpler to have one thread that handles physics and game logic in sequence. Almost every engine did this. I’m pretty sure Unreal Engine was this way to start with. If you say the engine is bad because it has this then Unreal Engine is also bad.
This is not an issue with the engine it’s an issue with the netimense code at the heart of the engine.
What? Code is not bad because of where it comes from.
You have utterly confused me with your last bit, you do realize that the list I used were all engines bethasda has used all built upon the previous right.
This conversation is about an engine being bad because of its heritage. Yes, they’ve built on the engine, as they should. You should almost certainly not write an engine from scratch. You’ll just write the same code that already exists again because 90% of the functionality is the same and already there. You think it’s bad because some old code exists. That’s a stupid position to hold. That doesn’t make an engine bad, and it can all be modified to fit modern requirements.
Netimmerse is still in there buried under all the spaghetti
Probably not really. Maybe some code, for some very basic systems that work perfectly fine, but likely not much. The same is true for UE, like the comment above says. There’s still some original UE code from the 90s in UE5 (and 6), and that’s totally ok. In fact, it’s smart. If it perfectly handles the job with no errors, changing it for the sake of change only creates opportunities to introduce new unknown bugs.
NetImense is late 80s but I digress. It’s the reason we are still stuck with framerate tied physics. (Shared rendering and physics per tic.). About 80% of it has been replaced with newer and better systems not counting the plugins and bolt-ons. But the bottom of the stack is still there supporting the rest of it.
No, it isn’t. There are plenty of engines that have had that issue and have fixed it over time. Bethesda could. The reason it still exists is because of either incompetence (which won’t be fixed by switching engines; if anything it’ll be worse for a while) or because it isn’t a priority.
I think you do not understand. All of Bethesdas games are frame rate physics locked because of netinense code that has never been replaced. It could be replaced yes but it has not been overhauled as it is a core system that many other systems are bolted onto
Netimense > Gamebryo > Geck > Creation kit same DNA .
There’s a reason all the 3d files are .nif Netimense Format
The point of this conversation is that they have upgraded the engine, as all engines are. It is not limited because it came from Netimerse. It’s limited because they haven’t fixed that issue. It can be fixed is the entire point of the discussion. They should not swap engines just because of the heritage, or all engines would have one version and then are abandoned.
It literally is limited because of the code from netimmense Which was originally a MMO engine ties framerate to physics
They have updated the engine many times iirc. We are on creation kit 3 now so that’s about 8 major revisions since netinense
This is not an issue with the engine it’s an issue with the netimense code at the heart of the engine.
You have utterly confused me with your last bit, you do realize that the list I used were all engines bethasda has used all built upon the previous right.
It’s a problem that needs to be solved, but it isn’t a hard limitation. Limitation implies it’s something that can’t be changed. Also, it isn’t because it was an MMO engine. It was incredibly common at the time. It was simpler to have one thread that handles physics and game logic in sequence. Almost every engine did this. I’m pretty sure Unreal Engine was this way to start with. If you say the engine is bad because it has this then Unreal Engine is also bad.
What? Code is not bad because of where it comes from.
This conversation is about an engine being bad because of its heritage. Yes, they’ve built on the engine, as they should. You should almost certainly not write an engine from scratch. You’ll just write the same code that already exists again because 90% of the functionality is the same and already there. You think it’s bad because some old code exists. That’s a stupid position to hold. That doesn’t make an engine bad, and it can all be modified to fit modern requirements.
I can only conclude your troll or you just don’t grasp the English language