Sooo, why doesnt GZDoom support replays? Or accurate compatibilities for that matter (closed: fatally consumed by derail that is not worth the time to prune)

[dasho]

34 minutes ago, banjiepixel said:

People would be more likely try and use EDGE-Classic if it is part of the software they are already using.

 

Or, like we've already seen, they will try to run ZDoom-oriented content on it and come to the conclusion that our engine doesn't work. They may also assume that we have the same lineage that Boom's descendants have (we don't) and discard EC because it does not have the compatibility that they expect.

 

34 minutes ago, banjiepixel said:

Using any lesser known standalone source port is always a potential security risk to the user.

 

This is FUD.

Edited October 20, 2023 by dasho

[Redneckerz]

32 minutes ago, banjiepixel said:

It was an attempt to be polite while giving still some push back against bad attitudes. Graf is a big name in the community so a direct reference is fine. But since I am more unfamiliar with the status of people do seem to have similar bad attitude, I feel like it's best not target them directly. In my mind "SOME GZDoom people" does atleast make it clear that I am not talking about all GZDoom users and for me it seems good enough as it would be a real generalization to me. Simply hinting about that there are some unnamed people that might need an attitude check shouldn't piss anyone off outside of those seem to have the attitude issues that I hinted at, atleast if they are able read my hints. Unrelated people with a clean conscience should be smart enough to understand I couldn't possibly be talking about them, right?

But it makes it very meaningless, equally so. Saying ''Some folks need an attitude check'' says nothing if you aren't referring to that person. You need to be celar.

 

EDIT: I mean, hell, i literally just got called out for failing to do the same thing!

27 minutes ago, Individualised said:

Can we not do this?

Gsus. I literally was phrasing the OP and only now see what this says so left out of context. There was zero intention in making a comparison, here! Ill edit it right away and i have sent my pencil to sharpening camp.

Edited October 20, 2023 by Redneckerz

[Individualised]

1 hour ago, Redneckerz said:

Gsus. I literally was phrasing the OP and only now see what this says so left out of context. There was zero intention in making a comparison, here! Ill edit it right away.

For future reference the term is "neurotypical". The person you were replying to used the word "neuroatypical" which is a dated way of saying "neurodivergent" so I see where the confusion came from. No hard feelings at all.

1 hour ago, banjiepixel said:

Different code bases can be adapted to become semi standalone modules that work in same underlying engine, this is pretty much how RetroArch works. It should be actually even easier simply because we are nnly talking about variations of the same base Doom source code. It would probably require completely new underlying engine designed to be modular from the ground up, but the thing is that all of the existing GZDoom code could be adapted into being a module. Why emulator community can do it but not the Doom community?

Because it's not the same thing at all. RetroArch passes video/audio output from an emulator core and passes input and config stuff to an emulator core. Realistically this is the only way an emulator frontend can be done, as the only thing you can rely on every core doing is taking input and displaying some sort of video. It is a similar situation with Doom clients - there is pretty much an infinite amount of ways to do things and therefore the only thing you can really expect every Doom client to do is output video of some sort and take input. Because we even have source ports now that render in a completely different way to other ports. I was going to say maybe you can also rely on every Doom source port reading a .WAD file but I remembered there are even exceptions to that (Phoenix Doom). Essentially what you would be doing is just recreating RetroArch. RetroArch even has a PrBoom core.

Edited October 20, 2023 by Individualised

[Redneckerz]

2 minutes ago, Individualised said:

For future reference the term is "neurotypical". The person you were replying to used the word "neuroatypical" which is an dated way of saying "neurodivergent" so I see where the confusion came from. No hard feelings at all.

Its pretty ironic considering i know many autistic people myself and tend to write people in the they form to remain genderneutral. Over here, ''neurodivergent'' has been used pretty commonly by autistic people. I prefer to write just ''people'' instead, ''neurotypical'', to me atleast, gives it a special name and i don't think there is anything special about being autistic.

[banjiepixel]

25 minutes ago, Graf Zahl said:

 

You clearly have no idea what this entails. No, it isn't nearly as clearcut as you make it out. Remember: Raze is a somewhat watered down version of such a concept and it is not trivial keeping all this stuff in sync between the 4 different game modules.

 

You seem be talking about all the game modules using generally the same expanded feature set which would require things being kept more in the sync. But my idea would mean that the modules would be both more separate from eachother and mode standalone, often lacking even big portions of the expanded feature set or replicating them in standalone manner eliminating dependencies of the features built into the underlying engine.

 

I am seriously just curious about the potential roadblocks. I know I am taking your time but any serious discussion about my idea would be welcome. Doesn't need to be related to GZDoom, just you sharing your general knowledge as a programmer.

 

3 minutes ago, dasho said:

 

Or, like we've already seen, they will try to run ZDoom-oriented content on it and come to the conclusion that our engine doesn't work. They may also assume that we have the same lineage that Boom and its descendants have (we don't) and discard EC because it does not have the compatibility that they expect.

 

Great thing about open source is that you are not required make a EDGE-Classic module but someone else that happens to be interested could adapt it into being a module. And if modules would generally universal, almost any source port could very easily have EC support, even those not based on ZDoom, or Boom.

 

2 minutes ago, Individualised said:

The person you were replying to used the word "neuroatypical" which is an dated way of saying "neurodivergent".

 

I used term neuroatypical because of I don't have a official diagnosis but alot of signs do point to that I am wired in pretty untypical way. For me atleast neuroatypical does seem to communicate well that some things are definitely different without making a claim of being actually valid for classification of a neurodivergent person.

 

15 minutes ago, Individualised said:

 Essentially what you would be doing is just recreating RetroArch. RetroArch even has a PrBoom core.

 

Fair point. But there issues with RetroArch's approach that could justify a Doom specific version of the same concept. The native framerate of RetroArch PrBoom is 60fps, basically breaking demo compatibility and generally being very inaccurate, Not to mention PrBoom being simply an ancient source port these days. As far I know, part of this comes from emulators being the main focus and all cores do technically run at native 60fps.

 

And another difference would be how much more intergrated the modules would be underlying engine instead of the engine being just a frontend for starting several different source ports. And in general I would like to move away from idea of all-in-one source port for now and focus more on modularity being cleaner and more flexible way to handle compatibility support in general.

[Individualised]

22 minutes ago, banjiepixel said:

Fair point. But there issues with RetroArch's approach that could justify a Doom specific version of the same concept. The native framerate of RetroArch PrBoom is 60fps, basically breaking demo compatibility and generally being very inaccurate, Not to mention PrBoom being simply an ancient source port these days. As far I know, part of this comes from emulators being the main focus and all cores do technically run at native 60fps.

 

And another difference would be how much more intergrated the modules would be underlying engine instead of the engine being just a frontend for starting several different source ports. And in general I would like to move away from idea of all-in-one source port for now and focus more on modularity being cleaner and more flexible way to handle compatibility support in general.

I think you're misunderstanding me. It has nothing to do with how RetroArch currently supports Doom or even RetroArch itself. My point was the only real way to achieve what you're asking would essentially just involve recreating RetroArch, except the cores would be Doom source ports instead of mostly emulators. You may as well just make libretro cores for GZDoom, DSDA-Doom, Crispy Doom, Chocolate Doom etc, and then make a custom frontend that's more suited for Doom players than those who want to play emulated games. Your other proposals such as "integrating engine modules" are also vague and without explaining in detail I can't really understand what you mean.

 

Something I want to do in the future is an isolated version of the Doom renderer that's completely detached from the Doom game logic and could be used as a library for other projects. Maybe you want something like that, except with other parts of the Doom source code as their own isolated modules that can be swapped in and out?

Edited October 20, 2023 by Individualised

[banjiepixel]

29 minutes ago, Individualised said:

Something I want to do in the future is an isolated version of the Doom renderer that's completely detached from the Doom game logic and could be used as a library for other projects. Maybe you want something like that, except with other parts of the Doom source code as their own isolated modules that can be swapped in and out?

 

That does sound rather close to what I have in mind. Even if it would be just something very simple that could be used to playback demos in traditionally non-demo compatible source ports. Maybe some kind of a vanilla demo emulator instead of a something that directly attempts to port demo compatible mode into more advanced source port. The whole nesting doll situation of doom port within a doom port would be bit silly of course.

 

Starting point should be rather simple, isolated vanilla demo player that could rather easily be integraded into any source port or pretty much any type of software without too much work. That could be then expanded into actual gameplay modes with specific compatibility simulation and renderer features wrapped into isolated module. And things like game logic and rendering could be given ability of existing as separate modules but it's probably easier to require custom module that could combine desired game logic and rendering features.

 

Modules would either replace underlying engine functionality, or probably more practically just run completely on top of the host engine, emulated or as engine within a engine.

 

But again, my base idea is that a vanilla demo player could be potentially made into something like a video player codec and this then could be easily integraded into GZDoom.

[Edward850]

8 hours ago, dpJudas said:

But it didn't do exactly what they needed.

But it did. So... yeah. You seem to be trying to force a standard and expectation for the function that simply didn't exist, and I don't know why or how many times I need to repeat that you are.

Edited October 20, 2023 by Edward850

[Andromeda]

5 hours ago, Gez said:

PrBoom and its offshoots were not around back when Doom v1.9 was brand new and people were updating from 1.666.

Of course, I was replying to the claim that there's no modern source ports that are able to play back 1.666 demos.

Edited October 20, 2023 by Andromeda

[andrewj]

7 hours ago, banjiepixel said:

my base idea is that a vanilla demo player could be potentially made into something like a video player codec and this then could be easily integraded into GZDoom.

Future thread title: "Sooo, why doesnt GZDoom support recording vanilla demos?"

 

Personally I think that for sourceports which have diverged greatly from the original code, demo playback is simply not worth the effort, even if technically possible using a stripped-down copy of the vanilla engine.

Edited October 21, 2023 by andrewj

[banjiepixel]

23 minutes ago, andrewj said:

Future thread title: "Sooo, why doesnt GZDoom support recording vanilla demos?"

 

Personally I think that for sourceports which have diverged greatly from the original code, demo playback is simply not worth the effort, even if technically possible using a stripped-down copy of the vanilla engine.

 

And that is exactly why GZDoom support should be side effect of there being API that would allow a simple vanilla Doom demo player plugin added to almost any piece of software. GZDoom does already support emulated music format playback so why not emulated demo format playback? The emulated music playback uses already existing libraries and emulated demo playbabk would technically only require the library that can do that to be created. Obviously emulating demo compatibility is much more complicated than emulating music format, they are in essence the same process and adding support to them to any software as long as the library already exists is basically identical.

 

And the great thing about emulated vanilla demo playback library would be that it is literally only few steps away from emulated vanilla gameplay and demo recording. In the end we would have this whole new layer of Doom source port development being based on this library that is extremely portable. Ideally the library could make things like playing Doom on video player sofware not only possible but also easy to implement. But for practical reasons, let's focus on just the demo playback for now.

[thelamp]

This thread has been a long and circular ride. It may not be my place to comment on anything here as I'm not a programmer so my understanding of the technical side of things is limited. However I do understand that it takes time and effort to create anything. I also understand that demo compatibility was never within the scope of GZ Doom's development. Based on what I've read in this thread, for the GZ Doom team to divert time and effort into demo compat features would be to waste that time and effort. There are already several great options for anyone looking for demo compat.

 

The bottom line for me is that I'd rather see GZ Doom's team use its time and effort to expand/refine its features rather than needlessly toil trying compete with ports that already support demo compat, and already do it very well.

[Kinsie]

9 hours ago, banjiepixel said:

 

That does sound rather close to what I have in mind. Even if it would be just something very simple that could be used to playback demos in traditionally non-demo compatible source ports. Maybe some kind of a vanilla demo emulator instead of a something that directly attempts to port demo compatible mode into more advanced source port. The whole nesting doll situation of doom port within a doom port would be bit silly of course.

 

Starting point should be rather simple, isolated vanilla demo player that could rather easily be integraded into any source port or pretty much any type of software without too much work. That could be then expanded into actual gameplay modes with specific compatibility simulation and renderer features wrapped into isolated module. And things like game logic and rendering could be given ability of existing as separate modules but it's probably easier to require custom module that could combine desired game logic and rendering features.

 

Modules would either replace underlying engine functionality, or probably more practically just run completely on top of the host engine, emulated or as engine within a engine.

 

But again, my base idea is that a vanilla demo player could be potentially made into something like a video player codec and this then could be easily integraded into GZDoom.

If it's all so "easy" and "simple" then surely you can lead the charge on it and show us all up for the lazy sods we all are.

[Individualised]

10 hours ago, banjiepixel said:

my base idea is that a vanilla demo player could be potentially made into something like a video player codec and this then could be easily integraded into GZDoom.

...but why? That would be like a .MOD tracker that could also play, but not manipulate in any fashion, MIDI sequences. You would essentially be including a completely unrelated program inside a larger program that's there for no real reason. It's not the type of thing the GZDoom team would want to devote their time to I would guess.

Edited October 21, 2023 by Individualised

[banjiepixel]

2 minutes ago, Kinsie said:

If it's all so "easy" and "simple" then surely you can lead the charge on it and show us all up for the lazy sods we all are.

 

Currently I am trying to brainstorm my ideas with community which is taking the first steps making it a reality and it would be much easier if people would willing to actually discuss about it instead of trying instantly shoot it down. I need make the idea float around so I could eventually get actual programmer interested doing the coding for it. I am already doing alot to process the idea itself forward and refining it into something practical to write code for.

 

There is zero implication of anyone being lazy, it's just me hoping atleast some cooperation from the community to help anything currently not vanilla Doom demo compatible to gain easy access to having demo compatibility. I am simply asking for willingness to help me and take my idea seriously, even if it is just to humor me and my nonsense ideas.

 

16 minutes ago, Individualised said:

But why? That would be like a .MOD tracker that could also play, but not manipulate in any fashion, MIDI sequences.

 

Like I said, adding support for manipulating MIDI sequences would be easy at that point, it would be very arbitrary limitation to have only playback support. And of course if Doom source could be simply audio or video player plugin, it would open alot of doors for "It runs Doom" stuff. Also one potential logical extreme could be that the same core plugin api or library could be used in expanded form to make even the mighty GZDoom run in browser and other very unlikely and hard to port places. It would be mainly about Doom community helping to make doom demo playback more accessible in general.

 

Honestly I am surprised that people aren't interested about the idea considering how much the community still uses demo recording and playback in the modern day and demo compatibility is highly valued feature. But then again, it does also seem like there haven't been any attempts to make demo playback more user friendly experience, atleast as far I know.

[Individualised]

16 minutes ago, banjiepixel said:

Like I said, adding support for manipulating MIDI sequences would be easy at that point, it would be very arbitrary limitation to have only playback support.

No, it wouldn't.

[rfomin]

A more realistic approach would be to use the GZDoom infrastructure (3D Engine, sound and music, controls, menu system, etc) with a demo-compatible source port. Like Raze for Build Engine games.
But honestly, it might be easier to port some of GZDoom's features to demo-compatible ports, like what you're actually missing in DSDA-Doom, Crispy Doom, Woof, etc? So far I've only seen improved mouse controls for high refresh rate monitors, definitely an interesting feature.

[RjY]

11 hours ago, banjiepixel said:

But again, my base idea is that a vanilla demo player could be potentially made into something like a video player codec and this then could be easily integraded into GZDoom.

 

This sounds like VIDD (Version Independent Doom Demo system):

 

Quote

 

The VIDD system intends to do the following things relative to Doom ".lmp" demos:

• remove the syncing problems during playback associated with current and future Doom ports
• allow demos to be more self-sufficient packages for easier distribution and viewing
• support random access to any point in a demo during playback

VIDD employs a general keyframe system to record the absolute position and properties of all the objects in a Doom world every frame. Using this system allows perfect playback of the events that took place during the recording in an application-independent way. Because it is a general format with a supplied API, it is possible to incorporate demo playback into ports of Doom that have absolutely no code-level relation to the original Doom.

 

[...]

 

The VIDD recording system is designed only to convert .lmp demos to .vidd files. This means you must first record the demo in the traditional manner with doom or doom2 using the -record command line parameter. Once you have a working .lmp, you can then convert that to a VIDD.

 

 

Unfortunately it was never developed beyond an experimental feature in the eventually-abandoned PrBoom v2.3 branch, but it shows something like your idea is not impossible.

[Kinsie]

50 minutes ago, banjiepixel said:

I need make the idea float around so I could eventually get actual programmer interested doing the coding for it.

If it's so easy and obvious, then program it yourself and submit a pull request. I have very little time or energy for Ideas Guys, and the actual port devs here probably have even less.

Edited October 21, 2023 by Kinsie

[Graf Zahl]

1 hour ago, rfomin said:

A more realistic approach would be to use the GZDoom infrastructure (3D Engine, sound and music, controls, menu system, etc) with a demo-compatible source port. Like Raze for Build Engine games.
But honestly, it might be easier to port some of GZDoom's features to demo-compatible ports, like what you're actually missing in DSDA-Doom, Crispy Doom, Woof, etc? So far I've only seen improved mouse controls for high refresh rate monitors, definitely an interesting feature.

 

As I have done this when migrating Raze to GZDoom's backend code, yes it is definitely easier when you can adapt the code on both sides than having to work within some rigid framework you are allowed to change, it is still a lot of hard work bringing two such code bases together and work. Conceptually it is relatively straightforward to take, say, DSDA's game code and merge it with GZDoom's backend, but you have to be able to adapt the interface on both sides or you are in for a lot of trouble and added work writing interface translators etc. Most importantly you have to define the proper boundary you want to draw between game and backend. Put it too high and too much data may not be in a usable form anymore, put it too low and you end up implementing far too much on the game side.

 

Another issue here is also that sometimes you have to make extensive alterations on the game side. As one example, most classic ports have the menu sit directly on the render code, not passing resource IDs for the textures but the physically loaded texture data - tailor made for the software renderer. Obviously you do not want to do that when working with a generic backend to benefit from the advancements it brings, so you'll be in for a lot of code rewrites on the game side as well to make it work with the desired back end.

 

The comparison with RetroArch that was made is really not appropriate because it sits far too low. It's ultimately more an operating system abstraction than a game engine.

 

 

 

[banjiepixel]

2 hours ago, RjY said:

This sounds like VIDD (Version Independent Doom Demo system)

 

Does sound like very similar idea, just slightly different approach that I had in mind. And I did realize that some like demo video player would probably require that demo files would include data defining the needed IWAD and potential needed PWADs to be loaded along with them, so mainly a enhanced demo file format ccould be a decent solution. One big goal would be to playback Doom demos outside of traditional source port enviroment and user interface so traditional demos needing to converted into new enhanced demo file format would be less of a issue, same could be said about GZDoom as it is so far removed from anything more directly demo compatible.

 

1 hour ago, Kinsie said:

I have very little time or energy for Ideas Guys, and the actual port devs here probably have even less.

 

Nobody is forcing you to engage with me, you are completely free to ignore me completely. But it should be clear that I am going beyond of just being someone with an idea and expecting port devs just make it a reality for me. I am going to need eventually somneone to do atleast most of coding for it as my brains are wired for design and user interfaces, it is better that designers do not do the coding and coders do not do the design, but that is not problem for today as I am currently in just the brainstorming, research and planning phase.

 

There literally no need for any programming yet and it is pretty much impossible to submit a pull request as my initiative isn't atleast currently specific to any existing source port. And it isn't probably a good idea to burden port developers directly and instead it's better to seek more general community help and advice, like I am doing right now in this thread where discussion is about a issue that my ideas could likely solve. And I am trying to discuss about the programming theory that would present roadblocks to my hypothetical solution, that is called doing research and seeking advice to find a shape for my ideas that would be practical to execute and would benefit the community.

 

I really don't like this "code first then ask questions" attitude. I know that devs generally might not have time to advice non-programmer like me about the practical coding roadblocks related to my ideas but how about atleast some positivity in the feedback if you're taking the time to reply. I do feel like this sign of a discussion culture that isn't very healthy.

Edited October 21, 2023 by banjiepixel

[Graf Zahl]

11 minutes ago, banjiepixel said:

I really don't like this "code first then ask questions" attitude. I know that devs generally might not have time to advice non-programmer like me about the practical coding roadblocks related to my ideas but how about atleast some positivity in the feedback if you're taking the time to reply. I do feel like this sign of a discussion culture that isn't very healthy.

 

The problem here is, you admit yourself you are a non-programmer, yet you are trying to present a concept where every single programmer that responded told you it's not that easy. You can rest assured that all these people know enough about these things to decide that it's not nearly as easy as you make it out to be.

 

[Redneckerz]

3 hours ago, banjiepixel said:

 

Currently I am trying to brainstorm my ideas with community which is taking the first steps making it a reality and it would be much easier if people would willing to actually discuss about it instead of trying instantly shoot it down. I need make the idea float around so I could eventually get actual programmer interested doing the coding for it. I am already doing alot to process the idea itself forward and refining it into something practical to write code for.

You have had a lot of people - seasoned programmers, mind you, like actual people who ship products in a commercial sense and people who actively develop or contribute to a source port - explain you in various ways that yes, the idea is interesting but no, it isn't practical. All you answer to that is but it could be done! Which is very circular. It's like you are forcing your idea through as if we (and i hope i can say we here) are obliged to take note and then do something with it.

 

You are literally stating here: ''I need to make the idea float around so i could eventually get an actual programmer interested doing the coding for it.'' My man, this is textbook Ideas Guy territory. Presenting an idea that is hilariously niche (We have to look at what seems to be an inactive port and holy shit VIDD to approach something similar) and probably said port and VIDD combined would be your idea. Considering the former is inactive and the latter got abandoned, you should have a pretty good picture of where your idea would arrive for any seasoned programmer.

 

There is a reason why @Kinsie wrote the way they wrote. You make it sound like it is an easy thing to pull when everyone with some sense of realism tells you it isn't. We aren't shooting down your idea, we are saying that you are an Ideas Guy and you shouldn't be.

 

32 minutes ago, banjiepixel said:

I really don't like this "code first then ask questions" attitude. I know that devs generally might not have time to advice non-programmer like me about the practical coding roadblocks related to my ideas but how about atleast some positivity in the feedback if you're taking the time to reply. I do feel like this sign of a discussion culture that isn't very healthy.

What can you expect? You consistently act like you are an Ideas Fella and you just need someone to code up your brilliant idea that nobody else seemingly is thinking about. This is juxtaposed against the opinions and views of many actual coders and programmers who are telling you otherwise. Yet you persist into spreading your idea around. In doing so, you come across as elitist.

 

As for the bolded: You really ought to look at yourself if you feel this way. Because you are clearly removing a very important part of the equation here - Yourself. You know why people increasingly get more hostile to you? It's because you aren't listening. You seem to only like to hear your own thoughts.

[banjiepixel]

3 hours ago, Graf Zahl said:

 

The problem here is, you admit yourself you are a non-programmer, yet you are trying to present a concept where every single programmer that responded told you it's not that easy. You can rest assured that all these people know enough about these things to decide that it's not nearly as easy as you make it out to be.

 

 

I do feel like the issue is that it's the current ecosystem that does make it not be that easy so I have started to move it away from that ecosystem and to the direction of something more independent that could be then brought into the excosystem once there is clean packaging and usable API for it.

 

How often the GZDoom's music format libraries, especially those responsible of things like vgm chiptune music formats are updated and how often they actually need to be updated? I would assume that very rarely if these use some kind of API solution. So currently my concept takes alot inspiration from this and would seem to be able to dodge alot of issues that devs have noted there being.

 

I am hoping to hear about solutions to the issues in my concept and pointers to the direction that would make my theoretical solution more practical. Some people done this and I am thankful for that, but you for example seem to take it as personal insult that I am trying despite maybe lacking some critical information about coding and software development. I might make some careless and uninformed claims about some things being easier than they probably actually are, but that is generally how I discuss and learn, I present my case for my current understanding about the topic and expect the other side to present a better case for the things that I am wrong about. Me presenting my case does seem to be often taken as attempt to argue or debate when in reality I am just trying to gain more data that I could use analytically to reach the right conclusion.

 

2 hours ago, Redneckerz said:

You are literally stating here: ''I need to make the idea float around so i could eventually get an actual programmer interested doing the coding for it.'' My man, this is textbook Ideas Guy territory.

 

Except it goes far beyond just ideas. While i am floating the idea around, my brains are so hard at work crunching all kinds of numbers related my idea that people seem to have trouble keeping up with how much it has already evolved with actusl programmer concerns having been pretty useful, despite plenty of negativity.

 

The thing about Ideas Guys is that they're out of touch because they lack in the practical analytical skills. That isn't a issue for me and it is literally just specific bits of data missing that is leading me into potential wrong conclusions. And my questions do usually target pretty well the places where I suspect there being important missing data so I can easily interpolate the rest to reach the correct conclusion, you know if dev people would bother to actually answer most of my questions.

 

I could be called more of a theory or analysis guy, on the surface it could look alot like a ideas guy, but actually can bring something deeper and practical to the table. You know, if the discussion wasn't mostly just shallow bickering. It does amaze me how much my regular, generally too polite behaviour can trigger some people that I do assume to have mostly more typical neurological state.

 

2 hours ago, Redneckerz said:

This is juxtaposed against the opinions and views of many actual coders and programmers who are telling you otherwise. Yet you persist into spreading your idea around. In doing so, you come across as elitist.

 

It is kinda hard to be elitist when I am constantly politely asking clarifying questions from the coders and programmers and get no answers because apparently it is arrogant to ask and I am expected to just take their word at face value without being allowed to reach the same conclusion on my own with just couple of extra pieces of information. 

 

And as a part of my natural analytical process, I must consider always a possiblity that there are gaps in the any coders knowledge, no matter how experienced and professional they are as a developer. At no point I am putting myself above them, only thing I do is attempt to rule out their own personal blind spots from the 

equation, after all we are just humans. And it is not like people outside of neurotypicality or specific community in general ever come up many brilliant ideas that are possible only thinking outside the box.

 

To be brutally honest, my alleged "elitism" does look alot like tons projection happening, people getting triggered because of my untypical behaviour and approach to things. It is almost funny how untypical lack of ego seems to look like there being too much of ego to a more typically egocentric person.

Edited October 21, 2023 by banjiepixel

[Redneckerz]

Oh you got answers, they just aren't fitting your thought process.

 

For real, make your own thread.

[Jayextee]

1 hour ago, banjiepixel said:

I could be called more of a theory or analysis guy, on the surface it could look alot like a ideas guy, but actually can bring something deeper and practical to the table.

No. Until you start to put your "theories" and/or "analysis" into any kind of actual form, there's literally no difference between the two.

"This could be done because RetroArch did it" smacks of blind ignorance; RetroArch and its many cores are the result of literal decades of work by many, many developers over the years and refactoring many years (again, in a whole 'nother direction) of work on sourceports to behave in the same 'moduled' way would be a waste of time and effort to practically no avail; users are likely going to find the module/core that's "best" for them (and, dollars to donuts; pounds to pound cakes, it'll likely be GZDoom after all) and stick with it. Because DOOM is DOOM is DOOM, and to a lot of people that's GZDoom -- there's no equivalency between, say, switching from Neo Geo ROMs to SNES ROMs to something else like in RetroArch.

Next to nobody wants nor needs your idea, there are so very few use-cases for it. So for the effort you're being told; repeatedly; that it will take to get such a thing in motion, there simply wouldn't be the payoff to justify it.