Anyone interested in client development?

[Speedz]

I'm also going to update my zone loader tool to read a user selected Game directory for the s3d files and copy from there as needed per launching. Instead of the original way I did it where you had to copy all s3d files to a zone directory.

Would make for faster maybe more handy zone comparison/work.

*
You select the EQ dir and it will load a list of the s3d files. You then select the s3d you wish to load from the list it generates and it will delete all s3d files in the lantern dir and copy the one you select. Basically its an as use/need basis so you don't have to either copy all s3d files to the lantern dir or constantly copy paste and change ini file every time.

If this makes any sense at all I will be surprised lol. I will try better next time.

[PixelEngineer]

Wow. I cannot believe I had not noticed that. I wonder if this is new in one of the latest versions. Thanks for mentioning that. I will fix it.

[pfyon]

I've never actually written a makefile or anything beyond compiling a single cpp file with g++, anyone have a working one for linux I could use for this?

[Tabasco]

This is based off of the latest svn. The archive includes the complete source tree, a diff, and the makefile. Also 32 bit binaries.

http://midian.homelinux.net/lanterneq_revised28.tar.gz

I renamed the FPS Counter directory with an _ instead of a space rather than trying to escape it in the makefile. There are also some header changes that probably aren't necessary since I'm not building in codeblocks anymore.

[Tabasco]

Updated download link:
http://216.49.224.132/eq/lanterneq_revised28.tar.gz

[pfyon]

Thanks, Tabasco. I was running into difficulties getting it to compile until I read the error messages and noticed it was complaining about x64 (this is a 32 bit machine). Just an FYI to anyone else who downloads the tarball, make clean first.

[PixelEngineer]

Did you get it up and running Pyfon? Got a screenshot?

[pfyon]

I haven't been able to get it working, probably due to the same issue that Tabasco et al ran into. I tried an s3d file from titanium, sof, and sod without luck.

pfyon@family-kubuntu:~/lanterneq/Lantern$ ./Lantern 
24

pfyon@family-kubuntu:~/lanterneq/Lantern$

pfyon@family-kubuntu:~/lanterneq/Lantern$ cat log.txt
<---> Logfile Initialized on 2-5-2012 at 19:56:27
<---> Preferences from lantern.ini have been read.
<---> Loading zone: crushbone
<---> Screen width: 800 - Screen height: 600
<-!-> This is not a valid PFS archive
<-!-> Could not initialize the S3D file!
<-!-> Fatal Error: Unable to load zone data!
<---> Fatal Error: Unable to initialize Lantern!

pfyon@family-kubuntu:~/lanterneq/Lantern$ cat lantern.ini
crushbone
800
600

[Tabasco]

I had to do a lot of fixes for 64 bit that I have yet to publish. I'll get those committed tomorrow along with some of the header fixes so we can hopefully have a single source tree that builds without any modification for platform or architecture.

You might be able to quickly fix your copy by looking at the global datatypes include.

typedef unsigned int uint;

typedef unsigned char uchar;
typedef int8_t int8;
typedef uint8_t uint8;
typedef int16_t int16;
typedef uint16_t uint16;
typedef int32_t int32, dword;
typedef uint32_t uint32;

[KLS]

The mirrored zones sounds very similar to an issue I ran into with my .eqg renderer because sony inverts x and y axis.

[pfyon]

Thanks again tabasco, that did fix that issue. I also had to change line 96 of S3D.cpp from

memcpy(&file_count, meta_block, sizeof(long));

to

memcpy(&file_count, meta_block, sizeof(int32));

Now I'm sitting at a black window from Lantern without any useful output.

pfyon@family-kubuntu:~/lanterneq/Lantern$ tail log.txt 
<---> Logfile Initialized on 2-5-2012 at 21:16:32
<---> Preferences from lantern.ini have been read.
<---> Loading zone: gfaydark
<---> Screen width: 800 - Screen height: 600

[Tabasco]

With SOIL I haven't had any texture issues, but I haven't tested in 64-bit yet.
What do you get if you try to move around (sometimes 0,0,0 isn't ideal) or what do you get when you run something from mesa-utils like glxgears, or glxinfo, or try to load a different s3d?

KLS, I noticed some strange stuff when translating 2d map files to locs inside a web-based editor. OpenGL tends to use a Y-Up model, but every engine wants to apply its own translation anyway. In addition to that, they use one system for coords and another entirely for labels. I can only imagine what other idiosyncrasies we'll find inside their archives.

[lerxst2112]

It may not help that by default Direct3D is left-handed and OpenGL is right-handed with regards to coordinate systems. Not hard to account for if you know the format the data is loaded in and the destination system you want it to fit, but certainly a common pitfall.

[Taurinus2]

Any thoughts toward a sound lib? FMOD? irrKlang?

What threading model do you plan to adhere to?

Also do you have a design doc laying around?

I applaud your drive and progress on this project.

[PixelEngineer]

Originally Posted by Taurinus2

Any thoughts toward a sound lib? FMOD? irrKlang?

What threading model do you plan to adhere to?

Also do you have a design doc laying around?

I applaud your drive and progress on this project.

I think when the time comes, I will try FMOD. Looks like what a lot of people use today in the industry.

As for threading, I honestly have no idea yet. There is a design doc (readme.txt) on the SVN and it just lays out some goals I want to accomplish.

I probably won't be committing anything for a week or so while I add support for shaders and lighting. More than anything I am just reading about the OpenGL pipeline and trying to understand everything before I move on. After all, this is a project for learning.

Great to see it running on Linux and go ahead and commit that whenever you get the chance.

Cheers!