Inuyasha authored 9 years ago and colette committed 9 years ago

... not just lstring though, but the behavior with i that is used elsewhere.

Inuyasha authored 9 years ago and colette committed 9 years ago

This is not how you use pushlstring! This is actually sending uninitialized memory to Lua, which is making scripts have inconsistent results (duh?)

c/o JTE: "Tell Red they're a doofus."

Monster Iestyn authored 9 years ago and colette committed 9 years ago

The point here is ColorOpposite(MAXSKINCOLORS) would have given an actual result of its own since MAXSKINCOLORS & MAXSKINCOLORS is still MAXSKINCOLORS. This shouldn't happen though, as both Color_Opposite[MAXSKINCOLORS*2] and Color_Opposite[MAXSKINCOLOR*2+1] aren't defined.

Inuyasha authored 9 years ago and colette committed 9 years ago

Objectplace reallocates the mapthings list to add one more mapthing. By itself there's no problem with this.
But, mobj->spawnpoint is a pointer to the mapthing's location in the mapthings list.
So by reallocating the mapthings list, all references to mobj->spawnpoints point to freed memory.

... Oops.

Now when objectplace reallocates the mapthings list it actually corrects the locations of all mobj's spawnpoints to point to the new list.

Hooray, you can use NiGHTS objectplace again if you really want to.

If the total file size is above 1MB after writing, discard all changes.

I got lazy and used a weird inefficient method, but I don't know how to clean this mess up :c At least it works.

Also block % in filename strings

Thanks Inu!

This is probably super inefficient. Someone please teach me how2C.

...and remove io.popen(), cause that shit is DANGEROUS.

Note: I/O library is fully functioning in this state, but lacks security restrictions. We'll get to those later ;)

Added missing SHORT macros around these variables, they're needed for big-endian builds to use these properly

...I'm to blame for this particular slipup as it happens, surprise surprise

some of the mess in here really bothers me

From what I can tell, correcting this one value in finetangent[] shouldn't cause any harm at all, so...

Note: polyobj_t's "translucency" is apparently a SIGNED integer, so in theory it's possible to get polyobj flats to use the "spanfunc = splatfunc" line using negative values. If this is not meant to happen, this should probably be fixed asap

Conflicts:
	src/f_wipe.c

I'm surprised how the source code flew in the face of this fact for so long and just used it everywhere, that's just silly.

Conflicts:
	src/f_wipe.c

Since cv_pointlimit is handled in P_CheckPointLimit, I've just created P_CheckTimeLimit for cv_timelimit.

It helps make P_UpdateSpecials less messy-looking anyway.

Actually uses 0 and 65536 now! (and also INT32_MIN)

Fix up lib_finetangent so tan() returns values starting from "0" in Lua (finetangent itself hasn't been touched)

Also fixed how the function went out of the array's bounds for ANGLE_180 and above (or negative angles)

Also makes comptime.bat work with git if able.
Development builds will now show the branch and the SHA1 hash of the revision. Also been tested to work with subversion, where it displays "Subversion r####". You know, just in case.

Monster Iestyn authored 9 years ago and Inuyasha committed 9 years ago

(I won't touch overlays for now)

Monster Iestyn authored 9 years ago and Inuyasha committed 9 years ago

more detailed description: vissprites now store dispoffset in a separate variable from (y)scale, and uses it to influence order between sprites without it affecting the actual drawing of the sprites themselves

The less branches, the better.

Optimization is a bitch, you know.

Fix md2s

shoutouts to MI for breaking them accidentally

I was about to just commit this straight to next but it's the perfect reason of why code review is beneficial and I'd be a hypocrite to point that out and then skip the process

See merge request !28

Not related to Wolfy's problems afaik... this branch seems to be turning into a misc compiling fixes branch now