UT99.org | Unreal Tournament Community

Info Thread: http://www.ut99.org/viewtopic.php?f=37& ... 747#p24747

Interesting thread. Are you planning to put these ideas into practice (and how, with third party add-ons or are you aiming to get this merged with the actual source?).

anth wrote:Interesting thread. Are you planning to put these ideas into practice (and how, with third party add-ons or are you aiming to get this merged with the actual source?).

Eh what? Just to make things clear, I am only a TESTER. I have not programmed anything of that stuff.

This is the oldunreal Unreal Patch project. Leader/source holder of that project is Smirftsch. Other important programmer are dots/:...: and Casey. For more information visit their site: oldunreal.com.
The complete story (how this started etc) will follow soon. (seriously, writing those 2 parts did cost me already a lot of time).

It is possible that this patch can be ported to UT as well. But this depends by the permission of Epic.

Like I said previouslly (by PMs), this kind of patch/addon to UT would be more than awsome. Not only we would be able to make better maps without almost any limits and looking still "UT99", as coders/modders would greatly benefit on this.

However:

Creavion wrote: It is possible that this patch can be ported to UT as well. But this depends by the permission of Epic.

Won't happen, or at least is highly unlikelly they will permit such a thing. The reasons are quite simple:
- They gave the same chance to UTPG, they messed it up in many ways. Even if they didn't have the power or "juice" to keep it up and do it right, they shouldn't leave the project as it was (players side and Epic side).
- UT is still sold, and there's a lot of people who prefer UT rather than UT2004 or even UT3 (from what I heard, the UT99 servers are more active than the newer versions). Yet, they still want to profit specially with UT3, and if this patch comes out to UT, UT3 and UT2004 will be basically killed and people will turn to UT, specially since most features which really do matter in those games, are done for Unreal already, and can be ported to UT in a blink of an eye. From Epic point of view, this can be bad. UT3 might still have a little force, since there are features that that patch doesn't have, but regarding UT2004, everything it has which really matter, UT would have as well.

And as far as I know, even the OldUnreal team had to ask permission to Epic to make this patch for Unreal, since it's a really wild patch (in a good way, of course), imagine for UT.

It kinda hurts saying this, but this is the truth, and we have to live with that.
Yet, if someday, by some chance or miracle Epic decides to let the patch be made to UT, I will be more than happy to use it, and not only me, but all the great developers I know.

Great stuff.


I just hope that the meshes will have the same lighting brightness that the level geometry has.

"Great stuff" goes without saying, I sincerely hope we get this update before it's too late. The UT mapping and modding community is already dwindling, but stuff like this could greatly help to liven it up.

I hope you don't mind, I linked this in a couple of other forums as well.

Also, it seems to me that the ut99.org domain is frequently offline. What's up with that?

...all I can say

@Myth: I dont know, but in the case you can see it by using "Lighting Only". (works as like in UEngine 2)
@Madis: We have to see how this develops... I am not that extremely pessimistic like Ferali. There is surely some hope.

Anyway, actually I thought there come more interest from the community, either it would come with a possible release of uhm patch 475 or its like the poeple say... its really a little bit disappointing.
I dont think I will make the trouble to write the other feature parts until further notice.

Anyway you can also check some infos here
http://forums.beyondunreal.com/showthre ... ost2460324

I don't care about the lightmap
When the lightmap is applied differently to level geometry and meshes in all unrealengine 1 games. Tho this depends a bit on the rendering settings. It's that bOneXBlending. If you set it true the levels look more suck, but this is what happens.
Take a gray texture. 127,127,127 RGB color over 64x64 sized texture.

Apply it to geometry and light it by maximum.
Apply it to a mesh and light it by maximum.

Here is an example map to this post so that you can see that I mean.
Both meshes and level geometry should use the same source*destination*2 blending mode.
For low intensity lights this is not visible because the mesh lighting is amplified.

Would be interesting a native dual core amd fix, and also optimize the engine to run in multicore.

Smirftsch said, that static meshes do not act like bsp regarding lighting, for everything else check my previous post.

@Dual Core stuff: No way.. at least not yet.

There is very little room for multicore optimizations in gaming (at the cpu level at least. gpu is a different story)

Then unfortunately they'll be lit like stardard meshes...

@anth
very little optimisations???
ARE YOU KIDDING ME????
It's quite the opposite you say
ut would run at 2x framerate...
Most of the cpu is either used up when the engine is clipping the bsp geometry (calculating what's not visible) on a high poly map or iterating through actors .. run clipping on a different thread and you already have a major speed boost and iteration through actors can be boosted by 99% in case of dual core PC's.

The 10 year old graphics engine is run at 1% GPU usage... there is no need to optimise that. Well unless you don't have a gpu... if you don't have a proper gpu then the computer is waiting for that non existing gpu to blit a few billion pixels.

You see unreal engine 1 was made for PC's that don't have GPU acceleration... the CPU works more so that less things need to be drawn. This works inefficiently if high number of things have to be drawn anyways. Unreal rocks on a 233Mhz MMX PC 320x200 32bit 2MB vram vesa gfx card whit no 3d support at 19frame/sec. GOOD OLD TIMES.

Good luck to all developers and testers.

By little room for optimization I mean that there isn't much that can easily be split off into seperate threads without redesigning some of the core subsystems (eg: the generic renderer, gmalloc, ...)

Myth wrote:Then unfortunately they'll be lit like stardard meshes...

The U1 static meshes act from the lighting nearly like the uengine 2 static meshes...
I made a comparison testmap with the same lighting conditions and the same static mesh construction some time ago. After some fixing you can barely see differences, its really very similar.
U1 SMs can not accept "static shadows" (unsure if that can be fixed) so far, but the ones of uengine 2 do not look in direct comparison to the ones of unreal 1 good, either.

@Dual Core/Multi core stuff: Maybe it will come.. somewhere in the future... maybe.
@cpu and gpu: Yes, nearly everything depends so far on the cpu. Lately the calculation from Distance Fog could be ported to the gpu. Actually the very first step...