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
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
- 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
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
The major outside-visible change is that this fixes the sound cutoff bugs that
happened because newly-spawned sprites took the place of those whose sounds
had not yet finished playing.
Besides, there are these changes:
- remove deletesprite{sect,stat}
- we have a new engine variable 'tailspritefree' that keeps track of the
sprite freelist tail
- we need to store it in savegames and mapstates, so bump the savegame
minor version
git-svn-id: https://svn.eduke32.com/eduke32@2470 1a8010ca-5511-0410-912e-c29ae57300e0
This is simply done by using the two list helper functions defined earlier
instead of a deletespriteX/insertspriteX pair.
git-svn-id: https://svn.eduke32.com/eduke32@2469 1a8010ca-5511-0410-912e-c29ae57300e0
Factor out two helper functions, do_deletesprite{sect,stat}
and do_insertsprite_at_headof{sect,stat}.
git-svn-id: https://svn.eduke32.com/eduke32@2466 1a8010ca-5511-0410-912e-c29ae57300e0
These operations aren't executed THAT often to warrant exposing four internal
functions. Besides, I'll be hacking on them and need everything laid out
cleanly. Should somebody complain, they can go change them to __fastcall or
something.
git-svn-id: https://svn.eduke32.com/eduke32@2465 1a8010ca-5511-0410-912e-c29ae57300e0
In changesprite{stat,sect}, don't check for deletesprite{stat,sect} failure,
because the only way it can fail was already checked for above. So, this is
essentially dead code elimination.
git-svn-id: https://svn.eduke32.com/eduke32@2462 1a8010ca-5511-0410-912e-c29ae57300e0
- forgot a glogy --> logy in a-c.c
- comment out stretchhline and slopevlin2 in a.nasm, the former also in a-c.c
- make transmaskvline2 use a uintptr_t where appropriate
git-svn-id: https://svn.eduke32.com/eduke32@2448 1a8010ca-5511-0410-912e-c29ae57300e0
When drawing from inside the mirror, there may be no 'bunches' (BUILD lingo,
not TROR ones) collected, but following code used the first one unconditionally.
git-svn-id: https://svn.eduke32.com/eduke32@2427 1a8010ca-5511-0410-912e-c29ae57300e0
The apparent horizon (in units proportional to pixels by a constant factor)
was being calculated without normalizing to viewingrange, resulting a
discrepancy between the drawn and actual up/down angle with non-default
viewingranges (e.g. with r_usenewaspect=1, or when setting it from setaspect).
This also means that the center-of-aim will now be the same regardless of
the aspect.
This fixes many derived bugs:
* inconsistency w/ crosshair when shooting a gun and aiming up/down (obviously)
* bugs resulting from being able to look up/down too far (garbage non-slope
texture-mapping and viewing BIGORBIT skies above the borders in classic).
Note: mods that had workaround logic for this bug will have to remove it...
git-svn-id: https://svn.eduke32.com/eduke32@2414 1a8010ca-5511-0410-912e-c29ae57300e0
This has no measureable difference. Oh well, maybe it benefits weaker
machines, since the generated loop code should definitely be prettier.
git-svn-id: https://svn.eduke32.com/eduke32@2408 1a8010ca-5511-0410-912e-c29ae57300e0
This doesn't give much, maybe 0.5 fps more, probably because the
loop body is pretty long.
git-svn-id: https://svn.eduke32.com/eduke32@2406 1a8010ca-5511-0410-912e-c29ae57300e0
(Classic renderer). We don't need 64-bit integers; also use the nice
asm version of divscale32() if possible.
git-svn-id: https://svn.eduke32.com/eduke32@2390 1a8010ca-5511-0410-912e-c29ae57300e0
This was discovered because viewscreens (TILE_VIEWSCR) ceased being drawn
with the MAXTILES increase (reported by Hank, who also did the bisect).
git-svn-id: https://svn.eduke32.com/eduke32@2376 1a8010ca-5511-0410-912e-c29ae57300e0
That is, everyplace a user input is to be converted. The only remaining
instance of atoi() is now atoi(s_buildDate).
git-svn-id: https://svn.eduke32.com/eduke32@2374 1a8010ca-5511-0410-912e-c29ae57300e0
Internally, the last argument to neartag is now a pointer to a function
int32_t (*blacklist_sprite_func)(int32_t i),
which is supposed to return 1 if sprite[i] should NOT be considered for hitting.
This is now used in the hard-coded neartag() calls in sector.c, but not in any
way in CON (there's neither a C blacklist function provided, nor is there a
possibility to define one in CON). There, all sprites with picnums >=1 and <=10
(i.e. the effectors) will be blacklisted. This remedies problems where such
sprites would get in the way of switches.
Note that a whitelist approach (only consider a predefined set, namely those
picnums which will be checked afterwards) has back-compatibility implications
since people may have used e.g. lotagged window sprites to cover a switch.
Also, the >=1 to <=10 range is [sic] (the static, not dynamic values are used),
since anyone redefining effector picnums is clearly out of their mind.
git-svn-id: https://svn.eduke32.com/eduke32@2373 1a8010ca-5511-0410-912e-c29ae57300e0
The bulk are whitespace changes; the only exception is a
"if (expr) { stmt; }" --> "if (expr) stmt;"
git-svn-id: https://svn.eduke32.com/eduke32@2353 1a8010ca-5511-0410-912e-c29ae57300e0
The reason was that drawmasks(), which was where the resetting of the fake
RoR textures happened under Polymer, can be called from polymer_displayrooms()
when mirrors are present. I was assuming that drawmasks() was only ever called
after the 'main' drawrooms and that hence the sequence of fake RoR tile tweaking
was set, reset, set, reset, ... which it was not.
Now, do the resetting explicitly after every drawmasks() in the editor.
git-svn-id: https://svn.eduke32.com/eduke32@2350 1a8010ca-5511-0410-912e-c29ae57300e0
I find this cleaner for two reasons. First, lotags won't get in the way of
neartag(), so that doors and switches near constrained TROR walls can be
pushed. Second, this removes the information leak so that CON coders aren't
tempted to read that values directly before a proper API for that comes along.
When writing out a map in-game (e.g. with dndebug), restore the respective
members so that it can be loaded in the editor again.
git-svn-id: https://svn.eduke32.com/eduke32@2349 1a8010ca-5511-0410-912e-c29ae57300e0
