Leaderboard

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.

Shin's Diff Patcher Info: Supports all Windows 32 bit versions (Windows XP SP2 and higher) and probably all 64 bit versions. Features: Plug-in based Uses list view instead of two seperate list boxes for easier selection Shortcuts to simplify your work Resizable window Inline diff descriptions (as long as the plug-in supports it) Auto-save and load of diffs Includes PlainDiffPlugin which provides support for *.diff files Allows items to be sorted either by type, group or diff name Prevents diff collision when selecting diffs that reference the same group CRC file check Data missmatch check Downloads: ShinsDiffPatcher SVN (Version 1.1.3b; 198kb) WeeDiffPlain Plugin Src SVN (Version 1.0; 11kb) Quick Usage 1. Select patch engine. 2. Select client exe. 3. Select diff file (if plug-in needs it). 4. Select output exe. 5. Click on "Patch It!" 6. Done. All patches that you have selected are automatically saved and will be restored the next time you select a diff file. You can also use the following shortcuts: - Ctrl + A = Select all diffs (only one item from each group if any) - Ctrl + D = Deselect all selected diffs - Ctrl + C = Copy all selected diffs into Clipboard Notes: You may think "What? Another patcher? Man..". Yes, another one. I'm not quite satisfied with the currently available diff patchers because they either lack of features or just don't provide the freedom I would like to have. I think I have chosen this name for the patcher because it's kinda convention to use his own name in the title bar (even though the initial name is WeeDiffPatcher). This is just an alpha release since there are some optimizations I would like to complete before I release a final version. I've included the source code for the DiffPlainPlugin to show you how you can implement your own plug-ins in order to get them working with my patcher. I would still like someone else to implement a proper plain diff plug-in because I haven't focused to optimize it to it's best (even though I have removed all possible memory leaks) since I developed this patcher for another plug-in based solution. If you have any suggestions or features that your plug-in needs in the future, don't hesitate to ask.

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.

Would it be possible to take the latest set of data files and treat them like the SVN? It's very difficult to find complete and accurate data files expecially with all the different versions of RO out there. I suggest you add it to the svn as its own section and then removed anything from the files that doesn't realate to rAthena such as other versions of skill names... It wouldn't be all that big for the basic files, but it would make an accessable area for all to go. I give much credit to the few people who are currently trying to keep them up to date, but with so many versions, who really knows which one is the most accurate. We need one specific to rAthena and it would be something that nobody else is doing YET! Thanks. Peopleperson49

Okay, here i'll provide some informations about branches/bs-coreoptimize. I just set up several milestones i want to reach in the future. The most of them are performance optimizations, as well was cleaning up messed up stuff (messed up == (crappy / unusable | usability fail). ) I'll try to keep the branch runnable / compileable the whole time, but you've been warned - the branch is not proposed to use in production environments - due to heavy changes in several essential subsystems. Every "completed" Milestone will be announced and after some testing (i'll probably tag it so you can give feedback before its getting applied to mainline.) will be merged back 'down' to trunk (and probably upcomming versions / branches...). So here's the List: #1 Milestone Core Related Add Threading Abstraction (Windows / Linux / BSD) Add Synchronization Abstraction (Windows / Linux / BSD) Add Atomic (CAS/ADD/EXCHANGE) Abstraction (MSC/GCC on x86 and x86_64) Add Generic threadsafe Memory-Pool implementation for preallocation (with asynchronous reallocator) to guarantee a fast / cost effective on demand allocation and reduce the memory fragmentation during runtime. Add generic 'athenastyle' configuration parser (to get rid of (n)x fscanf based parsers in every app.) this version is also 'improved' by allowing ini style declaration and comments, as well as Sections. Improve timing source (gettick) ~ Improve accuracy ~ Reduce overhead ~ Redcuce syscalls (On 32bit releases: Add warning/hint that the tickcount will overflow all ~24,8 day to restart the server before that happens!) Add IOBuffer subsystem (threadsafe / for new network subsystem) Add new Network subsystem to replace old 'socket' stuff ~ Improve Performance ~ Reduce Latency Using platform specific API's: Windows => IO Completion Ports (overlapped stuff Linux 2.6.9+ => epoll FreeBSD => kqueue other => select (as fallback) ~ More details when its getting implemented Add asynchronous workers (so stuff can be done in threads) For example: handling npc SQL querys async. so it wont block the server anymore. (Script will be yielded until result's got back from SQL/Worker thread.) Build / Release Related [T] Autoconf (configure): choose 64bit build by default, when building on 64bit platform. (So --enable-64bit will be dropped, and --disable-64bit will be added to enforce 32bit build in/on 64bit environments.) [T] Autoconf (configure): add LTO (Linktime Optimization) detection / support for newer gcc / binutils versions. Autoconf (configure): drop --enable-rdtsc (when new timing source / method gets implemented) Reading / using the tsc counter as time source is unsafe when running on older cpus or under several virtualized environments .. Autoconf (configure): (gcc platforms) due to changes done with atomic operations, require at least i686 (which is an old Pentium PRO or K6-III ..) Autoconf (configure): add --with-maxconn option to override the default max conn limit of the new network subystem (defualt: 16384) [T] Makefiles: cleanup build output (convert to kernel style build output.) [T] Makefiles: cleanup core dependency handling in subprojects (such as loginserver or charserver..) ~ by generating the common(core) as a static lib (ar) and link the subprojects against it. [T] Makefiles: cleanup core header file dependencies in subprojects, simply require all core/common headers. VC10: Cleanup / recreate the Solution ~ Building common(core) as static lib as well as the 3rdparty deps and link all subprojects against it. ~ Add 64bit target support for Windows platforms. Generic / Other Replace binary ZLib disitribution for windows with source (to be able to produce 64bit windows binarys). Replace / Update MySQL distribution from 5.0.20 to 5.5.x 32bit as well as 64bit (to support 64bit windows binarys). Color Legend: Green Text => Finished Tasks Red Text => Dropped Tasks (due to incompatibilities or such..) Prefix / Symbol Legend: [T] => Merged/Applied to trunk (feature available @ trunk) I'll keep you posted .. You can reach me via PM or IRC (irc.rathena.org #rathena / Nick: Sirius_Black) Florian

- script DAYNNIGHT -1,{ OnClock0600: announce "Good Morning Intel Ragnarok Players",bc_blue|bc_all;; end; OnClock1800: announce "Good Evening Intel Ragnarok Players",bc_blue|bc_all;; end; }

I could help a bit when I get home

Die wohl wichtigesten Unterschiede sind: 1. Ein funktionierendes Forum. 2. Der Emulator wird entwickelt. 3. Implementierte 3rd classes. 4. Eine aktive, freundliche Community. 5. Mitspracherecht für die User. (Hat bei eA schon mal jemand nach deiner Meinung gefragt?) ... und noch vieles vieles mehr. Wenn du dir mal unsere SVN-History anschaust wirst du sehen, dass rA im Grunde kaum noch mit eA zu vergleichen ist. Aber ich will ehrlich sein. Da es so viele Baustellen gibt, ist es schwer alles sauber umzusetzen, daher gibt es hier und da auch noch kleinere Bugs. Das relativiert sich aber auch wieder, wenn man sieht, wie schnell Busg bei uns bearbeitet und behoben werden. Hier noch eine kleine Zusammenfassung des letzten Monats: http://rathena.org/b...nthly-digest-1/

What Paulinds pointed out is true. The old command system lets you disable charcommands or set the minimum level. With the new system, we are unable to do the same. I suggest implementation of this feature. All in all, I'm starting to like this new command system, easy to setup but due to what I mentioned above it restrains me to fully like the system.