- Rewrite the "clear background" routine in a no-brainer way instead of
juggling around with rotatesprite(). Make it common to game+editor.
Expose glRectd to glbuild.
- Don't stop OSD text line drawing when encountering a non-printable char.
Instead, treat it as space.
- In OSD_SetTextMode(), don't use swaplong (which really swaps 32-bit ints)
to swap pointers. Write an analogous "swapptr" instead.
- When changing from/to OSD, don't inject a pause key. This *might* have been
the cause of the reported pausing problems.
- clean up the code...
(Yes, this commit throws together too much stuff. I suck sometimes. :P)
git-svn-id: https://svn.eduke32.com/eduke32@3321 1a8010ca-5511-0410-912e-c29ae57300e0
Unconditionally enabled, but useful for comparing the behavior of the 1-column
vline functions against the 2- or 4-column ones.
git-svn-id: https://svn.eduke32.com/eduke32@3311 1a8010ca-5511-0410-912e-c29ae57300e0
The former is really only a workaround. Walls/vertical sprites/pskies with
ysize 512 (and presumably greater, but this was not tested) are rendered
with one shade higher at the borders (1 pixel vlines) because of a certain
assumption in the ASM (see comments there). With very dark shades, the
palookup[] buffer is accessed oob. We simply allocate 256 bytes more at the
end for each.
The latter is only for CLASSIC_NONPOW2_YSIZE_WALLS builds, which is not enabled
yet. It seems to matter only for the uncommon case where the such pskies repeat
in the height. A 1680x1050 window fully covered with such a sky is then rendered
at about 60/85 the FPS for me (mostly due to not using the 4 pixel vline
routines), so it may be leaning a bit too much on the side of correctness.
A compilation switch DEBUG_TILESIZY_512 is introduced in engine.c for
demonstration purposes.
git-svn-id: https://svn.eduke32.com/eduke32@3310 1a8010ca-5511-0410-912e-c29ae57300e0
- If aiming at a swapped bottom wall, display "Wall <wallnum> -> <otherwallnum>"
- highlight pic, shade, pal, cstat in yellow then
- in printext256, accept at most 3 digits for the color format string (e.g. ^123)
git-svn-id: https://svn.eduke32.com/eduke32@3308 1a8010ca-5511-0410-912e-c29ae57300e0
Implemented using GL_LINEAR fog. The only source of difference (besides the
obvious indexed vs. true color) should now be the distance constant, which
still had to be determined experimentally. Polymer implements this mode in
its fog fragment program part.
Parallaxed skies are always drawn with full visibility, I'm not sure if there
are any maps that expect otherwise.
Also, accidentally committed: factor out initialization code from
polymost_printext256() into gen_font_glyph_tex(), small game.c changes.
git-svn-id: https://svn.eduke32.com/eduke32@3301 1a8010ca-5511-0410-912e-c29ae57300e0
It was caused by the definition of c_dfDIJoystick using literal 24 and 16 values in place of sizeof(DIDATAFORMAT) and sizeof(DIOBJECTDATAFORMAT), which include pointers. On 64-bit, the values end up being 32 and 24, causing a discrepancy in which DIERR_INVALIDPARAM was thrown.
1b1e05db06/diffs
git-svn-id: https://svn.eduke32.com/eduke32@3300 1a8010ca-5511-0410-912e-c29ae57300e0
This also means that the "r_shadescale_unbounded 0" option will work
in Polymer (except on models).
git-svn-id: https://svn.eduke32.com/eduke32@3286 1a8010ca-5511-0410-912e-c29ae57300e0
This global option will set bit 1024 and clear bits 256 and 512 for all
rotatesprite calls, fixing complex HUD drawing code relying on precise
alignment of individual elements (widescreen rotatesprite is entirely
unsuitable for this purpose).
git-svn-id: https://svn.eduke32.com/eduke32@3284 1a8010ca-5511-0410-912e-c29ae57300e0
This includes a complete Windows header and library refresh, including the addition of 64-bit compiled libs:
*libogg 1.3.0
*libvorbis 1.3.3
*zlib 1.2.7
*libpng 1.5.13
*libvpx 9a3de881c0e681ba1a79a166a86308bbc84b4acd
*SDL_mixer 1.2.12 (for RENDERTYPE=SDL)
*DirectX import libraries: dsound and dxguid (now included)
To build in 64-bit, you essentially need MinGW's MSYS (but not MinGW itself) and MinGW-w64 at the top of your PATH. The target is automatically detected using `$(CC) -dumpmachine`. The EDukeWiki will get detailed instrucitons.
All compiler and linker warnings when building in 64-bit mode have been fixed.
Remaining 64-bit to-do:
- The ebacktrace dll does not build under 64-bit. It uses code specific to the format of 32-bit executables and will have to be ported to work with 64-bit executables. A future 64-bit version will be named ebacktrace1-64.dll.
- RENDERTYPE=SDL crashes in SDL_mixer's Mix_Linked_Version().
- DirectInput gives an error and does not function. This only affects joysticks, and the error never happens without any plugged in.
- Port the classic renderer ASM to 64-bit. (Just kidding, this is way out of my league.)
This commit includes a fair bit of Makefile development spanning all platforms, including simplifying the SDLCONFIG code, fixing build on Mac OS X (thanks rhoenie!), globally factoring Apple brew/port inclusion, enforcing that all -L come before all -l, and ensuring that $(shell ) is always :='d.
In addition, I have resurrected the old GCC_MAJOR and GCC_MINOR detection using `$(CC) -dumpversion`, but I have made it failsafe in case the command fails or the version is manually specified. I have applied this new fine-grained detection where applicable, including allowing LTO, and restraining -W's to versions that support them.
git-svn-id: https://svn.eduke32.com/eduke32@3278 1a8010ca-5511-0410-912e-c29ae57300e0
Set up the use of {Windows,Apple}/{include,lib} regardless of feature toggles in Makefile.common using $(abspath ) in reference to the directory Makefile.common is in.
Add the three DirectX headers that are actually used to the repo. (from: http://alleg.sourceforge.net/files/dx9mgw.zip)
Since current MinGW versions include DirectX libs (for dynamic linking), remove "-L$(DXROOT)/lib".
The DirectX headers are no longer a separate dependency for building.
Add $(SDLROOT_OVERRIDE). $(SDLROOT) only functions for Windows and Mac OS X.
Factor handling of $(DXROOT_OVERRIDE) and $(SDLROOT_OVERRIDE) into Makefile.shared using $(abspath ).
git-svn-id: https://svn.eduke32.com/eduke32@3275 1a8010ca-5511-0410-912e-c29ae57300e0
Also, fix deficient logic in Gv_Free and Gv_Clear (both M32 and CON) so that gamevar and gamearray erasure results are (closer to) correct, and so that the game does not crash when system arrays are accessed from CON because they all have been nulled.
git-svn-id: https://svn.eduke32.com/eduke32@3274 1a8010ca-5511-0410-912e-c29ae57300e0
Commit breaks MSVC builds by failing to provide NOWARN macros to MSVC.
git-svn-id: https://svn.eduke32.com/eduke32@3232 1a8010ca-5511-0410-912e-c29ae57300e0
The attribute is set per tile from DEF: either
nofullbrightrange <begintile> <endtile>
or
tilefromtexture <tile> { ... nofullbright ... }
As a special case, the list may only contain "nofullbright", in which case the
texture is not changed. (This is analogous to "texhitscan".)
Example:
// make piggy's eyes fullbright red only when it fires the shotgun
nofullbrightrange 2000 2034
nofullbrightrange 2040 2049
nofullbrightrange 2055 2061
git-svn-id: https://svn.eduke32.com/eduke32@3230 1a8010ca-5511-0410-912e-c29ae57300e0
The two uses are from hitscan and neartag. The functionality is reproduced
exactly (assuming I made no mistake), down to different distance checking
(<= vs. <).
git-svn-id: https://svn.eduke32.com/eduke32@3228 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
This function also changed: it doesn't handle floor-aligned sprites now,
and the z offset is returned instead of set by pointer.
git-svn-id: https://svn.eduke32.com/eduke32@3205 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
- Eliminate use of the C++ standard library from arttool. I improved some of the program's workings but it continues to corrupt my art files in certain circumstances. (Note: Not a regression; it happens with previous revisions.)
- Construct "make utils" for the game side following the pattern of the engine.
- Move ivfrate to this new distinction.
- Minor Makefile cleanup and tweaks, mainly to facilitate CLANG=1 and to formalize text output in special cases.
git-svn-id: https://svn.eduke32.com/eduke32@3163 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
Specifically, if the first wall of the sector-to-split is to the left or right
of the *start* of the splitting line AND the sector has no TROR extensions,
make these two the new nextwalls of the respective split sectors.
git-svn-id: https://svn.eduke32.com/eduke32@3157 1a8010ca-5511-0410-912e-c29ae57300e0
Exporting only (de)compression functions. Also, different reader/writer
functions can be set.
git-svn-id: https://svn.eduke32.com/eduke32@3153 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, enable showing sprites in Mapster32's overhead view again, since that
was one (the only?) use of that code path. The uninitialized read was
introduced in r2927.
git-svn-id: https://svn.eduke32.com/eduke32@3144 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
separate tracker type by #defining __TRACKER_NAME and __TRACKER_GLOBAL_OFFSET.
eg.:
Then if you have a tracked value and a value of the same type at the given offset:
Tracker_1<int32_t> trackedInt;
int32_t trackedIntDirty = 0; // 4 bytes after
trackedIntDirty will become 1 everytime trackedInt changes.
git-svn-id: https://svn.eduke32.com/eduke32@3119 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
helixhorned
hendricks266
terminx
Plagman