[markanini]

Hendricks266, on 07 September 2020 - 03:40 PM, said:

http://meatballwiki....iki/HostileFork

A better example than the one given here is libav vs ffmpeg.

So it's a socialist term that Richard Stallman would approve. I'd be ashamed to use such terminology.

[Phredreeke]

markanini, on 19 September 2020 - 04:39 AM, said:

So it's a socialist term that Richard Stallman would approve. I'd be ashamed to use such terminology.

[Phredreeke]

Palette emulation is working again now in the dev build.

[Phredreeke]

Hendricks266, on 28 August 2020 - 02:27 PM, said:

Accurate palette emulation, accurate sound mixing, Fury's new game menu, SSI file loading for the Sunstorm expansions, and Adlib music from the best-in-class Nuked OPL are all casualties of Raze's development principles.

Makes this post all the more ironic. https://forum.zdoom....p?f=342&t=70127

[NightFright]

Well, if you want to use Raze, it ain't gonna be for its amazing OPL synth, then.

[jkas789]

Phredreeke, on 09 October 2020 - 11:43 AM, said:

Makes this post all the more ironic. https://forum.zdoom....p?f=342&t=70127

Im sorry but why would the current liscence limit what type of audio synth (did I understood right?) Raze can use. Im asking out of curiosity and pure ignorance here.

[Player Lin]

jkas789, on 10 October 2020 - 03:33 PM, said:

Im sorry but why would the current liscence limit what type of audio synth (did I understood right?) Raze can use. Im asking out of curiosity and pure ignorance here.

https://forum.zdoom....169588#p1169588
https://forum.zdoom....169595#p1169595

According those posts, seems like some sort of license in-compatible.
(Graf's code using LGPLv3, not comparable with GPLv2 with EDuke32 and Nuke.YKT's ports using, and without upgrade clause)
They just avoiding any possible license loophole or something that they think it'll be problem(s) in future.

I know EDuke32 team or others don't care Graf and their "clearly/better licensing blah blah" so whatever, just saying. :3

[Doom64hunter]

Player Lin, on 05 November 2020 - 08:42 AM, said:

https://forum.zdoom....169588#p1169588
https://forum.zdoom....169595#p1169595

According those posts, seems like some sort of license in-compatible.
(Graf's code using LGPLv3, not comparable with GPLv2 with EDuke32 and Nuke.YKT's ports using, and without upgrade clause)
They just avoiding any possible license loophole or something that they think it'll be problem(s) in future.

I know EDuke32 team or others don't care Graf and their "clearly/better licensing blah blah" so whatever, just saying. :3

My takeaway from it is that the "Free" in FOSS isn't as free as some people might think it is.

If you truly want to make your code reuseable without a huge hassle, avoid copyleft.

[enderandrew]

Doom64hunter, on 05 November 2020 - 11:47 AM, said:

My takeaway from it is that the "Free" in FOSS isn't as free as some people might think it is.

If you truly want to make your code reuseable without a huge hassle, avoid copyleft.

Open source licenses and copyleft can be absolutely fine and hassle free. Share-alike by itself is not difficult.

The problem is that Stallman believes the only form of freedom that exists is a lengthy set of restrictions he agrees with to get what he wants. His licenses are not designed to play well with other licenses.

Stallman also went on record saying he things Mozilla and Google are the enemies of open source. He attacks his strongest allies. With Firefox, you can install whatever themes, extensions or plugins you want as a consumer. Stallman thinks the only true meaning of free is to tell consumers they can't do what they want and have the browser block all themes, extensions and plugins that aren't GPL.

[Jimmy]

enderandrew, on 05 November 2020 - 03:18 PM, said:

With Firefox, you can install whatever themes, extensions or plugins you want as a consumer.

Hahahahah imagine believing this is true.

[markanini]

enderandrew, on 05 November 2020 - 03:18 PM, said:

Open source licenses and copyleft can be absolutely fine and hassle free. Share-alike by itself is not difficult.

The problem is that Stallman believes the only form of freedom that exists is a lengthy set of restrictions he agrees with to get what he wants. His licenses are not designed to play well with other licenses.

Stallman also went on record saying he things Mozilla and Google are the enemies of open source. He attacks his strongest allies. With Firefox, you can install whatever themes, extensions or plugins you want as a consumer. Stallman thinks the only true meaning of free is to tell consumers they can't do what they want and have the browser block all themes, extensions and plugins that aren't GPL.

it says a lot about Stallman and his fan boys.

[jkas789]

enderandrew, on 05 November 2020 - 03:18 PM, said:

With Firefox, you can install whatever themes, extensions or plugins you want as a consumer.

On old firefox, sure. On quantum? not so much. I also love firefox but I think it is going the way of the dodo and so already switched to google for my everyday use and TOR for my paranoid days.

[Jimmy]

Use Brave. It literally pays you to browse, has TOR built in, and really pisses off a lot of people purely by existing.

[Tea Monster]

Chrome is fun. They ask you to sign in on the privacy tab, then ask you to accept cookies...

... on the privacy tab.

[MusicallyInspired]

I'm still using Firefox. Every now and then I go to Brave to see if it's caught up but there is always something missing in the experience (can't think of it offhand at the moment) that I'm just too used to with Firefox. Something small and irritating. Like it's still rough around the edges. Eventually I'll switch over for good. I'll never use Chrome again.

[jkas789]

Huh, Raze got updated to 0.73.

Going by the changelog this seems to be a substantial update (I think?). That's cool I suppose. The first thing that would make this even remote usable for me would be able to use the voxel mods, which afaik don't work (and probably will not work).

[Phredreeke]

I don't see why voxel mods wouldn't work...

[Tea Monster]

Depending on how he's coded it, you may need to change how the defs are written. I don't know much about voxels though so I couldn't say.

[NightFright]

I doubt Graf cares much about how we do things over here. You probably would have to write all-new defs.

[mjr4077au]

I watch this thread all the time but have always beem hesitant to reply as I'm unsure whether I'm in the lion's den or that I'm more welcome than I realise. While there's many comments here I'd like to address, I'll probably just sum things up:

Raze's name is inspired by how Ken wanted to name his engine. Ken wanted a single syllable synonym of construction, so he chose Build. The antonym of construction is demolition (which Raze was going to be called) and a single syllable synonym of that is Raze. There is no further meaning behind the name other than being the opposite of Build.

ZScript has been talked about as a Doom-specific language that's getting bolted on. ZScript was designed to be game-agnostic from the ground up and as such could be used in any game or any program wanting scripting capabilities. The main reason ZScript exists is because AngelScript can't have script objects inherit from native objects in a seamless fashion. This is why Blood FS exported all native actor code to AngelScript. By using ZScript, the native code can be maintained for speed and accuracy.

Raze isn't going out of its way to be unfaithful and in fact until the game's main loops and networking code was consolidated, the NBlood component still played vanilla demos with no de-syncing. So while the original demos aren't playable, it does not imply we're an inaccurate port but I acknowledge without capability of playing the original demos it might seem as such. If there's something not accurate, that's a bug that should be fixed, and would appreciate any such reports.

Raze is not in any way an attempt to be a hostile fork, though I appreciate the perception that it might have been due to comments on various forums that indicated as such. Graf also opted to license all of his code under the 3-clause BSD license and requested other GZDoom contributors who source contributes to Raze to do the same thing. This is a very permissive, GPL-compatible license and allows our code to be included in EDuke32 and used with IF binaries, should the team deem anything we've done worthy enough for inclusion.

We're trying to do our own thing in our own way and the removal of the EDuke32 component will allow us to achieve that without the breaks in compatibility with EDuke32 that we had. It should show that we can manage the game-side code without having to reply on syphoning code from upstream ports and also puts us in a somewhat unique position where original EDuke 2.0 mods that can't be played on GDX or are no longer compatible with EDuke32 play fine.

Raze isn't about superseding any other ports or diminishing the significance of other ports, Raze is just another choice amongst a great list of ports one can choose from. GZDoom for instance does not affect the popularity of Chocolate Doom, and Raze probably won't affect the popularity of EDuke32, RedNukem or NBlood either. All of our ports have a specific design goal and aim and the audience will choose whichever one feels right to them.

I don't really want there to be bad blood between communities or for there to be rivalry or continued shit slinging from either side of the fence. I fully acknowledge that I've contributed to that angst in the earlier days, either on a forum or on Discord but it's not appropriate. I've tried to right wrongs by working with NY00123 on uplifting VoidSW to having fixed-point mouse input like EDuke32 does and by porting jfaudiolib's ALSA MIDI support into EDuke32's audio library.

I think a lot of people are still wondering about what Raze is doing and what its goals are. There has been a start on making Duke's actor code more accessible to ZScript and that will continue in time for the other games, but Graf has decided to re-engage with his original focus of improved rendering while we further evaluate the direction in which to take regarding scripting as each game manages actors differently. By working on the renderer, Graf can do what he does best and this will provide highly visible changes that people will respond to however they wish to.

Other things we've improved are interpolations by way of GZDoom's timing code, interpolated look_ang for Duke which gives that really nice and smooth panning when each new level starts, unsynchronised mouse input for Exhumed, along with an options menu for various bits and pieces within that game, internationalisation for game strings and content, plus many other minor things. There are of course divisive improvements like using OpenAL which might be better for some and not for others, but again that why players have the luxury of choice when it comes to ports.

I'm unsure what kind of replies I will get but I hope what I've said here is taken as an open letter of sincerity. We're just a small team of three guys in what's ultimately a smaller community than others like Doom. Rather than a continued divide, it'd be great if there was increased unity between camps as I strongly feel that more options irrespective of which one a player opts for will increase interest in these classic games and ultimately increases the community size as a whole.

jkas789, on 10 November 2020 - 09:43 PM, said:

Huh, Raze got updated to 0.73.Going by the changelog this seems to be a substantial update (I think?). That's cool I suppose. The first thing that would make this even remote usable for me would be able to use the voxel mods, which afaik don't work (and probably will not work).

Voxel support should be fixed as of three hours ago with this commit. Things like this were never disappearing but understandably while we're still alpha and still transitioning things over there might be some breakage.

Tea Monster, on 11 November 2020 - 01:18 PM, said:

Depending on how he's coded it, you may need to change how the defs are written. I don't know much about voxels though so I couldn't say.

NightFright, on 11 November 2020 - 01:34 PM, said:

I doubt Graf cares much about how we do things over here. You probably would have to write all-new defs.

Graf actually cares more than you think or more that he lets on. Particularly during early development, considerable testing of the EDuke32 component was done with major EDuke32 mods to ensure no breakage occurred. With the DEF parser, Graf left features there that he doesn't particularly agree with to maintain compatibility. Anything that loads on an EDuke32-based version of Build should load fine whereas the GDX parser is a lot more limited. For instance, we can parse and load the HRP fine but are still working on model and sky code.

[Phredreeke]

If you read old posts you see that people were harsh on BloodGDX as well.

As I said before, I'd be happy to see Raze succeed Polymer as the "fancy" renderer. While Polymost works great for me it can't have dynamic lighting by design.

[Ninety-Six]

Mitch Richters, on 11 November 2020 - 03:33 PM, said:

Rather than a continued divide, it'd be great if there was increased unity between camps as I strongly feel that more options irrespective of which one a player opts for will increase interest in these classic games and ultimately increases the community size as a whole.

I agree on this point at the very least. It would be nice if the bad blood could go away but that's probably a tall order right now. A lot of us are no fans of the Doom community, including myself, and the feeling appears to be very mutual.

Still, even so, I do wish we could all get along a bit better. Both communities have a common interest in these games, with Duke and Doom probably being the two biggest games of the era, Duke arguably even moreso than Quake. Most of us, despite not being fans of the Doom community, still enjoy the game itself and with the exception of a few loud-mouthed individuals over in Doom Land, I know a lot of those guys like Duke 3D too. But alas, we're just oil and water due to our polar opposite philosophies on...mostly everything, really. It's not impossible to get along but it would take a lot of work on both ends (in case it isn't clear, I'm including myself when I say "we.")

[mjr4077au]

Phredreeke, on 11 November 2020 - 05:15 PM, said:

If you read old posts you see that people were harsh on BloodGDX as well.

Which is a shame as the amount of effort that M210 has put into his games is insane. Opinions on Java aside, it's a high quality collection of ports with a number of architectural improvements to the games while maintaining demo support, etc.

Phredreeke, on 11 November 2020 - 05:15 PM, said:

As I said before, I'd be happy to see Raze succeed Polymer as the "fancy" renderer. While Polymost works great for me it can't have dynamic lighting by design.

We'll get there and Graf certainly has the capability to do so. It's a bit of a shame that it's all on him as even though I'm now listed as a developer, I'm still very new to C++ and programming in general, my experience comes from interpreted languages like VB and Powershell which I use for systems administration. I'm hoping I can increase the value of my contributions as my skillset increases.

Ninety-Six, on 11 November 2020 - 05:18 PM, said:

I agree on this point at the very least. It would be nice if the bad blood could go away but that's probably a tall order right now. A lot of us are no fans of the Doom community, including myself, and the feeling appears to be very mutual.Still, even so, I do wish we could all get along a bit better. Both communities have a common interest in these games, with Duke and Doom probably being the two biggest games of the era, Duke arguably even moreso than Quake. Most of us, despite not being fans of the Doom community, still enjoy the game itself and with the exception of a few loud-mouthed individuals over in Doom Land, I know a lot of those guys like Duke 3D too. But alas, we're just oil and water due to our polar opposite philosophies on...mostly everything, really. It's not impossible to get along but it would take a lot of work on both ends (in case it isn't clear, I'm including myself when I say "we.")

I've been a fan of all three games you've mentioned since the DOS days and played the shit out of them as my old Pentium 200 with an S3 ViRGE DX didn't play much else. I'm not really involved with either community as you can see by the age of my forum account here, as well as the ZDoom forums. I basically only opened the accounts to report bugs as I started finding more time in my life to play each game again after a period of absence.

I liked when Steve Jobs said at MacWorld 97 or 98 that the belief of "for Apple to succeed, Microsoft has to lose" has to disappear, and I think that holds true here. It's possible to like both games equally without liking the politics of one or more communities associated with either games. I also feel its possible for multiple ports of the same game to co-exist and that more ports and options leads more widespread community appeal.

[Jimmy]

The work speaks for itself.

[mjr4077au]

Jimmy, on 11 November 2020 - 05:44 PM, said:

The work speaks for itself.

GDX's work? Yeah it sure does. I'm excited to see what M210 is doing with his renderer work. I've seen a few tech videos on his YouTube, great to see.

[Jimmy]

EDuke32, Raze, GDX. Whatever. The works speaks for itself beyond any forum post could.

[mjr4077au]

Jimmy, on 11 November 2020 - 06:45 PM, said:

EDuke32, Raze, GDX. Whatever. The works speaks for itself beyond any forum post could.

Absolutely well said, couldn't agree more. Working on a port has really opened my eyes to how much of a massive undertaking it is commit to something like this. I've made comments in the past from an inexperienced standpoint regarding feature requests or "why can't the devs just do x or y". I try not to worry about it as I'm sure we've been there at one point or another.

[mjr4077au]

For anyone interested, we've just released 0.8.0 to the public.

Official announcement: https://forum.zdoom....p?f=347&t=70865
GitHub release page: https://github.com/c.../tag/0.8.0_beta

Full release notes are below, but main highlights are:

• Fully repaired sound issues with Powerslave/Exhumed.
  
• Working models again (there's a few interpolation issues).
  
• Interpolated floors and ceilings such as slime floors and the waves in Vacation's first level.
  
• Further input uplift such as crouch toggling now available in all games, and re-written RRRA vehicle mouse/controller input.
  
• The beginning of refactoring game-side code to make it more script-accessible to ZScript.

With this release, we feel we've reached a quality level where we can now declare ourselves beta and no longer alpha. I hope that if you test out this release, the quality of this release shines through.

I appreciate that there's still differences between the communities but I will continue to try and bridge the gap where possible. At the end of the day, it's all about the games in my mind and no matter what port one uses, as long as they're having a great experience and enjoying themselves, that's what matters most.

Full release notes notes for those who are keen. Some 500+ commits have been accured between 0.7.3 and 0.8.0.:

Spoiler

• Blood: instead of messing around with the damage factors when toggling god mode, let the game check the actual god mode flag itself.
  
• Blood: fixed cl_autorun affecting bobbing intensity even when no movement takes place.
  
• fixed model rendering.
  
• Duke/RR: Selecting the alternative weapon must set the proper bits in 'subweapon' to allow proper cycling. Fixes #182
  
• weaken the reverb in Duke. Unfortunately the entire thing is very poorly defined, not setting it for sectors but for sprites with a distance. But some of these sprites cover non-reverb sectors as well and this can produce some ugly sound field in spots where this isn't wanted at all.
  
• Exhumed: Use JSON for savegames.
  
• add back the missing secret hint notification calls for Duke/RR.
  
• Blood: There's some bugs that allow a secret to be triggered multiple times. However, since the hint system already knows which secrets were triggered, use that info to avoid retriggers. Fixes #206
  
• Blood: Force synchronised input while a revolving door is busy/in-use. Fixes #205.
  
• Exhumed: removed limits for most monster types by storing their work data in a dynamic array.
  
• use stricter checks when trying to levelwarp. If saving is blocked, so should changing the level. Fixes #204.
  
• added interpolation for texture scrollers and Duke's wave floor effect.
  
• make sector and wall panning variables floats and added some convenience wrappers to allow interpolation on them.
  
• cross-game, serialization-friendly and pointer free interpolation implementation.
  
• Blood: handle super secrets properly in the statistics display. Fixes #198
  
• SW: silence an apparently misplaced ambient sound in level 9.
  
• SW: Fix ladder angle issues. Fixes #197.
  
• Exhumed: added a countdown display for the magic spells in the fullscreen HUD.
  
• Exhumed: Switch sounds must use CHANF_LISTENERZ because they use no z-coordinate for their position.
  
• Exhumed: fixed typo in player taunt code making the taunts not play
  
• Exhumed: fixed positioning of the player's scream sound. This was played on the wrong actor - the calling code passed 0 instead of the player's actual sprite index.
  
• port from NBlood: Show all available powerups in HUD.
  
• Duke WT: attenuate sound volume when commentaties are playing
  
• SW: clear one-sided flag for certain items, like keys and medikits. Fixes #173.
  
• fixed weapon cycling in Exhumed. The sword was checked for ammo (and failed) and wraparound was not handled. Fixes #193
  
• RRRA: fixed progression from E1L7 to E2L1 plus a texture related crash. Fixes #189.
  
• Duke World Tour: Exiting E1L7 should go back to E1L5. fixes #187
  
• make sure that all of SW's sound function check SoundEnabled().
  
• RR: Give ammo for the secondary ripsaw mode when picking up the weapon in standard RR, too.
  
• Exhumed: Get GOG music playing without any user intervention required.
  
• Add registry detection for Powerslave/Exhumed from GOG.
  
• use JSON based savegames for Blood.
  
• Duke: fixed parsing of overlong CON identifiers. This makes Borg Nukem work again.
  
• fixed crosshair scaling in Exhumed & the other games.
  
• Duke: use original colors for inventory status display while retaining the percentage-based coloring.
  
• fixed hires texture replacements for 2D rendering.
  
• use correct CVAR for menu's statusbar scale setting. Fixes #169
  
• fixed crosshair setup. Fixes #168
  
• SW: fixed episode menu display. The subtitle needs to use the game specific drawer, not the generic one. Fixes #162
  
• Exhumed: Fixed issues with LEV20 energy towers in #159.
  
• c_notifybuffer.cpp: Center and pulse text for all RR games in DrawNative(). Fixes #163.
  
• Blood: Don't let Caleb's voice overlap if spamming the use key on a locked door. Fixes #113.
  
• Exhumed: Add crouch toggle mechanism.
  
• Blood: Add crouch toggle mechanism. Fixes #151.
  
• Duke/RR: Completely revamped vehicle mouse/controller input.
  
  • Original algorithm now used purely for keyboard input only.
    
  • Mouse and controller input is no longer a scaled double version of the keyboard input.
    
  • Mouse input is the square root of the base angle adjustment (20) multiplied by (mouse input divided by the input scale factor). As such, mouse input is completely consistent between synchronised and unsynchronised input.
    
  • Controller input is base angle adjustment (20) multiplied by itself.
    
  • Renamed turnl/turnr variables to kbdLeft/kbdRight respectively.
• Fixed issue where p->TiltStatus wasn't being backed up in boatApplyTurn().
  
• CONTROL_GetInput(): Reverse polarity of dx/dz and update processMovement() appropriately.
  
• Exhumed: Skip over weapons owned but without ammo when doing WeapSel_Next/WeapSel_Prev. Fixes #148.
  
• Exhumed: Move bullet puff animations up by 4096 units to give the illusion of more accurate aiming. Fixes #149.
  
• Duke: Fix missing ammo counter on modern HUD for WT's flamethrower. Fixes #156.
  
• Exhumed: Fix issues on start of Level 20.
  
• RRRA: fixed vehicle collision with psychedelic cactuses.
  
• cap the frame rate of RRRA's cactus drug mode. This was running at full render speed and not synced with the game's play ticker.
  
• changed how RRRA's psychedelic cactus handles the projection. This fixes issues with occasionally passing a bad matrix.
  
• changed Duke/RR palette handling to only retrieve the currently active palette right before rendering.
  
• fixed some issues with WW2GI event calls.
  
• internal refactoring of Duke/RR code for later scripting export.

[jkas789]

Hmmm will try it out. Saw the post and the commit that added voxel support so I can say that at least grabbed my attention. Does voxel support extends to all games or only Duke Nukem 3D?

[MetHy]

Mitch Richters, on 06 December 2020 - 04:04 AM, said:

[*]SW: silence an apparently misplaced ambient sound in level 9.

According to this page, I think you spotted this issue because you got the following error message "Invalid or out of range ambient sound number" ?

I believe this is the ambient sound sprite in question (spritenum 442, hitag 1002 for ambient sound, with a lotag of 31):

 capt0001.png (73.59K)
Number of downloads: 8

I believe the issue here isn't that the sound is out of range, it's well within a sector and it can be heard at the start of the map if you spawn next to it; but that a non ambient sound is used as ambient sound. Indeed ambient sound def 31 is actually "BREAKSTONES", a stone breaking sound, which is not an ambient sound.
My guess is that the sprite is most likely a leftover of a point during development when ambient sound slot 31 was used for something else; but it could also be a mapper mistake.

Either way it makes no visible difference; as this sound is definitely not meant to loop there, or heard at all. The player is not able to hear it as it only plays once at the start of the map, out of range of any player spawn, Wangbang included.

My point is, if I'm correct about this and about my assumption (if I'm not, I apologize in advance), and I don't know how to say this without sounding rude: if you're going to include map fixes directly into the executable, I hope you investigate to see what the issue really is. What if the mapper had placed this sound intended to be heard by the player at map start, and used the ambient sound FX for it simply because it works and because usingt ST1 1002 for it would take away the hassle of using ST1 134 and a touchplate? You'd still be getting the same error message about the sound being an invalid ambient sound.