Thank you! The real hardcore development is going to start as soon as I get everything stable. The original EverQuest developers made some very odd design choices and I have struggled to both understand and implement some of the more challenging ones. Every day I get closer to a much more solid code base and then the real fun development can begin.


Cheers!

This rocks, I have wanted this type of thing for years. But I never had the code know how to even grasp a start. Glad to see this taking off and having community backing.

Don't sell yourself short. I see you have written some programs in C#. Syntactically, it is not that different from C++. When I started writing the client, I couldn't write it either but i slowly learned and have learned an enormous amount. The link to the source is on the last page so take a look if you're interested.

Cheers!

Thanks for the vote of confidence :-) I grabbed the source and now to get the time to look at it. My knowledge is pretty basic but getting better. Not too bad for no schooling or work environment in coding.

Do you guys mind if I move this to Dev and perhaps sticky it? (I think it's cool and has actually shown some promise)

I just joined in on this thread but I like that idea.

Don't mind at all, as long as you let me pick your brain here and there. :)

Also, Speedz, pick up the commit I push tomorrow. It solved 98% of zone loading crashes. Might be a better starting point.

K will do, thanks

Revision 27

Changelog:
- Fixed a name length bug in the 0x03 fragment.
- Texture animation is now supported - still have to work on global timing
- Fixed up the 0x04 fragment issues. Figured out an unknown value in that fragment as well. Turns out it is animation delay, the number of milliseconds before the animated textures switches to the next texture.
- Finally fixed a weird texturing issue involving a NULL texture. For things like invisible wall, the polygons are still in the BSP tree (for collision). They do still have a texture reference but it points to a null value. This one was a pain to debug.
- Fixed a number of specific zone crash issues - some still remain, i.e. 'qeynos'

Known issues:
- Crash on texture load with some zones - have to look into this after the weekend.
- Animated textures do not always update at the same time.
- Some animated textures (waterfalls) flow the wrong way
- Oasis fails to load - stops on loading the file "canwall1.bmp" as it does not exist in the archive. canwall1a.bmp does however. I assume this is a fault on the
developer's end.
- Code base is still a huge mess. Bear with me while I slowly eliminate old functions that are not needed and rewrite certain fragment functions.
- Rendering seems to "freeze" when you go out of a leaf (travel back into a leaf and the frame will refresh). It hasn't actually froze but I disabled the whole zone rendering function until I finish the new rendering.

Goals for next commit:
- Texture crash fix
- Global texture animation timing
- Transparency and semi transparency with rendering (have to rewrite rendering function...again)
- Loading zone variables (sky/fog color/clip plane)
- Ambient light

One more thing before I disappear for the weekend, here is a concept UI I made. It needs to be something that's usable on different screen sizes. Again, just an idea but I am going to try and model the UI after this when the time comes.

http://i.imgur.com/c780P.png

Suggestions? Criticisms?

Grabbed it but I I'm not sure whats the deal with my setup.

'Lantern.exe': Loaded 'D:\EQEmu\Lantern\Lantern\Debug\Lantern.exe', Symbols loaded.
'Lantern.exe': Loaded 'C:\Windows\SysWOW64\ntdll.dll', Cannot find or open the PDB file
'Lantern.exe': Loaded 'C:\Windows\SysWOW64\kernel32.dll', Cannot find or open the PDB file
'Lantern.exe': Loaded 'C:\Windows\SysWOW64\KernelBase.dll', Cannot find or open the PDB file
'Lantern.exe': Loaded 'D:\EQEmu\Lantern\Lantern\SDL.dll', Binary was not built with debug information.
'Lantern.exe': Loaded 'C:\Windows\SysWOW64\advapi32.dll', Cannot find or open the PDB file
'Lantern.exe': Loaded 'C:\Windows\SysWOW64\msvcrt.dll', Cannot find or open the PDB file
'Lantern.exe': Loaded 'C:\Windows\SysWOW64\sechost.dll', Cannot find or open the PDB file
'Lantern.exe': Loaded 'C:\Windows\SysWOW64\rpcrt4.dll', Cannot find or open the PDB file
'Lantern.exe': Loaded 'C:\Windows\SysWOW64\sspicli.dll', Cannot find or open the PDB file
'Lantern.exe': Loaded 'C:\Windows\SysWOW64\cryptbase.dll', Cannot find or open the PDB file
'Lantern.exe': Loaded 'C:\Windows\SysWOW64\gdi32.dll', Cannot find or open the PDB file
'Lantern.exe': Loaded 'C:\Windows\SysWOW64\user32.dll', Cannot find or open the PDB file
'Lantern.exe': Loaded 'C:\Windows\SysWOW64\lpk.dll', Cannot find or open the PDB file
'Lantern.exe': Loaded 'C:\Windows\SysWOW64\usp10.dll', Cannot find or open the PDB file
'Lantern.exe': Loaded 'C:\Windows\SysWOW64\winmm.dll', Cannot find or open the PDB file
'Lantern.exe': Loaded 'C:\Windows\SysWOW64\msvcp100d.dll', Symbols loaded.
'Lantern.exe': Loaded 'C:\Windows\SysWOW64\msvcr100d.dll', Symbols loaded.
'Lantern.exe': Loaded 'C:\Windows\SysWOW64\opengl32.dll', Cannot find or open the PDB file
'Lantern.exe': Loaded 'C:\Windows\SysWOW64\glu32.dll', Cannot find or open the PDB file
'Lantern.exe': Loaded 'C:\Windows\SysWOW64\ddraw.dll', Cannot find or open the PDB file
'Lantern.exe': Loaded 'C:\Windows\SysWOW64\dciman32.dll', Cannot find or open the PDB file
'Lantern.exe': Loaded 'C:\Windows\SysWOW64\setupapi.dll', Cannot find or open the PDB file
'Lantern.exe': Loaded 'C:\Windows\SysWOW64\cfgmgr32.dll', Cannot find or open the PDB file
'Lantern.exe': Loaded 'C:\Windows\SysWOW64\oleaut32.dll', Cannot find or open the PDB file
'Lantern.exe': Loaded 'C:\Windows\SysWOW64\ole32.dll', Cannot find or open the PDB file
'Lantern.exe': Loaded 'C:\Windows\SysWOW64\devobj.dll', Cannot find or open the PDB file
'Lantern.exe': Loaded 'C:\Windows\SysWOW64\dwmapi.dll', Cannot find or open the PDB file
'Lantern.exe': Loaded 'D:\EQEmu\Lantern\Lantern\glew32.dll', Binary was not built with debug information.
'Lantern.exe': Loaded 'D:\EQEmu\Lantern\Lantern\zlib1.dll', Binary was not built with debug information.
'Lantern.exe': Loaded 'C:\Windows\SysWOW64\imm32.dll', Cannot find or open the PDB file
'Lantern.exe': Loaded 'C:\Windows\SysWOW64\msctf.dll', Cannot find or open the PDB file
'Lantern.exe': Loaded 'C:\Windows\SysWOW64\KBDUS.DLL', Cannot find or open the PDB file
'Lantern.exe': Unloaded 'C:\Windows\SysWOW64\KBDUS.DLL'
'Lantern.exe': Loaded 'C:\Windows\SysWOW64\KBDUS.DLL', Cannot find or open the PDB file
'Lantern.exe': Unloaded 'C:\Windows\SysWOW64\KBDUS.DLL'
'Lantern.exe': Loaded 'C:\Windows\SysWOW64\dsound.dll', Cannot find or open the PDB file
'Lantern.exe': Loaded 'C:\Windows\SysWOW64\powrprof.dll', Cannot find or open the PDB file
'Lantern.exe': Loaded 'C:\Windows\SysWOW64\dinput.dll', Cannot find or open the PDB file
'Lantern.exe': Loaded 'C:\Windows\SysWOW64\hid.dll', Cannot find or open the PDB file
'Lantern.exe': Loaded 'C:\Windows\SysWOW64\wintrust.dll', Cannot find or open the PDB file
'Lantern.exe': Loaded 'C:\Windows\SysWOW64\crypt32.dll', Cannot find or open the PDB file
'Lantern.exe': Loaded 'C:\Windows\SysWOW64\msasn1.dll', Cannot find or open the PDB file
'Lantern.exe': Loaded 'C:\Windows\SysWOW64\nvoglv32.dll', Cannot find or open the PDB file
The thread 'Win32 Thread' (0x1880) has exited with code 0 (0x0).
The thread 'Win32 Thread' (0x1854) has exited with code 0 (0x0).
The thread 'Win32 Thread' (0x1850) has exited with code 0 (0x0).
The thread 'Win32 Thread' (0x1b8c) has exited with code 1 (0x1).
The thread 'Win32 Thread' (0x14d8) has exited with code 1 (0x1).
The thread 'Win32 Thread' (0x280) has exited with code 1 (0x1).
The thread 'Win32 Thread' (0x1a14) has exited with code 1 (0x1).
The program '[8108] Lantern.exe: Native' has exited with code 1 (0x1).

log.txt contains all of the debug and error logging information you need.

However, I assume you don't have the .ini set up correctly. Open it. The top line is the zone shortname. The last one I used was qrg, Surefall Glade. Change it to arena or gfaydark and then drop the zone's .s3d in the same folder as the .exe

Then run as you normally would through Visual Studio.

When it doubt, check the error log. It's far from complete but definitely helps me to debug.

Edit: Also, you'll see a lot of texture related crap in the debug. I did a lot of that to solve most of the texture errors. Still have one more error so I am keeping them enabled.

Thanks for the quick reply and tips. Will try again in a few as I am reinstalling VS due to other issues not related to this build.

Didn't know or look deep enough to know about the zone and s3d files.
Will get this going and dive in soon.

No worries. Pace yourself and don't get burnt out. It took me months to get things working and I took many breaks so just take your time and have fun. Modify variables, mess around and see what makes things work. I am going to move a lot of the OpenGL stuff into a separate init.cpp so the main.cpp can just be client setup related.

Let me know if you ever have any questions or problems here, in a PM or at red.pixel.engineer@gmail.com

Cheers mate!

You are crazy talking to yourself. No really, I'm interested to see where you get with this

Got the client to fire up. For all interested peoples make sure you don't use s3d files from the SoF or SoD client :-)

This is something I will fix. The issue here isn't lack of support for the new WLD, it is lack of support for the texture formats (.dds, 24 bit bitmaps)

Told myself I wouldn't but I am going to try and fix that last pesky texture bug tonight.

Sent you a few emails with some minor things I played with and a launcher tool that I made.

Btw, the launcher tool will delete .s3d files in the root of where it is then load the s3d file you select from the list from a Maps folder. Made this to keep things simple for me, hope it is handy for ya.

I downloaded this right after you published svn and then I got hit hard at work. Sorry to just disappear.

I fired this back up today and got it building under debian testing 64-bit.
The most notable issues were case-sensitivity in filenames and includes, '\' instead of '/' in include paths, and a handful of windows API functions that I moved to SQL or just cobbled together windows.h equivalents.

The one remaining issue appears to be related to 64 bit builds. I looked back at one of my old projects that borrowd PFS code from azone and it looks like we did things similarly. After quite a bit of debugging I started testing my old code again (as it was working in linux32) and it failed as well.

I won't be able to validate this in a 32-bit environment until later, but here's what I have so far.

http://midian.homelinux.net/lanterndiff.txt

uint32 was typed to unsigned long and long types are used for crc's etc, which explains why there's not 64-bit love.
Now I'm having a problem with bitmaps, but I suspect it's related.

It seems like the solution here would be to use SDL_Image since it sounds like better general image support is needed anyway.

I've compiled it on Fedora 13, 32-bit using Tabasco's patch for Linux. I didn't want to mess with code::blocks settings, so I just did it on command-line with g++.

I can't seem to get it to work properly though, it opens and crashes trying to load gfaydark. I have gfaydark.s3d in the same folder as the Lantern binary file.

lantern.ini:

Partial log.ini:

Have I forgotten something?

Edit: This is using the .s3d from a fresh Titanium installation. I've also tried qrg and unrest, they both give similar errors.

This is what I was getting in the 64-bit build after changing all the types, but I thought I just hadn't found everything yet.
My 32-bit build does the same thing so it's more likely that I messed something up when trying simulate the windows.h types for bitmaps.

I just disabled texturing and enabled GL lighting and shading. It's not very pretty, but you can at least wander around the zone and it demonstrates that everything generally works.
It should be simpler in general to use SDL_Image for textures and I can probably get that in there at some point if pixelengineer is agreeable to that. Also after looking at how the scene is managed, I wonder if it would be wise to first make a tool for processing maps into a different format.

What release of gfaydark.s3d did you use?
I got exactly that till I used the titanium s3d files.

I have thrown together a couple of simple tools that I was going to just use for myself. But after getting into them I figured more people might find use for them. Heck maybe even improve my amateur code.

I am posting this on this thread as one of the tools directly relates to this project. Its called Zone-Selector.

The other is a offline spell search tool. It is far from complete, just hardly started even.

https://www.assembla.com/code/emustuff/subversion/nodes

If you do mess with it and improve it, please send me patch files so I can update the svn.

Hey guys, sorry I have been absent for a while.

Linux guys, great work and I am very happy to have some people on different operating systems.

The texture loader is an offshoot of a texture loader from another engine and it looks like it's giving problems so we can definitely kick it and use SDL_image.

Currently, this only has been tested on classic zones. Therefore, the only image type that is currently supported is an 8 bit bitmap. The reason there is a bit more code there in there is because I had to add an instance where the 8 bit bitmap would compute an alpha layer for masked textures.

What kind of format does the new client use? I see that the log said bitmap with an unrecognized BPP which make me assume 24 for which support can easily be added. In addition to bitmap, do the newer zones use .dds or any other format?

Since my last commit, I have done a ton of cleanup to the WLD class, changed a lot of the uchar* to char* to avoid mixed character type warning, and fixed a few other things but have unfortunately been at the whim of a six week intensive calculus class. After an exam on Monday, I will be able to push that latest version and have a couple of hours each night to code.

I'll add support for the texture types and try to get the linux diffs sorted. I see that as the new number one priority besides stability; getting the client working on linux as well. We can slowly eliminate Windows specifics and have an SVN that is cross platform friendly.

Thank you again for showing interest and I will definitely put some time in next week to get this stable on linux and adding you guys to the SVN if you so desire.

Cheers!

Life happens :-)

Good to see such interest in this. Add me if you like but with my limited experience in svn commits and coding anything past GUI utilities won't lend myself to heavy traffic at first. But gotta learn and get experience somewhere right?

Hey PixelEngineer,

Have you checked out SOIL?

http://www.lonesock.net/soil.html

I have not. Have you used this? Looks like a pretty full featured and lightweight library. Definitely will consider using it.

Thanks for the suggestion. I will have time today and tonight to work on the client again.

Yes, I've used it in the past. Small, efficient, one less dependency (can integrate directly into your source tree).

Depending on your decision to limit the amount of C you have in your project or not, you can easily slap a facade on it and be good to go.

Okay. I got SOIL implemented. Two potential problems. We are reading from memory in the loading of textures. I have the file interface as a workaround I would like to get rid of. I might have to add the functionality to SOIL to load from memory and not a file. Second issue is that when the textures do load, they look a bit weird. May just be an error in my code but I am getting the feeling the library might not support 8 bit bitmaps.

Do you have any idea if it does?

PixelEngineer

Edit: Found the option to load from a buffer. Wish there was a bit more documentation for this library but I really do like what I see.

Edit2: Went through the flags and found SOIL_FLAG_TEXTURE_REPEATS. This ended up denoting the textures as tiles. Not sure why this isn't enabled by default. All working. This will be part of the next commit. Thanks again Taurinus for the suggestion.

Commit 28

- Added SOIL library for image loading. Thank you to Taurinus2 for the suggestion. New zones now load. (textures are flipped)
- Integrated Tobasco's diff for Linux. Thank you Tabasco - huge help.
- Deprecated the use of the file interface library and the image loading library.
- Rewrote some of the texture documentation, debug output and 0x30 fragment handling.
- Fixed the texture crash error that prevented some zones from loading.
- Moved non Lantern related initialization into init.cpp and init.h.
- Added support for ambient light (0x2A), light source reference (0x1B) and light source (0x1C) fragments. Still not yet activated.
- Added specific categories of debug output for fragments (textures, lights, geometry...). Fragment errors will still output regardless.
- Huge cleanup to the WLD class
- Reimplemented the rending of the whole zone.
- Changelog.txt is now in the project directory.
- Added the SDL_ttf library. It is not used yet but I will commit my text on screen work in the next commit.

Known issues:
- Support for masked textures has been removed due to the new image loading library. Will have to re-add.
- A weird issue with mip masking makes far away textures have a tint to them. Still trying to figure this one out. Mip mapped images are disabled for now.
- Zone crash related to texture UV coordinates in some zones.
- Textures in Titanium zones are flipped

Priorities:
- Support for bitmap font rasterization
- Global texture animation timing
- Transparency and semi transparency with rendering (have to rewrite rendering function...again)
- Loading zone variables (sky/fog color/clip plane)
- Ambient and zone lighting
- Linux makefile
- Deprecate the current math library and introduce a new one.

Great work so far, I noticed something odd tho. Zones are flipped left <> right.

I looked at unrest, Crushbone, and cshome. all were flipped/reversed. Not just textures, but the entire zones.

Thanks Speedz. Can you be more specific? Are we talking just textures or something like Mario Kart mirror mode? New zone files or old zone files?

Cheers.

I noticed that as well in the last build. If you want an example, just load gfaydark and go to the crushbone entrance, it's completely reversed.

Sorry for a lack of description. Yes mirrored. Also it does this on all versions I have. Titanium to SoD s3d files.

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.

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.

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?

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.

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