Source port idea! - Doomworld Forums

Doomworld Forums : Powered by vBulletin version 2.2.5

Doomworld Forums > Classic Doom > Source Ports > Source port idea!

Pages (12): « 1 2 [3] 4 5 6 » ... Last »

Author

All times are GMT. The time now is 23:29.

GhostlyDeath
Forum Retard

Posts: 1008
Registered: 08-05

Dragonsbrethren said:
https://itunes.apple.com/us/app/hel...d363510823?mt=8

Whichever port that is based off (provided it is a GPL port), the author of the source port can report the program to Apple stating that the program is illegal due to a license and copyright violation, if the application seller refuses to release the source code.

11-14-12 06:43 #

Profile || Blog || PM || Homepage || Search || Add Buddy

IP || Edit/Delete || Quote

Graf Zahl
Why don't I have a custom title by now?!

Posts: 7451
Registered: 01-03

Sodaholic said:

Let's just hope that they don't renew it.

It's not that simple.

First, patents have a finite lifetime. When it expires it's gone. End of story.

Second, you can't retroactively apply new patents to old inventions. In fact, if you try so, you may even get the patent voided because there's some 'prior art' demonstrating that you didn't really make the invention.

And these are probably the only 2 things even the best patent lawyer in the world can't overcome.

Interestingly the 2015 date only applies to the US. Since the rest of the world used a 20 years from filing lifespan there shouldn't be any valid MP3 decoding patents anywhere else but the US next month, 20 years after publication of the standard (that is, if you strictly stick to the reference decoder. It wouldn't surprise me if most software actually uses some more recent patents for quality improvement.)

11-14-12 07:15 #

Profile || Blog || PM || Email || Search || Add Buddy

IP || Edit/Delete || Quote

Ladna
Junior Member

Posts: 234
Registered: 04-10

I strictly mean "shipping". Like the GP2X couldn't include ZDoom out of the box. Downloading after the fact is fine. I'm guessing, like Ralphis said about WADs with similar restrictions, that this is to prevent BUILD from ending up in cereal boxes and shit.

Re: BSD, nothing prevents someone from packaging a BSD project up as a closed binary, in fact this happens all the time and BSD proponents consider this a feature of the license, not a flaw. Generally what they argue is that someone else distributing a binary doesn't change anything for you, but my opinion is that viewpoint's a little shortsighted. Communities and projects depend on people and people generally follow features, not licenses. Therefore, it's possible for a project to take BSD code, add several features, release only a binary, and effectively kill competing, open projects. If you think this is unlikely, I would point you at the development of ZDoom, where its ability to be closed has fractured the multiplayer community severely, maybe even beyond repair.

To be clear though, Super Corp can't swoop a BSD project and sue people for using the open version.

11-14-12 07:17 #

Profile || Blog || PM || Email || Search || Add Buddy

IP || Edit/Delete || Quote

Gez
Why don't I have a custom title by now?!

Posts: 9159
Registered: 07-07

GhostlyDeath said:

Whichever port that is based off (provided it is a GPL port), the author of the source port can report the program to Apple stating that the program is illegal due to a license and copyright violation, if the application seller refuses to release the source code.

It's legit.

11-14-12 08:10 #

Profile || Blog || PM || Search || Add Buddy

IP || Edit/Delete || Quote

Maes
I like big butts!

Posts: 10193
Registered: 07-06

Graf Zahl said:
It wouldn't surprise me if most [MP3] software actually uses some more recent patents for quality improvement.

Given how the MP3 algo works, I doubt it: it's quite open-ended (or should I say, open-started?) on the encoding stage (none prescribes how you should process/optimize your signal before saving it in the format dictated by the MPEG 1, Layer 3 specs, you could have a super-naive approximative encoder that runs in real-time even on a Z80 as well as one that takes 1 hour on a Quad Core to encode 1 minute of audio but manages near-CD Audio quality from 128 kbps), but it's quite single-ended in the final decoding stage: there's One And Only One way to correctly interpret the bits in the stream as frequency components and, at the end, sound waveforms.

Edit: my comment refers mostly to the playback end of MP3, which is also the most predominant and obvious, with so many devices supporting it. Yet, no improvements can be made on that end, just making sure they play back the (butchered) sound information no worse than it's expected to ("anti-artifact" sound enhancers and sound post-processors aren't really part of the decoder, unless they operate on the psychoacoustic model itself before it gets converted back to audio). On the encoding side however, you can get as creative as you can.

Last edited by Maes on 11-14-12 at 16:19

11-14-12 08:16 #

Profile || Blog || PM || Homepage || Search || Add Buddy

IP || Edit/Delete || Quote

hex11
Forum Staple

Posts: 2000
Registered: 09-09

Ladna said:

Therefore, it's possible for a project to take BSD code, add several features, release only a binary, and effectively kill competing, open projects. If you think this is unlikely, I would point you at the development of ZDoom, where its ability to be closed has fractured the multiplayer community severely, maybe even beyond repair.

Heh, by the same line of thought, the SP community is also fragmented beyond repair, with all the competing standards and implementations. And so is Linux, with its hundreds of distros. But it's not BSD that's causing this, it's people who want choice and freedom, which aren't possible with a single one-size-fits-all solution.

I mean, all these codebases could be 100% open-source and you'd still have fragmented userbase. They could all be 100% close-source and the same thing would happen.

Incidentally if someon takes your BSD code and implements some interesting features, then releases it closed-source, what's to stop YOU from implementing those same or simillar (maybe even superior) features. I mean, assuming those features are even worthwhile to begin with.

11-14-12 09:38 #

Profile || Blog || PM || Search || Add Buddy

IP || Edit/Delete || Quote

Quasar
Moderator

Posts: 5158
Registered: 08-00

I WOULD just like to note that nothing stops you from using a different mp3 decoding library and piping its output through the much-maligned SDL_mixer, or, just the SDL audio stream itself. Frankly SDL_mixer *is* best avoided, it has a number of idiotic flaws that are limiting Eternity.

11-14-12 14:11 #

Profile || Blog || PM || Email || Homepage || Search || Add Buddy

IP || Edit/Delete || Quote

Blzut3
Member

Posts: 377
Registered: 06-04

Ladna said:
I want to soapbox about the "asinine" GPL. The GPL restriction that you can't link against a non-free library is intended to ensure that software remains free. Imagine if the Apache devs suddenly decided that you needed to link against libpoison.so in order to run their webserver, and the source to that library is closed. That sucks, I hope it doesn't root my machine. I hope there aren't security vulnerabilities. I hope there aren't bugs.

You are allowed to fork right? :P More importantly, nothing would stop you from making an alternative to libpoison.so using the same ABI.

While I see your point, I don't exactly see the point of holding a project back simply because the free alternatives suck (SDL_mixer). More importantly though if someone is working on a build engine port, why should they not be allowed to use ZDoom's resource system? Certainly it isn't their fault build is not GPL. (Yes that's debatable, but I don't want to think of another example at the moment.)

Another example of the GPL being "asinine:" Why can't nVidia use DMA-buf? It's merely an issue of trying to force nVidia to open source their video driver (which, whether you think they should or not doesn't particularly matter since they may have code they can't share for whatever reason). The result is we can't have optimus graphics with the binary blob due to an idealist position.

I'm all for promoting open source, but it needs to provide a better experience for the end user. Otherwise you're only making yourselves look bad.

11-14-12 14:22 #

Profile || Blog || PM || Email || Homepage || Search || Add Buddy

IP || Edit/Delete || Quote

DaniJ
Senior Member

Posts: 1958
Registered: 08-03

The day NVidia opens the sources to it's driver (which is the best in the industry by miles) - I'll eat my hat.

11-14-12 15:09 #

Profile || Blog || PM || Search || Add Buddy

IP || Edit/Delete || Quote

hex11
Forum Staple

Posts: 2000
Registered: 09-09

Linux may have rejected it due to license, but OpenBSD wouldn't have even considered it due to security risk (same as any other binary blob).

11-14-12 17:22 #

Profile || Blog || PM || Search || Add Buddy

IP || Edit/Delete || Quote

Blzut3
Member

Posts: 377
Registered: 06-04

hex11 said:
Linux may have rejected it due to license, but OpenBSD wouldn't have even considered it due to security risk (same as any other binary blob).

Standard repository guidelines are a completely different topic. OpenBSD most likely wouldn't be able to stop nVidia from using the API, but can only make it more difficult for users to install. I don't really have a problem with that as that's pretty much how it is for Mac OS X and Windows.

Death Egg said:
but what hurdles would have to be jumped to make a dual Doom/Wolfenstein 3D engine source port?

Forgot I wanted to answer this in my last post. In terms of supporting both games simultaneously quite a bit. The Wolfenstein engine and the Doom engine are vastly different from each other in terms of game play mechanics and physics. You can make a hybrid engine (such as ECWolf and ROTT) which uses some parts of the Doom engine in Wolfenstein, but that doesn't make it play Doom.

The other option would be to have an engine like Doomsday and then separate the differences into plug-ins, but I don't exactly consider that a unified engine in the same way as ZDoom. (Since each game follows a walled off code path. At least that's how I understand it.) Doing otherwise would just be too much work for too little benefit and really wouldn't satisfy anyone.

The closest you can get with that approach is to do something like the Wolf3D TC for ZDoom. Which, while quite remarkable, really doesn't play anything like Wolf3D.

11-14-12 18:08 #

Profile || Blog || PM || Email || Homepage || Search || Add Buddy

IP || Edit/Delete || Quote

AlexMax
Senior Member

Posts: 1070
Registered: 01-03

Blzut3 said:
Another example of the GPL being "asinine:" Why can't nVidia use DMA-buf? It's merely an issue of trying to force nVidia to open source their video driver (which, whether you think they should or not doesn't particularly matter since they may have code they can't share for whatever reason). The result is we can't have optimus graphics with the binary blob due to an idealist position.

If Randi would have taken more idealist positions earlier in the last decade, there is a very good chance that ZDoom would be much less of a license quagmire than it is today, and we wouldn't be having this conversation about source port licenses. "Idealists" is not a derogatory word.

I'm all for promoting open source, but it needs to provide a better experience for the end user. Otherwise you're only making yourselves look bad.

This is a non-sequitor and doesn't follow from your first point, other than taking a pot shot at open source projects that don't capitulate to random vendor X's demands on a whim.

11-14-12 23:36 #

Profile || Blog || PM || Email || Search || Add Buddy

IP || Edit/Delete || Quote

Graf Zahl
Why don't I have a custom title by now?!

Posts: 7451
Registered: 01-03

AlexMax said:

other than taking a pot shot at open source projects that don't capitulate to random vendor X's demands on a whim.

The base blzut pointed out is a classic case of open source extremists trying to force their view upon others with no regards to the consequences.

If you want open source you have to compromise eventually just so that you can get what you need.

If certain companies ignore your software it may be your loss in the end, especially if you want to force some company like NVidia to make all their research public just to defend your ideal. The most likely answer you might get is 'F*ck you!'.

11-14-12 23:53 #

Profile || Blog || PM || Email || Search || Add Buddy

IP || Edit/Delete || Quote

DaniJ
Senior Member

Posts: 1958
Registered: 08-03

Blzut3 said:

The other option would be to have an engine like Doomsday and then separate the differences into plug-ins, but I don't exactly consider that a unified engine in the same way as ZDoom. (Since each game follows a walled off code path. At least that's how I understand it.) Doing otherwise would just be too much work for too little benefit and really wouldn't satisfy anyone.

I'm not following your logic here. Yes the game plugins are "walled off" but there is very little duplication as all the important tasks are handled by the engine. The only stuff in the game plugins is the game-specific stuff such as playsim logics, which, if I want to implement support for another game I'd need to replace in any case. Shared logics used by multiple id tech 1 games are placed in the shared libcommon library (which all currently supported games use).

This is effectively no different to ZDoom except that in Doomsday we are forced to cleanly abstract everything because the architecture demands it.

11-15-12 00:03 #

Profile || Blog || PM || Search || Add Buddy

IP || Edit/Delete || Quote

AlexMax
Senior Member

Posts: 1070
Registered: 01-03

Graf Zahl said:
The base blzut pointed out is a classic case of open source extremists trying to force their view upon others with no regards to the consequences.

If you want open source you have to compromise eventually just so that you can get what you need.

Linux is one of the largest open source projects in the world almost precisely because the kernel developers come from many different backgrounds and on the whole tend to favor pragmatism over GNU-style dogma.

FreeBSD has had nVidia drivers in ports since forever. How much good did that do it? I don't think the linux kernel developers are crying themselves to sleep at night over the fact that nVidia doesn't want to follow in the footsteps of Intel, AMD and other graphics card vendors.

11-15-12 00:41 #

Profile || Blog || PM || Email || Search || Add Buddy

IP || Edit/Delete || Quote

Blzut3
Member

Posts: 377
Registered: 06-04

AlexMax said:
"Idealists" is not a derogatory word.

It wasn't supposed to be. The point is that working in an idealist world you neglect what your consumers actually want. The DMA-buf stuff is an example of "we want optimus support so we can get good battery life," and someone going "be open source then." It's "asinine" to think that that gets us anywhere.

AlexMax said:
This is a non-sequitor and doesn't follow from your first point, other than taking a pot shot at open source projects that don't capitulate to random vendor X's demands on a whim.

That point wasn't necessarily related to the nVidia issue. What I was getting at is that being open source doesn't excuse you from competing with non-free software. To your average user they are the same. It doesn't help to be an idealist (use the GPL) if the user experience degrades because of it.

Especially if being non-free is simply a matter of being not for commercial use. All the average user cares about is that their beer is free. :P

DaniJ said:
This is effectively no different to ZDoom except that in Doomsday we are forced to cleanly abstract everything because the architecture demands it.

Right. The difference though is that for ZDoom we just have a few flags we set based on the IWAD (for some basic hacks and what not) and then run everything in precisely the same way. This means in a hypothetical ZDoom+ZWolf we would have to support every difference in a way that they can operate simultaneously (unified playsim) since it's realistic that you might want to mix Hexen and Wolf things together. I would think this would be difficult to pull off while remaining relatively faithful to both games.

From what I can tell the Doomsday approach would not allow uncommon behavior to be mixed as freely. Much easier to support games for dissimilar engines this way, but it would result in each game having slightly different features (best word I can come up with atm). Nothing wrong with that approach of course, but it does depend on what the user is looking for.

11-15-12 00:42 #

Profile || Blog || PM || Email || Homepage || Search || Add Buddy

IP || Edit/Delete || Quote

DaniJ
Senior Member

Posts: 1958
Registered: 08-03

Blzut3 said:

Right. The difference though is that for ZDoom we just have a few flags we set based on the IWAD (for some basic hacks and what not) and then run everything in precisely the same way.

This is logically no different to what Doomsday does however we don't have constructs like "if doom do X else if Hexen do Y". As I said, its effectively the same thing but at a higher level of abstraction.

This means in a hypothetical ZDoom+ZWolf we would have to support every difference in a way that they can operate simultaneously (unified playsim) since it's realistic that you might want to mix Hexen and Wolf things together. I would think this would be difficult to pull off while remaining relatively faithful to both games.

And this is where our respective philosophies differ. We don't believe that anyone really wants to mix the monsters from multiple games. And that on its own is certainly not reason enough to chuck it all into a single monolithic binary. Particularly when the stuff you are talking about is ideally implemented in script form, which wouldn't need to be in a/the binary in any case.

Ultimately both ports will in all likelihood end up with roughly the same architecture. The difference is that Doomsday uses it already.

11-15-12 01:27 #

Profile || Blog || PM || Search || Add Buddy

IP || Edit/Delete || Quote

Blzut3
Member

Posts: 377
Registered: 06-04

DaniJ said:
monolithic

Ahh. There's the word I was looking for.

DaniJ said:
Ultimately both ports will in all likelihood end up with roughly the same architecture. The difference is that Doomsday uses it already.

Highly doubtful. From what I've heard from you Doomsday has a much greater scope than ZDoom (IIRC you said you want to make a generic engine for 2.5D games?). As far as ZDoom is concerned, excepting Doom 64, I think we have support for every game we care to support. I feel having a different port for each distinct engine is the way to go. Which is why I would have no interest in trying to merge ECWolf and ZDoom despite sharing some code.

Especially since both projects use the classic renderer from the respective games. Even if the common code was exported into a library, that library would hardly be a game engine by any stretch of the imagination (it mostly would consist of archive/texture management).

11-15-12 02:08 #

Profile || Blog || PM || Email || Homepage || Search || Add Buddy

IP || Edit/Delete || Quote

DaniJ
Senior Member

Posts: 1958
Registered: 08-03

It stands to reason that both ports will end up with similar architectures. Given Doom Script becomes a reality the ZDoom playsim will be externalised meaning that individual games become little more than a set of external scripts and definitions.

ZDoom may not require the same degree of architectural flexibility that Doomsday does (you are correct that we intend for a generic 2.5D engine) but from a technical POV, this *is* the better design given you care to implement it. The ability to add new native code to support a given game in the form of a plugin (which could be done by a third party) only adds to this flexibility (for example, one could extend the base classes used by the engine to add additional functionality).

In ECWolf's case, I have to say that I think having your own software renderer will only hurt you in the long run given you intend to track ZDoom and assume (some of) it's modding feature set. I would have thought the better solution would be to extend ZDoom's existing renderer (they aren't that different IMO).

11-15-12 02:29 #

Profile || Blog || PM || Search || Add Buddy

IP || Edit/Delete || Quote

Graf Zahl
Why don't I have a custom title by now?!

Posts: 7451
Registered: 01-03

DaniJ said:

We don't believe that anyone really wants to mix the monsters from multiple games.

It's not about 'mixing monsters'. Monsters are merely a set of external definitions, just with the action function code being native.

But the various games define a lot more than just monsters. For example:

- Heretic, Hexen and Strife have an inventory. Doom does not but inherits the feature from the common implementation.
- Hexen implements a new map format which now all games can use
- Strife has the dialogue system which is also available to all games.
- there's various different powerup types in the different games. Morphing, for example is much more flexible with being able to define your own morphed classes.

Besides, one can also use the other games' weapons and monsters as templates to be filled in by one's own resources. There's several mods out there which reskin some Heretic, Hexen or Strife weapons/monsters for use in Doom projects. The mere availability of the code, without using the actual monster is also worth something.

11-15-12 07:10 #

Profile || Blog || PM || Email || Search || Add Buddy

IP || Edit/Delete || Quote

DaniJ
Senior Member

Posts: 1958
Registered: 08-03

The way I see it the reason you wanted those features in all games is because they were technically a better solution to a common/shared problem. This isn't quite the same as what was being argued - that having all the code from all games in the same executable is inherently better (its not).

Doomsday also makes Hexen map format available to all supported games, so too DEH, however this is implemented in such a way where the game doesn't even know about it (though note that they aren't actually usable yet due to other issues we've not yet addressed). I expect ZDoom has a similar setup however in Doomsday we do this at a higher level (e.g., map and definition format plugins).

Your points about using the logic of one games' components as the base for another are moot because once this stuff has been externalised it is possible in any case, regardless of the architecture.

11-15-12 07:40 #

Profile || Blog || PM || Search || Add Buddy

IP || Edit/Delete || Quote

Blzut3
Member

Posts: 377
Registered: 06-04

DaniJ said:
The way I see it the reason you wanted those features in all games is because they were technically a better solution to a common/shared problem. This isn't quite the same as what was being argued - that having all the code from all games in the same executable is inherently better (its not).

I think saying that one way or the other is inherently better is kind of short sighted. I certainly wasn't trying to argue one way was better than the other. The monolithic approach has its merits when it comes to content sharing. The micro-engine (to try to equate to kernel design) approach works better for supporting a wider array of games. Which is not to say that you can't have shared content with your approach, just that it isn't to the extent one would expect from a monolithic approach. Which is better comes down mostly to user expectations. In my case, I believe the monolithic approach is the right way to do things. That is all.

Doomscript/ZScript isn't fundamentally changing anything here since we still have to maintain backwards compatibility. In terms of third party games though you may be right in that it is similar to your architecture, but in interpreted form. I guess time will tell here.

11-15-12 14:34 #

Profile || Blog || PM || Email || Homepage || Search || Add Buddy

IP || Edit/Delete || Quote

GhostlyDeath
Forum Retard

Posts: 1008
Registered: 08-05

DaniJ said:

This is logically no different to what Doomsday does however we don't have constructs like "if doom do X else if Hexen do Y". As I said, its effectively the same thing but at a higher level of abstraction.

In ReMooD, there are no "if doom/hexen/heretic". Things that control the game state are all variables. Which means you can use Heretic-gibbing in Doom, etc. Just that, if you choose to play Heretic or Doom or whatever, it will set the default settings for you to match said game closer.

11-15-12 14:41 #

Profile || Blog || PM || Homepage || Search || Add Buddy

IP || Edit/Delete || Quote

Quasar
Moderator

Posts: 5158
Registered: 08-00

Eternity is in the process of abstracting all such decisions into the GameModeInfo structure, which is selected at startup. That way there are not branches on gamemode/gamemission everywhere as was happening in BOOM (add Heretic etc onto that mess and you have yourself a nightmare).

11-15-12 23:00 #

Profile || Blog || PM || Email || Homepage || Search || Add Buddy

IP || Edit/Delete || Quote

AlexMax
Senior Member

Posts: 1070
Registered: 01-03

Blzut3 said:
It wasn't supposed to be. The point is that working in an idealist world you neglect what your consumers actually want. The DMA-buf stuff is an example of "we want optimus support so we can get good battery life," and someone going "be open source then." It's "asinine" to think that that gets us anywhere.

Slopes are not proprietary, undocumented and vendor-specific API's in binary blobs. Randi even mentioned that he knew how to finish the work, he just copypsated code to save time. If he hadn't, would ZDoom be in a significantly worse place than it is today? Or if ZDoom had not started the precedent of allowing a patent-encumbered music format in WAD files, would it be significantly worse off? Would the simple act of clicking "Export to Ogg" vs "Export to MP3" had caused map authors to throw up their arms and map for Legacy or SMMU instead?

Implying that ZDoom is as popular as it is because it shunned the GPL is pretty disingenuous. There are tons of great features in it under the ZDoom license proper. It's just that the BUILD and FModEx landmines feel like they could have been avoided with a little foresight.

But of course, I'm getting off on a tangent. The point is that as long as "proper" GZDoom continues to exist, I don't see what's wrong with a working libre' fork that is 99% functional aside from music formats that are widely expected to become unencumbered in the near future anyway.

Last edited by AlexMax on 11-16-12 at 05:12

11-16-12 04:51 #

Profile || Blog || PM || Email || Search || Add Buddy

IP || Edit/Delete || Quote

Blzut3
Member

Posts: 377
Registered: 06-04

AlexMax said:
FModEx landmines

Given that no one has been able to produce an adequate replacement for fmodex, yes ZDoom is better off with it. :P

AlexMax said:
But of course, I'm getting off on a tangent. The point is that as long as "proper" GZDoom continues to exist, I don't see what's wrong with a working libre' fork that is 99% functional aside from music formats that are widely expected to become unencumbered in the near future anyway.

The problem is no one apparently wants to do it. The OpenAL branch is the closest we have, but that has more issues than just MP3s not playing (IIRC it has MP3 playback anyways).

11-16-12 14:08 #

Profile || Blog || PM || Email || Homepage || Search || Add Buddy

IP || Edit/Delete || Quote

Graf Zahl
Why don't I have a custom title by now?!

Posts: 7451
Registered: 01-03

Blzut3 said:

The problem is no one apparently wants to do it. The OpenAL branch is the closest we have, but that has more issues than just MP3s not playing (IIRC it has MP3 playback anyways).

The main problem is that it only works on Linux and that all sound format functionality comes from a library that's a pain in the ass to use on Windows and certainly can't be distributed along with ZDoom due to its gigantic size. And of course the code is tied too closely to that monster.

11-16-12 20:32 #

Profile || Blog || PM || Email || Search || Add Buddy

IP || Edit/Delete || Quote

GhostlyDeath
Forum Retard

Posts: 1008
Registered: 08-05

Graf Zahl said:

The main problem is that it only works on Linux and that all sound format functionality comes from a library that's a pain in the ass to use on Windows and certainly can't be distributed along with ZDoom due to its gigantic size. And of course the code is tied too closely to that monster.

OpenAL works on more than just Linux.

11-17-12 17:03 #

Profile || Blog || PM || Homepage || Search || Add Buddy

IP || Edit/Delete || Quote

Gez
Why don't I have a custom title by now?!

Posts: 9159
Registered: 07-07

OpenAL isn't the problem. But OpenAL doesn't do everything, so it uses GStreamer as well; and it's GStreamer which is the problem on Windows. It is not preinstalled, it has a ton of dependencies, and it is quite large and hard to compile.

11-17-12 17:15 #

Profile || Blog || PM || Search || Add Buddy

IP || Edit/Delete || Quote