Anyone interested in client development?

[Derision]

Originally Posted by Taurinus2

You payed 1000USD for a license to software you don't know how to use? How did you get your developer confirmation for it?

If you got it through an unauthorized channel (would seem the case) then I can say with high confidence that you are root-kit'd (by someone other than yourself).

I think you are jumping to conclusions. I was referring to the IDA freeware 5.0 version in my post, and it is quite possible PixelEngineer has the free version too.

[Taurinus2]

True. I've forgotten that IDA Pro was once freeware. The warning about root kits still stands tho (for all who might read this).

PixelEngineer,

Have you ever considered switching to Qt Creator as an IDE? This would give you a nice IDE on multiple platforms and relieve you of having to maintain a makefile for linux. qmake really is quite capable and Qt Creator can be used even without using Qt libs in your project.

You would still need a compiler on Windows, but you can always use the latest Platform SDK to keep in sync with the compiler technology. You can also install Visual Studio and just use Qt Creator although that would seem a bit overboard when all you need is the compiler (which is what I do, because I use both and I also need the assembler).

mingw is another option (Qt Creator can use this toolchain also).

Just tossing ideas out there.

[PixelEngineer]

The IDA I was referring to was indeed the freeware version but for others that may have obtained it in other ways, thank you for the warning.

I like the idea of Qt although I am curious as to how much work it would do in translation for this project. I don't mind not using Visual Studio and if there would be something that would compile well on Mac OS (the other OS I want this client on), that would be fantastic. It is funny you mentioned it because two days ago actually, I downloaded the Qt framework and started messing around with it.

Can you list more advantages for making the switch?

[Taurinus2]

Bare in mind that I am only suggesting the Qt Creator IDE and not developing with the libs themselves (although Qt is quite solid - not really suited to your project).

The most profound thing in my mind that stands out is the ability to plug a new toolchain in without much hassle. You just invoke qmake and it can generate a makefile for the new toolchain. This simply cannot be said about Visual Studio.

Having the exact same IDE with the exact same interface on all of your target platforms is a really nice thing to have for productivity. Also, Qt is a standard lib in Debian/KDE distros (and probably more) so you would not face a dependency problem in getting up and running there.

Qt Creator can also use cmake if you wish.

In short, it just jives with cross-platform well.

Browse through the docs for qmake and see what you think.

[PixelEngineer]

From what I see, I really like this. A cross platform IDE is kind of a dream. I have learned a bit about Xcode but the lack of information about the newest Xcode (4.1) and its working with SDL is a little disheartening. If I choose to go with Qt as my IDE, what are we looking at with additional libraries/dependencies. I don't want the client to have a lot more external DLLs.

Cheers

[Taurinus2]

None. It uses your existing toolchain so your app will have whatever dependencies you had already and nothing more.

[PixelEngineer]

Small project update:

Hey guys. I think my next commit will actually be a switch to github. I could still push to assembla but I really like what I see from the way github works. I have ironed out the next steps and I am pretty sure the next version will support the loading of all the data needed to load a complete zone. This include objects, zone NPC models, skies, sounds and music. Most of the usage of these resources will not be implemented but the framework for their loading will all be in place.

It might be a while before I push to github but the next version will also include support for Mac OSX. I have decided against using Qt simply because I feel that learning Xcode is something that will come in handy down the road. That was a fantastic suggestion nevertheless and I will definitely consider it for future projects.

Any suggestions for the next release?

[PixelEngineer]

It's a start:



Cheers!

[Akkadius]

Originally Posted by PixelEngineer

It's a start:



Cheers!

That's awesome guys

[ableard]

Yes, the s3d goes in the with the SLN.

this work as advertised (hehe).

Quick question concerning back clip plane. There appears to be a fixed geometry for the back clip plane, do I have this right. Would much prefer that we can adjust this. I thought I could set this in the ini file but I can not get his working. Also in the code it looked as if we can adjust it some what but once we reach 2000 (I think this was the number) we gain nothing else.

I can increase the back plane distance also by increaseing the display dimensions, but the frustrum looks to have a geometric constraint built in.

Do I have this right or have I missed something.
thanks

[PixelEngineer]

I am in the process of rewriting all of the render code but as far as I know, the frustum pulls the clip distance from this line in init.cpp:

gluPerspective(75.0f,(GLfloat)width/(GLfloat)height, 0.1f , 10000.0f);

The last value in that command represents the furthest view able region.Again, this will be changed when shader rendering is in place. Hope this helps though.

[ableard]

Update!!!
I have modified the code to display the entire zone!

The dislpayable regions is hard wired by the wld decryption by way of veiwable regions from each region.
The above gluperspective is true, you can move out as far as you want but the displayable world reaches a maximum, my system it was 2000.

Except!

I modified the code inside 0x22 to compile a new list of viewable "regions" for each region to see ALL regions. Shazam the entire zone gets loaded and viewed. I have written the code to read in all veiwable regions as the WLD is loaded in, so if there is a zone with funny regions they are no displayed. The orignial code also checks for compatability with region and mesh not sure if this is required.

I have used eastkarana/westkarana as my test and they work great. My video card has tons of memory so frame rates are unchanged. I actually suspect with some additional work we can load all four Karana files as one (ie corrdinate transformations required, maybe scaling).

Since your reworking your client, I will add my modifications after you are complete. Load times become longer as expected. I suspect with some work I can improve or improvise a faster way to load.
Cheers!

[jayfromtholuxe]

Just found this thread. Awesome work!

Huge +1 for moving to Github and using Xcode! I can't speak highly enough of Github. I've seen many, many projects move their code to Github and afterwards find the community and collaboration tools there a tremendous boon.

By the way, what are your plans for the server component of this? Do you want to write something from scratch or try to use EQ Emu eventually somehow? If you want to do something from scratch I'd love to help you out. I have a lot of experience doing this for web and telephony infrastructures.

I ended up here doing some research for a side project I'm considering starting, very similar to this but using WebGL / HTML5 for rendering. I don't intend to reuse the existing EverQuest data files, however. For an example of what this technology can do, check out this game:

http://plsw.net/webgl/wloom6/shooter.htm

My first step is a build the backend game logic server with game mechanics as close to EverQuest as I can get. After that, I'll work on the graphics. It sounds like our needs for the backend are very similar.

By the way, I tried to build the code on Lion and got this error:

https://gist.github.com/f1f69fa98a15c54e6f30

It looks like the Makefile isn't wiring up the system install of OpenGL well for GCC.

[PixelEngineer]

Originally Posted by ableard

Update!!!
I have modified the code to display the entire zone!

The dislpayable regions is hard wired by the wld decryption by way of veiwable regions from each region.
The above gluperspective is true, you can move out as far as you want but the displayable world reaches a maximum, my system it was 2000.

Except!

I modified the code inside 0x22 to compile a new list of viewable "regions" for each region to see ALL regions. Shazam the entire zone gets loaded and viewed. I have written the code to read in all veiwable regions as the WLD is loaded in, so if there is a zone with funny regions they are no displayed. The orignial code also checks for compatability with region and mesh not sure if this is required.

I have used eastkarana/westkarana as my test and they work great. My video card has tons of memory so frame rates are unchanged. I actually suspect with some additional work we can load all four Karana files as one (ie corrdinate transformations required, maybe scaling).

Since your reworking your client, I will add my modifications after you are complete. Load times become longer as expected. I suspect with some work I can improve or improvise a faster way to load.
Cheers!

I am very confused. Lantern will only display the regions that are in the current zone's PVS. The PVS is a list of region's that you can see from your current region. This is to cut down on processing time and thus, framerate. The fact that the whole zone does not render at once is not a bug, it is how the original client worked.

The render function (although rewritten since) does work in the same way.

Here's the process.

1. Where is the camera? Iterate through the BSP tree until the current BSP region is found.

2. What can we see from this region? The vector visibility has the list of all of the regions you can see from the camera's region.

3. What regions can the camera see? The visibility vector is used again and the regions min/max values are checked against the camera's frustum. So only regions that are in the PVS and the camera's frustum will actually be rendered.

Now there is a special case where the camera is outside of any region. This would mean there is no PVS and thus no visible regions but then you couldn't see where you are. Therefore, there is a second function renderWholeZone in the WLD class. This will render the entire zone regardless of where you are.

In the Greater Faydark for example, what you are seeing might be regions "popping" up in the distance but you would never see those based on the clip plane of the zone and the fog. Lantern renders the zones using the same method.

If you want to force it to render the whole zone regardless, just change the render function in main.cpp:

From

   // Render if we in a region -- else render the whole zone
    if(!outside)
    {
                // If we are in a region, render every region in its PVS and frustum
                zone.renderNew(cameraRegion, cfrustum);
    }
    else
    {
                // We are not in a region, render the whole zone
                zone.renderWholeZone(cfrustum);
    }

to just:

zone.renderWholeZone(cfrustum);

Hope this helps alleviate confusion.

Cheers!

[PixelEngineer]

Originally Posted by jayfromtholuxe

Just found this thread. Awesome work!

Huge +1 for moving to Github and using Xcode! I can't speak highly enough of Github. I've seen many, many projects move their code to Github and afterwards find the community and collaboration tools there a tremendous boon.

By the way, what are your plans for the server component of this? Do you want to write something from scratch or try to use EQ Emu eventually somehow? If you want to do something from scratch I'd love to help you out. I have a lot of experience doing this for web and telephony infrastructures.

I ended up here doing some research for a side project I'm considering starting, very similar to this but using WebGL / HTML5 for rendering. I don't intend to reuse the existing EverQuest data files, however. For an example of what this technology can do, check out this game:

http://plsw.net/webgl/wloom6/shooter.htm

My first step is a build the backend game logic server with game mechanics as close to EverQuest as I can get. After that, I'll work on the graphics. It sounds like our needs for the backend are very similar.

By the way, I tried to build the code on Lion and got this error:

https://gist.github.com/f1f69fa98a15c54e6f30

It looks like the Makefile isn't wiring up the system install of OpenGL well for GCC.

Thanks for the kind words. On my next commit, I will be moving this project to github and including an Xcode project which does build on Lion. As for the server software, I am not sure yet. The thing about EQEmu, although it is very well written is that is was built to work with inflexible code, the client. With an open source client, we don't just have to send/respond to packets, we can design them ourselves.

I am not very versed in network programming but when I started this, I wasn't well versed in graphics programming.

Let me know what kind of ideas you have.

Cheers.