Engoo

[mankrip]

is that like a quad effect ?

It doesn't seem so. There's no dynamic light on the player in that shot, and there's no quad item at the beginning of that map.

It looks more like leileilol removed the red color from the palette, and redistributed the blue and green colors accordingly.

I liked the HUD scaling. That's the correct aspect for the HUD, as Quake's 2D graphics were made with a 4:3 320x200 screen in mind (which is confirmed by the pentagram icon's aspect). Makaqu can only display the HUD with the correct aspect if you play it at 800x600 stretched to the native resolution of a 16:10 monitor.

It's funny how Quake's 2D graphics were made for that aspect, while the 3D renderer was coded with a 4:3 320x240 square pixel aspect in mind.

[edit] This also makes me think... It may be a good thing to implement an option to change the pixel aspect of the 2D elements, as the 2D artwork of some mods and TCs may have a square pixel aspect.

[qbism]

I liked the HUD scaling. That's the correct aspect for the HUD, as Quake's 2D graphics were made with a 4:3 320x200 screen in mind (which is confirmed by the pentagram icon's aspect). Makaqu can only display the HUD with the correct aspect if you play it at 800x600 stretched to the native resolution of a 16:10 monitor.

Seems to be three choices available to deal with widescreens, say 16:9, none are optimal:
1. Pad the sides, equivalent to 360x200. Correct HUD aspect, but big gaps on the sides. Menus look good.
2. Chop to 320x180. Correct HUD aspect, but a bit large. Text will get chopped off bottom of menus and help.
3. Just stretch out the hud, 320x200. Looks OK (until you see a HUD at correct aspect )

With the Makaqu hud, or other side-mounted hud, padding could be placed in the middle.

[mankrip]

1. Pad the sides, equivalent to 360x200. Correct HUD aspect, but big gaps on the sides. Menus look good.

This is what Makaqu does in the classic HUD (sbar 1 to sbar 3), but it only corrects the aspect partially (due to the integer-based scaling).

2. Chop to 320x180. Correct HUD aspect, but a bit large. Text will get chopped off bottom of menus and help.

That wouldn't work, chopping content isn't an option for this case.

3. Just stretch out the hud, 320x200. Looks OK (until you see a HUD at correct aspect )

If you wanna see how bad this could go, run Makaqu 1.5.1 (not 1.6), set vid_config_x to the width of your desktop and vid_config_y to 200, and then set vid_mode 2.

With the Makaqu hud, or other side-mounted hud, padding could be placed in the middle.

To be more precise, what Makaqu does in this case is alignment. In Makaqu, alignment and padding are different things, and its 2D renderer basically aligns the 320x200 virtual screen area of the core 2D image drawing function (of which, besides the function for drawing the console background, there's only one - I've merged all the others into it). Alignment can be done independently on the horizontal (left, center, right) and vertical (top, middle, bottom) axes, and can be changed prior to every 2D drawing call, thus allowing each and every 2D element in the screen to be aligned independently. So, Makaqu isn't really able to do any padding in the middle of the screen - it just uses different alignment settings for the virtual screen of each group of elements.

In Makaqu, padding is usually very subtle, and it defines:
- how far from the left edge of the window/screen a left-aligned virtual screen will be,
- how far from the right edge of the window/screen a right-aligned virtual screen will be,
- how far from the top edge of the window/screen a top-aligned virtual screen will be,
- how far from the bottom of the window/screen a bottom-aligned virtual screen will be,
- how far from each side of the window/screen a center-aligned virtual screen will be,
- and how far from the top and the bottom of the window/screen a middle-aligned virtual screen will be.

The purpose of the padding in Makaqu is to ensure that nothing on the screen will be drawn outside of the visible area of CRT TVs and problematic CRT monitors. It is the equivalent of the "set screen size and position" option of some console games, but I've implemented it in a way that is simpler and easier for the users to set (as featured in the "Adjust screen" menu).

In LCD monitors, screen padding is unnecessary, so I've disabled it in Makaqu 1.6 when the "Pixel aspect" option is set to "square (LCD)".



Sorry for hijacking the thread, leilei.

[leileilol]

800x600 scr_scale 1, 1.5, 2, 2.5, 3


I think that implementation is versatile enough

[leileilol]

[mankrip]

The blur of the motion! Looks very well done.

Is that Transfusion?

[qbism]

Very cool. Can motion blur be off for vwep? Or is post-process?

[leileilol]

It's done by using a translucency table on the waterwarp buffer. The original game used a 320x200 screen buffer to do a trans lookup on too, so the method is pretty much almost identical, including the precision-lacking streak trails that come with it. If you were ever on the 'brink of death' in a bloodbath match, or if you ever picked up the shrooms item (which also exists in the alpha), or attacked by a certain spider, you'd know.

Trying to integrate it as a function (to work with old pre-PSK/pre-MD3 Transfusion) is another story. I try to support Transfusion as much as I can in this engine as it's a good yardstick to have compatibility for with lots of the standard DP 1.05 features used. The little bits (new blood particles, new weapon bobbing, random sound pitch) makes it feel much closer to Blood

[ceriux]

leilei that looks pretty awesome. i know that's all i say on your thread pretty much. but i really like what you do with engoo.

[leileilol]

I tried to steal Quakespasm's hor+ fov scaling stuff and I wounded up with a view of a gnome.

Was hoping to extend the standard 4:3 screen to 16:9 with it with no vertical change.

[qbism]

It's hard to juggle the native aspect of the display, the aspect of the video mode, and the various hard-coded aspect ratios.

[mankrip]

Was hoping to extend the standard 4:3 screen to 16:9 with it with no vertical change.

Take a look at the Makaqu 1.6 code, this is what it does. The only innacuracy is for fov_x in windowed modes with variable pixel aspect, but I've already fixed that in my current code.

[szo]

I tried to steal Quakespasm's hor+ fov scaling stuff and I wounded up with a view of a gnome.

You had better look at uhexen2 in order to adapt that to to your
software renderer which is a little tricky. The changes are in
screen.c, render.h, r_main.c, r_misc.c. It took me five commits
to make it work properly.

EDIT: The multiple svn commits are confusing. Here's a proper diff
(temp link) : http://uhexen2.sourceforge.net/tmp/uh2_sw_fovadapt.diff

[mankrip]

I'm porting some changes from Engoo to Makaqu, and noticed some things.

There's an error in asm_i386.h:

Code: Select all

// channel_t structure
// !!! if this is changed, it much be changed in sound.h too !!!
#define ch_sfx         0
#define ch_leftvol      4
#define ch_rightvol      8
#define ch_end         12
#define ch_pos         16
#define ch_looping      20
#define ch_entnum      24
#define ch_entchannel   28
#define ch_origin      32
#define ch_dist_mult   44
#define ch_master_vol   48
#define ch_size         52
#define ch_step         56

ch_size is the total size of the struct, but as can be seen in sound.h, ch_step is actually part of it:

Code: Select all

// !!! if this is changed, it much be changed in asm_i386.h too !!!
typedef struct
{
   sfx_t   *sfx;         // sfx number
   int      leftvol;      // 0-255 volume
   int      rightvol;      // 0-255 volume
   int      end;         // end time in global paintsamples
   int    pos;         // sample position in sfx
   int      looping;      // where to loop, -1 = no looping
   int      entnum;         // to allow overriding a specific sound
   int      entchannel;      //
   vec3_t   origin;         // origin of sound effect
   vec_t   dist_mult;      // distance multiplier (attenuation/clipK)
   int      master_vol;      // 0-255 master volume


   // ASMME - NEW STRUCTS

   int     step;         // AJA - Pitch shift
} channel_t;

step comes right after master_vol, so ch_step must come right after ch_master_vol, not after the total size of the struct. And the total size must be adjusted to include ch_step:

Code: Select all

// channel_t structure
// !!! if this is changed, it much be changed in sound.h too !!!
#define ch_sfx         0
#define ch_leftvol      4
#define ch_rightvol      8
#define ch_end         12
#define ch_pos         16
#define ch_looping      20
#define ch_entnum      24
#define ch_entchannel   28
#define ch_origin      32
#define ch_dist_mult   44
#define ch_master_vol   48
#define ch_step         52
#define ch_size         56

The same concept applies to the other struct offsets in Quake's x86 ASM code. After each struct's offsets, they included an extra "size" definition to indicate the size of the struct, and this definition must be updated when the size of the struct changes.



And what does this hack fix, exactly?

Code: Select all

void S_PaintChannels(int endtime)
{
   [...]
         if (ch->step < 5)
            ch->step = 256; // ambient suck hack
   [...]
}

[Spike]

fixes sounds with no 'step' set.
'step' in this case is how many source audio samples to skip per output sample, in 24.8 fixed-point.
set it to 128 and the sound will take twice as long to play. set it to 512 and it'll play at twice the rate.
If the step field isn't set, then the sound will not appear to play at all, as it will play the exact same sample until infinity.