XC_Engine [20] - XC_Core [7b] - XC_IpDrv

Chris
Experienced
Posts: 134
Joined: Mon Nov 24, 2014 9:27 am

Re: XC_Engine [20] - XC_Core [7b] - XC_IpDrv

Post by Chris »

Higor wrote:I have absolutely no idea, bear in mind that old C++ compilers didn't follow standards that well.
Take a look at GCC, the 2.95 version was putting the vftable pointers at the end of structs, it just worked with UObject because UObject is a subclass of FUnknown (no variables, vftable at offset 0)... maybe this is exactly one of the reasons they did it that way.

What the relative jump does is simplify DLL loading, when you put the code into memory you don't need to do weird address translations/loading or anything when you're working inside the same dll, the relative jumps works great there, absolute addresses are more of a function call thing.
Newer compilers have the symbols table direct exactly to where the functions are, not to a weird middle-man table with jumps which is why I wonder it was done that way.


Back to XC_Engine, there's still some unstable behaviour to take care of, as well as splitting the map in various local grids.
Hmm, but one thing doesn't make sense. If it places the vftable pointer at the end of the object, how could it possibly find the offset for derivatives if the size of the actual object is unknown?
RocketJedi
Inhuman
Posts: 850
Joined: Wed Mar 12, 2008 7:14 pm
Personal rank: I.T Master
Location: New York
Contact:

Re: XC_Engine [20] - XC_Core [7b] - XC_IpDrv

Post by RocketJedi »

I love this thread. :rock: :rock: :rock:
https://www.vulpinemission.com
Image ROCKET-X8 Server
Image MONSTERHUNT w/ NALI WEAPONS 3 + RX8
Image BUNNYTRACK NY
Image SNIPER DEATHMATCH
Image InstaGib + ComboGib + Jailbreak
Image ROSEBUM ROCKET-X RB
Higor
Godlike
Posts: 1866
Joined: Sun Mar 04, 2012 6:47 pm

Re: XC_Engine [20] - XC_Core [7b] - XC_IpDrv

Post by Higor »

A test build of XC_Engine loading a different collision grid.

You'll know if it's working if you see stuff like this on the log:
Log: Bound to CollisionGrid.dll
Init: Acquired GNewCollisionHash extern
Init: ========= XC_ENGINE - Test build 20 =========
Init: ================= By Higor ==================
...
XC_Engine: Setting up collision octree [Level Hook] for CityIntro
Log: [CG] CollisionGrid library succesfully initialized.
Log: [CG] Element holders succesfully spawned.
Log: [CG] Grid allocated [43,22,42,0]
bUseLevelHook=True is strictly necessary for now.
The grid requires a SSE2 capable CPU.
XC_Engine_CGrid_01.7z
(132.21 KiB) Downloaded 70 times
=============
EDIT:
MinGW is a nightmare to work with when it comes to aligned structures, so I'm sticking with VS2015 (with old CRT linking so new binaries don't need to be installed)
Also, primitive actors haven't been implemented at all.
User avatar
sektor2111
Godlike
Posts: 6403
Joined: Sun May 09, 2010 6:15 pm
Location: On the roof.

Re: XC_Engine [20] - XC_Core [7b] - XC_IpDrv

Post by sektor2111 »

Ummm... Nope...
ServerTravel =
Server_crash.log wrote: XC_Engine: Setting up collision octree [Level Hook] for MH-Sk_Godz
Log: [CG] Element holders succesfully spawned.
Critical: appError called:
Critical: Assertion failed: New grid exceeds 128^3 dimensions [File:ContainerLogic.cpp] [Line: 171]
Exit: Executing UObject::StaticShutdownAfterError
Critical: StartCollision
Critical: UXC_Level::SetActorCollision
Critical: UXC_GameEngine::LoadMap
Critical: LocalMapURL
Critical: UGameEngine::Browse
Critical: ServerTravel
Critical: UGameEngine::Tick
Critical: UXC_GameEngine::Tick
Critical: UpdateWorld
Critical: UXC_ServerCommandlet::Main
Exit: Exiting.
Uninitialized: Name subsystem shut down
Uninitialized: Log file closed, 08/17/17 16:20:29
Don't say that PentiumD doesn't include SSE2.
[attachment=0]machine_used.PNG[/attachment]
Attachments
machine_used.PNG
machine_used.PNG (69.77 KiB) Viewed 2614 times
Higor
Godlike
Posts: 1866
Joined: Sun Mar 04, 2012 6:47 pm

Re: XC_Engine [20] - XC_Core [7b] - XC_IpDrv

Post by Higor »

Replace CollisionGrid.dll (from this post) with this one.
Removed symbols and unnecessary code (check that DLL size lol)
Attachments
CollisionGrid_01.7z
(12 KiB) Downloaded 63 times
User avatar
sektor2111
Godlike
Posts: 6403
Joined: Sun May 09, 2010 6:15 pm
Location: On the roof.

Re: XC_Engine [20] - XC_Core [7b] - XC_IpDrv

Post by sektor2111 »

First testing stage passed, not bad but I cannot say it's safe. Some "bugged" tree which I did reacting at damage looks a bit moved from original point where it was attached to Mover. I need more testing to figure if things add around movers are not affected because... I've done tweaks around stupid TriggerControl Mover problems and I'm hoping to not see my work rammed at this chapter. For this task I'll spend more time in MH-TrainCommando - I should use some map specific debugging commands in Actors injected intended to have a deal in Level...
Higor
Godlike
Posts: 1866
Joined: Sun Mar 04, 2012 6:47 pm

Re: XC_Engine [20] - XC_Core [7b] - XC_IpDrv

Post by Higor »

Has there been any noticeable performance improvement on maps with a LOT of things in movement?
User avatar
sektor2111
Godlike
Posts: 6403
Joined: Sun May 09, 2010 6:15 pm
Location: On the roof.

Re: XC_Engine [20] - XC_Core [7b] - XC_IpDrv

Post by sektor2111 »

I'm not 100% sure about some occurrences but... let's say that some Bot behind me fired weapon at monsters, I got a sudden boost momentum dropping me nearby monster which in next few milliseconds was happily hacking me. I have to figure these more times they were happening in 2 Levels. I gotta admit they can boost player sometimes but this time that boost was a bit too aggressive or I might be wrong - or it was that movement adjusted specific for player around other pawn which was reacting too aggressive - I don't know each detail - more checks are needed. In exchange, I did not see pawns melted at walls stuck like a statue which were previously rarely indeed, but still happening... or hanging like they went to spider physics, this time they seems more normal related to physics.
The rest of movement things seems to work normal, actually maps sorted by me have an easy deal so they were always smoother - I must check more using maps with a higher load.
User avatar
sektor2111
Godlike
Posts: 6403
Joined: Sun May 09, 2010 6:15 pm
Location: On the roof.

Re: XC_Engine [20] - XC_Core [7b] - XC_IpDrv

Post by sektor2111 »

I'm going to disable bUseLevelHook. There is no good reason for having some pupae, mercenaries stuck in a sort of ducking position or like that, and heavily getting into attack - I see this in Demons][ which last times was running perfectly. Monsters spawning later don't have issues. A crash occurred in client post server-travel "TestReach blabla... KO". I went later to server.log. Spam ?
Server.log wrote: Log: [CG] Allocating extra element holder for MiniTree
Log: [CG] CheckResult stack depleted!
XC_UCC: === Last line repeats 25 times.
Log: [CG] Allocating extra element holder for MiniTree
Log: [CG] CheckResult stack depleted!
XC_UCC: === Last line repeats 81 times.
Log: [CG] Allocating extra element holder for MiniTree
Log: [CG] CheckResult stack depleted!
XC_UCC: === Last 2 lines repeat 1 times
Log: [CG] CheckResult stack depleted!
XC_UCC: === Last line repeats 587 times.
NetComeGo: Close XC_TcpipConnection18 08/20/17 17:03:38
Log: [CG] CheckResult stack depleted!
XC_UCC: === Last line repeats 410 times.
Log: [CG] Allocating extra element holder for MiniTree
Log: [CG] CheckResult stack depleted!
XC_UCC: === Last line repeats 948 times.
Log: [CG] Allocating extra element holder for MiniTree
Log: [CG] CheckResult stack depleted!
XC_UCC: === Last line repeats 487 times.
Else I still can see "unable to load texture" (even if texture is there) by XAN_A, XAN_B bots but finally getting skinned in game somehow. At this chapter I'm not interested to hard-code their skins because of loading skin blabbering - I recommend that whatever skin tweaking to go under a boolean for being disabled on demand - I don't know what does a Linux 451 server but for sure I don't need these "fixes" in my Win 440/436. Skin crushers can be happily banned especially those who think they are movers or decals or whatever monsters joining to an UT server.

EDIT:Errata related to monsters, I think I had some timing problem at server - things went more properly right now with monsters, but I'll keep doing tests.
Higor
Godlike
Posts: 1866
Joined: Sun Mar 04, 2012 6:47 pm

Re: XC_Engine [20] - XC_Core [7b] - XC_IpDrv

Post by Higor »

I used a very small memory stack for result sets, still... 1000 results on a single VisibleCollidingActors/CollidingActors query is ridiculous.
Are you scanning the collision hash for unreasonably high radiuses?
User avatar
sektor2111
Godlike
Posts: 6403
Joined: Sun May 09, 2010 6:15 pm
Location: On the roof.

Re: XC_Engine [20] - XC_Core [7b] - XC_IpDrv

Post by sektor2111 »

1600 1800 UU.
Haven't seen problems until now ?
Higor
Godlike
Posts: 1866
Joined: Sun Mar 04, 2012 6:47 pm

Re: XC_Engine [20] - XC_Core [7b] - XC_IpDrv

Post by Higor »

That's about the ok limits.
I fell short on the memory allocators, gonna try to improve the grid's memory managing even more.
In my opinion, what's making CollisionGrid.dll so much faster than both XCGE's and UT's is the memory manager, you'll find out how once I make the source code available.

The good thing is that I can simply build this DLL as many times as we want without touching XC_Engine.dll.
Btw, deleting CollisionGrid.dll makes XC_Engine use it's old implementation, no need to change settings. (At least for now, once CollisionGrid is final i'll remove the old implementation from XC_Engine)

=====
UPDATE

As usual, apply over the contents of this post.
CollisionGrid_02.7z
(12.08 KiB) Downloaded 63 times
Changes:
- Mem stack's size increased as follows.

Code: Select all

	if ( !G_Stack )	G_Stack = new (SIZE_KBytes, 256) GenericMemStack( 256 * 1024); //5461 results
- All memory operations use UT's allocators now (malloc/free), makes portability simpler... yet MinGW build still produces a broken 92kb DLL.
- Increased ElementHolder's size for MiniTree and ActorLink, expect less memory operations on big maps.
User avatar
sektor2111
Godlike
Posts: 6403
Joined: Sun May 09, 2010 6:15 pm
Location: On the roof.

Re: XC_Engine [20] - XC_Core [7b] - XC_IpDrv

Post by sektor2111 »

All right, I'll check it...
ShaiHulud
Adept
Posts: 459
Joined: Sat Dec 22, 2012 6:37 am

Re: XC_Engine [20] - XC_Core [7b] - XC_IpDrv

Post by ShaiHulud »

I don't know which bit or bits of the game are responsible for this, but is there any possibility that the file download process might be changed so that the server could indicate how many downloads will be needed?

So instead of:

"Receiving XYZ..."

You'd see something like:

"Receiving XYZ (1 of 7)..."

Or maybe even:

"Receiving XYZ (1 of 7. 52MB total, 10MB received so far)..."
Higor
Godlike
Posts: 1866
Joined: Sun Mar 04, 2012 6:47 pm

Re: XC_Engine [20] - XC_Core [7b] - XC_IpDrv

Post by Higor »

Like the idea... there's a little logistic complication with packages that depend on other non-present packages but it can be done.
Attempting to load a package file that's missing a dependancy (Like loading SiegeIV when sgMedia is missing) will make the package file to fail to load.

Would need to write a small package checker that loads the file, checks size, GUID (if net).
The good part of this? I could use this checker to pre-check the GUID before loading an existing package, and therefore fixing a long standing mismatch problem.

The result on clients would be something like this:
- Package list received.
- Preallocate a temporary 'to-download' list.
- Pre-load packages using the checker. (could be done on the 'PendingLevel' object)
- If package isn't cached (ex: Wood.utx, has 2 versions) check the GUID.
-- If GUID matches, consider valid
- If GUID mismatches, add to download list.
- Once downloaded, force loading of the cached package (this needs to be done in XC_Engine's UXC_Level::LoadMap)

That + the grid would be a nice excuse for a new XC_Engine build.

EDIT: Optionally the package pre-loading could be done in a way that if there's multiple folders with identical package names, the one with the matching GUID is loaded.
I intended to do this a while ago, and I might do this using XC_Core (and add some script support for it?)
Post Reply