Anyone interested in client development?

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

[Taurinus2]

Hey PixelEngineer,

Have you checked out SOIL?

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

[PixelEngineer]

Originally Posted by Taurinus2

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.

[Taurinus2]

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.

[PixelEngineer]

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.

[PixelEngineer]

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.

[Speedz]

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.

[PixelEngineer]

Originally Posted by Speedz

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.

[Vexyl]

Originally Posted by Speedz

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.

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.

[Speedz]

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