How can I work on my own Source Port? (not a joke)

[AtticTelephone]

I kinda want to experiment with source ports, and I'm using online C++ tutorials to teach myself. I heard about this port called "Fusion", and I think it could work as a sort of base for a prototype. I'm thinking of adding in crouching, just for fun, and when I learn more, I'll add in a mouse, like in ZDoom ports. Are there any tips out there? I also wonder how I'm supposed to find the source code, but I'll probably figure that out later.

[DSC]

I hope you don't get bothered by me not actually helping you out on your task, but I can't resist stopping to just say I love the fact you put "not a joke" in the title because of that one similar thread from a few days ago.

[AtticTelephone]

11 minutes ago, DSC said:

I hope you don't get bothered by me not actually helping you out on your task, but I can't resist stopping to just say I love the fact you put "not a joke" in the title because of that one similar thread from a few days ago.

Nah man, it's fine. I remember that thread, it was hilarious, especially when Mordeth had to come in and close the thread.

 

@DSC Yo I found the thread. 

 

Edited September 7, 2020 by AtticTelephone

[fabian]

You should probably start working on a code base that already has support for the tools that you are going to use, e.g. Visual Studio project files or GNU Autotools. Also, if the first thing you are going to do is port the code from DOS to your platform you'll have some hard times ahead. Better start with something that is already SDL based, e.g Chocolate Doom or Woof!

[AtticTelephone]

10 minutes ago, fabian said:

You should probably start working on a code base that already has support for the tools that you are going to use, e.g. Visual Studio project files or GNU Autotools. Also, if the first thing you are going to do is port the code from DOS to your platform you'll have some hard times ahead. Better start with something that is already SDL based, e.g Chocolate Doom or Woof!

Ah, interesting. Well, I use Code Blocks, and I think maybe I could use WinMBF. However, I still might experiment with trying to get Fusion to run on Windows.

 

Update: Well, obviously Fusion can't run on my Windows 10 64 bit computer, so I guess I'm going to figure out how to make it work on Windows. I found the Source Code, and it's a bunch of "C" and "H" files, this is gonna be complicated.

Edited September 7, 2020 by AtticTelephone

[AtticTelephone]

Alright, I'm looking at the files. At the top is the stuff with the application and an "O" file, the rest are header files and C source files. There's ALLEGRO, a header file with no C source file with it, and there's this one file called "COPYING". Man, there's so many files, where to begin.

[Redneckerz]

35 minutes ago, AtticTelephone said:

Man, there's so many files, where to begin.

As long as you don't ''Ok'' me, then there is this post to help you out:

 

[AtticTelephone]

ok?

 

Nah, just kidding. I'm learning C and stuff, and I know a bit about messing around in DeHackEd, so I think I'll be able to figure out how to make an MBF based port run on a Windows 64 bit computer.

[Graf Zahl]

Don't underestimate the 64 bit thing. If you start out with an old code base you may run into problems with pointer truncation - it was quite common to assume that a pointer and an int had the same size. I don't know how affected Doom's source is, but Heretic and Raven definitely did it, but the worst offender by far is the original Build code which frequently did casts from ints to pointers and back.

 

So better pick a target that comes with a bit of the things you want to accomplish and already runs on your platform of choice. For a novice programmer, trying to take some random old code base and making it work on a totally different system can be an overwhelming task. You'd really be better off if you started from something that already works and then try to make some changes. You first need to get a feeling of how the code operates before you can tackle something like a backend change. That's something even seasoned programmers can struggle with.

 

 

[Gez]

14 hours ago, AtticTelephone said:

I found the Source Code, and it's a bunch of "C" and "H" files, this is gonna be complicated. 

So you're a complete beginner, it's gonna be complicated.

 

Getting an old project to compile is IMO the most annoying, tedious, boring, discouraging part of programming. When you start your tutorial programs are generally just one file, maybe two so that you have separate header and code files. And then you jump to an actual project with dozens if not hundreds of files, and they have to be compiled in a certain order, and you have to handle library requirements, and these libraries don't use the same calling conventions so you have to rebuild them, and and and oh fuck it

 

So if you use CodeBlocks, I suggest starting by looking for a source port out there which has a CodeBlocks project (or, failing that, CMake files so that the CodeBlocks project can be automatically generated by CMake so you don't have to worry about it too much) so that you have something that compiles out of the box with minimal effort on your part, and then you can go in the fun part of programming, which is actually tinkering with code and looking at how your changes run.

[AtticTelephone]

@Gez @Graf Zahl Thanks, I guess I'll try modifying Chocolate and see if it works, and when I'm more experienced, I'll work on the Windows version of the Fusion port.

[Webern]

I'm also doing the same as @AtticTelephone , learning c/c++ from a Python background and trying to figure out how to do a source port. Thanks for the community feedback! It's have been really helpful!

[Gez]

30 minutes ago, AtticTelephone said:

 Thanks, I guess I'll try modifying Chocolate and see if it works, and when I'm more experienced, I'll work on the Windows version of the Fusion port.

Something you could do is to compare the Fusion code with the original Doom source code, to see what has been actually modified -- because the bulk of it will not be changed, or not meaningly changed (e.g. plugging in Allegro to replace DMX is not a very interesting change). Then you could port those same changes to Chocolate Doom and create Chocolate Fusion, which is a delicious name IMO.

[AtticTelephone]

Just now, Gez said:

Something you could do is to compare the Fusion code with the original Doom source code, to see what has been actually modified -- because the bulk of it will not be changed, or not meaningly changed (e.g. plugging in Allegro to replace DMX is not a very interesting change). Then you could port those same changes to Chocolate Doom and create Chocolate Fusion, which is a delicious name IMO.

Original Doom source code? Like... Linux Doom or something?

[Gez]

Yeah the Doom source code release.

https://github.com/id-Software/DOOM

[fabian]

4 minutes ago, Gez said:

Something you could do is to compare the Fusion code with the original Doom source code, to see what has been actually modified -- because the bulk of it will not be changed, or not meaningly changed 

 

Boom has already changed pretty much every line of code.

[drfrag]

Chocolate Doom should compile with Code::Blocks and TDM-GCC 5.1 (i made a PR to fix it). You create the projects with CMake (GUI).

[Webern]

5 hours ago, Gez said:

Getting an old project to compile is IMO the most annoying, tedious, boring, discouraging part of programming. When you start your tutorial programs are generally just one file, maybe two so that you have separate header and code files. And then you jump to an actual project with dozens if not hundreds of files, and they have to be compiled in a certain order, and you have to handle library requirements, and these libraries don't use the same calling conventions so you have to rebuild them, and and and oh fuck it

 

This makes me remember that livestream...

 

 

[AtticTelephone]

Ok, I do not know how to code the Fusion source code to work on 64 bit computers, I heard about this thing called WinMBF, I think I could copy some files from there and just... compile it all together and see if it works or not.

[fabian]

5 hours ago, AtticTelephone said:

Ok, I do not know how to code the Fusion source code to work on 64 bit computers, I heard about this thing called WinMBF, I think I could copy some files from there and just... compile it all together and see if it works or not.

 

Yeah, because that's how coding works, right? *sigh*

 

I have spent a couple of weeks this year to cleanly port WinMBF to 64-bit, the result is called Woof!. Maybe you should use that as your starting point and then add back the Fusion features that you are looking for.

[Gez]

6 hours ago, AtticTelephone said:

Ok, I do not know how to code the Fusion source code to work on 64 bit computers, I heard about this thing called WinMBF, I think I could copy some files from there and just... compile it all together and see if it works or not.

That won't work.

 

I'd say the first step is to get something that works to use as a base. I second fabian's suggestion of starting from Woof because that'll give you a base that's relatively close to your goal: since Fusion was derived from MBF, starting from a modern version of MBF that works in modern compiling environments will give you a lot less work to do.

 

The next step is comparing the MBF and Fusion source code. This is something that tools can largely do for you. E.g. programs like WinMerge can compare entire code hierarchies and tell you where there are differences, so if Fusion's code wasn't full of gratuitous changes that have no real semantic value but do get picked up by these programs (e.g. changing the formatting of comments, stuff like that) you'll get a clear view of where things were changed.

 

At this point, analyze the differences, get a feeling for how they work together. E.g. there's an enum that's lengthened here and a table that's increased there, are these two changes related? Just work a bit on understanding and following the logic of the program.

 

Once you've done that, you can port the changes. It's not dumping some files from Fusion to Woof (because you can be guaranteed it won't work), it's getting an intelligent view of how the content from Fusion differs from the content from MBF, and then applying this change to the content from Woof.

 

And then you can try compiling and deal with the mistakes you've most certainly made along the way. But the step where you first try to reconstruct in your mind how stuff works in MBF, how it was changed from MBF to Fusion, and how it was also changed from MBF to Woof, so that you can see what you need to do to adapt Fusion's changes to Woof? That stuff doesn't need to compile anything. And you can't skip it. You need to understand what you're doing. Merely copying files brings you zero understanding, so when it fails to work (and it will fail to work, I can guarantee it to you) you will not have any idea how to resolve the problem. Whereas if you understand the changes you make and why you made them, when you get error messages, you will know what the message is about, and you will be able to guess the mistake you made, and fix it.

[AtticTelephone]

God, this is complicated, maybe I should just not try and abandon coding until I'm done working on my megawad.

[Redneckerz]

1 hour ago, AtticTelephone said:

God, this is complicated,

Working with source code requires a level of math and programming skill.

 

Trying to tell a realistic tale here but not to belittle you, but from your posts, it is apparent to me that you have not reached that level yet.

1 hour ago, AtticTelephone said:

maybe I should just not try and abandon coding until I'm done working on my megawad.

That would be a wise decision.

[fraggle]

8 hours ago, AtticTelephone said:

God, this is complicated, maybe I should just not try and abandon coding until I'm done working on my megawad.

Hi @AtticTelephone! I just want to chime in here and give you some words of encouragement because I do believe you can learn to code. However, it's a skill that takes time to learn and develop. Think about how you would approach learning any other skill:

• If you were learning to play guitar, you'd start by learning how to play basic chords and scales rather than trying to play a whole song by your favourite artist.
• If you were learning to draw, you'd try drawing simple things first rather than rushing forward to immediately try to draw your masterpiece.
• If you were learning car maintenance, you'd learn how to do simple things like change the oil first, rather than starting with something complicated like how to replace the entire engine.

Coding is the same. You need to spend time experimenting with basic things first before you can do something complicated. However, you have the additional problem that because you're not a coder, it's also hard for you to judge what's simple and what's complicated! Here's a quick guide that might help:

• Simple things you can probably do:
  • Getting a modern source port to compile so that you can experiment and make changes to code. Find something already established - there are online guides for how to compile some of the popular source ports.
  • Changing in-game messages. It's easy to find the message that says "picked up a clip" and change it to say something else.
  • Adding a new linedef type (mostly copy and paste)
  • Basic changes to monster behavior or weapon behavior. In a lot of cases it's pretty simple to find some existing code and tweak some numbers - to make something do double damage for example. This doesn't require a lot of deep understanding of how the code works, if you're just changing a number.
• Medium complexity things that require more programming knowledge:
  • Creating a whole new weapon or monster
  • Adding new AI or in-game effects - something that isn't just a variation on "door" or "elevator" for example
• Hard things that will not be feasible until you have a lot of experience:
  • Visual effects or changing the renderer (since you can't pull this off unless you understand how the renderer works, and that's complicated)
  • Porting 32-bit code to 64-bit
  • Converting a DOS source port to run on Windows

Don't get disheartened. I actually disagree with Redneckerz - you don't need to be a programming or math expert to experiment with the Doom source and make basic changes. It's a fun way to get your toes wet as you learn how programming works and how to do more complicated things. I personally think a codebase like the Doom source provides a really nice sandbox where you can change stuff and see the effects of your changes, which is a much more satisfying way to learn than how things are usually taught.

[Redneckerz]

1 hour ago, fraggle said:

I actually disagree with Redneckerz - you don't need to be a programming or math expert to experiment with the Doom source and make basic changes.

I believe its always useful to know your math and a basic understanding of programming.

Seeing your neatly divided structure i realize my advice, for as much as it is one, falls more in line with the hard changes described.

 

1 hour ago, fraggle said:

I personally think a codebase like the Doom source provides a really nice sandbox where you can change stuff and see the effects of your changes, which is a much more satisfying way to learn than how things are usually taught.

Can't say i disagree there :) and there are a lot of educational tools available that explainthe inner workings of Doom.

[wesleyjohnson]

You should pick source code that was developed on your platform (which seems to be recent Windows).

Much of the early Doom code was developed on Unix (Linux) and then to DOS.

If you want to program on Windows, then DO NOT start with  Doom original, Linux Doom, Boom, PrBoom, MBF, DoomLegacy, or most any port from that era.

The system interface is not going to be Windows familiar, and you won't be able to easily make it Windows familiar.

 

While DoomLegacy has a Win32 port, it is meant to be compiled using MinGW using POSIX compatibility libraries, not some IDE.

Other Doom ports are similar in that they have been developed using a specific compiling context.

This is usually not the one you want to use.

Modifying the compile method for the compiling context (IDE) that you want to use is possible, but that is hardly

every documented (at all), and is a can-of-ugly-worms type of problem.

 

Until you have a good grasp of compiling it and making modifications on a working version,

you should avoid trying to change that to work with CodeBlocks or anything else extensive.

 

Porting to another platform is hard because nothing much will work until most of the porting is done.  There will be pages of error messages that

must be solved one by one, and they probably are interrelated, so already knowing the Doom code well is necessary to make reasonable progress

in a month of work.