EDGE-Classic v1.37 (Updated December 2023)

[macro]

2 hours ago, Lobo said:

Can we get the wad?

FYI, our voxel code comes from k8vavoom.

 

Thank you for the info.

 

I attach a WAD with a simple map, a sample voxel and scripting. You can drag & drop over the .exe to test it.

 

I used Goxel 3D to create it. But the result is the same using VoxelShop.

I tested KVX and KV6 formats. The colours are from the Doom palette.

 

The second file that I attach is the Doom Palette in Gimp format. You can use this palette only with Goxel 3D. You must place it exactly in

"C:\Users\<User>\AppData\Roaming\Goxel\palettes\". In Linux, I have no idea.

 

I don't have time now, but I will test this also with zDoom to see how is the result.

VOXELTEST.zip

Doom_Palette_Gimp.zip

[dasho]

4 hours ago, Redneckerz said:

@dasho @Lobo my typical nitpick request returns, but i am just keeping the lights on it because i really want to promote EDGE as a engine capable of this:

Standalone support for games. What is the current status? Because it would be awesome to see Alien: Stranded and Operation Artic Wolf be legit standalone titles (And then i can update said relevant thread for it, + wiki).

 

Please do not incinerate me for keeping tabs on this. :P

 

I do need to test it out with a more 'real-world' scenario, i.e. add the EDGEGAME lump to something like Arctic Wolf and see what errors I get, if any, when trying to launch it as an independent game. I know a lot of TCs that are 'almost' standalone games usually need a PLAYPAL added to them at a minimum. I'll post an update when I get a chance to suss it out.

[dasho]

7 hours ago, macro said:

I found that colours of individual boxes in voxels seem to be smoothed or blended in the horizontal plate, even in smoothing is not activated in EDGE.

 

Looks like I had GL_LINEAR set by default in the voxel code when processing the model. That should probably be GL_NEAREST instead. I'm guessing I was copying some of our MDL model loading stuff which uses smoothing on the skins by default, although I'm wondering if that shouldn't be changed too.

[Herr Dethnout]

4 hours ago, Jayextee said:

Gamers™ being how they are, if a game doesn't run at the absolute maximum framerate their monitor can output then apparently it's shit and unplayable.

Oh yeah, the Gamers™ how "can see" the difference between 60 and 200 fps and if it drops to 59 then is complete unplayable. heh

Anyway talking about EDGE, I realized that the spanish translation is... strange. It has questionable translations, like translating text in the most literal way possible (ON = Encendido? it would be better ON = Activado), it looks like mostly like a Google translator text than an actual human translation lol

Other thing, aside it only translates the game and the rest (the EDGE Menu) is unstranslated is the lack of latin characters (like vocals with tilde and ¡, ¿, ñ, etc...)

I suppose that enhancing the translations is the least priority, but would be nice to give some work on this :P

[dasho]

3 minutes ago, Herr Dethnout said:

Oh yeah, the Gamers™ how "can see" the difference between 60 and 200 fps and if it drops to 59 then is complete unplayable. heh

Anyway talking about EDGE, I realized that the spanish translation is... strange. It has questionable translations, like translating text in the most literal way possible (ON = Encendido? it would be better ON = Activado), it looks like mostly like a Google translator text than an actual human translation lol

Other thing, aside it only translates the game and the rest (the EDGE Menu) is unstranslated is the lack of latin characters (like vocals with tilde and ¡, ¿, ñ, etc...)

I suppose that enhancing the translations is the least priority, but would be nice to give some work on this :P

 

Any non-English translations are from, well, I guess whenever they were added along the way with DosDoom or EDGE. We'll gladly accept any updates from native speakers that will have them make more sense. The translation file is located in our repo at https://github.com/edge-classic/EDGE-classic/blob/master/edge_defs/scripts/language.ldf and is a plain text file (does not require any knowledge of 'programming' to work with). 

 

About the lack of extended characters, almost all of the text-related routines in the program are still Unicode-unaware, and as such they have no concept of characters outside of the ASCII/extended ASCII set. This will evolve as we now support things like Truetype fonts, but for now it is indeed a limitation.

 

[Redneckerz]

1 hour ago, dasho said:

 

I do need to test it out with a more 'real-world' scenario, i.e. add the EDGEGAME lump to something like Arctic Wolf and see what errors I get, if any, when trying to launch it as an independent game. I know a lot of TCs that are 'almost' standalone games usually need a PLAYPAL added to them at a minimum. I'll post an update when I get a chance to suss it out.

Appreciated. Can you tell me which TC's qualify as almost standalone for you?

[dasho]

2 minutes ago, Redneckerz said:

Appreciated. Can you tell me which TC's qualify as almost standalone for you?

 

Honestly, that's probably a better question for Lobo and CeeJay; other than AEM which you've already mentioned...mayyyybe something like QDoom? 

 

EDIT: Also, Astral Pathfinder even though it is short on level count. That would probably need Freedoom's enemies though so I'm not sure how that would turn out.

Edited August 18, 2023 by dasho

[Herr Dethnout]

1 hour ago, dasho said:

 

Any non-English translations are from, well, I guess whenever they were added along the way with DosDoom or EDGE. We'll gladly accept any updates from native speakers that will have them make more sense. The translation file is located in our repo at https://github.com/edge-classic/EDGE-classic/blob/master/edge_defs/scripts/language.ldf and is a plain text file (does not require any knowledge of 'programming' to work with). 

 

About the lack of extended characters, almost all of the text-related routines in the program are still Unicode-unaware, and as such they have no concept of characters outside of the ASCII/extended ASCII set. This will evolve as we now support things like Truetype fonts, but for now it is indeed a limitation.

 

I made some progress. I'm making a retranslation taking some references from Unity Doom, but it will be "original" rather that taking the Unity's translation heh
 

Spoiler

 

[Herr Dethnout]

I forgot, the unicode text also affect the sprite font (eg the ED1FNXXX)? because it can be possible to add the sprites with the extended characters and modify the font definition file o something like that.

[dasho]

40 minutes ago, Herr Dethnout said:

I forgot, the unicode text also affect the sprite font (eg the ED1FNXXX)? because it can be possible to add the sprites with the extended characters and modify the font definition file o something like that.

 

It currently affects all fonts, but yes you're right in that if you have a sprite with an extended character and a way to look it up it would work as well. Right now, most of the text functions simply drop a character or substitute the 'missing character' symbol if you provide it input outside of the ASCII range.

[Lobo]

And what spanish are you going to do?

Castillian or South America? 

[Herr Dethnout]

11 minutes ago, dasho said:

 

It currently affects all fonts, but yes you're right in that if you have a sprite with an extended character and a way to look it up it would work as well. Right now, most of the text functions simply drop a character or substitute the 'missing character' symbol if you provide it input outside of the ASCII range.

I see, welp I suppose just wait until the extended character is on Edge cuz I'm working using it lol

 

Spoiler

Anyway, more progress, I trying to give some death messages a "dark comedy" text, although I probably change the WolfSS death, because is proably "too dark/edgy". Also translating most of the Enemies names, but probably revert this too because it doesn't seem to look good xd

 

[Herr Dethnout]

4 hours ago, Lobo said:

And what spanish are you going to do?

Castillian or South America? 

I'm from South America, but I'm trying to be the most neutral possible in this translation. So it will be just Spanish in general. :P

Edited August 18, 2023 by Herr Dethnout

[Lobo]

Me parece bien ;)

[Herr Dethnout]

A pinche Lobo, con que si sabes hablar el fino arte del castellano. xd

[macro]

8 hours ago, dasho said:

 

Looks like I had GL_LINEAR set by default in the voxel code when processing the model. That should probably be GL_NEAREST instead. I'm guessing I was copying some of our MDL model loading stuff which uses smoothing on the skins by default, although I'm wondering if that shouldn't be changed too.

 

I would say that the expected behaviour regarding smoothing of voxels should be the same as what the player set in the configuration. So if the player set GL_NEAREST, everything, including voxels, should have GL_NEAREST filter.

[dasho]

28 minutes ago, macro said:

 

I would say that the expected behaviour regarding smoothing of voxels should be the same as what the player set in the configuration. So if the player set GL_NEAREST, everything, including voxels, should have GL_NEAREST filter.

 

I would agree in most cases, but in the case of voxels I worry that there will be a lot of irregularities with GL_LINEAR, like so
 

Spoiler

 

Edited August 19, 2023 by dasho

[macro]

2 hours ago, dasho said:

 

I would agree in most cases, but in the case of voxels I worry that there will be a lot of irregularities with GL_LINEAR, like so
 

  Hide contents

 

 

Yes, that looks bad and having gl_nearest is, in my opinion, the best looking style.

 

Maybe a solution could be to always force gl_nearest for voxel models even if the player activates smoothing, so the gl_linear filter only applies to textures and sprites but not to voxels.

 

Did you made a custom build to take that screenshot?

If so, would you please share it here? I need to test some voxels with letters such as in-game panels and signs, but with smoothing it is difficult to assess well the visibility of the letters.

 

Thank you.

[dasho]

12 hours ago, macro said:

 

Yes, that looks bad and having gl_nearest is, in my opinion, the best looking style.

 

Maybe a solution could be to always force gl_nearest for voxel models even if the player activates smoothing, so the gl_linear filter only applies to textures and sprites but not to voxels.

 

Did you made a custom build to take that screenshot?

If so, would you please share it here? I need to test some voxels with letters such as in-game panels and signs, but with smoothing it is difficult to assess well the visibility of the letters.

 

Thank you.

 

https://files.catbox.moe/rwhhnc.zip here is a 32-bit Windows build with the latest contents of the repository, which include switching voxels to use GL_NEAREST.

[camper]

Is it correct that the "jumpover" flag for lindef in udmf format doesn't work in edge-classic? The "midtex3d" flag won't work either?
This is for jumping over railings and fences.

[dasho]

2 hours ago, camper said:

Is it correct that the "jumpover" flag for lindef in udmf format doesn't work in edge-classic? The "midtex3d" flag won't work either?
This is for jumping over railings and fences.

 

We do not support Hexen specials or the ZDoom UDMF namespace. Please consult https://github.com/edge-classic/EDGE-classic/blob/master/docs/specifications/UDMF EDGE Extensions.txt for the current state of our namespace.

 

EDIT: jumpover appears to be a Strife special, which per our documentation above is not a supported namespace either.

Edited August 20, 2023 by dasho

[macro]

8 hours ago, dasho said:

 

https://files.catbox.moe/rwhhnc.zip here is a 32-bit Windows build with the latest contents of the repository, which include switching voxels to use GL_NEAREST.

 

Thanks a lot. It works perfectly and all the voxels look beautiful. Hopefully didn't take you much time to compile that.

 

 

2 hours ago, camper said:

Is it correct that the "jumpover" flag for lindef in udmf format doesn't work in edge-classic? The "midtex3d" flag won't work either?
This is for jumping over railings and fences.

 

That can easily be achieved with a simple 1-map-unit wide transparent 3D floor. 

I don't know exactly how that "jumpover" works, but if it is just what the name suggests then the result would be exactly the same, so I don't see the point of introducing new functions that produces basically the same results as what we have, but they require the developers to invest their time in coding them and possibly further work if bugs are found in the future.

 

In my case, I love the current status of EDGE-classic. I would rather like to have a way to call COAL functions from RTS/DDF in a simple and elegant way rather than adding other less useful functionalities.

 

Just my opinion, though, but EDGE is not gzdoom and hope it will never be.

[dasho]

17 hours ago, macro said:

In my case, I love the current status of EDGE-classic. I would rather like to have a way to call COAL functions from RTS/DDF in a simple and elegant way rather than adding other less useful functionalities.

 

About COAL, although COAL can execute RTS (this is essentially how the inventory system works; inventory item effects are simply RTS scripts), I'm not sure that having RTS call COAL directly would be useful unless you were wanting to change HUD elements via RTS somehow.

 

There is a distinct possibility that COAL will be 'frozen' in its current state and deprecated in favor of a more robust scripting solution moving forward. There are several candidates for what that might be, but Luau (a Lua implementation, https://luau-lang.org/) is a frontrunner at the moment (which oddly enough would be a throwback to earlier versions of EDGE itself).

[Lobo]

21 hours ago, macro said:

 

In my case, I love the current status of EDGE-classic. I would rather like to have a way to call COAL functions from RTS/DDF in a simple and elegant way rather than adding other less useful functionalities.

You can almost certainly do whatever you are thinking of right now. Generally with EDGE where there is a will there is a way.

You can call rts scripts from coal. And you can have rts change something (e.g. counters or ammo or health etc) that coal can detect and react accordingly.

[taufan99]

3 hours ago, dasho said:

There is a distinct possibility that COAL will be 'frozen' in its current state and deprecated in favor of a more robust scripting solution moving forward. There are several candidates for what that might be, but Luau (a Lua implementation, https://luau-lang.org/) is a frontrunner at the moment (which oddly enough would be a throwback to earlier versions of EDGE itself).

I think that's a pretty good solution to an extent. Would like to see an experimental build with a Luau support; I wonder where it might lead us to.

[dasho]

1 hour ago, taufan99 said:

I think that's a pretty good solution to an extent. Would like to see an experimental build with a Luau support; I wonder where it might lead us to.

 

When it's ready to fold in for testing, it will likely start as a CMake compile-time option and remain so for a while as it's polished up. 

[macro]

4 hours ago, dasho said:

 

About COAL, although COAL can execute RTS (this is essentially how the inventory system works; inventory item effects are simply RTS scripts), I'm not sure that having RTS call COAL directly would be useful unless you were wanting to change HUD elements via RTS somehow.

 

There is a distinct possibility that COAL will be 'frozen' in its current state and deprecated in favor of a more robust scripting solution moving forward. There are several candidates for what that might be, but Luau (a Lua implementation, https://luau-lang.org/) is a frontrunner at the moment (which oddly enough would be a throwback to earlier versions of EDGE itself).

 

Probably I meant more like call RTS from LUA. But I just found about "player.use_inventory(type)", so excuse my ignorance. There could be certain cases where calling COAL from RTS could be nice, but most likely not so useful.

 

As for Luau, it sounds really interesting and will be looking forward to know more about it in the future.

But would you please describe roughly what plans do you have in mind? What would be the purpose? Would be for HUD management and some simple functionality like COAL? Or a totally new scripting system like ACS for ZDoom, but better?

 

 

 

1 hour ago, Lobo said:

You can almost certainly do whatever you are thinking of right now. Generally with EDGE where there is a will there is a way.

You can call rts scripts from coal. And you can have rts change something (e.g. counters or ammo or health etc) that coal can detect and react accordingly.

 

 

Although I agree with you and generally speaking most of the things can be done, certain things are complicated or even impossible such as random number generation (could be done to a certain extent with DDF "JUMP" action) and variables to store arbitrary information. "Ammo" counters are fine if you need to count events, but cannot be used to store anything else, for example, how much health the player has when he enters the boss room.

 

But since I just found about "player.use_inventory(type)", all of this is most likely possible, and this opens a whole universe of possibilities.

[dasho]

11 minutes ago, macro said:

As for Luau, it sounds really interesting and will be looking forward to know more about it in the future.

But would you please describe roughly what plans do you have in mind? What would be the purpose? Would be for HUD management and some simple functionality like COAL? Or a totally new scripting system like ACS for ZDoom, but better?

 

The purpose would be to have a more developed language first and foremost. COAL is good for what it does, but if for instance you want something like an array or vector (the container, not the 3-float value that is the current COAL 'vector' type), it would require further developing the language. Lua is going to be much more 'batteries included' by comparison. Also, for beginners to programming/scripting, there are plenty of resources for learning Lua. As far as what it can do, it could theoretically do anything that COAL and RTS is doing right now. It would also be nice to have the menu system be a bit more dynamic and handled through Lua. 

 

Quote

Although I agree with you and generally speaking most of the things can be done, certain things are complicated or even impossible such as random number generation (could be done to a certain extent with DDF "JUMP" action) and variables to store arbitrary information. "Ammo" counters are fine if you need to count events, but cannot be used to store anything else, for example, how much health the player has when he enters the boss room.

 

We have added COUNTER00-COUNTER99 for free use by the modder. These can be updated and read from either RTS or COAL.

[Lobo]

The COUNTER types can be used to store arbitrary values. In fact just to push home the idea COUNTER01-COUNTER04 can also referenced as LIVES,SCORE,MONEY and EXPERIENCE respectively.

And don't write off the power of being able to call an RTS script from coal via hud.rts_enable(tag): that opens a lot of doors...

Random numbers can be generated from COAL.

 

https://edge-classic.github.io/ddf/index.htm

Has documentation on DDF and COAL.

[macro]

12 hours ago, dasho said:

 

The purpose would be to have a more developed language first and foremost. COAL is good for what it does, but if for instance you want something like an array or vector (the container, not the 3-float value that is the current COAL 'vector' type), it would require further developing the language. Lua is going to be much more 'batteries included' by comparison. Also, for beginners to programming/scripting, there are plenty of resources for learning Lua. As far as what it can do, it could theoretically do anything that COAL and RTS is doing right now. It would also be nice to have the menu system be a bit more dynamic and handled through Lua. 

 

Other that bugfixes and such, will RTS development stop as well in favour of LUAU scripting?

Also, would it be possible to address engine-level stuff or it will be like only an alternative to COAL/RTS, meaning, will it be some sort of interpreted engine by itself (think of LOVE engine is respect LUA)?

 

Feel free to ignore my opinion, but I would prefer to be only an alternative to COAL and RTS with maybe a few extra functionalities but without being some sort of interface to a lower level programming.

 

7 hours ago, Lobo said:

The COUNTER types can be used to store arbitrary values. In fact just to push home the idea COUNTER01-COUNTER04 can also referenced as LIVES,SCORE,MONEY and EXPERIENCE respectively.

And don't write off the power of being able to call an RTS script from coal via hud.rts_enable(tag): that opens a lot of doors...

Random numbers can be generated from COAL.

 

https://edge-classic.github.io/ddf/index.htm

Has documentation on DDF and COAL.

 

I recently found about the calling of RTS from COAL, and that is what I am mostly interested in at this moment.