Jump to content
Search In
  • More options...
Find results that contain...
Find results in...
Blastfrog

Attempting to get coding help for my TC's engine

Recommended Posts

EDIT: I just thought, this would be more appropriate in Doom Editing.

I figured that I might make a thread here instead, as it's more likely to be noticed than in the source port section. (which seems to be more about help with getting existing ports working rather than creating them)

So, what I have been trying to do is modify the existing bobbing code in Chocolate Doom to behave like the 0.4 alpha's bobbing. I honestly am not too experienced with C, and I have no idea how to do this on my own, and it would help me a lot if somebody would be willing to walk me through the steps necessary to accomplish this.

Share this post


Link to post

First you need to find the code that takes care of the bobbing. Then you need to change some numbers. I can take a look if you want. But then you have to show me where I can get the source code.

I have a little bit programming experience. (Mostly microcontrollers but it's all the same I guess)

Share this post


Link to post

Honestly, programming things like this is incredibly easy. The difficult part is finding the location of this in the source code.

Whatever you do, ask programming questions on forums like this. Never go to IRC for programming questions because people will just tell you to fuck off.

Share this post


Link to post

Note that I'm using the vanilla Linux Doom source code for help. I hope Choco-Doom uses a similar source code.

Sodaholic said:

So, what I have been trying to do is modify the existing bobbing code in Chocolate Doom to behave like the 0.4 alpha's bobbing. I honestly am not too experienced with C, and I have no idea how to do this on my own, and it would help me a lot if somebody would be willing to walk me through the steps necessary to accomplish this.

So you need to edit the bobbing? The game routine (function) that controls this is A_WeaponReady. To go there, open P_PSPR.C and locate A_WeaponReady. The first find result is the function description itself, with the comments describing it beforehand. At the end of the block, you'll find this sequence of code:

// bob the weapon based on movement speed
    angle = (128*leveltime)&FINEMASK;
    psp->sx = FRACUNIT + FixedMul (player->bob, finecosine[angle]);
    angle &= FINEANGLES/2-1;
    psp->sy = WEAPONTOP + FixedMul (player->bob, finesine[angle]);
First line makes "angle" be a product of 0.015625 degrees (128/8192 times 360, where 8192 is the maximum "fine angle" value allowed (360-degree equivalent), where "fine angle" is the type of angle used by trigonometric tables such as finesine, finecosine, finetangent) and the level time in tics. &FINEMASK keeps the resulting values in the 0-8192 domain (FINEMASK itself is 8191), because as always, angles are cyclical, but here the Doom trigono tables can always be used with values 8191 or below (down to 0). You can edit this line to control the direction the weapon will be directed at each moment (tic).

FRACUNIT is 1 in fixed-point arithmetics. It's written as 65536 or so in the code, but the game knows how to interpret it as 1 because it's used in situations where it is designated as such (and simply writing 1 in there would be useless because it would be interpreted as 1/65536, which would often be negligible or even truncated). I believe that for example when someone is crushed by a deadly crusher and that ceiling moves very slowly, you see how it passes fractions of height-units per tic. You can't edit the sector height in the map with such precision because you only have access to the integer part. But Doom also has access to the fraction part, probably via this fixed-point arithmetics.

psp->sx is the horizontal coordinate of the gun. It's set as 1.0 (FRACUNIT) + horizontal component of player->bob (which is controlled elsewhere). Consider that there's a vector of "player->bob" length, directed towards "angle".

Third line modifies the "angle" variable. FINEANGLES/2 is 4096 (180-degree) and &=FINEANGLES/2 - 1 modifies "angle" so it's limited in the 180-degree domain (if you attempt something similar, do not write only &=FINEANGLES/n without - 1, because - 1 is required: & (as in &FINEMASK) and &= do the modulo operation (limiting in a domain) only if the right operand is a power of 2, minus 1). Angle here needs to be 0-180 so the weapon (in psp->sy) won't be moved higher than the status-bar allowed maximum.

Speaking of psp->sy, due to being display coordinates, it is positive downwards, not upwards like in the Doom world or math world. So angle will always be below 180, which is pointing below, never up. The line moves the weapon's vertical coordinate to WEAPONTOP (defined in fixed point) + vertical component of player->bob down.

When you move at full speed, you'll see the weapon describe a semicircular trajectory. Too bad I can't help you because I don't know how the alpha guns move.

player->bob:

It's controlled in p_user.c at P_CalcHeight. That function not only controls weapon bobbing, it also seems to control the player head movement. What concerns you is here:
    player->bob =
	FixedMul (player->mo->momx, player->mo->momx)
	+ FixedMul (player->mo->momy,player->mo->momy);
    
    player->bob >>= 2;

    if (player->bob>MAXBOB)
	player->bob = MAXBOB;
It sets player->bob to squared player velocity, then divides it by 2, capping it at "MAXBOB" (which is defined in the same value as 0x100000, which is 16 in fixed-point (think of a hexadecimal number with a point before the last four digits).

So in default released Doom you have two parts controlling the bobbing: one in P_CalcHeight (triggered at every moment) where it calculates the displacement distance, and another in A_WeaponReady (triggered only when that function is called by a frame with A_WeaponReady action-function) where it calculates the angle and actually makes it happen on screen by changing psp->sx and sy.

How do the alpha guns move?

Share this post


Link to post
printz said:

How do the alpha guns move?

Thanks for helping me, it's really useful. :)

Anyway, you could download the 0.4 alpha (not 0.5, that version's bobbing sucked) and run it in DosBox. But I'll describe it anyway the best I can:
*Weapon bobbing was upside-down, it went in a /\ shape instead of \/ (keep in mind, it still went below the default alignment, it never went above, just like in the final)
*Weapon bobbing was also smoother, it did not jump to going the opposite direction immediately like in the final (instead it slowed down by the time it got to the end of it's path, and then sped back up)
*Viewheight bobbing slowed down when it got to the top, and then when it got to the bottom it yanked back up (like footsteps), unlike the final bobbing which was smooth on both ends instead of only the top.


Also, how can I have it so that when the weapon is in it's firing state, it raises 16 pixels?

Share this post


Link to post

Oh, and how do I add new objects to the game? (just decorations) I don't want to replace any existing decorations.

Share this post


Link to post

How do I define a state usable to a new actor? I see it referencing stuff like "S_TROO_STND", but I don't see where any of that is defined. I'm trying to add the chair from the Doom alpha, and this is what I have so far:

Sprite list:

char *sprnames[] = {
"TROO","SHTG","PUNG","PISG","PISF","SHTF","SHT2","CHGG","CHGF","MISG",
"MISF","SAWG","PLSG","PLSF","BFGG","BFGF","BLUD","PUFF","BAL1","BAL2",
"PLSS","PLSE","MISL","BFS1","BFE1","BFE2","TFOG","IFOG","PLAY","POSS",
"SPOS","VILE","FIRE","FATB","FBXP","SKEL","MANF","FATT","CPOS","SARG",
"HEAD","BAL7","BOSS","BOS2","SKUL","SPID","BSPI","APLS","APBX","CYBR",
"PAIN","SSWV","KEEN","BBRN","BOSF","ARM1","ARM2","BAR1","BEXP","FCAN",
"BON1","BON2","BKEY","RKEY","YKEY","BSKU","RSKU","YSKU","STIM","MEDI",
"SOUL","PINV","PSTR","PINS","MEGA","SUIT","PMAP","PVIS","CLIP","AMMO",
"ROCK","BROK","CELL","CELP","SHEL","SBOX","BPAK","BFUG","MGUN","CSAW",
"LAUN","PLAS","SHOT","SGN2","COLU","SMT2","GOR1","POL2","POL5","POL4",
"POL3","POL1","POL6","GOR2","GOR3","GOR4","GOR5","SMIT","COL1","COL2",
"COL3","COL4","CAND","CBRA","COL6","TRE1","TRE2","ELEC","CEYE","FSKU",
"COL5","TBLU","TGRN","TRED","SMBT","SMGT","SMRT","HDB1","HDB2","HDB3",
"HDB4","HDB5","HDB6","POB1","POB2","BRS1","TLMP","TLP2","BON3","BON4",
"FLG1","FLG2","ZAPR","SPAR","WIRE","CANI","SHI1","SHI2","CHAI", NULL
};

State definition: {SPR_CHAI,0,-1,{NULL},S_NULL,0,0}, // S_CHAIR

Share this post


Link to post

How can I make the background flat in smaller screen-sizes different? I need it to be FLOOR5_1 instead of FLOOR7_2.

Share this post


Link to post
Sodaholic said:

How can I make the background flat in smaller screen-sizes different? I need it to be FLOOR5_1 instead of FLOOR7_2.

How about searching for "FLOOR7_2" in the source code?

Share this post


Link to post

It appears that the same things you find in Dehacked, you can find in info.h, info.c, sounds.c, sounds.h and probably others.

INFO.* include the sprite, frame and thing tables. SOUNDS.* include the music and sound tables.

Adding new such objects doesn't appear to be very hard...

First you have to add a name in the specific list in the *.H file (such as MT_CHAIR or MT_MISC87 for the chair thing, S_CHAIR for the chair frame, SPR_CHAI for the chair sprite), right before the NUM* constant at the end of the list, which is important because it fixes the dimension of the corresponding data table.

Second, go into the *.C file and add the definitions themselves.

IMPORTANT: don't just add the definitions in the tables located in the C files. You also have to add the names in the H files, in order to push the NUMMOBJTYPES (and so on...) constants to the correct values.

What I don't know about this: how does Doom/Doom 2 determine which things are illegal in Doom 1 (and stops generating objects because of their presence in the map file)?

The tables remind me A LOT of Eternity EDFs, except I don't have to worry about correspondences in Eternity. Though you seem to want to change other things too, such as the bobbing, which of course can't be done in Eternity (yet).

EDIT: Indeed, if you don't understand a word or want to find how a keyword is processed, search for it in the code and try to isolate it.

Sodaholic said:

*Weapon bobbing was upside-down, it went in a /\ shape instead of \/ (keep in mind, it still went below the default alignment, it never went above, just like in the final)
*Weapon bobbing was also smoother, it did not jump to going the opposite direction immediately like in the final (instead it slowed down by the time it got to the end of it's path, and then sped back up)
*Viewheight bobbing slowed down when it got to the top, and then when it got to the bottom it yanked back up (like footsteps), unlike the final bobbing which was smooth on both ends instead of only the top.

This sounds like a more complicated math formula. It means you have to make the length and angle of the vector dependent on player->bob and angle.

First, define two new variables:

fixed_t v_len;
fixed_t v_ang;
Define their values and use them in the sx, sy settings instead of using player->bob and angle respectively. How you define them?

In raw math:

v_len is the length of the base of the isosceles triangle with the peak angle of 90-angle and the sides as long as player->bob.

EDIT: v_len = 2*player->bob*finesine[abs(2048-ang)/2];

Angle is 90 - the side angle of that triangle.

EDIT: v_ang = (1024 - angle/2)&FINEMASK;
Define it after angle is modified to fit for sy (that 4096 thing).

Tell me if this works, I haven't tested any of it.

Share this post


Link to post
Sodaholic said:

I honestly am not too experienced with C, and I have no idea how to do this on my own, and it would help me a lot if somebody would be willing to walk me through the steps necessary to accomplish this.


I honestly think that you should learn C and C++ before you decide to modify the source code. >_<

Share this post


Link to post
bgraybr said:

I honestly think that you should learn C and C++ before you decide to modify the source code. >_<

Yeah, you're right I have no idea what I'm doing! :P I still need a custom engine for my Doom Alpha TC (which was originally for ZDoom, but I always wanted it to be a modified version of chocolate-doom), so I think I'll try to just recruit a coder.



Anyway, I need somebody to help implement new features into Chocolate Doom since I'm not really capable of doing it myself. You should know that this project has a good chance of going somewhere (a good bit of work has already been done on the ZDoom version that I can easily port over), so your effort wouldn't be wasted on it.

The highest priority feature is probably porting over Strife's level system, where it remembers the state of all the maps in the episode, and having multiple level entrances and exits. I still want to keep the intermission screen, though.

Share this post


Link to post

Are there any coders that would be willing to help with a custom engine?

If you need a screenshot for proof that I'm actually working on it, here:

Share this post


Link to post

Is it too unrealistic to expect that there would be anyone out there willing to help my project by being an engine coder? I just want to know if I'm wasting my time trying to recruit a programmer for my project.

Share this post


Link to post

Anyone? Really, am I wasting my time trying to get a coder for my project?

EDIT: I just thought, maybe I should quit bumping this. :P It feels like it's been a week to me, even though it's only been a few days.

Share this post


Link to post

This 3D stuff is a lot more maths/algos than just any old C coding. You need a solid grasp of trigonometry and linear algebra, plus some basic background on 3D graphics in order to jump in and make arbitrary engine changes. I'm not saying you have to be Michael Abrash (though that doesn't hurt ;) ) but not just any C coder can do it, not without first getting up to speed in this domain.

Heck, back in 1995-96 I was playing around with real basic 3D routines in Turbo Pascal and a tiny bit of asm to speed up inner loops, putpixel(), etc. Anyway, it was just typical age-old stuff you regularly saw in demoscene productions, like starfields, text scrollers, image scaling/rotation, wireframe polygons, etc. But even those simple effects took me a while to wrap my head around. And I was really excited when it actually worked. ;)

Share this post


Link to post
Sodaholic said:

Anyone? Really, am I wasting my time trying to get a coder for my project?


Coding is one of the most specialized skills around here, going to take patience to make that happen. But you could continue putting resources together and other things you're able to do, getting the project along farther in that way might make it more appealing, should anyone want to help with programming.

Share this post


Link to post
hex11 said:

This 3D stuff is a lot more maths/algos than just any old C coding. You need a solid grasp of trigonometry and linear algebra, plus some basic background on 3D graphics in order to jump in and make arbitrary engine changes. I'm not saying you have to be Michael Abrash (though that doesn't hurt ;) ) but not just any C coder can do it, not without first getting up to speed in this domain.


Is there any reason why he has to mess with the rendering code to make his TC?

Share this post


Link to post
bgraybr said:

Is there any reason why he has to mess with the rendering code to make his TC?

Not really, no. I mostly want to do 2d/game logic stuff:
*Strife-like level state system
*Interactive intermission screen (you get to choose which level you go to when you're at the intermission screen)
*Alpha-style bobbing
*Alpha/Press-release beta like behavior for plenty of stuff
*New decorations, items, and powerups
*Cut systems like score, lives, etc.

That about sums it up.
__________

Use3D said:

Coding is one of the most specialized skills around here, going to take patience to make that happen. But you could continue putting resources together and other things you're able to do, getting the project along farther in that way might make it more appealing, should anyone want to help with programming.

That's what I think I will do.

But before I can do that, it is an absolute requirement that I have new object definitions so that the alpha items actually show up/the engine doesn't crash due to there being unrecognized actors in the map.

I suppose that I could remove them, but I really don't want to do that, as I may end up forgetting to put some of them back. Besides, I like to have all of my resources already loaded rather than being "on-hold".
__________

I don't really care about much other engine features at this point beyond new objects. I don't even want to bother with them being functional, I just want them to appear in the maps.

Could someone please walk me through each step of adding a new object to the code? (if it matters, I'm using The Ultimate Doom as a base for my TC)

Or at the very least, have Chocolate Doom ignore unknown objects rather than crashing? (I'd much prefer to have them in the game, though)

I thank printz for trying to help me, and I've tried to follow his instructions the best I could, but I think I jumped a little to deep when I decided to start editing the code. ** I'm not dismissing printz at all, I'm just saying that I need more specific and step-by-step instructions. :P

I did try to add the objects myself, but I feel a little bit lost, and would like to start over, so that I can do it cleanly and properly, rather than however my clusterfuck attempt would have ended up. I like to know that the code is well done and not a complete and utter hack job, so instructions from someone much more experienced than me are preferred to my aimless wandering.
__________

Lastly, I'm not sure if this post makes any sense, I'm so tired I'm about to fall asleep. I somehow have the feeling that a lot of my post was redundant, but I'm sure you guys can figure it out. (jesus im typing sloppy right now, i have to keep making edits every few seconds to correct constant tpyos)

Share this post


Link to post
Sodaholic said:

Not really, no. I mostly want to do 2d/game logic stuff:
*Strife-like level state system
*Interactive intermission screen (you get to choose which level you go to when you're at the intermission screen)
*Alpha-style bobbing
*Alpha/Press-release beta like behavior for plenty of stuff
*New decorations, items, and powerups
*Cut systems like score, lives, etc.


Chocolate Strife will help you out with the first one. The others (with the exception of the second) actually don't sound too complicated.

I would just take Use3D's advice. If the alpha objects are a problem, work on it some in Zdoom, or if that worries you just substitute the alpha objects with a few other ones for now.

Share this post


Link to post

I have a status bar made for ZDoom in an SBARINFO lump, how could I convert that to use in Chocolate Doom? I'd try to figure it out myself, but I won't have access to the source code for a few days. (I'm out of town, and am using public computers)

Share this post


Link to post
Sodaholic said:

(I'm out of town, and am using public computers)


Where Doom meets web development? :-p That truly IS rogue programming!

Share this post


Link to post

I'm pretty sure I can figure it out myself when I get back to Akron when I have access to the source code. But I was wondering if anyone could tell me in advance what files in particular have the status bar code.

All I'm going to be doing for now is just changing the font size and positioning of the number counters, but I want to add a few new features later on as well. How can I do the following?:

1. A picture showing what weapon you have selected (see "weaponicon" in ZDoom's SBARINFO for an example of what I need to do)
2. A display of the level time (minutes and seconds)

Share this post


Link to post
hex11 said:

This 3D stuff is a lot more maths/algos than just any old C coding. You need a solid grasp of trigonometry and linear algebra, plus some basic background on 3D graphics in order to jump in and make arbitrary engine changes. I'm not saying you have to be Michael Abrash (though that doesn't hurt ;) ) but not just any C coder can do it, not without first getting up to speed in this domain.

Heck, back in 1995-96 I was playing around with real basic 3D routines in Turbo Pascal and a tiny bit of asm to speed up inner loops, putpixel(), etc. Anyway, it was just typical age-old stuff you regularly saw in demoscene productions, like starfields, text scrollers, image scaling/rotation, wireframe polygons, etc. But even those simple effects took me a while to wrap my head around. And I was really excited when it actually worked. ;)


Yep.
A mathematician learning a programming language is good - the other way around sux.

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×