Blastfrog Posted January 27, 2015 To prepare for an upcoming project, I have decided to fork Eternity as the engine basis. This is not a Doom related project and I want to give it a unique feel, so please don't question the design choices outside of their technical feasibility. I can kinda fudge my way around, but I'm hardly a good coder. My main concern is that I've never really taken a deeper look at the Doom engine's internal workings and thus don't know exactly what I'm looking for and searching for keywords only gets me so far. Questions: 1. I changed TICRATE to 60. Note that I don't plan on having multiplayer. Will this rate cause any problems with local play without further adjustment? I haven't run into anything yet. 2. Where would I go to change the base resolution of 2D screen elements (titlepic, intermission, weapons, hud, etc) from 200p to 240p? Changing SCREENHEIGHT to 240 simply causes a crash whereas I don't get that problem making the same change to Chocolate. 3. Where would I go to change the 3D world view to use square pixels instead of vertically stretching them 1.2x? 4. What on earth is INV_ASPECT_RATIO? It's defined but I see no references for it elsewhere in the code. The comment is even weirder. "Ideally 0.75" yet is defined as something other than the ideal value? 0 Share this post Link to post
Quasar Posted January 27, 2015 Sodaholic said:1. I changed TICRATE to 60. Note that I don't plan on having multiplayer. Will this rate cause any problems with local play without further adjustment? I haven't run into anything yet. 2. Where would I go to change the base resolution of 2D screen elements (titlepic, intermission, weapons, hud, etc) from 200p to 240p? Changing SCREENHEIGHT to 240 simply causes a crash whereas I don't get that problem making the same change to Chocolate. 3. Where would I go to change the 3D world view to use square pixels instead of vertically stretching them 1.2x? 4. What on earth is INV_ASPECT_RATIO? It's defined but I see no references for it elsewhere in the code. The comment is even weirder. "Ideally 0.75" yet is defined as something other than the ideal value? Don't know. It might make interpolation less accurate, because 60 FPS is very close to the timing precision limit for SDL's time getting function. We had this problem in SVE. Don't. If you're making a new game, get rid of the scaling-based HUD shit altogether and write functions that draw directly to the framebuffer with proper square-pixel scaling. Get rid of the idea that the resources don't match the output aspect ratio altogether. If you're not able to do this, then I suggest you're in over your head on this project. You'd have to ask SoM this question. An unused extinct define that dates back to the Doom alpha versions. 0 Share this post Link to post
Blastfrog Posted January 29, 2015 Thanks for responding, Quasar. After enough digging I found the variable that controls pixel height in Cardboard: "ratio". I feel a bit foolish not having found it earlier. I'm probably going to hire an actual coder for the serious work, but for now I'm just trying to get off the ground with a few tweaks as a basis to work upon. Until that time comes, I've only two more questions: 1. How can I make the max and min viewpitch 120 lines instead of the current 100? topangle/bottomangle and trace.topslope/trace.bottomslope don't seem to be what I'm looking for. 2. How can I give the player full control to exert themselves when airborne without being subject to any friction? 0 Share this post Link to post
LordMeow Posted January 30, 2015 Kreimeier should have written that book on Doom source code... Maybe we should coordinate to write it. Very few people would read it, but the ones who did will find a fascinating reading. 0 Share this post Link to post
Edward850 Posted January 30, 2015 Sodaholic said:1. I changed TICRATE to 60. Note that I don't plan on having multiplayer. Will this rate cause any problems with local play without further adjustment? I haven't run into anything yet. The physics isn't quite well tuned for anything beyond 35hz. I would expect to see physics steps starting to become imprecise at around this point. Granted, I tested 1000Hz. I haven't done a proper test at 70Hz, which seems like as good of an excuse as any. 0 Share this post Link to post
Blastfrog Posted January 30, 2015 I've got a potentially interested coder, so I won't be needing anymore help in this thread for now. In the meantime, I've forked Eternity on Github and put down my amateur changes that I made locally: https://github.com/Blastfrog/catnip LordMeow said:Kreimeier should have written that book on Doom source code... Maybe we should coordinate to write it. Very few people would read it, but the ones who did will find a fascinating reading.If Kreimeir should've done anything differently, it would be not taking as many liberties as he did with the source. Still hoping the original DOS source will be released at some point. While Chocolate Doom is as flawless as possible, that doesn't include any potentially dummied out code that Kreimeir may have removed. Edward850 said:The physics isn't quite well tuned for anything beyond 35hz. I would expect to see physics steps starting to become imprecise at around this point.I intend to have the collision rewritten to be more robust, but I'm currently focused on getting the player controls to feel as I want them to just to start out with. Almost done with that initial bit, thankfully. 0 Share this post Link to post
LordMeow Posted January 30, 2015 Sodaholic said: If Kreimeir should've done anything differently, it would be not taking as many liberties as he did with the source. Still hoping the original DOS source will be released at some point. While Chocolate Doom is as flawless as possible, that doesn't include any potentially dummied out code that Kreimeir may have removed. Even with all his tampering, such a book would have been a great read. And yes, John Carmack should have release the DOS code with all the sound stuff stripped, and the code in an uncompilable state. In a day or so, everything will have been taken care of. 0 Share this post Link to post
Holering Posted January 30, 2015 What are you using to modify your fork of Eternity? Cygwin, Linux, MacOS? I mentioned Slackware in a previous thread of yours for a cygwin replacement. But you may be better off with cygwin. If you must try Linux you might prefer Arch, Gentoo, Debian or Ubuntu. There's "commercial like" distros like Opensuse, Slackware and Fedora. Slackware uses a human for package management which some folks don't like and may not be the best option for learning or project management to some. I'm assuming you're preference is programming-development or handling a project like a fork of something (Eternity). 0 Share this post Link to post
Blastfrog Posted February 2, 2015 Honestly, I never gave coding a serious try, I'm a script kiddie and a bad one at that. My potentially interested coder turns out to be too busy, so I'm on my own again. If anyone that can actually code wants to make an easy 40 bucks, talk to me. Before anyone says I'm "in over my head", the engine is not the primary focus and the vital changes are merely player control related. The content-building process is coming along fine. Holering said:What are you using to modify your fork of Eternity?Actually, I'm using Visual C++ Express 2013 under Windows 7. 0 Share this post Link to post
Linguica Posted February 2, 2015 Offering $40 to code any sort of significant change to the renderer is an incredible lowball. However, this bit:Sodaholic said:2. How can I give the player full control to exert themselves when airborne without being subject to any friction? This is fairly straightforward though. I don't know how it's structured in Eternity so I'll do it in Chocolate Doom and leave it as an exercise for the reader. I'm assuming you want full air control in the sense that moving while falling should act exactly like moving while on the ground. First in P_MovePlayer(): if (cmd->forwardmove && onground) ... if (cmd->sidemove && onground) Remove the && onground bit to allow air control to be registered at all. Then in P_XYMovement(), change if (mo->z > mo->floorz) return; // no friction when airborne to something like if (mo->z > mo->floorz) if( !player || (player->cmd.forwardmove== 0 && player->cmd.sidemove== 0)) return; This makes it so a player will fall at a constant sideways velocity like normal if he's not actively trying to move, but otherwise can change direction / speed in midair. 0 Share this post Link to post
Linguica Posted February 2, 2015 Trying that out makes me think that all non-vanilla source ports should implement air control with something likeif (cmd->forwardmove && (onground || player->mo->flags&MF_NOCLIP)) to allow full air control while in no clipping mode, that would be a nice thing when clipping through a big vertical map. 0 Share this post Link to post
Blastfrog Posted February 3, 2015 Linguica said:Offering $40 to code any sort of significant change to the renderer is an incredible lowball.I probably should have specified which features I was attempting to pay for: increased air control and increasing the max y-shear viewing range. I already managed to take care of the 3D world view's aspect ratio before your post which is enough on the rendering side for now. Eternity is structured slightly differently to Chocolate's implementation, but I was able to adapt your changes to it. It feels great in motion, thanks! 0 Share this post Link to post
fabian Posted February 3, 2015 Linguica said:Trying that out makes me think that all non-vanilla source ports should implement air control with something likeif (cmd->forwardmove && (onground || player->mo->flags&MF_NOCLIP)) to allow full air control while in no clipping mode, that would be a nice thing when clipping through a big vertical map. Indeed, good idea! 0 Share this post Link to post
Blastfrog Posted July 31, 2015 I'm a bit less clueless now, but I still suck. So uh, halp, plz I tried adding a jump sound effect, and I've filled all the spots I could find. It compiles fine, but the sound just doesn't play. It otherwise works when I tell it to use a sound other than my new jump sound. Spoiler In e_player.cpp, I added: #define ITEM_SKINSND_JUMP "jump" and CFG_STR(ITEM_SKINSND_JUMP, "jump", CFGF_NONE) In sounds.h, I added: sfx_jump, In p_skin.h, I added: sk_jump, In p_skin.cpp, I added: "dsjump", In d_gi.cpp, I added: "jump", and sfx_jump, In e_sound.cpp, I added: "sk_jump", What am I missing? EDIT: Maybe it'd be better if I updated my github copy... The spoiler'd info is probably too vague to be of use unless one manually followed my steps. 0 Share this post Link to post
Altazimuth Posted July 31, 2015 Hopefully a small change I've made to EE might be able to give you a hand. https://github.com/team-eternity/eternity/pull/13/files This doesn't add functionality but adds the properties and handles defaults in the case of nothing being supplied in an edf file. I would also highly recommend joining #noteternityenginerelated on the OFTC IRC network, where more immediate help may be available. Sadly I have since lost the specification given to me but this basically adds the ability to specify blood behaviour using EDF. 0 Share this post Link to post
Blastfrog Posted August 2, 2015 Quasar pointed out one area I missed, but it still doesn't work even after I've filled it in. https://github.com/Blastfrog/catnip 0 Share this post Link to post