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.

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.

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?

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.

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

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

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?

It's a start:

http://i.imgur.com/3tIui.png

Cheers!

That's awesome guys :)

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

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:

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.

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!

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.

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

to just:


Hope this helps alleviate confusion.

Cheers!

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.

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!

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!

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.

A proposal.

Hey everyone. I am still quite busy with school and such and I had a rather interesting idea. As I am pretty much a one man team working on an engine, I will likely never get this client up and running as solid as I have wanted. Sure, I will eventually implement full rendering, animation, UI and possibly client support but in a lot of those cases, I am reinventing the wheel.

I have had an idea that combines the work I have already done with a preexisting engine. I'd like to finish rendering with shaders, finish up some bugs and then switch to an open source engine. The problem with many EQ projects is that people try to convert the EverQuest format to a more common format and import it into an engine (Unity, Unreal, etc...) which is neither suited or optimized for the way the zones were originally created. What I propose is we pick an open source engine and load the EverQuest data into that.

I have had my eye on irrlicht, which is written in C++, is cross platform and has quite a few examples of loading Quake style BSP maps. The EverQuest format is similar and with the already extensive documentation of the fragments, I don't think porting my work would be that difficult.

The downside would be that I would no longer be working directly with the core engine code (although as it is open source, I could still see/modify it). The upside would be that a lot of the features that will take quite a while to implement (collision detection, per pixel light, parallax mapping) would be supported natively by the engine and I could focus on making sure the data from the zones are translated into this engine accurately.

I am very excited about the prospects of a quicker development cycle. I feel my learning of shaders thus far has been fantastic and I also realize that I will still learn a ton while working with an established engine especially because it is open source.

My plan is to finish up this next release of Lantern and then after that, begin the process of porting my work to the irrlicht engine.

Any comments/suggestion/criticism are welcome!

Cheers!

If you're going to use an engine I would suggest Ogre3d. I've used both and Ogre is much more capable and polished. It also has a better asset creation pipeline.
I'm sorry that I'm not able to dedicate more time to this, there just aren't enough hours in the day. When I do get a little time I'm not likely to get very far since the current SVN appears to be way behind and I don't know where the git repository is.
I would be more likely and able to work on it if commits were more frequent, maybe you could establish a release branch for feature complete updates that are sure to compile and keep the trunk always up to date.

I wrote my eqg loader in irr first then ogre3d (though the latter was a hacky mess as I was in the middle of getting advanced materials working). I'm not sure if they've changed anything recently with irr but it was a lot harder to work with the low level primitives that I needed to work with than it was in ogre.

The downside was ogre was a bigger set of dependencies to get up and running initially.

I also agree you shouldn't convert the assets, whatever you pick should just load them.

I read recently that Valve is porting Steam over to linux. This got me to thinking of this UI project. I have been following this with some interest from an end user standpoint.

Pretty cool work so far!

Have you guys made any headway in porting animations over to a new engine?

Hey guys. A quick update. I have been finishing up another semester in school and have been pressed for time. I am going to have a pretty open summer and will likely finish the client as I can spend upwards of 40 hours a week on it. I have still been looking at different graphical engines. I really like what I see from Ogre3D and the ability to still do a majority of the logic work and have control over how the data is handled and yet, utilize the work the talented Ogre3D programmers have done on their graphics engine.

I will keep you posted. Expect big things.

Tyen05, as I mentioned before, porting the EQ zones to another engine is very hard. Importing them natively via code is a much better route. If I remember correctly, you are using Unity. You may in fact have to write a converter which takes EQ animation fragments and outputs them in a format Unity understand. I am not saying it is impossible but the exact issues you are having are the reason I have not decided to use a closed source engine.

Cheers!

Hi PixelEngineer,

I know when you started this thread you said you would never enable networking. I thought I would touch bases with you and see if you had perhaps had a change of heart at all. I for one would love an open source linux client :) That would just rule.

That being said, once you feel satisfied you have got a solid grasp on the engine aspect, will you be developing an MMO? :)

Have a good one,
Diriel

A format in which any 3d modelling software understands would be just as good. Such as Maya/3d max.

The hardest part of converting EQ zones is wrestling with the various file formats. It looks like WLD is a well understood format, but none of the existing work on EQG files gives me any texture information (or I haven't found it yet, OpenEQ source might be handy here but all the links are broken.)

This loads the .map files the servers read so some of the geometry is omitted, but it would be easy to tell azone to output mapfiles with full geometry if one wanted to.
http://dungeoncrawl.us.to/eq/mapvis/?zone=crushbone

For WLD zones those json map files could easily include textures and UV's. The only thing you lose is the EQ spatial database of choice. Most modern engines use an octree scene graph with frustum culling by default, so just breaking the zone geometry into reasonably sized chunks should be serviceable.
I have some progress on a zone converter that borrows heavily from azone2. It can output the zone model and all the placeable objects as individual model files, but textures are hit and miss.

Sent you a PM, I have a partially working EQG zone viewer somewhere (up to v3) it's a mess as it was just a prototype but it's got better material support than OpenEQ and should be able to figure out how it is all parsed at least.

The zone viewer code has been really enlightening. Between the nice weather and other obligations I haven't has as much time to work on it as I would like, but I'm making progress here and there.

Rather than try to load all the various archives based on zone name and resource text files I've just decompressed everything into a resource directory. Since most of the compressed resources are binary the uncompressed directory is only about 10% larger.

Back at it again. More exciting stuff to come.

Can't wait to hear more!

This is really awesome, amazing work! I'm glad to see how active you are.

I've been looking for a good client for zone viewing for a while now and this looks fantastic. Is there anyway I can get windows binaries of the latest release?

http://i.imgur.com/kBL5y.jpg
http://i.imgur.com/ib0XW.png
http://i.imgur.com/89wIt.jpg
http://i.imgur.com/RJIrX.png

Pretty awesome! Nice work Pixel.

Looking good! Hurry up with a full blow Linux Client! :)

I will definitely make this client run on Linux. This was pretty much a complete rewrite of the Lantern engine. I decided to work on OSX in the beginning because:

1) I wanted to learn Xcode and the OSX filesystem
2) OSX annoyingly only supports up to GLSL 1.2

Rather that work backwards in compatibility, I just wrote shaders that ran on the least compatible system. Get your stuff together OSX devs.

The next step is models and animation (probably will be done in 1-2 weeks). I will also figure out a compatible way to translate the model animations to a standard format to help those devs that have the Unity project going. Who would have though it would be easier in some respects to write an engine rather than one as capable as Unity :grin:

Cheers!

Both Lion and Mountain Lion both support up to OpenGL 3.2 with GLSL 1.5.

It's honestly pretty shitty support as 3.3 has been out for over two years and they don't support any of the 4.x profiles (derp) but not quite as bad as being stuck on 2.1.