[WIP] PyDoom! GZDoom with Python scripting

[Kate]

Blender also runs off of Python Scripting so maybe this could be used to bring functions of Blender over.

I'm reminded of similar suggestions.

...They didn't happen either.

Will there be a way to change the ticrate?

Short answer: No.
Long answer: NNNNNNNNNNNNNNNNoooooooooooooooooooooooooo. Though, I will probably have a way of interacting with the actor thinker iterator, which will allow one to do the same thing that a [wiki=Classes:PowerTimeFreezer]TimeFreezer[/wiki] can do, possibly have similar for players and certain kinds of non-actors as well.

[MetroidJunkie]

Blender also runs off of Python Scripting so maybe this could be used to bring functions of Blender over.

I'm reminded of similar suggestions.

...They didn't happen either.

To be fair, both of those requests are easily solvable by going through GZDoom. The things I was thinking of are things that literally no Doom Source Port has ever managed to pull off. The only thing close I've seen is eDuke.

[MaxED]

Well, I really don't know anything about python scripting myself, I was just shooting the possibility. Of course, Blender has many functions involving 3D models such as shader effects that would be useful in GZDoom. Of course, that would rely on the community being interested in such a thing, which doesn't seem to be the case.

When totally different project uses the same programming language it doesn't mean that you can just copy-paste it's sources to your project and have all the features from said project. Blender's scripts rely on Blender's scene hierarchy, utility, renderer etc., which are not present in GZDoom.

[MetroidJunkie]

When totally different project uses the same programming language it doesn't mean that you can just copy-paste it's sources to your project and have all the features from said project. Blender's scripts rely on Blender's scene hierarchy, utility, renderer etc., which are not present in GZDoom.

Fair enough, but it's not as though Doom's original renderer allowed for things like models or dynamic lights, either and Duke 3D has the same kind of sector lighting system that Doom does but it didn't stop eDuke from having the advanced lighting effects it does.

[InsanityBringer]

Fair enough, but it's not as though Doom's original renderer allowed for things like models or dynamic lights, either and Duke 3D has the same kind of sector lighting system that Doom does but it didn't stop eDuke from having the advanced lighting effects it does.

Of course, but EDuke has a new renderer written from scratch to support the advanced lighting effects it does support now. GZDoom's renderer is also written from scratch, and it could support the same level of special effects, though from what I've observed over these years Graf is typically somewhat conservative about adding new effects to the game (but also, some effects would require extensive changes to doom's core, like dynamic lights that can be clipped properly in certain cases).

I guess that rendering hooks could be exposed in PyDoom, and you could go through a painstaking process to rework Blender's scripts to work with it, but at some point, everyone involved will probably ask themselves, "is this really the best way?"

[MetroidJunkie]

Of course, but EDuke has a new renderer written from scratch to support the advanced lighting effects it does support now. GZDoom's renderer is also written from scratch, and it could support the same level of special effects, though from what I've observed over these years Graf is typically somewhat conservative about adding new effects to the game (but also, some effects would require extensive changes to doom's core, like dynamic lights that can be clipped properly in certain cases).

I guess that rendering hooks could be exposed in PyDoom, and you could go through a painstaking process to rework Blender's scripts to work with it, but at some point, everyone involved will probably ask themselves, "is this really the best way?"

Yeah, I sort of got the impression that the Doom Community simply doesn't care about effects that much, I guess because Doom fans tend to be more fans of the old school. I asked TerminX how eDuke manages to do it and his response was "it tessellates the whole sector based map into actual 3D geometry every time it changes" which I guess WOULD involve completely rewriting the renderer. Probably not a very reasonable request but it seemed odd to me that they bothered to give GZDoom things like models and dynamic lights without wanting to go any further than that.

[MaxED]

I may be HORRIBLY wrong, but I think dynamic lights and model support were ported from ZDoomGL. I'd really like to see some changes in GZDoom's rendering department, but I don't think that doing that via external scripts is the proper way.

[Minigunner]

I'm not sure if GL code can be modified or expanded by Python scripts in the first place.

[Kate]

Okay, so I'm going to pose a serious question to anyone that's interested in this - Would you be pizzacato'ed off if I required a system install? It's not necessary of course, it would only keep distribution size down. I'm fine with either option.

For reference, the library, stripped of stuff I'm definitely never going to use like sqlite and html, is ~1.5mb, so less than the exe itself. With further stripping as time goes on, it will shrink more.

[Patriot1776]

I wouldn't mind it, IF you include a utility to COMPLETELY and CLEANLY uninstall it later with no remnants left of it after the uninstall. I really like this whole idea of GZDoom with Python working in it. This whole concept of modding games like this using currently utilized programming languages I think is also an awesome way for people to have a fun way of learning to program. I can for one thing say I've been enjoying learning fundamental programming concepts from playing with ACS, and this project would give me a fun avenue to learn Python. My ACS knowledge is still of course very rudimentary. Best I've done so far is be able to change sector lighting at level load and also make a multi-sector platform lift to have a lift with multiple brightness levels in it.

[Kate]

There's no need for an uninstaller because there's no installer. So I guess like blender is actually grossly incorrect, since, as the original option said, it's still drag and drop, so it won't leave anything outside of its' own directory. The main difference between the two options is size, and the need for an install already in place - you'd have to visit Python.org to grab the installer and run it yourself if I didn't include the library is all.

Updated the poll to reflect this.

[Patriot1776]

Ahh. I think I've already got Python then, as on my home system, I've installed blender just to try and play around with a few things and get my feet wet with models, more learn about models than anything, but I see now. Nice, just make it such that Python has to be installed beforehand.

[Kate]

Okay so re-thinking on it, I actually am swinging toward including a stripped version of the library, because I've gotten it down to ~1.2mb, which is really not much these days, and it also gives me the option to export actual game code into the library zip when/if I get around to doing so (Decorate parser is the first to go, rewriting it because it majorly blocks forward progress due to ...Well, long story short, it's every one of the coding-related horror stories I've ever heard come true), which I'm really wanting to do because it'll make it much more maintainable for me since I'm not nearly as skilled in C++ as I am in Python.

This won't affect wads for the most part, it's mostly just preference, but it may open up some future modding possibilities.

Edit: Okay, so 11 / 0 vote, I'll include the standard library in future distributions.