[Fox]

It has been suggested before for Eduke32 to automatically load MYMAP.CON and MYMAP015.art, and if save files can store the con I suppose it can be loaded with a user map.

[Fox]

Fox, on 22 December 2013 - 03:03 PM, said:

Would it be posible to separates the shade and fog colors? I feel like using the same color for both is very limitating, especially for realistic environments. I am not 100% sure, but as far I know it would be technically possible with the way lookup palette works.

I also would like to request the ability to have a black fog (0, 0, 0) that uses a shade table generated by the engine. Otherwise I am forced to have a shade table with the same shade values as Duke 3D palette files...

To further expand on this subject, here is a photo that show what I am talking about:



This kinda of thing is quite not possible if both shade and fog must use the same values.

[TerminX]

The whole way fog works is by generating new shade tables that are used in place of the traditional "fade to black" tables you get by default. What you are asking for is not possible.

[Daedolon]

Fox, on 24 December 2013 - 11:17 AM, said:

To further expand on this subject, here is a photo that show what I am talking about:

Makes me want to work further on my Blood map(s). It's almost sad how much ingenuity went into the design of the features of Blood. I just wish some of them could be back-portable somehow.

[Fox]

Alternatively I could create 32 pals that replace the texture shading (sorta like I already did in Duke Nukem 64 Mod for the Nightvision) and use in conjuction with any fog. But that's just conceptual.

[Helixhorned]

Fox, on 27 December 2013 - 09:45 PM, said:

Alternatively I could create 32 pals that replace the texture shading (sorta like I already did in Duke Nukem 64 Mod for the Nightvision) and use in conjuction with any fog. But that's just conceptual.

Not conceptual any more:


See r4236. I'll leave the documentation for the new year, but in the meantime feel free to look into the commented test/shadexfog.lua.

[Fox]

Thanks! I tought it should be possible in some way if I can do it with palettes (even if it is impractical).

Quote

Failed attempt at recreating the base shade table. It is NOT a linear ramp
of the base palette colors to (0,0,0). That is, it's not created by
build/util/transpal.exe!

Not really sure what you meant here, but I am not asking for a black fog (0, 0, 0) that mimics the original Duke 3D shade table, but rather for one that works in the same way as any custom fog. Think of it as if I would use 1, 1, 1 as a replacement if I can't use 0, 0, 0.

[Helixhorned]

Fox, on 31 December 2013 - 04:49 AM, said:

Not really sure what you meant here, but I am not asking for a black fog (0, 0, 0) that mimics the original Duke 3D shade table, but rather for one that works in the same way as any custom fog.

Yup, I understand that. The Lunatic manual now has a subsection documenting how the classic renderer uses shade tables. It's required reading for anyone wishing to discuss effects such as these. Also... Mapster32 didn't start with the Lunatic build before, d'oh. It should be fixed now, so you can get to experimenting with the editor.

I wanted to exactly reproduce the shade table provided with Duke3D, but failed -- transpal.exe generates a table giving a similar, but noticeably different result. For example, the fading happens slightly faster in the PALETTE.DAT table, but it's not only a matter of a factor. It's surprising as I expected that program to be what was run by 3DR/Ken to generate it.

[Fox]

I am quite sure the shade table from Duke 3D was created with a slightly different palette (the one used in these early screenshot in PCX format).

[LeoD]

make USE_OPENGL=0 fails to build:

src/defs.c: In function 'defsparser':fs.o...
src/defs.c:1284:38: error: 'HUDFLAG_HIDE' undeclared (first use in this function)
                             flags |= HUDFLAG_HIDE; break;
                                      ^
src/defs.c:1284:38: note: each undeclared identifier is reported only once for each function it appears in
src/defs.c:1286:38: error: 'HUDFLAG_NOBOB' undeclared (first use in this function)
                             flags |= HUDFLAG_NOBOB; break;
                                      ^
src/defs.c:1288:38: error: 'HUDFLAG_FLIPPED' undeclared (first use in this function)
                             flags |= HUDFLAG_FLIPPED; break;
                                      ^
src/defs.c:1290:38: error: 'HUDFLAG_NODEPTH' undeclared (first use in this function)
                             flags |= HUDFLAG_NODEPTH; break;
                                      ^
src/defs.c:1243:61: warning: variable 'flags' set but not used [-Wunused-but-set-variable]
                     int32_t ftilenume = -1, ltilenume = -1, flags = 0, fov = -1;
                                                             ^
Failed building ../source/eobj_win/defs.o from src/defs.c!
make[1]: *** [../source/eobj_win/defs.o] Error 1
make: *** [enginelib] Error 2

[Helixhorned]

Fox, on 02 January 2014 - 12:39 AM, said:

I am quite sure the shade table from Duke 3D was created with a slightly different palette (the one used in these early screenshot in PCX format).

No, it's not that either. Look at a plot of the color of palookup[s][223] against the shade s:



You'd expect the colors to distribute around the dotted lines if it were a linear ramp. Now compare this with a plot showing the colors of the base palette split by R/G/B, recently added to the wiki. In the second plot, color index 223 has been moved to 159. The bottom line is, they have been created using a different computation method than taking close colors of linearly-blended ones.

LeoD, on 02 January 2014 - 05:17 AM, said:

make USE_OPENGL=0 fails to build:

Fixed in r4241. Thanks.

[Daedolon]

Helixhorned, on 02 January 2014 - 09:18 AM, said:

shadecolor_223_rgb.png

How did you calculate that?

And can you make a "perfect" palette (for the 256 colours anyway) that fixes those gradients?

[Fox]

I have some questions about multiplayer. How exactly the player ID works in regards of players joining or leaving a game?

[Helixhorned]

Daedolon, on 02 January 2014 - 09:21 AM, said:

How did you calculate that?

Using some home-brewed Octave code, found here. It's all data plotting though, no real calculation involved. If you want to reproduce it, you'll have to compile Octave from source. The official binary packages don't ship with classdef support yet, but it has recently been merged into the default branch.

Quote

And can you make a "perfect" palette (for the 256 colours anyway) that fixes those gradients?

Well, you can create one whose colors will be closest to linearly-blended ones (for a given distance function; in transpal.exe it's the squared Euclidean distance, with a weighting on the color components). However, it turns out that it's not even desirable. Try running the following from the latest Lunatic Mapster32's OSD, with quotes entered as shown:

lua "shadexfog=reload'shadexfog'"
lua "shadexfog.create0(100)"

Now, switch to the newly created pal with

lua "shadexfog.challpal(100)"

You'll notice that the result is quite inferior to what the shipped shade table provides. I think it's been generated similar to this: Assume that the base palette contains all color ramps in consecutive blocks (like in the rearranged base palette colors plot on the wiki) and for a color index i, let b(i) denote the least color index belonging to the same ramp as i (the "base" color index of that ramp). Then, for a shade s and a color index i, palookup[s][i] = b(i) + round((s/32)*(i - b(i))). In a sense, this is a good thing, as it means that shaded versions of a color stay within their ramp.

edit: corrected the formula

[Hendricks266]

Fox mentioned that the shade tables could have been generated from an older palette version that can be found in PCX prototype screenshot collections. Have you tried running your script(s) on it/them?

[Helixhorned]

I think it's unlikely for the mentioned reasons. Wouldn't you expect to see basepal(palookup[][]) to spread around the dotted line in the earlier plot if that were the case? What you see instead is that it follows the R/G/B ramp itself! I haven't run transpal.exe/shadexfog.create0 (these two only differ by a small amount -- maybe I got some rounding wrong or the like) on it though. Is there a PALETTE.DAT available for it? I just don't feel like coding these couple of utility lines right now.

edit+edit2: I mean, the "PALETTE.DAT" without the shade and translucency table of course with the palette from the picture, but the original shade and translucency tables, so that I can load it into Mapster32 and re-run shadexfog.create0 on it. Yes, I'm really, really a bit lazy here...
edit3: To be exact, I also mean "around the dotted lines of the linear ramp, but starting at the color of the other palette". Sorry for the sloppy wording in this post, I hope you can "fill in the gaps" by now.

[Fox]

I checked it, and I couldn't find any old screenshot with a different palette. I figured out the palette I was thinking of was from this picture, which I don't know where it came from:



The most notable difference is that the darkest shade for colors like red or blue is not pitch black like the final version.

[Hendricks266]

I extracted the .pal from this image using IrfanView, and I used bsuite to insert it into a PALETTE.DAT. http://hendricks266....ke3d_unk_proto/

Here's LameDuke's: http://hendricks266....uke3d_lameduke/

I would add Redneck Rampage and PaintBrawl but I don't have the data for those with me at the moment. IIRC at least RR uses the same color arrangement but different specific color values.

[Fox]

Is it possible to make the Pistol / Expander auto-aim accuracy adjustable with ANGRANGE or ZRANGE? Right now there is no way to modify that behavior.

[TerminX]

They have a weapon flag set on them to change the autoaim behavior, unset the flag and they should act like regular weapons.

[Fox]

enum weaponflags_t {
    WEAPON_SPAWNTYPE1           = 0x00000000, // just spawn
    WEAPON_HOLSTER_CLEARS_CLIP  = 0x00000001, // 'holstering' clears the current clip
    WEAPON_GLOWS                = 0x00000002, // weapon 'glows' (shrinker and grower)
    WEAPON_AUTOMATIC            = 0x00000004, // automatic fire (continues while 'fire' is held down
    WEAPON_FIREEVERYOTHER       = 0x00000008, // during 'hold time' fire every frame
    WEAPON_FIREEVERYTHIRD       = 0x00000010, // during 'hold time' fire every third frame
    WEAPON_RANDOMRESTART        = 0x00000020, // restart for automatic is 'randomized' by RND 3
    WEAPON_AMMOPERSHOT          = 0x00000040, // uses ammo for each shot (for automatic)
    WEAPON_BOMB_TRIGGER         = 0x00000080, // weapon is the 'bomb' trigger
    WEAPON_NOVISIBLE            = 0x00000100, // weapon use does not cause user to become 'visible'
    WEAPON_THROWIT              = 0x00000200, // weapon 'throws' the 'shoots' item...
    WEAPON_CHECKATRELOAD        = 0x00000400, // check weapon availability at 'reload' time
    WEAPON_STANDSTILL           = 0x00000800, // player stops jumping before actual fire (like tripbomb in duke)
    WEAPON_SPAWNTYPE2           = 0x00001000, // spawn like shotgun shells
    WEAPON_SPAWNTYPE3           = 0x00002000, // spawn like chaingun shells
    WEAPON_SEMIAUTO             = 0x00004000, // cancel button press after each shot
    WEAPON_RELOAD_TIMING        = 0x00008000, // special casing for pistol reload sounds
    WEAPON_RESET                = 0x00010000  // cycle weapon back to frame 1 if fire is held, 0 if not
};

[Helixhorned]

Fox, on 04 January 2014 - 06:58 AM, said:

Is it possible to make the Pistol / Expander auto-aim accuracy adjustable with ANGRANGE or ZRANGE? Right now there is no way to modify that behavior.

What kind of modification do you have in mind? You can now have arbitrary values for these two, where formerly you were forced to used powers of two. How to disable spead follows from this commit message:

r3715 said:

Generalize ZRANGE and ANGRANGE to accept any nonnegative number.

Numbers 0 and 1 mean 'no spread', but the latter does one krand() call.
Negative numbers are reserved for potential future use.

It's the projectile flags that toggle this behavior: PROJECTILE_ACCURATE has to be unset to enable spreading.

If you want to research this in detail yourself, player.c:P_PreFireHitscan() is a good starting point.

[Helixhorned]

Hendricks266, on 03 January 2014 - 08:14 AM, said:

I extracted the .pal from this image using IrfanView, and I used bsuite to insert it into a PALETTE.DAT. http://hendricks266....ke3d_unk_proto/

Doesn't look as if it's been extracted properly. Open it with a hex editor -- you'll only see values 0xC, 0xD and 0xE.

I'm done with attempting to recreate the base shade table for now though. My guess is that maybe the software they did the art with had that capability in some form.

[DavoX]

This question has nothing to do with anything but is it possible to keep a single zip file for all the necesary items to run eduke32 and mapster32 on the synthesis page? I've recently checked and mapster32 is on one file and eduke32 is on another... it's pretty confusing now.

[Fox]

Helixhorned, on 05 January 2014 - 05:53 AM, said:

What kind of modification do you have in mind?

To be specific, I want to remove Eduke32 specific behavior regarding the Pistol / Expander accuracy when auto-aim is off for Duke 64. But it's not that important (since I probably would make it an option anyway).

[Fox]

Would it be asking too much to disable that unfinished 2 player split screen code for now?

[Hendricks266]

Fox, on 05 January 2014 - 02:21 PM, said:

Would it be asking too much to disable that unfinished 2 player split screen code for now?

What specifically do you need changed? Any hacks in the code that make life easier for splitscr.con while making life harder for normal mods should be chainsawed. I personally would rather see proper splitscreen done internally (which is a tall order), but I don't mind hacking around some things as long as it's transparent.

IIRC there was something about co-opting the fake multiplayer mode specifically for splitscr.con. That's no good.

[Fox]

I don't know, it's just that a second HUD and weapon is displayed by default with another player, even if I am not using splitscr.con.

[Helixhorned]

Fox, on 05 January 2014 - 03:32 PM, said:

I don't know, it's just that a second HUD and weapon is displayed by default with another player, even if I am not using splitscr.con.

Isn't that conditional on the use of the -q (fake multimode) flag? I assumed that it's not useful for anything than splitscreen at this moment, but I can see how it's in the way of coding your own Duke bots.

[Fox]

I don't know, I am just using bots to test some features.

Based on the name, I assume DISPLAYREST is called when all in-game screen code is done, right? Is it possible to include an event that does the opposite, i.e. is called before any in-game screen code? DISPLAYROOMS is not far doing that, but it doesn't run it some cases (i.e. with automap).