Anyone interested in client development?

[PixelEngineer]

Thank you. I have reduced most of the Windows specific functionality and will eliminate the rest when I get around to it. A bit of code is taken from various other projects and the way they handled fragments was a bit all over the place. Consider my work on textures in 0x03.cpp, 0x04.cpp, 0x05.cpp, 0x30.cpp and 0x31.cpp for a sample of what most of fragment handling will look like as I rewrite.

If you see any glaring errors, submit some changes and I will of course get around to reviewing them. Also, if I understand correctly you're looking to make it Linux compatible? Let me know how I go about doing this/helping to do this.

Cheers!

[Secrets]

Originally Posted by PixelEngineer

Thank you. I have reduced most of the Windows specific functionality and will eliminate the rest when I get around to it. A bit of code is taken from various other projects and the way they handled fragments was a bit all over the place. Consider my work on textures in 0x03.cpp, 0x04.cpp, 0x05.cpp, 0x30.cpp and 0x31.cpp for a sample of what most of fragment handling will look like as I rewrite.

If you see any glaring errors, submit some changes and I will of course get around to reviewing them. Also, if I understand correctly you're looking to make it Linux compatible? Let me know how I go about doing this/helping to do this.

Cheers!

This is very good! I've got a great idea for creating new content: Why not a 3DS Max exporter plugin? You could have it build WLD files from scenes, and I believe 3DS Max already supports animations. Not sure how it handles BMP files but it should be trivial.

SOE already uses 3ds max for their animation files afaik.

[PixelEngineer]

As of now, the next time I have time (Friday), I will finish my rewrite of the PFS (S3D) extractor. It works fine for the most part but there are some weird issues and I think it might be related to this. Then, I will begin work on models and light and get them all working properly.

Those are just my 2 main objectives at this point but I don't have time for the next two days due to finals.

Cheers.

[Vampire1212]

I'd love to help out with this client. I'd personally like to do my own revamp of the classic zones by simply change textures, lighting not the graphics themselves.

[PixelEngineer]

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.

[Speedz]

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.

[PixelEngineer]

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!

[Tabasco]

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

[Tabasco]

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.

[Vexyl]

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:

gfaydark
800
600

Partial log.ini:

..........

<-!-> Error: Could not link mesh: 0
<-!-> Error: Could not link mesh: 1
<-!-> Error: Could not link mesh: 2
<-!-> Error: Could not link mesh: 3
<-!-> Error: Could not link mesh: 4
<-!-> Error: Could not link mesh: 5
<-!-> Error: Could not link mesh: 6
<---> Total polygons: 74981
<---> Total render vertices: 97028
<---> Total indices: 0
<---> Filename here: SGRASS.BMP
<-!-> SGRASS.BMP has an unknown bpp
<-!-> Unable to load texture SGRASS.BMP!
<-!-> Unable to load zone textures!
<-!-> Fatal Error: Unable to load zone data!

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.

[Tabasco]

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.

[Speedz]

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

[Speedz]

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.

[PixelEngineer]

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!

[Speedz]

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?