ZScript Discussion

[Graf Zahl]

Aside from merely being syntactic sugar - why not?
I saw no point adding new functions here because they are ultimately redundant.

[ZZYZX]

Syntactic sugar? A_Log is not everywhere, and it's the only way to log rn.
Even if we forget about my event stuff, there are Thinkers that shouldnt have A_Log as well because it's an action codepointer for actors.
/anyway, going to finally sleep, spent ultimate 20 sleepless hours awaiting your review of the events ;P, will do the console.printf later/

[dpJudas]

I have also experimented with this, you can find it in src/gl/unused/gl_builddraw.cpp, but this was too slow with large area sectors so in order to work it will require some splitting of large sectors by a different method than a BSP normally uses.

Would you mind sharing your idea, if it's in a presentable state?

Sure. The code can be found on my master branch (https://github.com/dpjudas/dpDoom). To run it, you have to make sure that it is set to use the OpenGL software framebuffer. If you just start it directly from the launch screen without making that change first it will crash due to using OpenGL with the D3D FB.

What is implemented in it is an opaque rendering pass that splits the scene into two categories: static and dynamic. When it loads a map, it first generates a mesh for the entire map. Then, as it detects a sector changing from the original static state, it stops drawing that sector from the static mesh and includes it in a dynamic mesh it generates each frame. The code is pretty stupid about it in the sense that it only checks two states (ceiling and floor position) to decide if a sector changed, and once it changed it keeps generating that sector for the duration of the map (no matter where you are). It also just draws everything each frame.

It is able to render the Frozen Time big room at about 300-500 FPS on my computer (at 1920x1080), although the more stuff you activate in the map the slower it gets because it keeps promoting more and more sectors to the dynamic mesh.

One last thing: make sure you don't include lights.pk3 when launch it. There seems to be some performance problem with the function that links dynamic lights to sectors. I'm not sure yet whether this is a general speed regression in GZDoom, or its the experimental renderer that causes it. Either way, keep dynlights off in FrozenT's big room.

[dpJudas]

I should probably also mention what my full plan is when it comes to drawing the scene: instead of using just a single static mesh like I described above, the plan is to split the map into groups of sectors. Each group would have such a static mesh, and then the main rendering would be to decide which groups are visible.

Since we know which subsectors connect with other subsectors, it should be possible to create some entrance polygon/planes between each such group. That in turn should allow a fast visibility test on a much smaller set, like Doom did using clipsegs when walking the BSP nodes.

[Graf Zahl]

One last thing: make sure you don't include lights.pk3 when launch it. There seems to be some performance problem with the function that links dynamic lights to sectors. I'm not sure yet whether this is a general speed regression in GZDoom, or its the experimental renderer that causes it. Either way, keep dynlights off in FrozenT's big room.

Hard to say, but with such an approach it makes no sense anymore to link the lights into subsectors and linedefs, it may be advisable to link them only to sectors and use that for everything. The main problem may be that the sector links are not ok, they aren't even used by the renderer right now.

And concerning the approach in general - it may need some tinkering with portals, in case a sector wraps around the portal, to avoid having stuff get into the way that's not supposed to be seen. With a subsector-based approach this cannot happen, but otherwise some stray elements may become visible, if no care is taken to weed them out. If you look around in GZDoom's code you may find quite a bit of code to calculate portal silhouettes and stuff so that these elements can be eliminated easily. With a static mesh that would become quite a bit more difficult.

[dpJudas]

And concerning the approach in general - it may need some tinkering with portals, in case a sector wraps around the portal, to avoid having stuff get into the way that's not supposed to be seen. With a subsector-based approach this cannot happen, but otherwise some stray elements may become visible, if no care is taken to weed them out. If you look around in GZDoom's code you may find quite a bit of code to calculate portal silhouettes and stuff so that these elements can be eliminated easily. With a static mesh that would become quite a bit more difficult.

Portals are definitely one of the biggest hurdles to overcome. There's lots of loose ends to resolve in this experimental renderer to show this approach is viable - but I think it nicely demonstrates that tomorrow's GZDoom could very well be drawing things very differently from today's.

[Graf Zahl]

In the end, what' preventing us from combining different approaches: Static mesh for the main parts of the map and some hybrid approach for portals where the static way won't work? The main view is the most important one anyway so if that can be sped up, it may even be fine to render the portals with a traditional BSP - and even there a lot depends on the portal's shape. A line portal can be handled with a simple hardware clip plane and for sector portals some analysis is necessary to decide how to do it - but that's normally a one-time operation when the map starts.

Well, maybe it's something to tackle when your work on the software renderer is done.

[Rachael]

@ ZZYZX:

After seeing this unfold, my only real comment is this:

When someone tells you something is a bad idea, they have their reasons for it. If you want to throw caution into the wind I would advise you to create a fork. You really are a capable coder and I know you have at least enough of a following that it will stand for its own merit without too much effort on your part.

But the problem is - when one of us disagrees with you, you seem to have no problem arguing with us about it. We're not here to argue with you - and just keep in mind, MaxED left this community for a reason - if this stuff stops being fun for us, you can bet we will be gone too. That includes when you think that something is a "good idea" but it creates a mess/nightmare for us.

The license is as permissive as it is for a reason. Fork the code and maintain it with downstream for a year. I think in that time, you will begin to see very clearly why Graf and dpJudas (and myself, actually, especially with regards to the suggestion with your logic code and renderer feature check) are not in your park. It's understandable that you won't take anyone's word at face value but if that's the way you are going to be, then maybe you need some first-hand experience with it and maintaining it, to see why they think that way.

And to make it clear: I am 100% against any renderer code touching playsim code whatsoever. All by itself this will break Zandronum compatibility right out the gate because it does run as a headless server no matter what renderer it is configured for. And I've already mentioned breaking demos and multiplayer - even in the sorry state that they are in now I see no reason to break them further. Please don't.

[Kinsie]

When someone tells you something is a bad idea, they have their reasons for it. If you want to throw caution into the wind I would advise you to create a fork. You really are a capable coder and I know you have at least enough of a following that it will stand for its own merit without too much effort on your part.

But the problem is - when one of us disagrees with you, you seem to have no problem arguing with us about it. We're not here to argue with you - and just keep in mind, MaxED left this community for a reason - if this stuff stops being fun for us, you can bet we will be gone too. That includes when you think that something is a "good idea" but it creates a mess/nightmare for us.

I personally thought the back and forth between ZZYZX and Graf was fairly civil and reasonable. No name-calling, no raised voices, just two fairly knowledgeable people disagreeing back and forth, marking some boundaries for ZScript and spawning some interesting discussion about possible renderer futures.

[Rachael]

I wasn't trying to imply there was any real hostility, but there was a case of simply not taking "no" for an answer, and that was mainly what I am trying to address.

"No" from any dev - be it dpJudas, Graf, myself, ZZYZX, or anyone else - simply means "do it (and maintain it) yourself if you want it that badly." After that point, the discussion should be over, unless you have some REALLY compelling reason to keep it going (in this case, I didn't think there was much of one - mucking with the renderer state in any playsim code whatsoever is really a dead issue in my book).

[Graf Zahl]

And to make it clear: I am 100% against any renderer code touching playsim code whatsoever. All by itself this will break Zandronum compatibility right out the gate because it does run as a headless server no matter what renderer it is configured for. And I've already mentioned breaking demos and multiplayer - even in the sorry state that they are in now I see no reason to break them further. Please don't.

These are good points, actually, which I didn't even think of. Which makes it even more problematic.
I can see the problem this is trying to solve but it should be clear that this approach is not working - if it can be done with some actor settings the renderer just needs to check and act upon it will both be less invasive and more future proof.

So, if you want this solved, better make a new thread, clearly outline the problem you want to address and hope that some good ideas are thrown around.

[Major Cooke]

Is Size() capable of being used right now or is that still partial implementation just like the dynamic arrays?

[Graf Zahl]

Size() for what?

[Major Cooke]

Arrays in general.

Code: Select all

for (int i = 0; i < myArray.Size(); i++)
//Or would it be <= ?

[The Second]

Hello,

I'm wondering if there is a Zscript language file available for Slade, notepad++ or other text/script editor. If not, is there a list of Zscript keywords and functions so I can write my own language file?

Notepad++: Say no more fam

SLADE: Coming soon according to sirjuddington

List of keywords: Look inside gzdoom.pk3, it's all in the /zscript directory

Thanks for the info.

Nice to see Slade is still in active development as well.