EDGE 2.1.0 Discussion [RC-1 Released on 10.3.2018]

Game Engines like EDGE, LZDoom, QZDoom, ECWolf, and others, go in this forum
Forum rules
The Projects forums are ONLY for YOUR PROJECTS! If you are asking questions about a project, either find that project's thread, or start a thread in the General section instead.

Got a cool project idea but nothing else? Put it in the project ideas thread instead!

Projects for any Doom-based engine are perfectly acceptable here too.

Please read the full rules for more details.
User avatar
Coraline
Posts: 447
Joined: Wed Aug 15, 2012 3:41 pm
Location: California
Contact:

Re: 3DGE 2.1.0 Test3 Released (12.13.2017)

Post by Coraline »

Enjay wrote:Same problem I'm afraid. :?
Gah, time to hit up Ryan again, this is really irritating. We can't switch back
to SDL 2.0.5 anymore (which was the last version that worked for everyone
before they made these audio changes under Windows), because we are already
using other functions that were made available since 2.0.6, and going back
will break other things we have since implemented. The only other option
is to try 2.0.6, but other than that, this is definitely a bug with SDL2. It makes
it even worse because the main SDL2 author made changes in our code that should
have fixed these problems.

The only other thing I can think of is that they ALREADY fixed them later on down
the road and didn't bother to announce them. :S
....and with 2.0.6 but 2.0.5 works!
2.0.5 works still??? I'm blown away. Maybe those fixes were from that version we used,
so maybe Ryan hacked away at something that was since attended to in later versions
of SDL2.

But it doesn't make sense why SDL2 2.0.8 is linking and working on my end with EDGE,
both x64 and x86, and I'm not getting that error... (?)



Later tonight I'll try removing all of the commits he made (roll-back) and see if I can't
get it working properly as intended with a newer version of SDL2. If not, then I guess
we will just ship with 2.0.5 and try to figure this floating point audio mess out later...
User avatar
Enjay
 
 
Posts: 26517
Joined: Tue Jul 15, 2003 4:58 pm
Location: Scotland
Contact:

Re: 3DGE 2.1.0 Test3 Released (12.13.2017)

Post by Enjay »

Well, just been playing with it for a good few minutes and it does indeed seem to be working with 2.0.5. No relevant issues noticed and it seems to be running pretty well.

The only thing I have noticed (and it won't be anything to do with SDL, of course) is that EDGE can't identify my additional mouse buttons. The mouse is a Logitech G300. and the buttons get identified like this (how ZDoom sees the buttons are included in brackets and in red):

Image

I've no idea why two buttons are seen as R and Z by both EDGE and ZDoom (perhaps something in how I've set it up, I only really bothered with the top two buttons) but with EDGE picking things up like this, it means I can't bind secondary fire to one of the top shoulder buttons and have next/previous weapon bound to the scroll wheel (like I usually do) because EDGE is seeing both the buttons and the wheel as being wheelup/down. Not that big a deal but I just thought I'd mention it.
CeeJay
Posts: 1467
Joined: Sun Mar 14, 2010 2:52 am

Re: 3DGE 2.1.0 Test3 Released (12.13.2017)

Post by CeeJay »

Coraline wrote:
CeeJay wrote:what exactly is the CROSSHAIR special for IMAGES.DDF supposed to do?
The CROSSHAIR special for Images.ddf (as per the EdgeWiki):

Code: Select all

CROSSHAIR
For weapon crosshair sprites: center it on screen
So, if you don't have custom crosshair sprites via IMAGES.DDF defined with the SPECIAL=CROSSHAIR, you definitely should.
CeeJay wrote: The automatic detection for targets is a little wonky (TARGET_JUMP), it don't appear to take height into consideration as evident by the screenshot.
About those other crosshair commands, it appears that TARGET_JUMP is definitely doing what you described, but the description for it seems odd:

Code: Select all

TARGET_JUMP
The action will check if there is something that the autoaiming can lock onto, and change the crosshair accordingly. Crosshair jumps to the given frame IF player has a target. Can only be used in the crosshair states.
Autoaiming lock...is it just me or does it feel kinda like that old-school autoaiming that DOOM would use. Maybe it was created back
in DOSDoom or very early versions of EDGE, because that kind of feels like a nobrainer to have the player view jump to the target
as well. I can always use the MLOOK_ code from the other DDF and implement (or replace) the TARGET_JUMP function. . .


So just to be absolutely clear, in your second screenshot, you would prefer the overall behavior for this function to snap the screen
TO the enemy (crosshair), or would you like the crosshair GRAPHIC snap to the enemy? Because this can go both ways in the event
that there is no mouselook enabled (or a mouse in general). I can snap the crosshair graphic to the enemy if mouselook is completely
disabled, or if mouselook IS enabled, have the PLAYER VIEW (screen) snap to the target. Or just ignore the player view/screen thing
and just have the actual crosshair snap to the target regardless of the screenpitch. If we did it the first way, it would certainly feel
strange if the crosshair was on a target and the crosshair was off-center (0,0), but it would be cool for 3D modeled weapons as that
is certainly possible for those as their orientation can change dynamically (sprites, as you can imagine...not so much lol)
Also, there is no way to turn it off in-game. By selecting no crosshair in the options menu, shouldn't this also disable all custom ones too. Just a thought.
A little confused here. How are you defining custom crosshairs? If you are defining them in IMAGES.DDF, the engine will not associate
crosshairs with the defaults unless you have the CROSSHAIR special defined first, otherwise, as far as the engine goes it isn't even
using a properly defined crosshair graphic as a 'crosshair', but the engine won't complain if that's something someone wanted to do.

{...}
{..}

Also, has anyone gotten their sound working in the latest versions of EDGE, by deleting their EDGE2 configuration file? Please let me
know if this fixes or does not fix the problem. If it doesn't, then I'll have to double-check Icculus' commit to the SDL audio code, because
under Windows it should always be on Float32 audio. If it isn't...well, I'll have no way of knowing without attaching your DEBUG.txt, since
I can see where the audiospec sits on your machine for SDL audio. If sound is messed up and there was a pre-existing EDGE2.CFG in your
EDGE root directory, it should be printing incorrect audiospec outputs in the Debug (which is one reason I have completely disabled the
ability to change the Khz rate/etc in the Sound Options menu for now).
Spoiler:
I threw together a demo to show what I mean: http://www.mediafire.com/file/m78542mno ... r.epk/file

The CROSSHAIR special as is does not work properly, I still had to manually adjust the X and Y to get it (actually) centered.
CeeJay
Posts: 1467
Joined: Sun Mar 14, 2010 2:52 am

Re: 3DGE 2.1.0 Test3 Released (12.13.2017)

Post by CeeJay »

I am experiencing a very perculiar issue: Smoke trails from projectiles as launched by enemies apear to be spawned infront of the missile instead of the back.
User avatar
Coraline
Posts: 447
Joined: Wed Aug 15, 2012 3:41 pm
Location: California
Contact:

Re: 3DGE 2.1.0 Test3 Released (12.13.2017)

Post by Coraline »

Okay guys, new versions of both 32 and 64 bit builds of EDGE available:

https://devbuilds.drdteam.org/3dge/

Lots of changes here, mostly in the utility code. Modders will be happy because
some of the archaic utility code that was replaced -- grAb now functions as it
should across all PNG images no matter if they are HUD, Entity, etc etc. FINALLY,
right?? =)

This has a lot to do with us ripping out EDGE's reliance on external libraries
to do its image decoding - with us transitioning to a far smaller, more modern,
and safer image header, we not only got a lot of the image problems worked out
from old bugs, but we now support a LOT more image types than we did previously:

IMAGES.DDF

In addition to PNG and JPEG, we also now support
BMP, PSD, GIF, HDR, PIC, PNM, and animated GIFS.

So needless to say, image code has improved by a ton! Most of all, the best part about
this is that EDGE figures all of this out automatically. So entering these into IMAGES.DDF is a
little different, though there is still a need to define PNG specifically if grAb structs are used.

The old way would have been:

Code: Select all

[gfx:EDGETTL] 
IMAGE_DATA = LUMP:TYPE:"JPEG001";
Where 'TYPE' would have to EXPLICITLY be defined as JPEG or otherwise -- not so anymore.

We have introduced a new 'TYPE', called 'EXT', which leaves the image format open for EDGE
to do automatic interpretations - as long as the format is any of the listed above, you would
just use :EXT: and let EDGE sort out the rest. I have kept the old JPEG/JPG handles for backward
compatibility concerns.

PNG will still have to be explicitly defined if you are using PNGs with grAb structs! That part is not
altered, but for normal PNG images - 'EXT' is sufficient. EXT is a catch-all kind of thing so it will
definitely be much easier than having to remember format definitions all of the time.

COAL

Another big introduction is the REMOVAL of setting camera bobbing in DDF. The new way, now, is a COAL
function (which you can see in coal_hud.ec as per the new builds) which can set it:

cam.set_vert_bob(1.0)
cam.set_roll_bob(0)

Putting both of those values in COAL to 0 will disable bobbing completely. But, we now introduced camera
rolling! It can either be called by itself, or referenced in other PLAYER modules inside of coal_hud.ec. So, for
instance, if you are wanting to do QUAKE-style strafe rolling with the camera, you would use this new function
that we have also written:

player.get_side_move() [in the API, it is called function get_side_move() : float = native]

That is basically a float, either 1 or 0. So say, you set up a function that activates when player.get_side_move
in conjunction with the math.floor stuff (for x, y, and x). You can call it to basically roll the camera side to side,
exactly like QUAKE does (and very similar to Nash's ACS script) by writing a new function for it. Most of you who
have done math in COAL know this already, but it's a welcoming addition and just a step forward for us to have total
control over camera movements.

OTHER

Other improvements we have made is in the shader code, sceensize adjustment (changing resolutions works again, but
changing from window -> fullscreen or back again does cause a bit of a delay). We have also re-introduced fixed
code for ACTION3 and ACTION4.

There are other things we are quickly implementing (OpenAL replacing SDL2 for audio support, which will bring other
benefits like reverbs/echos, etc), Terrains.ddf for customization of terrain sounds/actions, and Wolf3D/ROTT native
support. We are also looking into improving Multiplayer and hoping to eventually get online play working. We are also
planning on retiring glBSP for ZDBSP, which is proven for EDGE to both increase framerates in larger levels, and eliminates
rendering gaps/errors on surfaces. Oh, and audio module support (dreamcast EDGE has this already) - so you could use
MOD, IT, XM, and all those kinds of things for music playback if desired.

There's a few more things that have been added, but I can't remember.

@Ceejay: We are working on your autoaiming code, don't worry! But at least you'll be happy to know grAb has been fixed now,
even for Crosshairs/et all.

Try it out and get back to me! We are very close to releasing the first full EDGE release in a few years, so we want to make sure
new features work great, old bugs are fixed, and overall stability is solid. Please don't hesitate to let us know of any concerns or
bugs/issues!
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
Posts: 49056
Joined: Sat Jul 19, 2003 10:19 am
Location: Germany

Re: 3DGE 2.1.0 Test3 Released (12.13.2017)

Post by Graf Zahl »

Coraline wrote: In addition to PNG and JPEG, we also now support
BMP, PSD, GIF, HDR, PIC, PNM, and animated GIFS.

What image library are you using? I had always wanted to support animated GIF but GIF libraries tend to be rather shitty in terms of usability.
User avatar
Enjay
 
 
Posts: 26517
Joined: Tue Jul 15, 2003 4:58 pm
Location: Scotland
Contact:

Re: 3DGE 2.1.0 Test3 Released (12.13.2017)

Post by Enjay »

Coraline wrote: There are other things we are quickly implementing (OpenAL replacing SDL2 for audio support...
Given that this hasn't happened yet, I'm sure you won't be surprised to hear that I still get the sound problems that I reported with the earlier version, but I thought I'd report in just in case.

It's hard to do much without the sound working properly but what I've seen with it so far, it seems to be working quite nicely otherwise.
User avatar
Coraline
Posts: 447
Joined: Wed Aug 15, 2012 3:41 pm
Location: California
Contact:

Re: 3DGE 2.1.0 Test3 Released (12.13.2017)

Post by Coraline »

Graf Zahl wrote:
Coraline wrote: In addition to PNG and JPEG, we also now support
BMP, PSD, GIF, HDR, PIC, PNM, and animated GIFS.

What image library are you using? I had always wanted to support animated GIF but GIF libraries tend to be rather shitty in terms of usability.
We dropped all of the other external libraries (which shaved off more than 1MB from the exe) and went with stb_image. It handles many more formats,
and best of all simplified our DDF imaging system. PNG is still kind of wonky as 'PNG' needs to be explicitly defined for images that use grAb - I don't know,
the way Andrew Apted wrote it is to always expect an extension, so it's hacky to me that I had to make an 'EXT' "format" for generalized image handling. I
really, REALLY need to think about updating how DDF and the syntax works at this point, especially since we have a real VM like COAL (which works a lot like
ACS and then some).

Anyways, you are free to check the code out in EDGE, and PM me if you have any questions about it. We made modifications to internalize it but, it works very
well. ^_^
Enjay wrote:
Coraline wrote: There are other things we are quickly implementing (OpenAL replacing SDL2 for audio support...
Given that this hasn't happened yet, I'm sure you won't be surprised to hear that I still get the sound problems that I reported with the earlier version, but I thought I'd report in just in case.

It's hard to do much without the sound working properly but what I've seen with it so far, it seems to be working quite nicely otherwise.
It's still not working properly? I'll dedicate today to figuring that out. If SDL2 changed that in any way from 2.0.5 to 2.0.8, I'll probably have to get ahold of Ryan Gordon to take a look at it,
since he wrote all of the support code in EDGE for float32 audio device handling. It's just that, SDL2 is messy for audio at this point and I can't wait to get rid of it completely and bring
back OpenAL. :)
User avatar
Enjay
 
 
Posts: 26517
Joined: Tue Jul 15, 2003 4:58 pm
Location: Scotland
Contact:

Re: 3DGE 2.1.0 Test3 Released (12.13.2017)

Post by Enjay »

Coraline wrote:It's still not working properly?
'fraid not. Still heavy distortion during the intro video and no sound at all during the game.

FWIW, here's how the intro sounds.

http://www.aspectsweb.co.uk/enjay/doom/ ... f/EDGE.ogg

The sudden cut off at the end was when the EDGE logo disappeared and the Doom2 title screen appeared. From that point on, the game is just silent.
User avatar
Coraline
Posts: 447
Joined: Wed Aug 15, 2012 3:41 pm
Location: California
Contact:

Re: 3DGE 2.1.0 Test3 Released (12.13.2017)

Post by Coraline »

Enjay wrote:
Coraline wrote:It's still not working properly?
'fraid not. Still heavy distortion during the intro video and no sound at all during the game.

FWIW, here's how the intro sounds.

http://www.aspectsweb.co.uk/enjay/doom/ ... f/EDGE.ogg

The sudden cut off at the end was when the EDGE logo disappeared and the Doom2 title screen appeared. From that point on, the game is just silent.
For now, we will have to use the SDL2 binaries from 2.0.5. We made the decision to not try and fix that mess and just continue working towards OpenAL since
SDL2 is already being phased out. When 2.1.0 Final comes out, OpenAL will already have replaced SDL2 for audio processing =P Sorry if that's inconvenient Enjay,
but at least we know that using 2.0.5 fixes those problems. ;)
Cacodemon345
Posts: 419
Joined: Fri Dec 22, 2017 1:53 am
Graphics Processor: ATI/AMD (Modern GZDoom)
Contact:

Re: 3DGE 2.1.0 Test3 Released (12.13.2017)

Post by Cacodemon345 »

Turning on OpenGL3 mode in-game still causes all sprites to be pitch-black. Happens on both Nvidia and AMD.
User avatar
Coraline
Posts: 447
Joined: Wed Aug 15, 2012 3:41 pm
Location: California
Contact:

Re: 3DGE 2.1.0 Test3 Released (12.13.2017)

Post by Coraline »

Cacodemon345 wrote:Turning on OpenGL3 mode in-game still causes all sprites to be pitch-black. Happens on both Nvidia and AMD.
Thanks for reminding me - I'll get on that! <3
Cacodemon345
Posts: 419
Joined: Fri Dec 22, 2017 1:53 am
Graphics Processor: ATI/AMD (Modern GZDoom)
Contact:

Re: 3DGE 2.1.0 Test3 Released (12.13.2017)

Post by Cacodemon345 »

Also, what is with the Quake 3 BSP support? Sorry if this sounds like a dumb question; haven't really played that game so I don't know.
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
Posts: 49056
Joined: Sat Jul 19, 2003 10:19 am
Location: Germany

Re: 3DGE 2.1.0 Test3 Released (12.13.2017)

Post by Graf Zahl »

Coraline wrote: We dropped all of the other external libraries (which shaved off more than 1MB from the exe) and went with stb_image.
Ah. I've never used it myself but it definitely looks like one of the better options, although for PNG and JPG I'd stick to what GZDoom currently uses, because I'm not really sure that stb_image properly handles all possible variations - and I have seen people use some unusual PNG formats in the past. Besides, GZDoom's PNG code is already very compact.

But for supporting some other formats it looks like a good option.
CeeJay
Posts: 1467
Joined: Sun Mar 14, 2010 2:52 am

Re: 3DGE 2.1.0 Test3 Released (12.13.2017)

Post by CeeJay »

A bit wonky when setting up. When switching from windowed to fullscreen I got a solid black background, restarted the game. Also, had to manually adjust the aspect ratio. Isn't it possible for EDGE to automatically detect these sorts of things?

Now, things I noticed after a very quick play: The exagerated shaking effect when the player is hit is still there. It is too much and it goes on for a little too long. It's like the player is having a seizure.

Also, something about the HUD face is broken. It got stuck in "rage" mode, and wouldn't change even when I restarted the game. Same pain state and all.

That is all for now.
Post Reply

Return to “Game Engines”