[Added (as new branch)] 3D floors ... again (impossible comes true)

[Graf Zahl]

Something like that. The code is close to incomprehensible and I got enough of that to deal with at work so I know it's not fun.

[kgsws-CZ]

Here, i made some changes in code.
- added new cvar, r_3dfloors for testing, you can see FPS difference for example
- fixed this bug
- fixed particles visible trough 3D floors
- fixed FAKE3D flag names

[randi]

Thanks for the patch, though it was really troublesome for some reason.

• It wasn't made with SVN, so TortoiseSVN didn't like it.
• It made my command-line patch program on Windows crash.
• The Linux patch rejected almost every chunk.

So in the end, I had to apply it by hand.

[Edward-san]

Yeah, to make work the patch in linux I had to change the .diff adding the "^M" characters at the end of every line where there was the reject...

BTW: Randy, I've used the 3dfloors3 build, it's amazing how the fps increased!
A question: do you need crash logs generated from this build?

[edit]uh, it didn't compile, as pointed by Gez :\

[Gez]

So in the end, I had to apply it by hand.

And I can't compile the result, so I made this:

[Graf Zahl]

Patches like this one are the reason why I reject any submission I found that can't be applied directly with TortoiseSVN. The generally available patch tools are just too troublesome as this clearly shows. And why is it so hard to write text processing tools that can deal with mixed line ending styles?

[kgsws-CZ]

I don't understand, i always used this way to make patches. Was it always problem to work with my patches?

[Edward-san]

I wonder if you recently updated the patcher program ... which could break something...

[Bio Hazard]

why is it so hard to write text processing tools that can deal with mixed line ending styles?

Code: Select all • Expand view

$ svn propset svn:eol-style native $FILE

SVN will checkout $FILE with '\n' on Linux, "\r\n" on Windows, automatically convert when committing, convert when patching, everything. It basically solves the line-ending problems. I don't understand why it's not set on text files by default.

You can even have SVN automatically set the property on new files with this quick and easy config stuff:

Spoiler: "Bio's ~/.subversion/config"

Code: Select all • Expand view

[auto-props]
# Basic text files
LICENSE   = svn:eol-style=native
*.txt     = svn:eol-style=native
*.conf    = svn:eol-style=native
*.example = svn:eol-style=native

# Programming
*.c       = svn:eol-style=native
*.h       = svn:eol-style=native
*.cpp     = svn:eol-style=native
*.hpp     = svn:eol-style=native
makefile  = svn:eol-style=native

# Web pages
*.html    = svn:eol-style=native
*.htm     = svn:eol-style=native
*.css     = svn:eol-style=native
*.php     = svn:eol-style=native
*.sql     = svn:eol-style=native
*.js      = svn:eol-style=native

[Graf Zahl]

I guess it's off because it's a destructive option by its very nature and I know tools that get hopelessly confused if stuff can get changed that way.

It's also only a pathetic workaround for some Unix tools' shortcomings. In all the years I've been working with Windows I only encountered 2 tools that had problems with line endings:

Notepad and patch.exe.

[Bio Hazard]

I guess it's off because it's a destructive option by its very nature

What do you mean destructive? Having SVN handle the line endings automatically leads to fewer whitespace-only commits, wouldn't that be a good thing?
I suppose it would make a digest hash on the checked-out source fail, but I don't see any reason anyone would make the hash of a specific SVN source tree matter. Maybe for tags I guess, if for some reason the line endings are somehow critical to the build process. (o.O)

I know tools that get hopelessly confused if stuff can get changed that way.

How could the tools get confused? eol-style:native makes the line endings consistent for the system you're using specifically to avoid getting your tools confused. I would be curious to see an example of where using the system's native line endings causes a problem.


Not even going to touch the bait on that second line.

[Graf Zahl]

Anything that alters a file without asking is destructive, even if it's just line endings. A tool is just that: a dumb piece of software that just does what it's told. How can it know that maybe, just maybe, some of these files need to be processed in a way that things like line endings are preserved - maybe a checksum tool or who knows what. So logically SVN is set to keep stuff intact unless you explicitly tell it not to do.

Also what bait? I just listed the only 2 programs I had ever problems with when it comes to line endings in a text file. Granted, Notepad is garbage regardless of this issue but it completely puzzles me how someone could write a stdio-based command line tool that can't read Unix style text files on Windows without puking all over the place.

[randi]

Yeah, to make work the patch in linux I had to change the .diff adding the "^M" characters at the end of every line where there was the reject...

I tried that, but it didn't make a difference for me. Patch still rejected them.

A question: do you need crash logs generated from this [3dfloors3] build?

Not yet. I kind of wish I was moving faster with it, but since I'm dividing my free time between ZDoom and learning Japanese (and whatever else I may feel like doing at the time), learning Japanese usually wins the larger share of time.

[Bio Hazard]

How can it know that maybe, just maybe, some of these files need to be processed in a way that things like line endings are preserved - maybe a checksum tool or who knows what. So logically SVN is set to keep stuff intact unless you explicitly tell it not to do.

Fair enough, I understand why it's not the default. It still solves a ton of problems for files that don't need a specific encoding.

Also what bait?

My inner elitist 'nix snob was refuting your claim that Unix tools have shortcomings (*gasp*). I was just playing with you.
(Probably should have made it more obvious, you know, 'cause you're a Windows user. )

[randi]

Well, I've never seen this error before:

Error: While preparing 'E:￥zdoom￥trunk￥src￥r_3dfloors.h' for commit
Error: Inconsistent line ending style