This requires one tweak in drawrooms' umost/dmost setup to prevent oob access.
Specifically, a coordinate difference of 0 is allowed. In the classic renderer,
this would mean a one-pixel (real screen coords) height or width. In Polymost,
it would currently mean a one-pixel height and zero-pixel width, but this might
be subject to change.
git-svn-id: https://svn.eduke32.com/eduke32@2574 1a8010ca-5511-0410-912e-c29ae57300e0
The showview command transforms the 320-based screen bound coordinates to the real
screen bounds like xreal = (x*xdim)/320, which shows a bias towards zero: for
example, for a 1680 screen width, the maximum permissible value 319 is mapped to
round_to_zero((319*1680)/320) == 1674. (The rounding is implicit in the integer
division). This makes it impossible for a view to cover the whole screen with any
other resolution than 320x200. The new command transforms the bounds like
xreal = (x*(xdim-1))/319, which would map 319 to 1679 in the preceding example.
git-svn-id: https://svn.eduke32.com/eduke32@2573 1a8010ca-5511-0410-912e-c29ae57300e0
(That is, the base shade table.) Before, we allocated each palookup buffer.
For a vanilla setup, this means that we're now saving 224*32*256 ~= 1.8 megs,
which might be interesting for low-memory gadgets.
git-svn-id: https://svn.eduke32.com/eduke32@2571 1a8010ca-5511-0410-912e-c29ae57300e0
First, it's unlikely in our day and age. Second, they're always free'd at the end,
so allocache'ing them is incorrect.
git-svn-id: https://svn.eduke32.com/eduke32@2570 1a8010ca-5511-0410-912e-c29ae57300e0
Also,
- use this in game.c and astub.c palookup loading code
- when makepalookup() is passed a 0 palnum, return early. This means that
'fogpal' will silently fail when attempting to change pal 0.
- in 'makepalookup' DEF command, error out if passed a pal of 0.
git-svn-id: https://svn.eduke32.com/eduke32@2569 1a8010ca-5511-0410-912e-c29ae57300e0
The syntax is as follows:
makepalookup { <token-list...> }
where valid tokens are
* pal <palnum>: the palette number, 1 .. 250
* red <num>, green, blue (or r, g, b): the fog color components on a 0 to 63 scale.
Components that are not present are assumed to be 0.
* remappal <palnum>: the palette number to take the index remapping from, i.e. 21
for blue -> red. When absent, defaults to 0.
* remapself: when present, specifies that the remappal is the same as the 'pal'.
This is to prevent textual redundancy when overwriting existing palookups.
Examples (best tested with tile #251):
1) makepalookup { pal 200 red 30 remappal 23 }
This creates palookup 200 with a fog of (30,0,0) and a blue-to-yellow remapping
(assuming it has not been changed before)
2) makepalookup { pal 21 red 30 remapself }
This 'fogifies' palookup 21 with a red fog.
3) makepalookup { pal 21 red 30 }
This overwrites palookup 21 with a red fog, but clears the blue-to-red remapping.
The fog aspect of this command affects the GL modes just like 'fogpal', but the
remapping has no effect for hightiles.
- Also, silently clamp 'fogpal' r,g,b values to the range 0 .. 63.
git-svn-id: https://svn.eduke32.com/eduke32@2568 1a8010ca-5511-0410-912e-c29ae57300e0
Instead of drawing the rooms and masks with the classic renderer once.
The captured scene is transformed to use the base palette, so that the
screenshot will also show up in classic. No aspect correction is done.
git-svn-id: https://svn.eduke32.com/eduke32@2567 1a8010ca-5511-0410-912e-c29ae57300e0
The primary change is that things have been made memory-clean. Some of these
pointers may point to wildly different places during the course of the program
such as statically or dynamically allocated storage, the buffer returned by
getenv() (which must not be modified according to the docs), or an element of
argv[]. Consequently, we need to strdup, or better, dup_filename them if they
are ever to be passed to a function that modifies their pointed-to data.
Specifically:
- added statics or consts according to usage
- 3 new functions clear{Grp,Def,Script}NamePtr, only 'Def' one extern for now
- in G_CheckCommandLine, don't strip 'const'; use Bstrncpyz where appropriate
- remove multiple declarations
Also, warn if an application parameter has been ignored (not matched).
git-svn-id: https://svn.eduke32.com/eduke32@2561 1a8010ca-5511-0410-912e-c29ae57300e0
It allocates a buffer of size BMAX_PATH and copies the passed string into it.
git-svn-id: https://svn.eduke32.com/eduke32@2560 1a8010ca-5511-0410-912e-c29ae57300e0
This additionally fixes leaks that were caused by traversing the file name
list with the 'findfiles' pointer and not clearing them afterwards (even if
there was a handle to the list head via 'findfileshigh').
git-svn-id: https://svn.eduke32.com/eduke32@2557 1a8010ca-5511-0410-912e-c29ae57300e0
Don't actually replace the instances in the code now.
Additions in common.h:
- fnlist_t, which combines CACHE1D_FIND_REC *finddirs, *findfiles and
int32_t numdirs, numfiles
- the FNLIST_INITIALIZER macro, which MUST be used for automatic variables
- fnlist_clearnames, fnlist_getnames functions
- G_LoadGroupsInDir, G_DoAutoload, two often-occurring uses of these
git-svn-id: https://svn.eduke32.com/eduke32@2555 1a8010ca-5511-0410-912e-c29ae57300e0
Alongside, these make into into the header:
- the 'tokenlist' type (a typedef'd struct)
- the T_EOF and T_ERROR enumeration values
git-svn-id: https://svn.eduke32.com/eduke32@2549 1a8010ca-5511-0410-912e-c29ae57300e0
These are for LLVM bitcode, I think. In any case, they're giving me errors.
git-svn-id: https://svn.eduke32.com/eduke32@2544 1a8010ca-5511-0410-912e-c29ae57300e0
As inauguration, move G_AddGroup, G_AddPath and struct strllist there.
The header is located in build/include, because in the future, code that resides
closer to (but is not strictly part of) the engine might need to be factored
into here. The source file, however, is in the source/ directory.
git-svn-id: https://svn.eduke32.com/eduke32@2542 1a8010ca-5511-0410-912e-c29ae57300e0
- Help window text cleaned and made more consistent between game and editor
- Added help entry for "-clipmap"
- Log text for using CON, DEF, and RTS files has been made consistent
- All instances of '%s' have been replaced with \"%s\" because ' is a valid filename character. (At least on Windows.)
git-svn-id: https://svn.eduke32.com/eduke32@2538 1a8010ca-5511-0410-912e-c29ae57300e0
This was broken ever since updatesprite() had been forked off drawsprite() and
would cause static lights to never hit static sprites until one or the other
changed, after which the light would always get culled against outdated sprite
geometry.
git-svn-id: https://svn.eduke32.com/eduke32@2536 1a8010ca-5511-0410-912e-c29ae57300e0
Since updatesprite() only happens once for static sprites, avoiding
light culling if we hit it in a shadow pass means that sprite will
never be lit as long as that happens.
git-svn-id: https://svn.eduke32.com/eduke32@2535 1a8010ca-5511-0410-912e-c29ae57300e0
There are instances where oob picnums may propagate to that function, so
protect it. The digitanumber[z] bound check is actually made more permissive,
but could also just as well be removed now.
git-svn-id: https://svn.eduke32.com/eduke32@2533 1a8010ca-5511-0410-912e-c29ae57300e0
The code in the editor was potentially doing a strcat on a strdup'd string.
Also, rename AddGamePath to G_AddPath in astub.c and add CODEDUP markers
because shared stuff like this ought to be factored out into a separate
source file some time.
git-svn-id: https://svn.eduke32.com/eduke32@2531 1a8010ca-5511-0410-912e-c29ae57300e0
Skill names are defined via 'defineskillname' as before, but the index
of the last non-empty skill name (plus one) is taken as the skill count.
So, if you only define the 6th, there will be no effect.
Note that currently, there is no way to specify less than four skills
because the CON parser doesn't allow the empty string for the name (it'll
go beyond the line) and because the default skill names are initialized in
EDuke32 too, in addition to the CONs.
git-svn-id: https://svn.eduke32.com/eduke32@2530 1a8010ca-5511-0410-912e-c29ae57300e0
This makes the differences in these codes stand out much more clearly.
git-svn-id: https://svn.eduke32.com/eduke32@2526 1a8010ca-5511-0410-912e-c29ae57300e0
The nofloorpalrange beginning and end indices are silently clamped to 1 .. 255.
git-svn-id: https://svn.eduke32.com/eduke32@2524 1a8010ca-5511-0410-912e-c29ae57300e0
- Fix typo, correctly adding SDL libs to the tools on OS X so that makesdlkeytrans builds.
- Move all mention of $(LIBS) out of build/Makefile into build/Makefile.shared because no linking takes place in the engine itself so LIBS additions were lost. This should fix USE_LIBPNG=1 on Windows at least.
- Other assorted cleanup.
git-svn-id: https://svn.eduke32.com/eduke32@2523 1a8010ca-5511-0410-912e-c29ae57300e0
- Fix up and add building instructions for kmd2tool, getdxdidf, and makesdlkeytrans.
- Add kmd2tool to "utils" build job.
- Fix warning in and cross-platform building of generateicon.
- Source and text cleanup!
git-svn-id: https://svn.eduke32.com/eduke32@2521 1a8010ca-5511-0410-912e-c29ae57300e0
- Properly handle the architecture definition when BUILD32_ON_64=1
- Add proper $(*LDFLAGS) to which LTO and ARCH are correctly passed.
- Cleanup of compiler flag variables.
This should fix to some degree building of the Build tools on OS X, and it may possibly fix the crashing of the OS X x86 32-bit build.
git-svn-id: https://svn.eduke32.com/eduke32@2520 1a8010ca-5511-0410-912e-c29ae57300e0
It has always annoyed me how floors with "shirt-color" type palookups like 21
affected the color of its containing sprites and HUD-drawn stuff. This commit
allows one to specify an inclusive range of pals for which this should be
disabled for sprites (but not for HUD stuff, yet).
git-svn-id: https://svn.eduke32.com/eduke32@2517 1a8010ca-5511-0410-912e-c29ae57300e0
An effect is only really seen in the buildtools written in C++, currently just arttool.
This is mainly of interest to distributors of the buildtools to avoid missing DLL errors.
git-svn-id: https://svn.eduke32.com/eduke32@2507 1a8010ca-5511-0410-912e-c29ae57300e0
We shouldn't assume a particular bytes-per-line value and use ylookup[] instead.
Specifically, windowed modes on Windows use a frame buffer that always has odd
x dimension.
git-svn-id: https://svn.eduke32.com/eduke32@2505 1a8010ca-5511-0410-912e-c29ae57300e0
- replace bit tweaking for big endian archs with clear code
- allow palette lookups >= 128, previously we read into a signed byte
git-svn-id: https://svn.eduke32.com/eduke32@2503 1a8010ca-5511-0410-912e-c29ae57300e0
- in Mapster, pre-form the default 10 clip map names before returning from
G_CheckCommandLine() so it gets loaded even if we passed no cmdline args.
- malloc + strlen + strcpy --> strdup
- don't need to spank dead variables ;)
- we may call calloc with zero size, which isn't bad by itself, but asserting
for non-null afterwards is. Allocs of 0 are implementation-defined, and may
well return a null pointer (C99 7.20.3).
git-svn-id: https://svn.eduke32.com/eduke32@2502 1a8010ca-5511-0410-912e-c29ae57300e0
Gives a couple more fps for scenes where much screen estate is covered by
stuff, like when holding the devastator.
git-svn-id: https://svn.eduke32.com/eduke32@2499 1a8010ca-5511-0410-912e-c29ae57300e0
With the same setup as before, a screen-filling translucent wall (with nothing
drawn behind it) renders at about 7 fps faster (from 60-something fps initially)
git-svn-id: https://svn.eduke32.com/eduke32@2498 1a8010ca-5511-0410-912e-c29ae57300e0
These two functions draw a vertical line 4 neighboring pixels at a time.
This gives a significant speed boost for a full screen solid and masked wall
scene for x86_64 (where we have plenty of registers), about 60 --> 76 fps.
git-svn-id: https://svn.eduke32.com/eduke32@2497 1a8010ca-5511-0410-912e-c29ae57300e0
Also, a very minor change in the con/def module code. (int --> int32_t)
git-svn-id: https://svn.eduke32.com/eduke32@2495 1a8010ca-5511-0410-912e-c29ae57300e0
A run of consecutive mapstates may share sector/wall/sprite blocks, but
the code was deciding whether to free them solely on local properties.
Now, save a reference count at the beginning of each such allocated block
and free it only if it reaches zero.
git-svn-id: https://svn.eduke32.com/eduke32@2492 1a8010ca-5511-0410-912e-c29ae57300e0
Also, always print at least level 5 corruptions (that is, have no instances
of completely silent corruptcheck).
git-svn-id: https://svn.eduke32.com/eduke32@2490 1a8010ca-5511-0410-912e-c29ae57300e0
This checks for about every possible type of sprite list corruption and
reports back with a corruption level 5 if one of the 14 validations fail.
git-svn-id: https://svn.eduke32.com/eduke32@2489 1a8010ca-5511-0410-912e-c29ae57300e0
- start scrolling from about half of the visible page
- PGUP/DGDN moves the cursor by 1/4 of the page
- code cleanup (we only need one displine[80], use clearkeys())
git-svn-id: https://svn.eduke32.com/eduke32@2488 1a8010ca-5511-0410-912e-c29ae57300e0
- Make all arguments explicit toggles (except for onlyzip).
- Disable PowerPC builds by default on Snow Leopard in addition to Lion.
- Enable Darwin 9 compatibility for all builds whenever PowerPC is enabled.
git-svn-id: https://svn.eduke32.com/eduke32@2487 1a8010ca-5511-0410-912e-c29ae57300e0
Note the capitalization. I hope that this makes clashes with user variable
names less likely.
git-svn-id: https://svn.eduke32.com/eduke32@2484 1a8010ca-5511-0410-912e-c29ae57300e0
Also include one comment about a currently failing assertion there.
git-svn-id: https://svn.eduke32.com/eduke32@2482 1a8010ca-5511-0410-912e-c29ae57300e0
Previously, if the sprite turned really out to be in void space, either freelist
inconsistency (before the list rewrite) or oob access (now) would happen.
Also add an bound-checking assert() for insertsprite's sectnum argument (it's not
a bound check!)
git-svn-id: https://svn.eduke32.com/eduke32@2480 1a8010ca-5511-0410-912e-c29ae57300e0
New engine variable 'int32_t Numsprites', not yet saved into savegames
or mapstates. (The capitalization is to distinguish it from the often-used
'numsprites' locals or structure member names.
In the editor, get rid of updatenumsprites().
git-svn-id: https://svn.eduke32.com/eduke32@2478 1a8010ca-5511-0410-912e-c29ae57300e0
Previously, the lists starting at headspritestat[MAXSTATUS] and
headspritesect[MAXSECTORS] were both used as sprite freelists and were always
in complete synchrony. Now, make only the statnum list keep the free sprites.
This way, it has no CON compatibility implications because
headspritesect[MAXSECTORS] is inaccessible there. Leave the array at its
original size for now.
git-svn-id: https://svn.eduke32.com/eduke32@2477 1a8010ca-5511-0410-912e-c29ae57300e0
