"DSDoom"
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.
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.
-
- Posts: 3886
- Joined: Fri Feb 08, 2008 9:15 am
- Preferred Pronouns: She/Her
- Operating System Version (Optional): (btw I use) Arch
- Graphics Processor: nVidia with Vulkan support
- Location: Vigo, Galicia
Re: "DSDoom"
Wait... you guys added custom screen shading? Damn that's what I gave up trying to implement...
-
- Posts: 8
- Joined: Sun Jun 22, 2014 4:39 pm
Re: "DSDoom"
We haven't started that feature, what with all the Python. What problems did you run into?Saya-chan wrote:Wait... you guys added custom screen shading? Damn that's what I gave up trying to implement...
-
- Posts: 2950
- Joined: Thu Jul 17, 2003 12:07 am
- Graphics Processor: ATI/AMD with Vulkan/Metal Support
Re: "DSDoom"
Depends how easy it is in the first place. Save-scumming can be cheap, yes, but isn't that up to the player to do? They're the ones playing, and if they get more enjoyment with save-scumming, why purposely make them have a less enjoyable time? If something is too hard to do in a single straight run, and a player needs to be able to save regularly to not lose too much progress, shouldn't that be up to them?DevilBlackDeath wrote:Reason is that the "save anytime" system is kind of cheap Put down some health on the boss without losing health -> save -> repeat over and over (load when losing too much health) and that becomes a piece of cake
Sounds like a self-control problem. Just because you habitually do something you don't want to do doesn't mean you should prevent someone else from doing what they want (or need) to do. Besides, actually saving isn't a problem. If you 'accidentally' saved when you didn't want to, then you can simply ignore or delete that save the next time you're in the load screen (where the flow of the game is already broken).I know because I used to do this, and this is WAY too easy, now I save only at the beginning of every level, and it actually brings some challenge without being cheap ^^ So here are my 2 cents. And it would actually enhance some projects. If not forcing the player to not save, I would at least like to see an option to turn quick save off (I still have the habits of hitting F5 sometimes, I have to refuse saving and that breaks my pace )
What would be nice, though, is putting quicksave and quickload keybindings in the customize controls menu (I didn't notice them there when I checked). That way players can disable them if they want, or easily remap them to something more appropriate for them.
-
- Posts: 3886
- Joined: Fri Feb 08, 2008 9:15 am
- Preferred Pronouns: She/Her
- Operating System Version (Optional): (btw I use) Arch
- Graphics Processor: nVidia with Vulkan support
- Location: Vigo, Galicia
Re: "DSDoom"
The source code being a major pain in the butt to work with is pretty much the only problem I ran into. :Vdeathsong13 wrote:We haven't started that feature, what with all the Python. What problems did you run into?Saya-chan wrote:Wait... you guys added custom screen shading? Damn that's what I gave up trying to implement...
-
- Posts: 244
- Joined: Tue Oct 18, 2011 8:57 am
Re: "DSDoom"
THIS is what I am interested in.deathsong13 wrote: [*] Hit locations (head shots, leg shots, etc.) natively supported rather than hacked in with custom damage types.
[*] "Paperdoll" sprites (maybe voxels?) that would allow you to say, define a base dude and then seventeen hairstyles and outfits which could be randomized at runtime.
-
- Posts: 676
- Joined: Wed Apr 03, 2013 11:36 am
- Location: Elsewhere.
Re: "DSDoom"
Actually, if you're interested in adding procedural content, there is something I may be more interested in even than procedurally generated BSP: procedurally generated actors. Being totally unfamiliar with ZDoom's source code, I may just be naming the impossible. But, if by chance I'm not, it would be a fantastic aid to ZDoomers that want to introduce new behaviors to several actors without the tedium of going from definition to definition and applying changes by hand.Loki wrote:Bingo. In fact, one thing I would love to do, eventually, is to add support for procedurally-generated BSP.SidDoyle wrote:I think it shouldn't be too hard for any of us to agree that procedural content is becoming increasingly popular and revealing new ways to increase replayability and complexity.
A seamless integration of decorate and ACS in some sense. Actually, as far as I know, adding new states and redefining states may be just about the only thing scripts have no access to. If there were a way to manipulate these at a base level (for all actors of a type) and on a per-TID basis, that would be incredible.
-
- Posts: 17
- Joined: Wed Jul 06, 2005 6:20 pm
- Location: Sigil, the City of Doors
Re: "DSDoom"
That may be one of the bigger understatements I've heard lately. I sometimes work on a 5-year-old fork of a decade+-old open-source C HTTP server at my job, in which the new code is mostly in C++ but has annoyingly inconsistent C idioms everywhere, and even that was easier to manage than ZDoom's source tree. When you're using malloc() and free() (or, in ZDoom's case, a custom wrapper called M_Malloc()) to manage the memory of C++ types, you've probably taken a wrong turn somewhere. Not to mention that pretty much any code that has to deal with rendering, especially in OpenGL, is going to be pretty hideous by necessity if nothing else.Saya-chan wrote: The source code being a major pain in the butt to work with is pretty much the only problem I ran into. :V
Aaaanyway, /rant. At least ZDoom doesn't also need to be a highly-available fault-tolerant web service, I suppose.
That's another thing we've definitely thought about, especially since we're interested in having paperdoll sprites and/or voxels. Given what I know about the ZDoom source, I have a feeling that might even be easier than procedural level generation: to the credit of Randy and co., Actors are pretty flexible, and hooking into the same system that DECORATE uses might prove to be relatively straightforward. Not to build you up too much, though, as I haven't actually tried yetSidDoyle wrote: Actually, if you're interested in adding procedural content, there is something I may be more interested in even than procedurally generated BSP: procedurally generated actors.