Notes:
- Atomic Edition (Censored) -> Plutonium Pak in grpscan.c
- "scale" in astub.c:drawtileinfo() is incorrect, I think.
- in demo.c, the gethitickms() value should be returned to a double.
git-svn-id: https://svn.eduke32.com/eduke32@3178 1a8010ca-5511-0410-912e-c29ae57300e0
NOTE: changes such as these are best viewed with something like
git diff (...) --color-words='[a-zA-Z0-9_]+|[^[:space:]]'
git-svn-id: https://svn.eduke32.com/eduke32@3176 1a8010ca-5511-0410-912e-c29ae57300e0
Note the type change of vplce[] in engine.c: int32_t -> uint32_t.
git-svn-id: https://svn.eduke32.com/eduke32@3172 1a8010ca-5511-0410-912e-c29ae57300e0
This reverts r3159..r3161.
Conflicts:
eduke32/build/include/compat.h
(Handled so that r3163's changes are kept applied.)
git-svn-id: https://svn.eduke32.com/eduke32@3165 1a8010ca-5511-0410-912e-c29ae57300e0
I think there's also a fix for the CON precache system breakage in here (lost it in my local tree when I started getting the C++ build working in MSVC, sorry!)
git-svn-id: https://svn.eduke32.com/eduke32@3159 1a8010ca-5511-0410-912e-c29ae57300e0
On the engine side (functions starting with L_), there are now the basic
parts like state creation and running code from strings and files.
The game and editor can add to that by e.g. loading whatever they please
into the state. Their functions start with El_ and Em_, respectively.
The Lua scripts still reside in source/lunatic, even for the common ones.
This is because they will be embedded into the binaries as bytecode or
compressed source eventually, so their location on disk will be irrelevant.
git-svn-id: https://svn.eduke32.com/eduke32@3148 1a8010ca-5511-0410-912e-c29ae57300e0
Also, reorganize some G_DrawRooms() code a little without changing anything.
git-svn-id: https://svn.eduke32.com/eduke32@3143 1a8010ca-5511-0410-912e-c29ae57300e0
arrays; any write access to them will run the corresponding hook and write
to the [sector/wall/sprite/tsprite]clean array.
Note: tsprite and sprite use the same hook and require running a few more
instructions per access in order to disambiguiate; this could be made more
optimal (like the other arrays) by clearly separating the types in the game
code.
Note #2: taking a member's address currently marks it dirty because of tons
of helper functions across the editor code. I don't know how many read-only
accesses we have after taking a member address, but it could also be fixed
with some finessing of the code.
git-svn-id: https://svn.eduke32.com/eduke32@3138 1a8010ca-5511-0410-912e-c29ae57300e0
That section was only ever read in for little profit and never written
out! Keyboard input is actually dispatched as OSD commands for a good
while, so that old cruft has to go!
git-svn-id: https://svn.eduke32.com/eduke32@3125 1a8010ca-5511-0410-912e-c29ae57300e0
Credit to Plagman for the idea and doing the work on the game side, which is included in this commit.
(Building as C++ will give us features with which we can make improvements and optimizations on the multiplayer code and Polymer.)
git-svn-id: https://svn.eduke32.com/eduke32@3116 1a8010ca-5511-0410-912e-c29ae57300e0
Submersion only happens when the upper sector has lotag 1 and its vertical
neighbor has lotag 2 (this can be useful to create non-submergible above-water
sectors). Currently, only the player is handled. On the implementation side,
the water handling code is split into P_Submerge() and P_Emerge() preparing the
"teleportation", and P_FinishWaterChange() for the finalization.
git-svn-id: https://svn.eduke32.com/eduke32@3072 1a8010ca-5511-0410-912e-c29ae57300e0
Hendricks found a bug caused by that commit, so this one enables exprimentation
with setbrightness() bit 1 behavior.
git-svn-id: https://svn.eduke32.com/eduke32@3025 1a8010ca-5511-0410-912e-c29ae57300e0
See the comment in source/osdcmds.c for instructions on its usage.
git-svn-id: https://svn.eduke32.com/eduke32@3021 1a8010ca-5511-0410-912e-c29ae57300e0
Specifically, use the elevator's own ceiling z height instead of searching
nextsectors with nextsectorneighborz(). This makes maps like L9.map (Spaceport
from N64) or DEMOUNT.MAP work. [Note well: work at all, since if it happened
to work before, that was pure coincidence.]
git-svn-id: https://svn.eduke32.com/eduke32@3013 1a8010ca-5511-0410-912e-c29ae57300e0
- duke3d.h: comment the timing marcos a bit more
- factor out smoothratio calculation
- (TICRATE/TICSPERFRAME) --> REALGAMETICSPERSEC
git-svn-id: https://svn.eduke32.com/eduke32@3007 1a8010ca-5511-0410-912e-c29ae57300e0
A new function maybe_append_ext() is added to common.c and used in the handling
of the -d<demo.edm> cmdline parameter and the 'map' OSD command with one
non-wildcard arg. (It's slightly different from the way the extension was
maybe-appended previously.)
git-svn-id: https://svn.eduke32.com/eduke32@3004 1a8010ca-5511-0410-912e-c29ae57300e0
This currently says that MP saving/loading isn't supported, but doesn't
really work correctly. Also, properly bound-check the immediate argument
to CON's 'save' command and one more ... -> G_HandleAsync().
git-svn-id: https://svn.eduke32.com/eduke32@2999 1a8010ca-5511-0410-912e-c29ae57300e0
A macro MAYBE_FCLOSE_AND_NULL(fileptr) is introduced in compat.h that does
what it says.
git-svn-id: https://svn.eduke32.com/eduke32@2995 1a8010ca-5511-0410-912e-c29ae57300e0
The spawn-time SE 17 setup uses nextsectorneighborz() which can fail
(return -1) on some circumstances and would cause an OOB sector[] access.
git-svn-id: https://svn.eduke32.com/eduke32@2971 1a8010ca-5511-0410-912e-c29ae57300e0
Basically, base palettes with lower indices trump higher ones. For example,
when one player is underwater and the other above, the normal palette takes
precedence.
git-svn-id: https://svn.eduke32.com/eduke32@2955 1a8010ca-5511-0410-912e-c29ae57300e0
Currently, the only kinds of tint that can be applied simultaneously are
one "palfrom" per player, plus one loogie tint per player. Each palfrom
still overrides the preceding one. However, this is not a big problem IMO
since palfroms decrease at the same rate (loogie tint decreases at half the
speed). This change is especially good for the splitscreen mod, since now
the tints of the two players won't compete with each other. See the comment
in the source for some properties of the blending formula.
git-svn-id: https://svn.eduke32.com/eduke32@2954 1a8010ca-5511-0410-912e-c29ae57300e0
A debug macro to test tints being stuck at the least intense non-zero value
is provided in engine.c.
git-svn-id: https://svn.eduke32.com/eduke32@2952 1a8010ca-5511-0410-912e-c29ae57300e0
