Help
Duke4.net
DNF #1
Duke 3D #1
MusicallyInspired, on 12 February 2020 - 04:58 PM, said:
Master O; aka "nobody."
Who's nobody? I've never gone by that nickname anywhere. *confused*
Graf Zahl Razes EDuke32 game code from his fork
#151 Posted 12 February 2020 - 05:14 PM
Who's nobody? I've never gone by that nickname anywhere. *confused*
- King of SOVL
-
#152 Posted 12 February 2020 - 06:07 PM
ReaperAA, on 11 February 2020 - 07:10 PM, said:
Okay Radar, we already know that 
Really? Because some ZDoomers are speaking like after 17 years of the source code being released there's finally a remotely playable Duke source port.
This post has been edited by Radar 100 Watts: 12 February 2020 - 07:15 PM
- The Sarien Encounter
-
#153 Posted 12 February 2020 - 06:34 PM
Master O, on 12 February 2020 - 05:14 PM, said:
Who's nobody? I've never gone by that nickname anywhere. *confused*
It was just a joke because Player Lin said "nobody can stop me" and then you said "*stops Player Lin*". Therefore you are "nobody" lol.
#154 Posted 12 February 2020 - 07:23 PM
MusicallyInspired, on 12 February 2020 - 06:34 PM, said:
It was just a joke because Player Lin said "nobody can stop me" and then you said "*stops Player Lin*". Therefore you are "nobody" lol.
Ah, that makes sense.
This post has been edited by Master O: 12 February 2020 - 07:23 PM
#155 Posted 12 February 2020 - 11:36 PM
Radar 100 Watts, on 12 February 2020 - 06:07 PM, said:
Really? Because some ZDoomers are speaking like after 17 years of the source code being released there's finally a remotely playable Duke source port.
Said who? At least I didn't said anything like that. I really like Eduke32 and I appreciate the effort put by TerminX, Hendricks and co.
However, I also believe that the more ports there are, the better (even if one is just a fork of the other). Right now, Raze is in a janky alpha state and it is overall buggier than Eduke32. But even now, it does have one thing better than Eduke32 (that is smoothness with Vsync).
This post has been edited by ReaperAA: 12 February 2020 - 11:42 PM
- Weaponized Autism
-
#156 Posted 13 February 2020 - 12:09 AM
Blzut3, on 10 February 2020 - 08:03 PM, said:
I am not directly involved with Raze's code, nor do I know much of anything about hardware rendering so my knowledge is very limited here. From what I understand there's nothing wrong with EDuke32's vsync implementation per se. Instead it has to do with the use of legacy/deprecated OpenGL features which are emulated with inconsistent performance on modern drivers. That and, on nvidia drivers at least, a driver issue with creating texture IDs sometimes causes a wait for vblank.
Would this affect frametime jitter, or FPS?
At startup, we pack 8-bit ART tiles into large texture atlases on the GPU side in order to minimize state changes and texture creation, at least for the base games with no hightile.
This post has been edited by Hendricks266: 13 February 2020 - 12:53 AM
#157 Posted 13 February 2020 - 02:36 AM
Hendricks266, on 13 February 2020 - 12:09 AM, said:
Would this affect frametime jitter, or FPS?
Frametime fitter. Raw throughput doesn't mean much if a driver bug is causing you guys to skip a frame randomly at no fault/control of your own.
Hendricks266, on 13 February 2020 - 12:09 AM, said:
At startup, we pack 8-bit ART tiles into large texture atlases on the GPU side in order to minimize state changes and texture creation, at least for the base games with no hightile.
I would encourage you to PM Graf (or ask publicly on the ZDoom forums if you prefer) for the details since like I said I know next to nothing about OpenGL. I can only give you second hand information, so the gist I have is that texture atlases don't do much for modern hardware (Raze doesn't do atlases I believe). I can tell you the deprecated feature has something to do with "texture sampling parameters," but that's pretty much the limit of what I know.
And it all makes sense since I can tell you that for me eduke32 is silky smooth on Linux with the open source Radeon drivers, but stuttered constantly on Windows with the same hardware (I haven't tried the latest code, but I don't use Windows much). Raze is smooth on both and isn't doing any tricks with frame rate limiting or unusual APIs.
- Polymancer
-
#158 Posted 13 February 2020 - 03:08 AM
There have been one or two who have stated that they can now play Build games because Raze has arrived. I am assuming that they have lived extremely sheltered lives.
#159 Posted 13 February 2020 - 04:45 PM
Jimmy, on 12 February 2020 - 04:39 PM, said:
Rednukem perfectly ports the 1.5 DOS exe.
False.
"^02%s^02 gave AnAl MaDnEsS to %s",
#160 Posted 14 February 2020 - 06:32 AM
Photonic, on 13 February 2020 - 04:45 PM, said:
False.
"^02%s^02 gave AnAl MaDnEsS to %s",
lmao what's this reference about?
#161 Posted 14 February 2020 - 10:50 AM
A few "features" of eduke32 that linger in rednukem, the multiplayer obituaries are classic tx.
Spoiler
- King of SOVL
-
#162 Posted 14 February 2020 - 10:53 AM
That has nothing to do with gameplay though. Once the C/S netcode is complete, the entire DOS netcode should absolutely be nixed even in Rednukem.
This post has been edited by Radar 100 Watts: 14 February 2020 - 10:53 AM
#163 Posted 14 February 2020 - 12:47 PM
I was under the impression that the c/s netcode is working great for rednukem and it's just eduke32 specific things holding it back for Ion Fury. Is this not correct?
Obviously ditching p2p for c/s is good, but changing multiplayer obituaries is taking an artistic liberty in an otherwise faithful port.
Obviously ditching p2p for c/s is good, but changing multiplayer obituaries is taking an artistic liberty in an otherwise faithful port.
- King of SOVL
-
#164 Posted 14 February 2020 - 04:06 PM
Photonic, on 14 February 2020 - 12:47 PM, said:
I was under the impression that the c/s netcode is working great for rednukem and it's just eduke32 specific things holding it back for Ion Fury. Is this not correct?
No, but I wish!
Photonic, on 14 February 2020 - 12:47 PM, said:
Obviously ditching p2p for c/s is good, but changing multiplayer obituaries is taking an artistic liberty in an otherwise faithful port.
I'm not really sure if I consider that categorically inaccurate in regards to gameplay. But I will say that xduke retains the DOS style frag messages and I prefer that way over what EDuke32 does. In DOS, both text and frag messages are displayed at the bottom center of the screen. As opposed to EDuke32 which displays super small text at the top left corner and I have to take my eyes off the game in order to read it. There are some things they got right in 1996 that shouldn't be touched.
This post has been edited by Radar 100 Watts: 14 February 2020 - 04:11 PM
- The Truth is in here
-
#165 Posted 21 February 2020 - 03:35 PM
Today I took a first look at the latest Raze build and played the first three Duke3D shareware levels just for the lulz.
My findings:
- Movement and general feel of the game is indeed very smooth.
- Sound mixing doesn't seem to work properly yet. In spite of choosing 44kHz and cubic resampling, sounds are very dull.
- My beloved KEPAD5 key which I like to use for inventory selection just works.
- Biggest advantage for me: MIDI device selection. A lot more options here than EDuke32 has to offer, however OPL3 and Timidity are missing due to GPL issues/conflicts. These are unlikely to be resolved, so unless someone ports over the EDuke32 OPL3 implementation to Raze, it's not gonna be in. The lack of Timidity means no EAWPats, which is sad news for fans of those. There's still Bashe's soundfont which is quite accurate, but it still takes some liberties which prevent it from being 100% faithful to the original.
- Mouse input via wheel sometimes seemed to lag a bit.
- Player does not always take damage, e.g. from that exploding wall after using the red keycard in E1L1.
- User Map support is missing, but that's probably something for later.
In total, I won't see this as anything that would make EDuke32 obsolete, but it has a few nice things already that I liked in GZDoom. It's weird because when you go through this familiar menu structure, you think you are playing Doom - until you enter the game and realize it's Build. A bit confusing at first, but also kinda amazing.
My findings:
- Movement and general feel of the game is indeed very smooth.
- Sound mixing doesn't seem to work properly yet. In spite of choosing 44kHz and cubic resampling, sounds are very dull.
- My beloved KEPAD5 key which I like to use for inventory selection just works.
- Biggest advantage for me: MIDI device selection. A lot more options here than EDuke32 has to offer, however OPL3 and Timidity are missing due to GPL issues/conflicts. These are unlikely to be resolved, so unless someone ports over the EDuke32 OPL3 implementation to Raze, it's not gonna be in. The lack of Timidity means no EAWPats, which is sad news for fans of those. There's still Bashe's soundfont which is quite accurate, but it still takes some liberties which prevent it from being 100% faithful to the original.
- Mouse input via wheel sometimes seemed to lag a bit.
- Player does not always take damage, e.g. from that exploding wall after using the red keycard in E1L1.
- User Map support is missing, but that's probably something for later.
In total, I won't see this as anything that would make EDuke32 obsolete, but it has a few nice things already that I liked in GZDoom. It's weird because when you go through this familiar menu structure, you think you are playing Doom - until you enter the game and realize it's Build. A bit confusing at first, but also kinda amazing.
- Polymancer
-
#166 Posted 22 February 2020 - 01:54 AM
I like that it's a one-stop-shop for the most popular build games.
Apart from that it's early days yet.
Apart from that it's early days yet.
#167 Posted 22 February 2020 - 05:05 AM
Does it do a drive search for all your build games and tie them together in it's own menu or do you actually have to group all those games together somehow in one main folder?
#168 Posted 22 February 2020 - 05:54 AM
It locates games in normal install paths from steam and gog.
#169 Posted 22 February 2020 - 08:44 AM
NightFright, on 21 February 2020 - 03:35 PM, said:
- Sound mixing doesn't seem to work properly yet. In spite of choosing 44kHz and cubic resampling, sounds are very dull.
It does work, but you need to set the 'resampler' option to 'Nearest', which is hidden in "Options > Sound Options > Advanced Options > OpenAL Options".
Also the key config is set to the original Duke 3D defaults for some reason. To quickly set it to WASD, select the control preset "Default".
NightFright, on 21 February 2020 - 03:35 PM, said:
- Player does not always take damage, e.g. from that exploding wall after using the red keycard in E1L1.
Works for me, but it's possible that you are playing an old version where the explosion radius fix from TX hasn't been merged.
#170 Posted 22 February 2020 - 10:01 AM
NightFright, on 21 February 2020 - 03:35 PM, said:
- Sound mixing doesn't seem to work properly yet. In spite of choosing 44kHz and cubic resampling, sounds are very dull.
Like Doom64hunter said, you probably want to be using nearest resampling not cubic. There are a lot of people that are used to hearing the resulting aliasing in these older games and think the game sounds "dull" without it.
Personally I prefer the "dull" version since that's the more mathematically correct way to resample, but to each their own.
- The Truth is in here
-
#171 Posted 22 February 2020 - 01:38 PM
Ok then, will try that. Thanks for the hint! I was expecting it to work like in GZD, but it's probably not there yet. For its early dev stage it still works quite well already, anyway.
#172 Posted 22 February 2020 - 01:47 PM
Photonic, on 22 February 2020 - 05:54 AM, said:
It locates games in normal install paths from steam and gog.
Since I own the original CDs would I have to recreate a Steam or GOG folder structure and drag my files and subfolders into it?
If so, I won't bother trying it.
#173 Posted 22 February 2020 - 02:24 PM
You can just extract Raze into a folder and put your .grp files there. If there's more than one it will offer a menu. From a command line, you can also use the '-iwad' switch (showing its Doom heritage there LOL) or -gamegrp (as in EDuke32) to select the game group file to use.
#174 Posted 22 February 2020 - 02:32 PM
you can enter the path in the ini. Raze is buggy and in alpha stage but is promising. In 6 months I believe (or hope) that it will be stable and fully working.
#175 Posted 22 February 2020 - 02:46 PM
Thanks guys. I rarely play the vanilla games so I'll wait a while before jumping in. Let the community work out the bugs first. 
#176 Posted 22 February 2020 - 06:59 PM
NightFright, on 22 February 2020 - 01:38 PM, said:
Ok then, will try that. Thanks for the hint! I was expecting it to work like in GZD, but it's probably not there yet. For its early dev stage it still works quite well already, anyway.
Assuming "it" is still the resampler, it does work the same. I think the reason people notice the difference in Duke more than Doom is because Duke uses lower quality sounds that lack any high frequency information when resampled properly. Some people are just used to the high frequencies being filled by noise added by aliasing.
The way Raze sounds by default is because Graf, like me, views that noise for what it is: noise. The option to use low quality resampling is there for those who want it.
- The Truth is in here
-
#177 Posted 23 February 2020 - 09:05 AM
Duke sound samples are also of really shitty quality. They compressed those too much back then to save disk space. Not much to work with when resampling.
This post has been edited by NightFright: 23 February 2020 - 09:06 AM
- el fundador
-
#178 Posted 24 February 2020 - 04:18 PM
Blzut3, on 22 February 2020 - 06:59 PM, said:
The way Raze sounds by default is because Graf, like me, views that noise for what it is: noise. The option to use low quality resampling is there for those who want it.
I think this is an incredibly short-sighted way of looking at it. It fits a narrow technical definition of "noise", but it's also the only way the game ever produced audio with higher frequencies--something certainly accounted for when shipping a game full of audio that even dips into the 6-8 kHz range.
A "correction" that changes the output such that it becomes dissimilar to the original output heard by the artist or audio engineer isn't much of a correction at all... it's just enforcement of a personal preference for algorithms that produce numbers that make you happy versus output representative of what the games actually sounded like. Maybe that doesn't make much of a difference to Doom people as Doom used a commercial audio library for which the source has never been released, making the audio engines in Doom ports reimplementations by necessity, but Build games don't have that problem. Build games do not need to sound different from their original versions unless someone goes out of their way to make them sound different.
It's OK to like ports that don't replicate the audio frequencies produced by the original games, but please don't pretend the output is more correct.
#180 Posted 24 February 2020 - 10:36 PM
TerminX, on 24 February 2020 - 04:18 PM, said:
A "correction" that changes the output such that it becomes dissimilar to the original output heard by the artist or audio engineer isn't much of a correction at all...
The output heard by the audio engineer will also depend on the sound card used, what amplifiers, what speakers, human factors (i.e. do they have any hearing loss). Everything in the chain changes how sound is heard and people have different preferences. You'll probably say none of that counts for various valid technical reasons, but at least the sound card's filters/behavior does matter to people since there are endless debates on what OPL emulator sounds right despite many of them supposedly being bit accurate.
As for being the same code, it's worth noting that in the Duke 3D setup you can turn the mixing down to 8kHz which from a quick test and to my ears seems to reduce (or at least change) some of the noise. (And this would probably depend on what sound hardware the user is using and how it handles lower sample rates.) So is 16-bit 22kHz the only truly correct sound when vanilla had multiple modes?
There's a lot in your post I don't necessarily disagree with, but I don't think it's as easy as saying "it's what the engineers heard" and declaring the one true "correct." Both interpretations can be correct for different reasons. To each their own.
