I do not work on it anymore! Its development has been continued a bit recently by Drakia. You can find the code at:
http://code.google.com/p/titanfiesta/

Do not ask me for help for any aspect of it including compiling, because I won’t give it, I do not work on this project any more.

There are simple instructions provided here: http://titanfiesta.wikidot.com/basic:compile

Thanks for no longer annoying me.

Here is a beautiful picture for you to enjoy:

R3E Revision 3

The thing I do rather like about my engine is how easy it is to use, this scene was created with just the following code:
mPlayer = new Player();

mPlayer->SetSkeleton("3DDATA\\AVATAR\\MALE.ZMD");
mPlayer->SetAnimation("3DDATA\\MOTION\\AVATAR\\EMPTY_RUN_M1.ZMO");

mPlayer->SetItem(ROSE::IT_BODY, 2);
mPlayer->SetItem(ROSE::IT_FOOT, 2);
mPlayer->SetItem(ROSE::IT_ARM, 2);
mPlayer->SetItem(ROSE::IT_HAIR, 1);
mPlayer->SetItem(ROSE::IT_FACE, 2);
mPlayer->SetItem(ROSE::IT_WEAPON, 1);
mPlayer->SetItem(ROSE::IT_SUBWPN, 1);
mPlayer->SetItem(ROSE::IT_BACK, 223);

mScene.AddEntity(mPlayer);

Yay.

Code is available at http://code.google.com/p/r3e/

The googlecode page for it can be found at http://code.google.com/p/r3e/ and the svn at http://r3e.googlecode.com/svn/trunk/.

This 3D engine is designed in a way which is optimised for rendering with OpenGL, incase you wonder why I do odd things.

I hope to update it to the point of being able to display everything and anything from ROSE in 100% accuracy (that will be fun when it comes to effects and particles…).

Currently, although the code base is very large at the moment, all that is supported is rendering simple meshes (.ZMS files), the next feature I plan to support is using .ZSC files and then on to using skeleton (.ZMD) and animation files (.ZMO) to provide a full animated render of ROSE NPCs and Characters. How exciting.

Once the engine gets to that stage I will code a few simple things such as the Item Viewer which was included with the old R3E.

Currently I am not offering binary builds of the engine as there is not much to show, if you are interested in those then expect them some time in the near future.

Note: Sorry if you get lost when looking at my code, it has 0 comments (excluding commented out old code). Maybe one day I shall consider commenting it .

The first boring bit is creating the window and all that rubbish, so I have decided to go ahead and do that for you and create a very basic framework from which we will work off of. This framework includes creating the OpenGL window, a few math classes such as support for Matrices and Vectors and a Camera class. This leaves me to focus the tutorial on uses OpenGL to render the items as the code mentioned beforehand is not really anything new or special to ROSE and can be found anywhere.

So if you download my basic framework and compile it you will see that there is just 3 axis lines which you can move the camera around using the right mouse button with dragging to rotate and the mouse wheel to zoom in and out. This is not very pretty at all! So we shall now focus on loading ZMS, the ROSE mesh files, into this application.

The file format for ZMS can be found here: ZMS File Format

It is pretty simple to load this into memory, the only trick is using the bone lookups. At the beginning of the file there is a list of bone indices, these are the actual bone index of the ZMD, the ROSE skeleton files, I name it the ‘bone lookup’ list. The BoneWeights for each vertex actually reference an ID in the bone lookup list. Here is an example: the first bone for a vertex would actually be boneLookup[boneWeight.id[0]] for the correct index in the ZMD file.

There are multiple ways to render this model, I use things called Vertex Buffer Objects which actually upload the model data into your graphics card and uses the RAM on it to store the data there. This is much faster as the vertex data does not get sent every frame. Unfortunately to use VBOs we must use OpenGL ARB extensions which makes our code a lot messier . The required functions are: glBindBuffer, glGenBuffers, glBufferData and glDeleteBuffers for clean up.

To load these extensions we have to call the function wglGetProcAddress (when on Windows), and example for glGenBuffers:

PFNGLGENBUFFERSPROC glGenBuffers = (PFNGLGENBUFFERSPROC)wglGetProcAddress("glGenBuffers");

The type PFNGLGENBUFFERSPROC is defined in gl/glext.h which is an include which should come with the OpenGL headers which can be found in the windows sdk.

There are two types of buffers I use, Vertex Buffers and Index Buffers, the difference is Vertex Buffers store the per-vertex data such as position, UV coordinates, colouring, normals etc whereas Index Buffers store the face -> vertex links. ROSE ZMS files are defined with a list of vertices and a list of faces which reference those vertices. These faces -> vertex references are loaded into and index buffer and used to draw faces from the list of vertices.

I also created two helper functions for creating Vertex Buffers and Index Buffers:

GLuint CreateIndexBuffer(void* data, unsigned int size){
	GLuint buf = 0;
	glGenBuffers(1, &buf);
	if(!buf) return -1;
	glBindBuffer(GL_ELEMENT_ARRAY_BUFFER, buf);
	glBufferData(GL_ELEMENT_ARRAY_BUFFER, size, data, GL_STATIC_DRAW);
	return buf;
}

GLuint CreateVertexBuffer(void* data, unsigned int size){
	GLuint buf;
	glGenBuffers(1, &buf);
	if(!buf) return -1;
	glBindBuffer(GL_ARRAY_BUFFER, buf);
	glBufferData(GL_ARRAY_BUFFER, size, data, GL_STATIC_DRAW);
	return buf;
}

As you can see these take two arguments, data and size. The data should be an array of the vertex data, this is not only vertex positions but also uv maps, normals, colours or any other per vertex data you would like to send to the graphics card, to render from these buffers you can use the glVertexPointer and glDrawElements calls.

As mesh rendering now works at this point (I am writing the code as I write the tutorial) I come to the problem of texture loading, this requires an external library as we are loading DDS files which are not natively compliant with OpenGL! I use the DevIL library which I have always found to be reliable and work with the ROSE textures.

With an addition of loading images from DevIL and using glTexCoordPointer we can now render the textured ZMS:

ZMS Texture Render

As the first part of this ‘tutorial’ comes to an end I realise this is either 1. a really shit tutorial or 2. not really a tutorial at all. There is the bare minimum of explanation here, it is more of a source code release with a slight explanation. I apologise for this, but maybe once this rendering engine is complete I can make a nice item viewer and people will use that rather than read this ‘tutorial’ .

Coming up in the part 2: using the ZSC files to render full models!

Edit: Sorry I forgot the source, you can find it here: Rendering ROSE Part 1

I have only been back for one day and have already done some very exciting never before done things I have just finished coding up the system to load and save achievement data server side to MSSQL and to send it to the client, here is a kind of unexciting picture showing the client displaying the achievement data sent to it from the server:

Server Side Achievements

Previously, at Ruff-Rose, achievements were stored and unlocked client side so was pretty rubbish and unsecure and would require you to use the same computer every time, now they are loaded server side when the player enters the game, checked every 5 seconds to see if the player has unlocked any new achievements and saved when the player quits the game. This also gives us more control and allows us to do things such as display an animation to all players when someone has unlocked an achievement, the effect shown below was created by Razor:

Achievement Unlocked!

Very exciting things are happening at titanROSE and expect alot of good news coming soon, the website and vault are very close to completion, I cannot wait to show off mine and Dae’s hard work on the vault, I am very proud of it .

Anyway this was just a quick update and I will look at posting more tutorials shortly .

It works in the way that every class and its functions are defined in my library, I also have one function which must be used before all others (RoseAPI::Init()) this function goes through every class member functions and rewrites the first bytes of them to a JMP to the original code using my function ‘FixMemberFuncAddress’.

template<class T> void FixMemberFuncAddress(int troseAddr, T func){
	CodeHook::ApplyJmpHook((unsigned char*)(*((void**)&func)), (unsigned char*)troseAddr, 0);
}

The crazy recasting of func is to get around the fact that you cannot convert a member function pointer to a memory address directly so I used the redirection shown above to get around this compiler restriction.

There was one more challenge to handle though, rewriting constructor and destructor addresses, so far I only have a need for constructor so I did not bother with writing a handler for them. The reason this was a challenge is because in the c++ specification it is stated that constructors are not functions, not physically existent and thus you cannot get their address. Well, fuck the standards, we don’t want any of that shit. So I declared it was time for a workaround!

This is where my code gets dodgy and I highly recommend you use my .lib file and do not attempt to recompile the lib as this constructor code is based on the final assembly generated and it will differ between compilers.

First step was making a small function which just creates an object:

void CSlotCreator(){
	CSlot* slot = new CSlot();
}

The next step was to write a function which reads the assembly generated for this small function and attempts to get the address of the constructor, I found two types of constructing, one which used a CALL and one which used a JMP to go to the constructor, both are able to be processed in my code.

void FixConstructorAddress(int addrROSE, unsigned char* createFunc){
	unsigned char* addr = createFunc;
	if(addr[2] == 0xE8){
		for(int i = 0; i < 0x20; ++i){
			if(addr[i] != 0xE9) continue;
			int relAddr = *(int*)(addr + i + 1);
			int cAddr = (int)(addr + i);
			int ctorAddr = cAddr + relAddr + 5;
			unsigned char* codePtr = (unsigned char*)ctorAddr;
			DWORD oldProtect;
			VirtualProtect(codePtr, 5, PAGE_EXECUTE_READWRITE, &oldProtect);
			codePtr[0] = 0x8B;
			codePtr[1] = 0xC8;
			VirtualProtect(codePtr, 5, oldProtect, &oldProtect);
			CodeHook::ApplyJmpHook(codePtr + 2, (unsigned char*)addrROSE, 0);
			break;
		}
	}else{
		addr = addr + 0x30;
		for(int i = 0; i < 0x20; ++i){
			if(addr[i] != 0xE8) continue;
			int relAddr = *(int*)(addr + i + 1);
			int cAddr = (int)(addr + i);
			int ctorAddr = cAddr + relAddr + 5;
			unsigned char* codePtr = (unsigned char*)ctorAddr;
			DWORD oldProtect;
			VirtualProtect(codePtr, 5, PAGE_EXECUTE_READWRITE, &oldProtect);
			codePtr[0] = 0x8B;
			codePtr[1] = 0xCE;
			VirtualProtect(codePtr, 5, oldProtect, &oldProtect);
			CodeHook::ApplyJmpHook(codePtr + 2, (unsigned char*)addrROSE, 1);
			break;
		}
	}
}

So as you can see, it reads the bytes until it finds a JMP or CALL and then reads the address to the constructor, once this is done it rewrites the first bytes of the constructor to MOV ECX, ESI or MOV ECX, EAX (depending on CALL or JMP style) then JMP to the original TRose constructor! Hurray, that was fun.

Download the code and library here: TRose.lib.

As many of you are aware now titanRose has been started once again, this means one hell of a work load and thus a lack of time to do anything on this website! In my last post I mentioned Project Colossus and that is titanRose, if you google ‘define: titan’ colossus is the first word that comes up hur hur that was fun.

What am I doing that takes so much time you may ask, well Dae and I are working on titanVault, it is a very large web project coded in PHP and the database in MySQL. Most of the database is generated by a C++ program which reads many files from the ROSE client and generates a complex source of information on everything ROSE.

The titanVault can be seen as our version of World of Warcraft’s Armoury, as we are not only showing game data but also player data, it will show off players items, stats and achievements but for those who want this to remain hidden there are options to do so.

I am very excited about this as no one has done anything similar for ROSE before, it will be very cool and is progressing very quickly, I can’t wait to show it off to everyone . To show you how much work we have done, here is a beautiful graph:

TitanVault Lines of Code

I personally have wrote 9807 lines of code (76.4%) and Dae 3023 lines of code (23.6%), he needs to pick up the pace!

Here is another graph I found amusing, it shows what time of the day we did commits, notice the low levels around lunch time and dinner time .

TitanVault Activity Time

And you probably want some more statistics:
Total Files: 132
Average File Size: 51.9 lines
Average Revisions Per File: 4.3

I am going on holiday for 1 week now so Dae has plenty of opportunity to catch up with me!

Bye

You can download the library and source code to it here:
http://tgamectrl.exjam.co.uk/tgamectrl.lib.zip

I have also produced a kind of documentation with doxygen, there isn’t much detail in there but it lets you see all the classes in the library with relative ease
http://tgamectrl.exjam.co.uk/

Later I shall release a little tutorial on how to use it .

Yes it is madness, but I actually got it to work. I still can’t believe it even works to be honest as it is completely reliant on Visual C++ compiling my lib (with all its inheritance and virtual functions) to be identical to the ROSE dll. Which is ridiculous, yet worked.

Most likely you will not understand how ridiculous it is that this works unless you have a good knowledge of C++ and how those aforementioned features compile into assembly.

What does this mean then? This means it is piss easy to create a custom dialog for ROSE Online, simple link to my library and include required header files such as #include ‘TDialog.H’ or ‘WinCtrl.h’ or w/e you want .

Custom dialogs are now as easy as this:

class TestDialog : public CTDialog {
public:
	TestDialog(){}
	virtual ~TestDialog(){}
};

void AddTestDialog(){
	TestDialog* testDlg = new TestDialog();
	testDlg->Create("dlgAchievements");
	AddDialog(1339, testDlg, testDlg->GetControlID());
	testDlg->Show();
}

How simple eh? It is as if we actually have the real code to TGameCtrl, this is how it would be used in ROSE, with the simple inheritance, all the virtual functions working properly and everything .

Pretty awesome .

It is not yet ready for release as I have many more classes to reverse from TGameCtrl_r.dll, below is a list of what I have done so far after many hours of reverse engineering. It may look light a random assortment of classes but it is basically every class which CTDialog depends on, other than the scroll bar related ones, I began implementing them now so I can implement the ZListBox class so I can fully recreate my achievements dialog with my new code.


Directory of C:\Programming\Libraries\TGameCtrl\TGameCtrl

221 ActionListenerList.h
161 IActionListener.h
115 IScrollModel.cpp
495 IScrollModel.h
79 ITControl.cpp
340 ITControl.h
134 ITDraw.h
319 SinglelineString.h
886 TButton.cpp
1,300 TButton.h
677 TCaption.cpp
886 TCaption.h
171 TCommand.h
217 TCommandQ.h
2,281 TDialog.cpp
2,582 TDialog.h
345 TGameCtrl.h
5,878 TGameCtrl.vcproj
593 TImage.cpp
923 TImage.h
131 TObject.cpp
256 TObject.h
1,012 TScrollBar.cpp
1,289 TScrollBar.h
190 TScrollBarType.h
704 TScrollBox.cpp
974 TScrollBox.h
251 TStatusBar.cpp
411 TStatusBar.h
2,156 WinCtrl.cpp
2,892 WinCtrl.h
33 File(s) 28,869 bytes


Sorry if you guys are not as excited as I am but I thought this was totally awesome, it might not seem as awesome if you do not know how C++ works and how it compiles into ASM.

Expect a release soon.