- more codegen
- make more members const, some char unsigned
- fix some "geom" metamethods
- '^' operator
git-svn-id: https://svn.eduke32.com/eduke32@3253 1a8010ca-5511-0410-912e-c29ae57300e0
This introduces winbits.[ch] in the engine, containing layer-independent code migrated from winlayer, including nedmalloc, ebacktrace1, OS version detection, and high-resolution profiling timers.
sdlayer has been expanded to include the code from winbits under _WIN32.
All uses of RENDERTYPEWIN in the source have been examined and changed to _WIN32 (or removed) where the block in question is layer-independent.
git-svn-id: https://svn.eduke32.com/eduke32@3221 1a8010ca-5511-0410-912e-c29ae57300e0
This needs improvements to bring it up to par with winlayer, but it is functional. In particular, a good amount of code from winlayer could be used for both layers, including the profiling timers, the version printing code, and the hInstance and hModule sharing.
Known problems: the mouse cursor is not trapped, and the game starts before the startup window shows options.
git-svn-id: https://svn.eduke32.com/eduke32@3219 1a8010ca-5511-0410-912e-c29ae57300e0
The redundant ones are in code like this: s->cstat = (int16_t)32768;
Because the value is eventually converted to the type of "s->cstat", any
casts to integral types having at least as many bits are no-ops, signedness
being irrelevant due to (probably any two's complement arch targeting
compiler's) bit-pattern preserving semantics of these conversions.
The now incorrect one is: if (lotag == (int16_t) 65535),
"int32_t lotag" being read from a wall or sprite struct directly earlier.
Now, with these members being unsigned, and (int16_t)65535 equalling -1,
the check always fails. The correction fixes normal switches having such
a lotag ending the level immediately.
In short: integer casts before assignments are unnecessary, those in reads
highly relevant!
git-svn-id: https://svn.eduke32.com/eduke32@3211 1a8010ca-5511-0410-912e-c29ae57300e0
The size of that struct is currently 4, and its layout almost the same as
what is read in with loadpics(). The number of tiles in an animation is
bumped to 256, so that the max. tile difference in DEF's animtilerange is
255. (There's no way to have such animations from ART.)
git-svn-id: https://svn.eduke32.com/eduke32@3202 1a8010ca-5511-0410-912e-c29ae57300e0
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
