banjiepixel

True, but alot of people also just don't want deal with all that and rather just pay to remove the ads, especially since alot of YouTube use these days does happen also on devices without an option to install adblocker. And it is pretty much inevitable that amount of people accessing YouTube with web browser is going to shrink as time goes on. There is nothing wrong with YouTube taking the direction of becoming subscription service first and free service to be a secondary priority, especially since no one else has the infrastructure to do what YouTube does at the same scale. And more focus on being a paid subscription service means that advertisers will have less power to decide what is allowed on YouTube.

I have Premium mainly for watching Youtube from the Android TV app without ads. It has been funny see how much people are willing to do to avoid ads or paying premium. I watch way more Youtube than I would watch Disney+, Netflix or any other similar service so Youtube Premium is definitely worth the price for me. The amount of video that gets uploaded to Youtube every hour is massive and there are no storage limitations, so it easy to see why they want to move Youtube more to the direction of a being mainly a subscription service. The free version Youtube needs to have many ads or have many limitations, and generally even excessive amount of ads is better than limitations. Situation is messy, but the best way to stop Youtube becoming even worse is to either disable adblocker or go Premium.

Would it be possible and practically viable to integrate DOSBox into a Doom source port and basically have the source port user interface work as a DOSBox frontend to run the original DOS version within the source port program? Has there been any previous attempts at doing something similar in the past, with Doom or some other game?

I was really surprised how it doesn't really require very beefy hardware. I use Lakka OS on old office pc from 2009 with low profile GPU from 2010 and Flycast core can run almost any Dreamcast and related Arcade game just fine. Usually if some game doesn't work, it seem to be more of an emulation issue as Flycast isn't very accuracy focused emulator. My Lakka OS setup has some minor issues with Flycast, mainly the core doesn't close itself properly (nothing a quick RetroArch reload can't fix) and some games do have some graphical glitches that I assume to be caused of the ancient GPU that my machine has, but these are specific to my setup. It's kinda funny how Dreamcast works well on this hardware but Saturn doesn't. Also to me atleast, Dreamcast is the point where filesizes of games start to get too large, especially for the 120 gig SSD that my emulation machine has. My Dreamcast games are currently on external drive because of this. Flycast does require a bios files but outside of that, I feel like the experience isn't too far from using Dolphin to run Gamecube games. I have not tried other Dreamcast emulators but DC emulation seems to be in very good state, to me it feels like N64 emulation still has more issues these days, atleast what comes to emulators that have RetroArch core versions.

I can emulate Dreamcast version of Quake 3 Arena on my Dell Optiplex 380 (Core 2 Duo, Radeon HD5450) that was released in 2009. Granted, it is not very accurate emulator but it is still more advanced hardware than old pc being able to run Doom. And based on very quick testing, Doom 2 and Quake seem to work just fine. So there should generally no issues on actual modern hardware, and keep in mind this was while the image was being rescaled to 1080p similar manner as Chocolate Doom does it. And personally 320x200 is all the rendering resolution I need for these games. I mean it would be resource hog only when DOSBox portion itself would be running. And why are we so worried about it taking some extra resources? I don't doubt the accuracy of Chocolate Doom, it is more of a personal preference, I like to use the untouched original code. And I just happen like emulation, I play mostly retro console games these days and those already use emulation.

Not much I guess, especially if the DOSBox user experience would be more like using a source port. Both being together would be a neat package and OOSBox could be used to play other games too, not just Doom. And if it would be a very easy feature to add, what source port wouldn't want to have have built in DOSBox? It seems pretty natural thing to have in my opinion. And I do trust the DOSBox emulated Doom to have potentially less bugs/differences than native port like Chocolate Doom. But mostly it is just the extra step towards purism.

I am pretty big emulation enthusiast, especially on dedicated hardware instead of just running emulator on my everyday pc. My first dedicated hardware for emulation was Raspberry Pi 3 with RetroPie that was able to handle PS1 and pretty much anything lighter. Couple years ago I upgraded to old Dell Optiplex so I was able to also play N64 and Dreamcast. I am pretty heavily focused on arcade emulation because I play mostly arcade ports on consoles anyway. I do have a collection of older consoles but trying to hook them up to modern tv just isn't worth the time or money for me. It is also nice that one device can play some many different consoles and have so many games without taking extra space. There is also the huge selection of controllers that I can use, including those that need an adapter.

Complex Doom

Basically that, running DOSBox on top of Chocolate/Crispy session. Of course it would be probably easiest to just remove whole menu system of the source port and build new system that would be free from limitations of actual Doom engine. Loading the actual Doom engine is pretty fast and the I think there should be no problem with the menu system being more of a separate overlay. And maybe this overlay menu system could be then used to also launch DOSBox sessions within it, just like it could already run a source port within the overlay. DOSBox would just take over things so overlay's menus would be disabled while DOSBox is running so there would be no confict with menus inside games running in DOSBox. It would be atleast an interface to use with DOSBox that would work great with a controller. I am not actually sure about the actual controller support of DOSBox but simply reusing existing controller support of source port does atleast sound easier in many ways. It wouldn't even need to be that complicated for my own personal need, just translating controller inputs to keyboard inputs for DOSBox to read. And I know, probably many easier routes, but in general this was supposed to be more of a thought exercise.

Rebranding is definitely a thing, but in terms of actual code, where does use of Quake Engine end and use of GoldSrc start? How many of the Quake bits need to be replaced before it is actually a new separate engine. Otherwise we are talking only about modified versions of same engine, just with different branding.

Slightly offtopic but what makes GoldSrc (the Half-Life 1 engine) to be no longer the Quake Engine? But like people have said Doom 64 is just idTech1 with modifications, like Hexen is idTech1 with modifications. Doom 64 just added more advanced graphical features to the mix. And if I am not mistaken, PSXDoom is also idTech1 and does some advanced things too. Both the base Doom code and modified forms of it are still idTech1.

In my opinion, we barely even got on topic, but can't blame people for not wanting to waste their time analyzing and hypothesising very niche concept. Atleast this thread has increased my motivation to learn coding and has helped me to form more concrete plan for it, and that was kinda the real point all along. And it is very ironic that thread related to DOSBox would turn into discussion about Windows. Personally as the OP of this thread, it doesn't really bother me that much and I would allow it. It is just taking over because there isn't that much on topic to talk about, unless people want to actually talk about my niche concept and not about me and my personal projects.

You'd be surprised how far this is actually from the truth, I am just constantly educating myself about so many things, it is just that for things less relevant to me personally, I have to go more by the general vibe I see. I should had made it clear that is was meant to be more of an option, didn't expect that people would turn it into drama.

I personally feel like it shouldn't really matter. My main purpose was to only ask about specific concept, the DOSBox integration, and rest has been just to give context. As we are talking about only private projects here so far, it seems bit irrelevant what I will be able to actually achieve. And I am always tinkering with something and contantly jumping between projects. It's less indecisiveness and more of a issue with attention span. I need to have other projects to stimulate my brain while I take a break from previous one that I worked on. I should probably experiment first with converting my DeHackEd mods into actual engine modifications. It would be probably closest to my current knowledge and my general Doom related interests. And adding the option to turn those modifications on or off could be pretty nice step towards understanding how things work. I also would assume that attempting limit removal would be good idea for learning. Despite this thread not really going as I planned, my desire to know how to modify ChocoDoom has really grown. The inspiration for this thread was based on being something that I could maybe do myself. Despite my intention being generally to just give people free inspiration, this time I wanted to seek inspiration for myself to create something. Perhaps it could be said to being progress from some of my previous discussions. I would say that Windows 11 does seem to take the operation system into a direction that is more anti-consumer, atleast based on alot things they have experimented with and what their future plans seem to be. To my knowledge the Win11 adoption rate is also lagging behind what they were with Win10 and clearly the official system requirements caused alot of that. And updates do rather often seem to break things. To be honest, I have not keeping up with most of that stuff. But I see no reason to trust the direction Windows seems to be heading.

I know that it is the most realistic place to start. To be specific, have the GUI be separate frontend that could be used basically with any source port. Only then start to actually think about combining the GUI with the source port, to get it to work like any other source port specific launcher, like the one that GZDoom has, with just my own twist. And work from there to trying to get them more seamlessly work together. If I feel like it, I might try coding better launcher for Eternity at some point. Just I like have said before, maybe it is the language I use. Alot of things I am speaking about are part of a very loose long term plan that might at some point go to completely different direction. I will start from more basic experimention and goals and see first where that goes, one step at the time. One idea I could also explore is turning Chocolate Doom into dueling focused multiplayer source port. And splitscreen stuff would be always close to my heart. There are plenty of places where my experimentation project could go. I am speculating about what could be possible on how it maybe could be done, but this is just pie in the sky until I know how to do basic development using Chocolate Doom as the base, and the very first step is to learn to modify it at the same level as I can mod ZDoom based ports. I do wonder if I could start "porting" simpler ZDoom mods to the Chocolate Doom engine.

I have considered this, creating extra GUI layer of outside of actual Doom source port portion would fix this, yes? Something that could be used to launch either the source port, or DOSBox, with latter having it's own submenus for actual launch options. Main thing I would just want is that they use same window and can transition as smoothly as possible. When is say "Doom source code", I mean Chocolate Doom source code, as it is probably the simplest form of modern Doom code. Also did you just assume my operating system? All kidding aside, I am actually thinking about using Linux as my development OS because it is probably easier to put together a coding setup there. I really don't get where the people get the "coding for DOS" part. The GUI part that would be used for launching DOSBox games would be external to actual DOSBox and would work more like more traditional 3rd party frontend made for DOSBox. Unless I am badly mistaken, I should need modify the parts that interact with the operating system, not things in the actual virtual machine. Ideally alot like how RetroArch DOSBox works to my knowledge, with just more GUI driven launching options because unlike RetroArch DOSBox, my frontend would be meant for launching only specific limited selection of games. I am not even talking adding option to load PWADs here and I think there is very little reason to even have that because you will have already the native Doom source port for that. One goal would be simply to switch between native Doom source port and DOSBox without breaking the immersion by needing to exit the program, so much like RetroArch, but with actually good source port and Doom style/based launcher GUI. It would be a non-DOS GUI for launching a DOSBox session, nothing more complicated atleast for now. But my dream would be to eventually add some ram/state based features, kinda like with some emulation based pc ports of games, for example how Street Fighter 30th Anniversary Collection added versus modes to the games despite the arcade versions lacking that feature. As far I know, they basically use the same method to allow online play and use rollback netcode, something obviously lacking from arcade game code from 90's. There are plenty of pc ports of old arcade games that add new features but emulate the original roms instead of being actual native ports. My knowledge might not be very deep but it is very broad.

Not solely, but it is the main metapurpose in this. And alot is based on just desire to do GUI design, with DOSBox being great target for that. I am also just have interest at getting familiar with Doom source code in general to know how it actually works outside of random basic information found in discussions in this forum.

Note that the developers needed to only give people ability to customize and developers themselves just made smaller improvements to the general design. Windows 10 had to generally backtrack alot because customization is less of a thing and the design of Metro was just so bad. And despite being a KDE/Plasma user, only issue I really have with Gnome Shell is that it tends to be bit heavy, especially for little bit older hardware. KDE/Plasma is more usable on older hardware while also being more modern than the lightweight options. Have a good design and actually commit to making changes so the whole package will function to it's full potential. It is always possible to make adjustments later. But with Microsoft lacking any solid vision, they are just very bad at designing operating systems. Just look all the bad decisions they have been making with Windows 11. First thing I will do won't be to bolt DOSBox into Doom source port, that would come only after I know better what I am doing. And more I have thinking about, I have realized that maybe I don't need to actually use "real" DOSBox at all and could probably just replace it with the RetroArch core, it should generally have every I need already. So I should technically get away with building RetroArch core support to a source port. This would come also with the benefit of Playstation core being able to be added later, you know, for Playstation Doom. But in general, it's the menu stuff that is the main event, this thread is very much just me asking about possibility of DOSBox support being added later. And probably for the menu system, something like being able to change wads or games without exiting the source port would probably be more relevant. This would bet technically possible just with the DOSBox support. And I probably should start with maybe some kind of ZDoom-family port based mockup/prototype, make the basic menu design layout there so it could be then later converted to more basic source ports. I am also fine with PWADs having only generic map selection data while IWADs would have more specific information. But source port being able to "hotread" WADs would be mighty useful here. If I remember correctly, atleast Eternity has some WAD loading features when it is running and I suspect that Odamex has too. There is currently no real end goal. Just a plan to experiment with some very loose goals to give direction. I am giving myself alot of opportunities to change direction of my experimentation if needed and bigger point is just for me to create something, you know, not be just "Ideas Guy". And most of it is to have a excuse to learn. DOSBox integration is just an idea I would like to eventually explore. Wouldn't I need to actually plan to have public release to be eligible for nomination? Currently all this is just for my own personal use.

I am not rushing into anything, everything I am saying is to happen in long term, take even decades if needed. I am going split things into smaller manageable goals once I find solid direction to my plans. I want to have a big vision to chase for motivation, I can always change direction later if I want. And Chocolate Doom menu system experimentation was already one of my first targets in the plan. I could probably do alot of other neat stuff with just the menu skills.

There might be bit a confusion caused by there being different types of creative people. It would seem that more technical type creative people put alot of focus on solving problems in their creativity. I am however more of an artistic type of a creative person so I care more about creating something because I simply want that something to exist. It probably would be more accurate or atleast easier to think my goals as more of an art project. That is probably because my reasons are so highly personal and likely based on rather untypical way of thinking, so it simply just will not make any sense to others. And if I would be looking at project of someone else, I simply personally wouldn't even think about the question of why. It wouldn't really be my business and my natural reaction would be to just take the idea at face value. There seems have been alot of misunderstanding happening. I do apologize if what you said is how it has looked like. Based on alot of responses, it would seem like I have failed at presenting my concept using a language that would be understood. Many people seem to have misunderstood it as things like DOSBox based source port or adding source port features to DOSBox emulated Doom. And I am not disagreeing, I am simply questioning and presenting my understanding of issue to be corrected by someone who knows better so I could gain more understanding. The language I use do this is probably too "streamlined" so it is being taken as me not understanding depth and thinking that everything is simple. I am behaving in the way that is optimal for myself learning things, but atleast in some places it does clash with personalities and social behaviour of others, just like clearly has happened here. I am meaning of no offence by being so skeptical and needing extra information to convince me. There probably could be some better way to respond to try to gain that needed extra information, but I am still trying to find it.

It is not about unlearning, it is about many people just being slower to adapt and big part of that is usually more of a choice. You do seem the be thinking about much deeper integration that what I actually have in mind. Maybe I am not using the right terms and that is causing misunderstanding. Only way I need the Doom enviroment and the virtual machine to interact with eachother is at very surface level, so it would be simpler things to do, with probably the most complicated thing being just directing DOSBox video and sound output to the Doom window and feeding input data from Doom engine to DOSBox. I don't care about there being some jank and hacks if it is making things I want possible. Doom and DOSBox are meant to be very isolated, to the point DOSBox being able to be it's own separate executable. DOSBox side would literally use native Doom code only for the launching and basic display, audio and input purposes, interactions very similar to current interactions between DOSBox and operating system running it. What if it will work out poorly, so what? People are so concerned about the end result that they are missing how much the journey itself can actually matter. No matter how far I will end up with this, it will push me forward as a person in some way. As a software developer, your time is obviously too valueable for anything this unpractical from multiple viewpoints, so you wouldn't attempt it even if you would like the idea on paper. But I do have plenty of time to waste to attempting this and that time is probably even better used to attempting than to things I would use it otherwise.

And this information would benefit you and other people how exactly? Can't we all just assume that it is relevant to my interests and move on to the actual discussion? I wouldn't need do any MS-DOS programming. DOS related functionality I need to reach my main goals are to use existing DOSBox features. I would need to do relatively minor modification to DOSBox and most of the integration and modifications to make these two programs to work more closely together would be to source port. People seem to be struggling with understanding the role of DOSBox here when it is pretty simple, just something extra included for playing DOS games. And the point is to gain that understanding of C with something actually challenging to keep myself motivated. Not asking for, but yes, that is basically the concept I have in mind. No, bad design with UI is what got us Metro. And another issue with Microsoft's operating system UI design has been half measures, you must not be so scared of forcing people to learn new things that you handicap good things in the new design. Gnome Shell also pushed the envelope with UI, better design and better results than Metro. And Metro wasn't even that bad to actually use, it was just extremely messy.

Not just Doom style graphics but literal Doom graphics. And yes, I want to make things harder for myself on purpose by using actual Doom source code as much as possible in a launcher.

It is just the the ability to run DOS programs that I want, not the DOS command line user interface. I have only minor experience from using DOSBox but from what I gather, simplest form what I want is that a source port could be used to launch specific .conf files with DOSBox. First step wouldn't even actually need to be DOSBox but simply turning a source port into something that would have ability to launch a external program. We are talking purely a potential personal project here, so "why" should be irrelevant as the project would fill purely my own personal need. Generally just something for me to do, exist as creative outlet and fitting excuse to find motivation to learn something new, To me, people asking "why" seems mainly like people sticking their noses in and acting like I would need their permission. And people being so focused "why" seem like they don't see value in just general experimentation without it being attempt to solve actual problem. Another issue seems to be the general lack of ambition from source port developers, many traditional things are deemed "good enough" and people do not push the envelope, atleast what comes user interfaces. It might not be seen as big priority but source ports do lag way behind official releases what comes to user interfaces. We are still relying so heavily on command line parameters and 3rd party launchers because they are "good enough". And in same way people have been suggesting to me that current solutions to what I want are "good enough" when I want to create something that goes beyond that. i have no problem using DOS or command line stuff and I have even made my own .bat frontend for launching Doom stuff. I also love using terminal to launch Doom on Linux because it reminds me of my DOS days. But on Windows, command line stuff are just messy, less integrated to the overall user experience. There is no skill or effort issue, this is about making the packaging attractive to myself.

I really don't understand why so many people are asking "why?". Seem highly irrelevant and unproductive to me. What if it is just a thing I want? I am really starting to lose my motivation from constantly being asked to justify something I want to make for my personal enjoyment. People asking "what?" are fine, it is a strange concept and I am really struggling with this type of more technical language.