Increasing client drawing range?

Feeh

Does anyone know how to increase the client draw range?
Since I've got a big screen the default 800x600 viewport became too small and changing resolution would be annoying :p

Razor can increase the viewport but since the client doesn't support it bigger, most of the time it leaves black fragments over the map that is pretty annoying

If anyone know how to increase it (injecting code, patching client...any) I'd be glad

as17.postimg.org_n0rrg892j_fragment.jpg

Thanks
 
Last edited:
I actually have better luck with UOSteam having a slightly faster draw distance than Razor, plus Razor likes to freeze a lot on the new clients.
 
What client version are you useing @Feeh
That black stuff that shows up on the 36x36 area,. is due to the client version you're using. I know it happens on 7.0.2 & some 6.# versions. Other version I'm not sure of. I really wish someone could explain the technical reason that this happens. You gotta keep hitting resync client to make it go away.

For anyone wondering,. I'm not talking about the black or gray are outside the 36 x 36 map display around the player. But it does seem like that black area isnt entirely removed on certain client versions. When you move and the 36x36 area is update. I've also experainced this mostly happening when I run certain directions.
Neither Razor or UOSteam will fix this problem. (as of this post)

I've even edited the memory for the client to extend the game window without razor or uosteam and it has the same result.
My solution was just using the latest uo client and modifying the files to meet the servers requirements but that's not always easy.
 
I'm guessing the client has a hard coded 36x36 value. Since it renders in all GDI BltBit calls, artifacts are going to happen, im guessing this is why you have the problem you are describing @Hank. Unfortunately no amount of memory rewriting is going to fix this.
 
The 36x36 are im sure you're aware. Is the area around a player that they can visually see. Some people call it the draw distance. You're right, no amount of memory edits will change that. It's hard coded. Artifacts is probably the very best way to describe this problem.
(for anyone who doesn't know what an artifact is. Here is an example: http://en.wikipedia.org/wiki/Visual_artifact)

This does not however explain why certain client version have these artifacts when a player expands their game window. It's been 36x36 tiles (16 tiles in all 4 directions) since the early days of UO. Makes me wonder if these artifacts have been there for a long time now and due to the limitations on the game window not many people have noticed.
Also when a player gets close to these artifacts it removes them and shows properly. I don't know the hardcode myself but it doesn't add up in my mind why the entire 36 x 36 square wouldn't be cleaned of artifacts after the player moved. Perhaps its just as you said with the BltBit when the players animation passes over the artifact it's cleared. (my head hurts now)
 
@Hank The way BltBit rendering works is nothing like DirectX. Basically DirectX redraws the entire screen @ 60 frames per second. BltBit draws a specific region of the screen as fast as the CPU will allow it (with a calculated frame rate limitation, fixed time stepping). Because of this, you usually want to clear everything within the rectangle, then draw everything again within that same rectangle. However, to save time, at the outer edges of the screen, where the objects can be prioritized as less important to the playable area of the screen, you might just want to draw the update objects over whatever exists. This is how you get artifacts, and this is probably what you are seeing. Because GDI+ is not using your GPU and is exclusively using the CPU, back in the day you had to really watch your performance, and spend as little time doing the most things as possible. This is probably how UO is coded (and yes, this is a guess, I have no real factual information. On the experience of doing this for a living over the past 12+ years).

http://en.wikipedia.org/wiki/Bit_blit more information about Bit Blit (i had it backward BltBit = BitBlt) ;)
 
That sounds right. I appreciate you taking time to lay it out for me/us. You were right to think I was thinking in directx terms. I often forget just how old school UO is. Thank you.
 
You must log in or register to reply here.
Back