Normals in Shading / Sounds needed / Fedora Extras Packaging

[Entropy]

The artwork is under a proprietary license, like most of the other games do. For example, the Quake code is GPL, but the art is not.

People can use the client for other projects, but not the artwork.

[KarenRei]

The artwork is under a proprietary license, like most of the other games do. For example, the Quake code is GPL, but the art is not.

People can use the client for other projects, but not the artwork.

 

Darn. Darn, darn, darn. Fedora requires that packages meet the OSI definition, which states that:

 

"3. Derived Works

 

The license must allow modifications and derived works, and must allow them to be distributed under the same terms as the license of the original software.

 

Rationale: The mere ability to read source isn't enough to support independent peer review and rapid evolutionary selection. For rapid evolution to happen, people need to be able to experiment with and redistribute modifications.

 

4. Integrity of The Author's Source Code

 

The license may restrict source-code from being distributed in modified form only if the license allows the distribution of "patch files" with the source code for the purpose of modifying the program at build time. The license must explicitly permit distribution of software built from modified source code. The license may require derived works to carry a different name or version number from the original software.

 

Rationale: Encouraging lots of improvement is a good thing, but users have a right to know who is responsible for the software they are using. Authors and maintainers have reciprocal right to know what they're being asked to support and protect their reputations."

 

Accordingly, an open-source license must guarantee that source be readily available, but may require that it be distributed as pristine base sources plus patches. In this way, "unofficial" changes can be made available but

readily distinguished from the base source.

---

 

I could propose to have the artwork, etc be downloadable as a seperate package, but I doubt that they'd accept it a client that doesn't do anything without a proprietary download. Things that are "crippled" in some way are okay (for example, xmms without mp3 support), but without *any* functionality, I doubt they'd take it.

[emajekral]

If you've got the packages ready would one of the major unofficial Fedora Core repositories, such as rpms.livna.org or RPMForge, be interested?

 

See also http://www.fedorafaq.org/

Edited October 15, 2006 by emajekral

[KarenRei]

If you've got the packages ready would one of the major unofficial Fedora Core repositories, such as rpms.livna.org or RPMForge, be interested?

 

See also http://www.fedorafaq.org/

 

I suppose that's my only choice. They don't have as wide of a distribution base as Fedora Extras, but they'll do. I'm not an RPMforge or Livna developer already, as I am with Fedora, so this will take longer.

[Entropy]

Are you sure that license doesn't apply only to the source code? Most of the OSS licenses are used exclusively for the code.

[ttlanhil]

actually, I have an intel wireless card in my lappy, ipw2100 drivers work for it (as far as I know), but it requires binary firmware (and I'm pretty sure that I got the firmware package from fedoras main reps, not livna)

I dunno if there's some special case for that, if not, then there's an example of a package with binary (not open source) code, not just data files, already in there (for more info, firmware_faq.php)

Edited October 15, 2006 by ttlanhil

[KarenRei]

actually, I have an intel wireless card in my lappy, ipw2100 drivers work for it (as far as I know), but it requires binary firmware (and I'm pretty sure that I got the firmware package from fedoras main reps, not livna)

I dunno if there's some special case for that, if not, then there's an example of a package with binary (not open source) code, not just data files, already in there (for more info, firmware_faq.php)

 

You sure about that? Because Fedora specifically bans the NVidia and ATI drivers because they're proprietary, even though they're essential to a proper system with NVidia or ATI cards (which is most cards).

[ttlanhil]

You sure about that?

not certain, no... could have been after I added livna that I got the package for the firmware

I'm usually running under windows, so I can't go check the package info and stuff 8^/

Edited October 16, 2006 by ttlanhil

[dns_server]

With debian there is a non-free section of the repository i believe it is possible for debian to have a package split between the free and non-free packages. For example there is a package called doom-wad-shareware, this contains the data files for doom and it is non-free, then there are open source ports that depend on this (or an equvelent dummy package) that are considered free.

 

So i suggest you distribute 2 packages, eternal-lands-bin and eternal-lands-data (non free) but it may be confuseing to the users.

[KarenRei]

With debian there is a non-free section of the repository i believe it is possible for debian to have a package split between the free and non-free packages. For example there is a package called doom-wad-shareware, this contains the data files for doom and it is non-free, then there are open source ports that depend on this (or an equvelent dummy package) that are considered free.

 

So i suggest you distribute 2 packages, eternal-lands-bin and eternal-lands-data (non free) but it may be confuseing to the users.

 

I don't have Debian, so I can't really develop for Debian. However, I do have good news: we're now in ATrpms Bleeding (bleeding edge -- packages go there before they're moved into the main distro to give time for bug reports to be made). Soon, anyone with ATrpms set up as a repo (ATrpms gets 15,000 unique hits per day) will be able to type "apt-get install eternallands" or "yum install eternallands" and get the game installed and ready to use.

 

I've also set the permissions so it can handle pushed updates to models, maps, artwork, etc.

 

Next up, I'm working on eye candy; it's going quite well; textured point sprites are oh-so-pretty and draw fast enough that you can use plenty of them. I already have a gravity-motion system with built-in error correction that can track a moving object, an IFS particle spawner (IFS = Iterative Function System -- a type of fractal generator; this way, it can do things like have particles rise off of 2d or 3d patterns, and even have the patterns morph), and am mostly through adding in timed events (so it can do things like fireworks-style explosions or sparkling). Motion blur is also on my list. After that, I'll need to make a bunch of presets for each effect that we want, then incorporate it into the game.

 

After I finish with eye candy, I'll work on the lighting model. That should be a pretty easy task, at least the first part. Normal mapping will take more time, obviously.

[Entropy]

Great job, keep up the good work!

[mikeman]

Hey KarenRei, as far as the lighting goes maybe I can give you some hints that will help you when you implement it. Most of the things you mention can be attributed to:

 

1) Ambient lighting. As others have said, at night there is no sun, only local lights that have a certain (spherical) area of influence. Beyond that, everything gets a constant amount of lighting. If you lowered the ambient and maybe add an additional directional light that represents the moon?

 

2) Vertex lighting. All the models have normals, but the lighting is calculated only at the vertices, not on the whole surface of each polygon. You'll see this in static geometry, because character models have a higher tesselation and they don't suffer from the problem this much. A large polygon with a small light in its centre will look all dark, because its corners are dark. A large polygon with small lights close to its corners will look all light, because its corners are lit, and so on. You can implement plain per-pixel lighting(which does not require normal maps) or normal mapping to fix that.

 

3)One other thing I noticed, at least when I was working on the code, is that EL takes into account only the lights that are visible from the camera's POV. This is not entirely correct, because a light maybe invisible but you can see its effect on visible geometry(for example, a torch out of view lighting a box inside the view). I noticed some incorrect lighting/popping due to this.

 

-EDIT: Ooops, I see you adressed those issues in page 1, sorry Anyway...

Edited October 20, 2006 by mikeman