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

Eternity Tweaking [Catnip Engine]

Recommended Posts

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?

Share this post


Link to post
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?

  1. 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.
  2. 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.
  3. You'd have to ask SoM this question.
  4. An unused extinct define that dates back to the Doom alpha versions.

Share this post


Link to post

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?

Share this post


Link to post

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.

Share this post


Link to post
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.

Share this post


Link to post

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.

Share this post


Link to post

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.

Share this post


Link to post

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).

Share this post


Link to post

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.

Share this post


Link to post

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.

Share this post


Link to post

Trying that out makes me think that all non-vanilla source ports should implement air control with something like

if (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.

Share this post


Link to post
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!

Share this post


Link to post
Linguica said:

Trying that out makes me think that all non-vanilla source ports should implement air control with something like

if (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!

Share this post


Link to post

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.

Share this post


Link to post

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.

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
×