Custom Ragnarok Online Client

[xXAkatsukiUchihaXx]

xD real-time rendering in games

[Shinryo]

No screens this time, but expect to get some with my next post.

I have finished orbit camera control today (even though it's pretty easy to do with ogre) and noticed something while I compared some old screens made with the orignial client and those screens made with my implementation. It looks like objects have a different angular area. Most applications use 45° - 60° for the y-dimension field of view. Ragnarok, however, seems to have 20° (gives almost identical results). However, I doubt they use 20°, but moreover 340°, which results in a verticaly flipped y-axis (sounds familiar, huh? probably a mistake made by Gravity a decade ago when they built the projection matrix with DirectX7). I don't have the desire to reverse engineer this part of the original client to be 100% sure, so did someone made already research in this area and can confirm my assumption?

Edited March 20, 2012 by Shinryo

[Maki]

Looks interesting Deleted the post as requested.

[GreenBox]

No screens this time, but expect to get some with my next post.

I have finished orbit camera control today (even though it's pretty easy to do with ogre) and noticed something while I compared some old screens made with the orignial client and those screens made with my implementation. It looks like objects have a different angular area. Most applications use 45° - 60° for the y-dimension field of view. Ragnarok, however, seems to have 20° (gives almost identical results). However, I doubt they use 20°, but moreover 340°, which results in a verticaly flipped y-axis (sounds familiar, huh? probably a mistake made by Gravity a decade ago when they built the projection matrix with DirectX7). I don't have the desire to reverse engineer this part of the original client to be 100% sure, so did someone made already research in this area and can confirm my assumption?

I think that this can help: http://pastebin.com/VBrm7M9j

[Shinryo]

Your snippets seems to contain only sanity checks for the camera related to distance and latitude/longitude. The function name CRenderer::SetSize sounds confusing, but seems to contain the code for the matrix.

Edited March 31, 2012 by Shinryo

[Shinryo]

I have finished with an algorithm that allows me to create a raycast from the mouse into the terrain to find out on which cell the mouse currently is over (splitting the cells up into bounding boxes, up to the root node). Thanks to KeyWorld for some hints! Basically, there is almost no performance decrease with this algorithm. Besides that, I have worked more on the camera control and have finished it completely. This means the camera behavior is now exactly the same (and even better) than the original clients camera.

I have also finished a normalmap generator to apply bump mapping. I have applied them only to the ground yet. And since I have promised to post some screens the last time, here they are (models and shadows are hidden for debuggin purposes):

Testmap without bump mapping:

http://www.abload.de/img/screenshot04202012_1961kdk.png

Same testmap with bump mapping:

http://www.abload.de/img/screenshot04202012_19l9d7q.png

Prontera field:

http://www.abload.de/img/screenshot04202012_234ei0c.png

Hugel:

http://www.abload.de/img/screenshot04202012_23d5dvf.png

I'm stil working on the shader, so there will be some improvements in the near future.

[Maki]

Is it me or does the resolution look tons better compared to Gravity's client? Not to mention the 1200 FPS =p

[KaitoKid]

Looks great!

Keep up the good work!

Looking forward to this project

[JayPee]

Nice... Looks it looks better

[Syouji]

Very impressive! Nice work Shinryo. I can't wait for the client to be released. Will be awesome!

[Shinryo]

Thanks!

Here are some further screenshots, I'm not yet satisfied though:

Izlude:

http://www.abload.de/img/screenshot04252012_001ha6c.png

Rachel:

http://www.abload.de/img/screenshot04252012_000totr.png

Comodo:

http://www.abload.de/img/screenshot04252012_00b3o0e.png

Dicastes:

http://www.abload.de/img/screenshot04242012_21x0rx6.png

Bump mapping has quite an impact on the frame rate. I'm actually thinking about a toon shader. Any opinions?

[Maki]

Rachel looks really impressive now, infinitely times better then the current client!

Toon shader = cell shader? Meaning like this: http://2.bp.blogspot.com/_cBaSt0V-3s4/S_UlePEu91I/AAAAAAAAA34/Xqv45AzELcc/s1600/toonshaderexample.jpg or

If so, I'd love to see an example of what you mean/how it would look /me loves cell shading.

[Olrox]

MARVELOUS!

Incredible, I can't say by words how amazed I'm haha.

Congratz, you are really skilled, all of your work are incredible. But I'm totally amazed with this one. I was very impressed with the -bump mapping- and all the improvements... it is like playing a High Definition RO.

I'm kinda curious to see how some one or other map that I have, would look with such a great client engine like this one haha, they would gain another life for sure. But I know it is not possibe.

For now I'm just thankfull with you to allowing us to see those screens and the progress of this amazing work. Thanks really.

[Shinryo]

Thank you! You can send me a map and I can load it up to make some screenshots, if you wish. Or you can wait until september, where I plan to release a binary build and the source code.

[Nameless2you]

Have to say 1 thing.

OMG shadow on objects o_o, it's a big miss on gravity's part for not having that but I see some of it in the last screenshot on eldicastes01 and I like it, a little dark so I think I understand why you dislike it or are simply unpleased.

Great to see you still here and posting updates, appreciate that a lot, however sad to see you go to tera )':

I hope you'll still lurk around every now and then

[Syouji]

Is the sky feature available in your client? If so, can you please show us an example. If not, can you tell us what route you will be pursuing on this matter?

[Shinryo]

@Maki:

Yes, I mean Cel Shading. It might become tricky though, since the textures have not been designed for this case.

@Syouji:

No, I haven't added this feature yet. However, I won't hard-code this into the client as Gravity did.

@Project:

I've been improving the lightmapping of my client today and did some research with the original client. As far as I can see, Gravity had problems with getting the lighting correctly themselves. That's why it is indeed a bad idea to re-implement the same buggy behavior. Furthermore, I found out that the level of my posterization filter was off by one. So the correct level is 17.0f - 1.0f (or 16, whatever). The confirmation was done with a reduced diffuse color in comodo which displays only the colormap (which is not affected by global lighting). Furthermore, I have removed all dynamical lights from comodo and saw how some object still had light affecting them. Like in this example:

http://www.abload.de...ero002qvl1b.jpg

I haven't found out where the blue color on the trees comes from. Diffuse colors were set to 0.1f with a black ambient color. Here's also a screen with weird shading:

http://www.abload.de...ero0038molg.jpg

Take note that dynamical lights (those in the RSW structure) were removed. And just for your interest: As far as I have tested, the lights in the RSW structure only affect objects, not the ground.

I have also added an option to disable posterization if needed. I think the client looks better without it:

http://www.abload.de...012_00ovorc.png

Edited April 26, 2012 by Shinryo

[CrescentSaga]

See the apple on my avatar picture??

That's how i looks like when i saw pictures from your client

[Maki]

@Maki:

Yes, I mean Cel Shading. It might become tricky though, since the textures have not been designed for this case.

I cannot wait to see how it would look cel-shaded! I hope you get it to work *-*

[Mystery]

I wonder how the client is going to work with all these different packets and packet versions o_o

[Itako]

I really hope the networking part of the client will be highly customizable or even fully replacable.

This would allow people to rewrite the server in their language of choice and thus changing the very mechanics of RO with ease.

No offence to eA/rA devs, but the current source code is pretty ugly and unorganised mainly due to number of people that had been working on it.

I'm not even going to mention how messy packets are, but that's just gravity's fault.

So anyway - good luck with your project, Shinryo. Everyone's looking forward to seeing the results.

It surely will benefit the RO community.

[GreenBox]

I wonder how the client is going to work with all these different packets and packet versions o_o

the client doesn't have to support all packets, it need's just one packet version

[Shinryo]

Thanks for your interest in this project!

@Maki:

I will definitely add cel shading, but it has to wait until around september. I have a schedule for this project which I have to complete first.

@Mysterious:

I don't plan to support all available packet versions until now. The best solution is to support the most recent packets, based on the state of this client and let macro directives handle the current active version, most likely how it actually is with rAthena. However, the architectur will be different. Meyraw had a pretty nice idea. Each packet was defined as a struct, containing all relevant packet information. Something like this:

struct packet_0x111
{
  unsigned short cmd;
  int index;
#if PACKET_VER 20120101
 char blah;
#endif
  ....
}

The packet above is made-up and and doesn*t exists, btw.

@Project:

It actually becomes interesting, because I have started to implement further stuff besides the rendering. I've started with sprites and their animations and I can't believe that it took a whole day to find an acceptable solution for rendering the sprite billboards.

As you may already know, billboards always face the camera. But what happens if the latitude of the camera changes and you're near a wall/object? Right, the billboard will be clipped by the wall. Something like this will be the outcome:

http://www.abload.de...012_22j0yyy.png

When you look at the original client, it looks like this:

http://www.abload.de...ero0053jy5v.jpg

My billboard obviously is clipped. The original client has some kind of evil magic to let the sprite be always on top of these objects (well, not so magically, but ugly). However, the best workaround I have come up so far is to modify the z value of the billboard vertices based on the camera angle and the distance from the camera to the sprite. It's not exactly the same way how Gravity does it, but it's still pretty satisfying.

Here's the outcome:

http://www.abload.de...012_21jfluw.png

Here's some code how it could be implemented in a shader, if needed:

out.position = mul(worldViewProjMatrix, in.position);
out.position.z -= latitude * 2.5f / distance(out.position, cameraWorldPosition);

Latitude is between 0° and 90°. The constant 2.5f has no magic behind it. The output looks better with it. Don't forget that the operation above should only be made for the upper vertices, since you might get in trouble if there is only a plane behind the character. You might end up the same way as the original client:

http://www.abload.de...ero00728ja5.jpg

With my client:

http://www.abload.de...012_23d8e5k.png

If someone needs further information, don't hesitate to ask via PM.

Concluson:

My solution seems to be faster and looks better then the originals. There is also no distortion with high angle views. I'm pretty satisfied.

Edited May 6, 2012 by Shinryo

[KeyWorld]

Interesting post, I was looking for this billboard hack for a while, I didn't find a way to figure it out.

So thank you for the tips !

Happy to see the progress

[Rikimaru]

Really nice,gonna wait for more Updates.