Anyone interested in client development?

[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).

[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.

[ableard]

thanks for the reply.

Taurinus2 the .s3d is indeed in /debug

Log file

<---> Logfile Initialized on 3-5-2012 at 10:57:24
<---> Preferences from lantern.ini have been read.
<---> Loading zone: gfaydark
<---> Screen width: 640 - Screen height: 480
<-!-> Could not load the PFS archive!
<-!-> Could not initialize the S3D file!
<-!-> Fatal Error: Unable to load zone data!
<---> Fatal Error: Unable to initialize Lantern!

[PixelEngineer]

Originally Posted by ableard

thanks for the reply.

Taurinus2 the .s3d is indeed in /debug

Log file

<---> Logfile Initialized on 3-5-2012 at 10:57:24
<---> Preferences from lantern.ini have been read.
<---> Loading zone: gfaydark
<---> Screen width: 640 - Screen height: 480
<-!-> Could not load the PFS archive!
<-!-> Could not initialize the S3D file!
<-!-> Fatal Error: Unable to load zone data!
<---> Fatal Error: Unable to initialize Lantern!

If you're in Windows, the .s3d should be in the same folder as the SLN. Try moving it there. The error there (so glad I did error logging) is from the .s3d not being found.

[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!

[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!

[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 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.

[ableard]

PuxelEngineer, I did see the zone.renderWholeZone. But when I used that not everything was displayed. I thouhgt it ws unfinished.

If you pull up qey2hh1, run up and look east. You do not see the entire zone, down by the river is not complete, no river, no river bank, there are patches out in the distance that are open. Some of the edge hills are not displayed.

[PixelEngineer]

Originally Posted by ableard

PuxelEngineer, I did see the zone.renderWholeZone. But when I used that not everything was displayed. I thouhgt it ws unfinished.

If you pull up qey2hh1, run up and look east. You do not see the entire zone, down by the river is not complete, no river, no river bank, there are patches out in the distance that are open. Some of the edge hills are not displayed.

I will check that zone when I am home. In the meantime, I'd like to see your changes to the 0x22 fragmentfunction. Again, the idea isn't to add all of the regions to the PVS. The PVS is super useful as a first pass method of reducing the number of regions to consider for rendering. But if you are just rendering with renderWholeZone, and still see missing regions, chances are there is a bug and I seem to remember a region missing when exploring Sleeper's Tomb and just assuming it was the location for an object or something silimilar. Thank you Ableard.

Post the changes on pastebin or something and send me a link if you would.

Cheers!

[PixelEngineer]

Thank you for noticing this bug. Turns out you were right. There is a problem with the renderWholeZone function. I will go ahead and fix that before the next release. As for the normal rendering function, everything looks fine. The zone regions pop into view when they are needed. Remember there will be fog and clip in this zone as well.

Thanks for pointing this out to me though. I will go ahead and get it fixed up for the next release.

Cheers!

[ableard]

Very Good. So question about reading a zone of your own creation? Has this been revisited yet, besides azone. What is the limit in reading zones that you have run across, ie what era of
eq zones can you read?

cheers

[PixelEngineer]

Originally Posted by ableard

Very Good. So question about reading a zone of your own creation? Has this been revisited yet, besides azone. What is the limit in reading zones that you have run across, ie what era of
eq zones can you read?

cheers

So far, the client has been tested with old zones and newer Luclin era versions of that same zone. I did away with SOIL (although a good library) because it was inflexible and I didn't really need it. All I need is the ability to load 8 bit bitmaps, to add an alpha channel to those and to load DDS format textures for the post Velious clients. I have no idea how it would react to the newest zones but I doubt I would get far seeing as how most of them are in a new format.

However, I may eventually add support for them. As far as our own zones, try it. I am sure they would load properly.