Jump to content
Search In
  • More options...
Find results that contain...
Find results in...


  • Content count

  • Joined

  • Last visited


About Ferk

  • Rank

Recent Profile Visitors

1598 profile views
  1. You also have AGPL which forces publishing the server-side source code for server software. The choice mainly depends on how much they want to allow third parties to use that code for proprietary closed source products. Or whether they want to be able to take back code contributed by others and include them into proprietary versions of the engines they release in the future. A large library project can perfectly choose to go GPL instead of LGPL if the intention is for it to be used only in open source projects and not be mixed up with closed source or more permissively licensed software. I think the only reason to go for MIT/BSD/Apache is to allow the integration of that code back into proprietary products. It's up to the licenser to decide whether they want to allow that. Personally I think GPL (and AGPL for server software) is the most community-friendly. It might not be the most permissive, the one that gives more freedom to entrepreneurs or the easiest to monetize, but it's the one that incentivizes the open distribution of source code the most since it makes impossible (legally) for someone to modify it without contributing the changes back to the community.
  2. The corporate world is constantly changing. Back in the late 90s Google was the cool new kid and MS the evil corporation. Not only did Id change, also Microsoft changed as did Google. I'm not saying that in MS they are saints, but they are definitely more friendly with the community than they used to, for their very own sake they have had to change gears in several topics. And the videogame market is one where they are the counterbalance to giants like Sony which I'd rather not have them become a new gaming monopoly. At least with MS they are committed to PC gaming (even Halo is now on PC), as long as a game is on PC and as long as PC keeps being an open platform I'd not consider that an exclusive. If you don't want to support exclusivity and walled gardens then you should be avoiding consoles anyway. In fact, if you truly wanted to avoid big corporations then you probably should be gaming on Linux using only open source or indie games under some puri.sm hardware and avoiding AAA titles, so none of these big firm deals would be making a difference to you.
  3. Ferk

    [FINAL RELEASE] Eviternity

    I don't know how "final" is "[FINAL RELEASE]" meant to be, but if there ever is will for a new release it would be great if UMAPINFO lump was added so the episodes / intermissions work as intended in PrBoom+um
  4. Ferk

    What's the deal with the sailor

    I was thinking... another idea could be using sprites from C-Dogs SDL (which is also Free and Open Source, assets are CC0/CC-BY/CC-BY-SA ..though we would need to ask which character graphics would be available in CC0 for it to be used in Freedoom). The angle is a bit different though, but I wonder if it'd still be serviceable. Btw, unrelated but they have already done tribute to Doom themselves before by making a campaign heavily inspired by it:
  5. Ferk

    What's the deal with the sailor

    The only issue with Shadow/Rise of the Woolball´╗┐´╗┐ sprites is that they don't have rotations, while the SS guards are meant to have them.
  6. Ferk

    PrBoom+/UMAPINFO v

    True, the syntax is slightly different, but I don't think the same syntax from the cfg needs to be used for the lump. And the port just needs to read the lump, not write it, so things like help comments being different would not matter much, any line that isn't a known option can just be ignored. I meant many of the options themselves and their names are the same.
  7. Ferk

    PrBoom+/UMAPINFO v

    Eternity added many new features to its OPTIONS that are not compatible with MBF. When an option is not recognized it's ignored. At least that's what PrBoom does when parsing prboom.cfg and I would expect the same from eternity.cfg and mbf.cfg, many options are already the same since all three are descendants from the same family of ports.
  8. Ferk

    Prboom+ Controller Support?

    It has some issues still (demo desyncs, weird-sounding opl...) but the libretro PrBoom port is PrBoom+ compatible (even supports UMAPINFO) and it does have controller support. Now it also supports Retroarch savestates, which allows it to do rewinding (kind of like in Prince of Persia Sands of Time), which is something I haven't seen in any other port.
  9. Ferk

    PrBoom+/UMAPINFO v

    One idea could be having support for the OPTIONS lump which Eternity and MBF already support: https://eternity.youfailit.net/wiki/OPTIONS This would allow PWADs to set some preferred default values for several settings, including fine-grained compatibility flags. But these should just be defaults, the user should still have freedom to change the settings, imho.
  10. Ferk

    PrBoom+/UMAPINFO v

    Personally I don't think UMAPINFO would be the right place to add compatibility flags. It's meant to be a cross-port standard. For preserving demo compat it would be better to use the new demo format extensible header for which there's an open PR.
  11. The "Dropped item" field is already in both Crispy and PrBoom+ (other than Doom Retro). But I don't know if the other ones are meant to, I don't know if maybe they are too specific to Doom Retro. There were also these additional fields that were merged in Crispy with the idea of dehardcoding some of the vanilla behavior, but they haven't been added to other ports yet (should I open a PR in PRBoom+ for it?): - Melee threshold: distance to switch from missile to melee attack - [the vanilla Revenant has 196 as threshold] - Max target range: Maximum distance range to start shooting (zero for unlimited) - [the vanilla Archivile has 14*64 as limit] - Min missile chance: Minimum chance for firing a missile [standard value from vanilla is 200, except Cyberdemon being 160, the lower the number the higher minimum likelihood] - Missile chance multiplier: multiplier that factors the likelihood of missile attack (FRACUNIT being the base value, lower values will proportionally increase the firing chance, while higher values will reduce it) - [Cyberdemon, Spider Mastermind, Revenant and Lost Souls have FRACUNIT/2 making them fire twice as often in vanilla]
  12. Ferk

    Super 3D Noah's Ark Is Now on GOG

    There's also the missing chapter from the bible when Noah saves us from the invading aliens who are allergic to earthling food.
  13. At least in C it only applies to specific methods that deal with strings, not everywhere, and you can use sizeof: int a[40] = {[2] = 6, [4] = 12}; printf("size: %lu\n", sizeof(a)/sizeof(int)); // size: 40 I'm not sure if you can do something like that in Lua a = {[2] = 6; [4] = 12} print("size:", #a) -- size: 0 print("size:", table.getn(a)) -- size: 0
  14. The "everything is a hashtable" in lua is also problematic with arrays, it's hard to trust if the size count is reliable, a "nil" value inside the array will make the size calculation stop in that element. It also has some very weird quirks (like being 1-based instead of 0-based) and in general the language is a bit more tedious to write than something like python (not just because of the syntax, but lacking some conveniences like some standard methods not returning the value back, no "+=" operators and things like that which force you to be a bit more verbose in some moments were using those would have helped with clarity).
  15. I didn't mean they are the same. What I implied in my second paragraph (which was sort of a separate comment) is that the best way to be really safe and ensure the job is consistently good is to have a mathematical model that deterministically can find that solution. Yes. Any attempts have failed so far, except targetted solutions. Also things like image recognition, translation, machine learning, etc, they are basically programs coding other programs for very targetted and specific applications. Yet in several cases it resulted in algorithms much more accurate than what any coder could have possibly written manually. The day that a generalized AI can produce evolutionary algorithms by itself is probably very far away, if ever possible. So that's why we still need coders that know what they are doing. But this is going off-topic, sorry.