The Unreal X (An idea, maybe it will never exist.)

[FXANBSS]

Hello... After all these years, i can't believe there wasn't something too big like i am going to tell, it's just my idea.

If someone wants the love of all UT and Unreal players he can make this, maybe never.
Yeah, Unreal X is basically, every Unreal game that uses Unreal 1 Engine.
Ex: Unreal Gold and Unreal Tournament GOTY
Unreal Gold = Unreal + Unreal:RTNP

I will only talk about mutators, campaigns and something.

Mutators:
You can put the mutators from UT and Unreal, but be careful, put them in his lists! Since they will be merged and... for example use a UT mutator to play Unreal, maybe it doesn't work...
At least only the mutators that are configured for Unreal X, you don't have problem, they still work in UT (No Unreal X) but it can't read the special configuration of the .int but no problem!
Also you can modify the already configured mutators, if you want them for Unreal (X or not.), Maybe it doesn't work but i think some of them would work and do something in the game.
Yeah, this is confusing, but this makes the game more flexible.

Campaigns:
You can play every campaign here, even oldskool ones, there will be also campaigns configured for Unreal X, they will have special features.
You can remove both Unreal Gold and Unreal Tournament in Unreal X, but you will get a message that you can't play! Unless you have other mod that doesn't use Unreal or Unreal Tournament stuff, completely custom.
You can't play Unreal RTNP without Unreal files!!

Engine: It will basically uses the enhanced Unreal 227i from oldunreal.
The shadows. You can configure them, you want the realistic from 227i or the classic shadows?
You can use the Classic graphics or the enhanced Unreal 227i graphics.
New Unreal Editor 2.2, more flexible.
More options for actors, Ex: Scripted Pawns.
A modified SkaarjWarrior Boss that regenerates, does multiple attacks, explodes when dies...
AMD Compatibility, always those cards runs slower in older games! I just play old games but with AMD.
Direct X11? Is that possible? The current DX11 is actually buggy.

Something: Unreal Tournament uses the same engine than Unreal as i know.

I want your opinions about what do you think.
Thanks and sorry if you thought this was real, no, this is UNREAL.

This post has been also posted in...
UT99.org
UnrealSP.org
oldunreal.com

[Higor]

AMD Compatibility, always those cards runs slower in older games! I just play old games but with AMD.

Taskkill the Catalyst Control Center, games will run better (at least that's my case).

Direct X11? Is that possible? The current DX11 is actually buggy.

100% unnecessary, the biggest bottleneck isn't in the 'RenderDevice', it's in the 'Render' interface that passes data to the RenderDevice.
Well, a rewrite in 'Render' will automatically mean a rewrite in 'RenderDevice', and a few vtable replacements on all model types (UMesh, ULodMesh, USkeletalMesh) unless an Engine.dll upgrade is done.

[Chris]

What exactly are those vtables?

[sektor2111]

You can put the mutators from UT and Unreal, but be careful, put them in his lists!

Huh ? How many ? Have you seen PlayerPawn.uc and Player.uc classes from UT and Unreal. By example a mutator based on these classes might fail to work or even crash - only some of them very simple might work because VARIABLES are used DIFFERENT.
UT doesn't have too much compatibility with Unreal patch 227 anyway. Beside this 227 has extended with a lot of new things which doesn't exist in UT - keep dreaming.

[FXANBSS]

Unreal X will use the same packages but with a better quality, but for servers (that are not from unreal X), it will use the old packages for compatibility, so you can play UT and Unreal servers that aren't from Unreal X...

You can switch to Tournament mode in options, to play UT and some tournament mods.
Oldskool campaigns will be in the Unreal side like every campaign.
Unreal X does accept oldskool stuff too.

Oh, about UT compatibility, maybe remake it for the 227i since the enhanced 227i engine will be used in Unreal X, oh wait, this is a DREAM.

[Barbie]

What exactly are those vtables?

Virtual method tables (VMT) are used to store pointers to the matching functions while run-time bindings. Example: the object Actor defines the function PostBeginPlay(). Then the pointer to that function is stored in a VTM at position 0. The Actor sub class object Pawn overrides PostBeginPlay(), and that address is stored at position 1. The Pawn sub class actor Cow overrides PostBeginPlay(), and that address is stored at position 2 and so on.
If now the function PostBeginPlay() is called at any point in any class of that tree, the last entry of the PostBeginPlay.VTM is used. On the other hand you can call the parents implementation by PostBeginPlay.VTM[i-1], in UScript with Super, in this example with Super.PostBeginPlay().

I'm not a compiler builder, so please correct me if I'm wrong.
PS: Wikipedia has an article about.

[Chris]

What exactly are those vtables?

Virtual method tables (VMT) are used to store pointers to the matching functions while run-time bindings. Example: the object Actor defines the function PostBeginPlay(). Then the pointer to that function is stored in a VTM at position 0. The Actor sub class object Pawn overrides PostBeginPlay(), and that address is stored at position 1. The Pawn sub class actor Cow overrides PostBeginPlay(), and that address is stored at position 2 and so on.
If now the function PostBeginPlay() is called at any point in any class of that tree, the last entry of the PostBeginPlay.VTM is used. On the other hand you can call the parents implementation by PostBeginPlay.VTM[i-1], in UScript with Super, in this example with Super.PostBeginPlay().

I'm not a compiler builder, so please correct me if I'm wrong.
PS: Wikipedia has an article about.

Oh so it's the structure of polymorphism.
Does that mean UT uses a VTable for every class, like C++?
By your description it sounds more like VTable is running in serial with the inherited classes, and parallel with all its methods.

[Higor]

In this UEngine version, each mesh type has a function where it populates a vertex array (per request) and transforms them for rendering.
Then a class named 'URender' (Render) will process that vertex array, apply special flags to surfaces, compute lighting.
Once done, it will pass the surfaces one by one to the 'URenderDevice' (RenderDevice) in use.

This kind of design doesn't really go well with today's standards, where you can cache an entire subset of vertices in your GPU memory and delegate transformation to it, instead of doing it all yourself on CPU.
Also, let's notice that all vertices in meshes are compressed, so they need decompression every single time they're being fetched.

A serious project would need:
- Planning of a completely new rendering pipeline system.
- Determining where your caches go, this is easy, the game is quite old so I'd keep the decompressed meshes' vertices in the GPU cache.
- New URenderDevice BASE interface capable of interacting directly with UPrimitive classes (renderables), common cache, drawcall code and effects applying (via shaders?).
- Vulkan/DirectX12 renderers derivated from the above interface.
Because seriously... AMD gave us a huge boost with Mantle.

[FXANBSS]

What? I think i am confused but i can boost the game's framerate with mantle?
In UT or Unreal...
It runs like crap when i put lot of stuff, it lags with 100 monsters... What?!
This doesn't happen in Nvidia, but AMD is technically the best! (For new games... duh!)

[Barbie]

Does that mean UT uses a VTable for every class, like C++?

What I remember of reading in UnrealWiki (is again down atm): every function is virtual in UCScript. And because of this I conclude every function needs a VMT. (Except you define it with the modifier Final what means that it cannot be overridden.)

By your description it sounds more like VTable is running in serial with the inherited classes, and parallel with all its methods.

I don't see what you mean by this. oO

[Higor]

I will make it short.
Making a Dx12/Vulkan renderer on the current interface... is like putting a MacLaren F1 GTR to run on thick wet mud, the gain is almost null.
Making a VBO based, GPU cache heavy, object-grouping interface+renderer, you get UT to run at 500 FPS.

It has to be a big project, something GIT based, and the render interface must be started from scratch (not using licensed code... we won't be needing it except for simply understanding current behaviour) in order to stay on the legal side.


EDIT:
Every single c++ class/struct that has at least ONE virtual function, has a vtable.
The (first) vtable pointer is at offset 0x00 of each object, objects with multiple inheritance do contain more than one vtable but I won't go deep explaining that.
The pointer goes to a table of function addresses, so if you change the vtable itself (ugh) or the individual object's vtable pointer to another vtable you can change the behaviour of the object's Virtual Functions.
UMesh, ULodMesh, USkeletalMesh use GetFrame() func (virtual) to retrieve a list of vertices, all of this is CPU based.

TBH I wouldn't even try vtable replacing every mesh and instead use dummy classes like this:

Code: Select all

class UMeshDummy : public UMesh
{
    void SetupGPUCache(...);
};

So when we detect we're about to render a UMesh (one of the mesh types) do this:

Code: Select all

((UMeshDummy*)Actor->Mesh)->SetupGPUCache(...); //Gotta love low level languages allowing you to do this

If the mesh is a LodMesh...

Code: Select all

((ULodMeshDummy*)Actor->Mesh)->SetupGPUCache(...); //Gotta do IsA(ULodMesh::StaticClass()) && !IsA(USkeletalMesh::StaticClass());

If the mesh is a SkeletalMesh...

Code: Select all

((USkeletalMeshDummy*)Actor->Mesh)->SetupGPUCache(...);

If Vulkan/Dx12 code can be portable between each at this stage, then it could be possible to avoid adding renderer specific code here.

Bottom line is, can be done but needs a VERY dedicated team to do this.
A team as dedicated as Dolphin Emulator's (which I once betatested for when I was young and noob).

[Chris]

Does that mean UT uses a VTable for every class, like C++?

What I remember of reading in UnrealWiki (is again down atm): every function is virtual in UCScript. And because of this I conclude every function needs a VMT. (Except you define it with the modifier Final what means that it cannot be overridden.)

By your description it sounds more like VTable is running in serial with the inherited classes, and parallel with all its methods.

I don't see what you mean by this. oO

Yes they are virtual functions, I was more curious about your description of the implementation.
What I meant was that by your description it sounded more like every (virtual) function has a VTable (Not every definition of them, but per declaration) and then indexing them starting from the base and then increasing for every redefined function in all of the derivative children classes. (One per function, not one per class)
In C++ it's the opposite where every class (like Higor said) that has at least one virtual function, implements a pointer to a (static) VMT. In that VMT we have pointers to all the virtual functions that in turn points to the most recent version of the function (determined by the compiler). We know that every pointer is 4 bytes in 32bit builds, and 8 bytes in 64bit. So it would make most sense to store the functions in the same order as the class declares them. Sorry if I confused you.

[Dr.Flay]

You don't know what you are asking.
ask yourself this first;
How may years have Unreal 227 and the UT-SDK been in development ?
A project like this would take far longer and would never finish.

Just make do with combining Unreal and UT like I do.
I play Unreal in UT and UT in Unreal. Keeping them joined but separate means that only the mutators that work for that engine are visible.

[Higor]

Dolphin-Emu came out of nowhere and look where it is now, as I said, everything is possible.
You just need a very capable and dedicated team.

EDIT:
UT SDK is just as CPU heavy as the old code, unfortunately this project would mean starting over from zero... but it can still be used for reference.