Custom Ragnarok Online Client

[Shinryo]

I'm currently working on a custom client and wanted to share some screenshots about the progress. Some of you might wonder why there is again another project like this one with the same goal as the others, and why not just join the others to speed up development? In fact, I thought about this opportunity. However, I'm still learning to work with virtual reality and I want to learn as much as possible. And that's why this projects main goal is not to be finished as fast as possible. But still, it looks like I'm at good pace.

I still don't have a "good" name for this project, even though there's a proto-name. One of the other goals of this project is to provide a stable client that runs on both, unix and windows systems.

It is being developed in C/C++ and Ogre3D, takes advantage of multithreading where it is appropriate, uses atlas textures to reduce batch count and some other fancy algorithms to improve performance. Even though the complete terrain is being loaded instantly, it takes some milliseconds to finish the objects. That's why I'm currently working on further algorithms, allowing caching and paging of objects. I will release

a working demo in the style of RagCam as soon as the new algorithms are finished and working.

Here's a list of things that are implemented so far:

GND (Terrain)

• Lightning
  
• Shadowmaps
  
• Colormaps (with reduced colors to match the original client)
  
• Vertex diffuse color
  
• Walls
  
• Smooth Normals
  

RSM (Objects)

• Smooth Normals (with smooth groups)
  
• Animations
  
• Transparency
  
• Two Sided Triangle Faces (with correct normal vectors for both sides)
  

RSW (World)

• Water (with texture and wave animation)
  
• Objects
  
• Ambient and diffuse lightning
  

Performance is always a very important part for me. A lot of things are optimized as good as possible. This project will stay closed-source providing plug-in functionality in the future. Most of the information that has been used in this project has been discovered through reverse engineering of the original client. Rendering a map is almost completely done using the same and some improved approaches done by the original client itself. The main focus after this will be the visual improvement of the maps themself, like BumpMapping, Cel Shading support, etc. blah blah. When this is done also, I will focus on implementing network functionality and a GUI.

I have started in november and worked effectively 5-6 weeks on this project. I had to stop at the end of december and started to work again two days ago.

Enough talked, here are some screenshots using OpenGL as renderer (the results in DirectX are the same):

Vertex color mapping:

Each tile can have a diffuse color. This color, however, is not being applied to all four corners of a tile, but only to the bottom left vertex and all vertices that share the same coordinate.

Textures have been disabled in this image to show that diffuse colors are being applied correctly.

The border of a map is also being rendered correctly when vertex diffuse colors are applied.

Shadowmaps:

Some devs are still wondering why their shadowmaps look a bit weird. The reason is plain simple:

A lightmap consists (most of the time) of 8x8 tiles, where only the 7x7 pixels in the center are used. Nothing new. However, the tiles are combined into

a large texture. If texture filtering is being applied, then the borders of the different textures interpolate into each other, fatal for colormaps when they

have different colors. This is called texture bleeding. Because of this, Gravity added a padding of 1 pixel to each tile (resulting in 8x8, instead of 7x7)

and filled them with colors that still look nice when they are interpolated.

The image below shows the correct display of shadowmaps.

Colormaps:

They are the same as shadowmaps, but use RGB colors instead. When applied to the terrain, they look smooth. If you look into a dungeon, you will notice

that colormaps are not smooth at all. In fact, they look like the colors were reduced. This process is also called posterization.

The best result are done with 16 levels. The idea is basically to use float colors, multiply them with the amount of levels, convert the result to an integer (and so dropping the decimal part) and divide the result by the amount of levels. Done.

This image displays correct colormaps. Notice the borders of the lightning.

Prontera indoor:

Transparency:

I've used BrowEdit to compare my results and found an issue that was the same as in my project. Some models had wrong depth writing. Using the correct order, it is possible to render objects

regardless of their transparency. You can try to open BrowEdit and compare dicastes01 with this image.

Instancing:

A lot of objects in a map reference the same model, so it makes common sense to combine them for reducing the batch count. This image shows

pretty could FPS, even though all objects of yuno are rendered.

Instancing in prontera:

I would also like to show animations, but am too lazy to upload a video.

I am not generating MipMaps yet, since this will be part 2 of this project. As you can see from the screenshots, rendering itself is almost complete. Only some minor issues that have to be done.

If you want to see a screenshot of a specific map, don't hesitate to ask. I will upload one.

I let you guess which of the posted screenshots are made on linux and which on windows.

Edited January 25, 2012 by Shinryo

[Gepard]

This is absolutely awesome. I'm sure it will be a state of the art RO client when you finish it.

I'm a bit worried about closed source though. Being open source it would instantly gain enormous advantage over Gravity's clients, by being easy to mod, improve, customize. With closed source, it won't make much difference, unless you provide a really good plugin system.

I think the best solution would be to split rendering from networking and GUI. Even if you want to keep rendering part closed, freeing networking and GUI part would be absolutely sufficient.

Do you have any plans on securing this client or will this be left up to server owners?

[Shinryo]

Thanks!

I have been working and experimenting a lot with different plugin architectures (e.g. in WeeDiffgen), so that won't give any problems. I have indeed plans to isolate rendering from networking and everything else. The possibility to install hooks would be quite useful. As you may already know, there are also quite a lot of hard-coded effects (that are not really hard to reimplement) which are too many to implement them on my own. I will, however, implement a LUA supported "effect engine" so that others can help creating those effects too. The GUI will be based on XML layouts, allowing everyone to modify whatever they want. So yes, even though I will use closed source plugins, I will indeed release interfaces so that everyone can create their own implementations or install hooks to extend the whole system itself with no restrictions.

I'm not quite sure if it would make sense to provide full securing features, since they would be reversed anyway. But I will keep the possibility of creating a very simple skeleton, giving others the idea on how to implement packet encryption, grf protection, etc. on their own.

Edited January 25, 2012 by Shinryo

[xazax]

Awesome progress so far!

I like the concept of being multiplatform, and care about the performance. However I'd be happier if it would be opened up. But with a decent plugin system it is still enables much more flexibility than gravity's client. I hope this after so much dead RO client rewrite project, this one will be finished.

[KeiKun]

Gorgeous!

I Love when shin do exotic things. I wish you will continue this Project since its really Good to see Improvement with Client too. although your still thinking of a name for your project. Just Looking with the Screenshot. Its Really Wonderful.

[Arcenciel]

I hope to see this project finished and released. I've seen far too many projects that had great potential but just failed.

Good luck!

[CalciumKid]

When can I start using it? LOL.

Just make sure that you make an extensible lua table for packets. It'd be nice to actually map and view packets easily.

[KeyWorld]

Looks nice, better render than my engine (I don't support model opacity and animation to optimize the framerate).

Do you have this weird model in amatsu ? It's the only model with a weird position I have (I think other RO engine use a culling that skip it from render).

Why do I choose a low level API for my project ?... Maybe for the challenge lol...

Keep it up even if it's a bad thing to keep the source closed, I don't see the point.

[Shinryo]

Heh.. good catch. I have the same model there:

However, the solution is pretty simple. The original client uses a quadtree to improve culling performance. Each model intersects or is within at least one quadtree node. If a model does not belong to a node, than it won't get rendered at all. Basically, those nodes are bounding boxes. The client gets all those boxes that are within the viewing frustum. Afterwards, the client checks which models belong to which quadtree node and renders them. The object in the screen does not belong to any node and therefore shall not be rendered.

If you don't use a quadtree (or octree, whatever), then there is another simple solution: All quadtree nodes are (or have to be) within the xz-coordinates of the ground bounding box. So if a model has a position that is not within this range, then just don't render it.

[ngek202]

man another awesomeness from you hmm WeeRAClient?

[mrjnumber1]

This project isn't much better than Gravity's client if it stays closed-source IMO.

[Shinryo]

Mind to explain your opinion?

[Gepard]

Few more thoughts on closed source:

There are multiple parts of client that server owners would certainly like to improve, extend or customize:

• additional settings, preferences
  
• GUI changes and new windows
  
• new packets to support GUI changes
  
• security
  

This is just a very abstract list; a full list of ideas and improvements that I would do would be really long, and I'm sure there are much more creative people with great client ideas.

I'm afraid that closed source (even with plugins) will prevent at least some of these possibly great ideas to be implemented in your client. It would be lost potential.

Another things is reliability. Gravity client will be there forever, as long as RO is not dead. New features, packets will be added to it. Your client, being closed source and developed by - how many? 1? person, will not be a good choice due to high risk of project not keeping up with updates or even abandonded (not a disaster yet) and not being picked up by other people because no source is available (unacceptable for a server that needs to switch back to Gravity client all of the sudden, possibly being unable to use all additional features that players already got used to).

Not everyone would take risk of being dependant on you, when it comes to such a crucial thing - game client. I wouldn't, if it was a production server.

It might be a great client - with best performance, improved graphics, multiple OSes supported etc... like I said in previous post: "state of the art". Just make sure that piece of art has practical application.

And now, do you mind explaining why do you want to keep source closed? Open source would be really a natural choice here. Honestly, I'm a bit disappointed and suprised (I've heard it would be opensource, did you change your mind?).

[Shinryo]

The points in your list can be easily implemented with the help of a plugin system. I know how most of the users out there feel to have an open source client to add customizations to it. That's why I will focus to allow a lot of modifcations. However, as you might already read out from my first post, I don't hesitate to share the information that I have extracted from the original client. And these information are probably what most people are interested in anyway. So why am I still going for closed source?

Simple: If reduced down, there are two factions of people. Those which focus to implement the ideas you're talking about and those that will use this ideas and indeed make money from the work of others (most likely how it is with eAthena/rAthena). I don't see the point why the second faction shall gain all the money without doing anything. I am working with a lot of interfaces that allow splitting very easy. Basically something like this:

As you can see, those people with ideas can hook everywhere they want to extend whatever they want. They can even completely reimplement the closed parts and use it for whatever they want. Let's say if I have implemented a class that allows a sprite to run around, but someone wants a 3D character instead, he can write his own implementation and exchange it without changing any other parts. Some could even change the rendering engine from Ogre3D to Irrlich, if they want to. They just have to make sure to implement the given interfaces, which will be open source since they are only guide lines. You might still wonder what to do when some interfaces themself have to be modified. Well, I'll add the ability to hook the core which might be risky. But I assume that the one who wants to change one of the interfaces knows what he does, so that should not be a problem.

This ensures that those with gread ideas have the possibility to chose if their implementations shall be closed or open source (for the same reasons as I have) and those that want only money still have to do something on their own. And even if I drop this project, as long as the base is done and available, anyone else can still further improve it. Besides that, you don't really have to worry. If I lose intereset or stop working on any of my projects, I'm gonna release the source anyway. So when I shall disappear, I will make sure to release the source (as I will do with WeeDiffGen). The only problem that might come up is the fact, that only a small amount of people are willing to continue such a project as soon as it gets open sourced.

I hope you can understand this decision of mine.

[Gepard]

Sounds good and fair enough. Thank you for detailed explanation.

Besides that, you don't really have to worry. If I lose intereset or stop working on any of my projects, I'm gonna release the source anyway. So when I shall disappear, I will make sure to release the source (as I will do with WeeDiffGen).

That's reassuring

Do you have any estimates when various parts of client will be finished?

[xXAkatsukiUchihaXx]

Good Job.

[xazax]

Simple: If reduced down, there are two factions of people. Those which focus to implement the ideas you're talking about and those that will use this ideas and indeed make money from the work of others (most likely how it is with eAthena/rAthena). I don't see the point why the second faction shall gain all the money without doing anything. I am working with a lot of interfaces that allow splitting very easy. Basically something like this:

Well, the plugin system you proposed looks promising, if it will have a nice interface. I only wonder because, I think keep the source closed, but provide a plugin system does not mean, some won't make money from others work at all. Just instead of selling source modifications, they will sell plugis this time.

Anyways even if it is closed source, I would use it rather than gravity's client, being multi platform is a very important for me.

[Gepard]

I think the problem is not plugin authors making money (they actually do something), but server owners leeching off of them. If client was GPL'ed, everyone would have to release source code for their modifications. With closed source, unless there is some weird license, everyone will be free to write client extensions and sell them if they want (I guess?)

[Erazer]

Im up for Closed Source.

[yiming]

If you like open source then go help Open Ragnarok -> http://open-ragnarok.org/

Features:

All Maps, map change.

All Classes, class change.

All gears display including weapon and shield.

All Skills displayed including ground targeting.

All NPCs.

All Monsters with all animations and attackable.

All Items displayed on floor with pickup ability.

TODO:

No inventory display yet.

No equip window yet.

Screenshots here:

http://www.eathena.ws/board/index.php?showtopic=222832&st=15&p=1384883entry1384883

[KeyWorld]

If you like open source then go help Open Ragnarok -> http://open-ragnarok.org/

Screenshots here:

http://www.eathena.w...3

The screenshot is from Pantheon Online, an other open-source client (abandoned project), not Open Ragnarok.

Agree with Gepard, closed source with plugin doesn't avoid people to write their own plugin and sell them after - it's not a good reason for me.

By the way, good luck for your project.

[Gepard]

Agree with Gepard, closed source with plugin doesn't avoid people to write their own plugin and sell them after - it's not a good reason for me.

But why would you prevent that? It's actually a good thing, because project will more likely flourish with great variety of plugins/customizations (both free and paid) built around free base. More people would like to learn how to write for Shinryo's client if they're not forced to release everything for free.

That is one damn good point in favor of closed source.

[KeyWorld]

In my opinion, plugin system is just a veil to hide the bad "closed source" thing, nothing else.

1 - We can't do all things we want with plugins, they can't manage every things or hook every functions for complex modifications.

2 - If it's manage as his diffpatcher, do you really want a client with 50-60 plugins that generate 50-60 dll ?

3 - What about security ? Use the plugin system to ""cheat"" on some other pserver ?

4 - If there is a bug or memory leak, we have to report and wait for an update when it can be fixed quickly on a open-source client.

5 - We just have to trust the dev about the performance, security, ... when we have no idea about what he did with his code (keylogger, ...) (no offense to Shin).

[Gepard]

No, plugin system is there, because it's a required thing to convince anyone to using such a closed-source client. With no measures to customize it, nobody would use it. It's not to hide anything, but to make up for all the doors that closed source would close.

1. Probably. Time will tell. Everything depends on how well designed are interfaces Shinryo was talking about.
   
2. Is that a problem really? Opensource client modifications could be included in the client binary itself, but there's nothing wrong about dynamic libraries too.
   
3. How is that different from open-source? I assume source would be released on GPL license or similar, which forces everyone to provide source code too. Then it would be even easier to add or remove anything.
   
4. Yup.
   
5. All GRF patchers are closed source. Yet every server uses one of them.
   

I'm by no means advocating closed source for this project. I'm all for open source. But (depending on license) it will also have some drawbacks.

[Hayate Yoshida]

Wait are you hinting that there is gonna be a Linux version? Of course, provided you finish it.