RunUO Community
This is a sample guest message. Register a free account today to become a member! Once signed in, you'll be able to participate on this site by adding your own topics and posts, as well as connect with other members through your own private inbox!
Open source XNA Ultima Online client
- Thread starter Poplicola
- Start date
Thilgon
Sorceror
i remembered another thing that doesn't work well with the OSI client...
Character slots.
It shows fine if the number of admitted characters is 1, 5, 6 (maybe the seventh works well too, i haven't tried it anyway), but if you set by script the maximum char slots to 2, 3 or 4, it keeps on showing the "new" button and make the char creation (anyway, the server answers fine refusing the new char if it exceed the maximum admitted, hanging the connection)...
my suggestion about that is to make it so one can make up to 10 chars (i think they enter in the window
), removing the "new" button if the server-side maximum allowed is reached, whatever number it may be...
i'll be thinking about other improvements
Character slots.
It shows fine if the number of admitted characters is 1, 5, 6 (maybe the seventh works well too, i haven't tried it anyway), but if you set by script the maximum char slots to 2, 3 or 4, it keeps on showing the "new" button and make the char creation (anyway, the server answers fine refusing the new char if it exceed the maximum admitted, hanging the connection)...
my suggestion about that is to make it so one can make up to 10 chars (i think they enter in the window
), removing the "new" button if the server-side maximum allowed is reached, whatever number it may be...i'll be thinking about other improvements
Poplicola
Sorceror
This will definitely be fixed. There should be a better way to enumerate a user's characters on the login screen. I'm partial to Diablo 2's character select screen, which might be appropriate since there is a comparable level of detail in a UO and D2 characters.Thilgon;803434 said:i remembered another thing that doesn't work well with the OSI client...
Character slots.
It shows fine if the number of admitted characters is 1, 5, 6 (maybe the seventh works well too, i haven't tried it anyway), but if you set by script the maximum char slots to 2, 3 or 4, it keeps on showing the "new" button and make the char creation (anyway, the server answers fine refusing the new char if it exceed the maximum admitted, hanging the connection)...
my suggestion about that is to make it so one can make up to 10 chars (i think they enter in the window
i'll be thinking about other improvements
Working on inventory today! In this client, every single frame of the GUI will be editable using C#. The Inventory window which is displayed takes about 120 lines of code to initialize, update every frame, and draw.
Just updated to r17 at the Google Code project!
Changes in this version:
GAMEOBJECTS:
* Items now have a stackcount variable (for things like arrows, bandages), and a ContainedWithin variable (to note which bag the item belongs within). Neither of these variables is currently used, but they are updated by the server. (GameObjects/Item.cs)
* Added code to handle Container objects, which are an extension of Item objects (GameObjects/Container.cs).
TILEENGINE:
* GameObjects now only draw once (GameObjects/GameObject.cs)
* Normals are now calculated correctly and lighting is perfect. Thanks Jeff for the help with terrain normals! (TilEngine/GroundTile.cs, TilEngine/Map.cs)
INPUT:
* The Client can now 'use' objects (Network/GameClient.cs) You use an object by right-clicking them, which replaces double-click in the default UO client (GameState.cs)
* The Keyboard can now tell you which keys have been pressed since the last update (Input/KeyboardHandler.cs)
NETWORK:
* The client can now receive Container packets, and AddItemsToContainer packets. (Network/GameClient.cs) You can display your backpack by clicking 'B' (GameState.cs)
* Added opcodes: CMSG_USEOBJECT = 0x06, SMSG_CONTAINER = 0x24, SMSG_ADDMULTIPLEITEMSTOCONTAINER = 0x3C,
GUI:
* Added a error popup for login errors. It's called ModalErrorPopup, but it's not modal yet.
* The Engine opens the Login GUI on startup (Engine.cs)
* The GUI class now maintains a list of open windows and updates them every frame. The GUI now exposes methods to display a Container GUI, and allows windows to close. (GUI/GUI.cs, GUI/Window.cs)
* There is now a login gui, which includes a login window and a backdrop picture. (GUI/GUI.cs, GUI/LoginBG.cs, GUI/Login.cs)
* There is now a container GUI, which is comprised of a window which displays objects in a container. Very basic and ugly but it's a good place to start! (GUI/Container.cs)
* Updates to the xWinLib library: among other things, support has been added for custom buttons (used for inventory icons and the 'close' button in the container frame), and support for showing which control in a form is currently focused and will receive keyboard input (this only works for textboxes... soon I hope to add support for hitting enter or space to activate a button). Also you can now tab between controls (no support for ctrl-tab for backward tabbing yet).
Chase.XNA
Sorceror
I should hopefully be home Friday night, just have a bit of out processing to do this week then I'll be on my way! I definitely want to get back into coding, before I left I was working on other ways to do the rendering and I think I came up with a pretty fast and efficient way to do it that I never posted so I'll have to try and find that.
The big set back I ran into was applying hues within a shader, I almost had it working but no quite... I've done extensive work with the UO network protocol and know it very well. When I get home I'll take a look at what I got and let you know.
The big set back I ran into was applying hues within a shader, I almost had it working but no quite... I've done extensive work with the UO network protocol and know it very well. When I get home I'll take a look at what I got and let you know.
Poplicola
Sorceror
An idea which Jeff shared with me was to load the hue into the shader as a 1D texture.
To use this, I think we would then look at each pixel in the sprite and determine what the grayscale value is, and use each hue shade for (100/32)% of the grayscale spectrum.
Does that make sense?
[update]
As of 6/14, the interface graphics have been replaced by a new unified style.
To use this, I think we would then look at each pixel in the sprite and determine what the grayscale value is, and use each hue shade for (100/32)% of the grayscale spectrum.
Does that make sense?
[update]
As of 6/14, the interface graphics have been replaced by a new unified style.
Attachments
-
new-ui.jpg
Poplicola;803543 said:
It's a lot easyer than that becouse we will be working with floats raging from 0.0f to 1.0f and not integers
And 1D textures are not good, this way we would have to sort tiles/statics/items per texture and hue, becouse we would have to change the hue texture even when the texture is the same.
The best solution is to load the hues in one 2D texture and calculate hue cordnates in it.
I'm downloading the source code now, I'll take a look at it.
Poplicola
Sorceror
Ocelet, the code you're looking for will be in:
TileEngine\TileEngine.cs (Sends objects to SpriteBatch3D to be queued for drawing)
SpriteBatch3D.cs (Draws the objects)
Shader.fx (The pixel shader)
r21 is up!
* Updated GUI graphics to new unified style.
* GUI now uses Ultima cursor by default.
* Container.cs now draws item icons with the new unified style.
* Fixed a bug where containers in the game (such as bookshelves) did not
properly expose their container object and would raise an exception when the
server tried to add items to them. ( Issue 8 )
* Occasionally, the client would run out of room when decompressing large
packets. To fix this problem, I increased the maximum packet size in
SocketClient.cs. ( Issue 9 )
TileEngine\TileEngine.cs (Sends objects to SpriteBatch3D to be queued for drawing)
SpriteBatch3D.cs (Draws the objects)
Shader.fx (The pixel shader)
r21 is up!
* Updated GUI graphics to new unified style.
* GUI now uses Ultima cursor by default.
* Container.cs now draws item icons with the new unified style.
* Fixed a bug where containers in the game (such as bookshelves) did not
properly expose their container object and would raise an exception when the
server tried to add items to them. ( Issue 8 )
* Occasionally, the client would run out of room when decompressing large
packets. To fix this problem, I increased the maximum packet size in
SocketClient.cs. ( Issue 9 )
Ok, here it is, It seens to be working, the only thing I noticed is that it is a little darker than the UO Client itself but it seens to be getting the right hue, and I only added hues support to your client, but I didn't changed any network or mobile code, so right now it is hueing the mobiles using the fixed hue you set on Unit.cs
The hues are stored in one 32x4096 texture and the Y offset is calculed in the Pixel Shader based on the Hue Number, the Shader now takes two textures, the texture for the object/terrain being rendered and the hue texture. By using one big texture for all hues we don't have to bother sorting the objects based on hues and don't have to change any rendering logic, just have to add our new information to it, adding this information was the hard part.
I had to make a big change to your client, the VertexPositionNormalTexture wasn't good enough for hueing, so I create a custom vertex format called VertexPositionNormalTextureHue, it has a new Vector2 field called Hue.
This field is used to tell the shader the Hue number in the X field and if it's a partial hue in the Y field, if the Y field is anithing other than 0 it's treated as a partial hue.
You have to set the Hue field to Vertex2.Zero anywhere you dont want to use a Hue, you will see I've done it everywhere I didin't had the hue in the Update method of TileEngine.cs
So now it's up to you to get the hues sent by the server and add hues to the Statics/Items, it's easy now to add hues anywhere you want.
I don't know how to send the changes through google code so I attached it here, in the zip you will find the project and a copy of the changed files so you can winmerge then.
The hues are stored in one 32x4096 texture and the Y offset is calculed in the Pixel Shader based on the Hue Number, the Shader now takes two textures, the texture for the object/terrain being rendered and the hue texture. By using one big texture for all hues we don't have to bother sorting the objects based on hues and don't have to change any rendering logic, just have to add our new information to it, adding this information was the hard part.
I had to make a big change to your client, the VertexPositionNormalTexture wasn't good enough for hueing, so I create a custom vertex format called VertexPositionNormalTextureHue, it has a new Vector2 field called Hue.
This field is used to tell the shader the Hue number in the X field and if it's a partial hue in the Y field, if the Y field is anithing other than 0 it's treated as a partial hue.
You have to set the Hue field to Vertex2.Zero anywhere you dont want to use a Hue, you will see I've done it everywhere I didin't had the hue in the Update method of TileEngine.cs
So now it's up to you to get the hues sent by the server and add hues to the Statics/Items, it's easy now to add hues anywhere you want.
I don't know how to send the changes through google code so I attached it here, in the zip you will find the project and a copy of the changed files so you can winmerge then.
Thilgon
Sorceror
remembered another two...
Layers.
Since paperdoll (and animation) layers work in an horrible way, why don't make them settable from server side, like some of the other improvements you are planning? So, that would be, the ability to add new layers (just a matter of settings once this setup is created), choosing a layer deapth, selecting what it can hide and what it is hidden from, and so forth...
this goes well with the totally custom files you said before, since it gives the ability to set the paperdoll to whatever you like...
Lights.
Lights in UO client cannot be hued, so one cannot have the "mystical torch that burns purple", but just a purple torch that casts light like anyone else. So, adding the hue information to lights might be a nice (yet cosmetical) graphic improvement respect the original client...
Layers.
Since paperdoll (and animation) layers work in an horrible way, why don't make them settable from server side, like some of the other improvements you are planning? So, that would be, the ability to add new layers (just a matter of settings once this setup is created), choosing a layer deapth, selecting what it can hide and what it is hidden from, and so forth...
this goes well with the totally custom files you said before, since it gives the ability to set the paperdoll to whatever you like...
Lights.
Lights in UO client cannot be hued, so one cannot have the "mystical torch that burns purple", but just a purple torch that casts light like anyone else. So, adding the hue information to lights might be a nice (yet cosmetical) graphic improvement respect the original client...
Jeff
Lord
Thilgon;803647 said:
All these suggestions would require modification to the server as well. I would suggest getting everything working the way it currently work, then leave it open for the ability to change those ways later. It would suck to not be able to use the client because you needed RunUO core/script changes just to use it.