Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

Faster, no (unknown) problems

Faster, problematic

Same speed, no (unknown) problems

Same speed, problematic

Slower, no other (unknown) problems

Slower, problematic

Doesn't work at all

[bombcar]

I cannot move the raw and data directories into the bundle; Toady would have to use NSBundle and CFBundleRef to find them.

Since those folders contain data the user might want to modify they shouldn't go into the bundle anyway. For example, the data folder contains savegames, those really shouldn't be written into the bundle.

Yeah, I know. In a perfect world save files would be written to a location such as %Documents%/DFSave or ~/Documents/DFSave or something; and the init files would be in a location easy to edit; and the build-in raw and data directories could be overridden by directories in the right place.

But that's years down the road.

[Linknoid]

Notice how "x * dimy * 4 + y * 4" is used over and over.  My initial code was full of stuff like that as well.  But probably half my optimization gains came from simply calculating values like that into a local variable ahead of time:

Whatever compiler you're using is amazingly horrible if what you said is indeed true.  Compilers are supposed to do *exactly* what you describe on their own.

Yes, I agree with you that compilers SHOULD optimize it.  I went in assuming it was optimizing those calculations the way you'd expect.  But there's a difference between "should" and "does".  I was using gcc version 3.4.2 (MinGW) with -O3, and simply storing those values myself made a huge speed difference (30 ms per frame drawn down to 20 ms on my hardware).  And yeah, before I did this, I went through and looked for all the -f optimizations that I could reasonably turn on.

I would be curious if other compilers do a better job of optimizing that, but I would no longer assume they are without actually testing it.

[Baughn]

GCC 3.4? How long ago was that?

We're up to 4.4 now, and I assure you, it most definitely does eliminate such common subexpressions.

Well, I'd point you at the opengl code in the git repo, but it's amazingly horrible. Instead, look at renderer_opengl.cpp in the matrix branch of that repo.. er, here: http://github.com/Baughn/Dwarf-Fortress--libgraphics-/tree/matrix/g_src/

Since I'm cleaning it up anyway, you'd better see the cleaned-up code, not what's actually in d19. Please, don't look at what's in d19. 

[Sizik]

I cannot move the raw and data directories into the bundle; Toady would have to use NSBundle and CFBundleRef to find them.

Since those folders contain data the user might want to modify they shouldn't go into the bundle anyway. For example, the data folder contains savegames, those really shouldn't be written into the bundle.

Yeah, I know. In a perfect world save files would be written to a location such as %Documents%/DFSave or ~/Documents/DFSave or something; and the init files would be in a location easy to edit; and the build-in raw and data directories could be overridden by directories in the right place.

But that's years down the road.

Raw files will be stored in the region folders next version, so that's a step in the right direction.

[zxcvmnb]

I cannot move the raw and data directories into the bundle; Toady would have to use NSBundle and CFBundleRef to find them.

Since those folders contain data the user might want to modify they shouldn't go into the bundle anyway. For example, the data folder contains savegames, those really shouldn't be written into the bundle.

Yeah, I know. In a perfect world save files would be written to a location such as %Documents%/DFSave or ~/Documents/DFSave or something; and the init files would be in a location easy to edit; and the build-in raw and data directories could be overridden by directories in the right place.

But that's years down the road.

IMO, it's better to have all the data in one directory. There's currently no need to install/uninstall, it's easy to have multiple versions at once, you only have to look for files in one place and there is no annoying distinction imposed between what the user should and should not modify or copy, it's clear which raws are being used because there aren't copies all over the place and it gives the user a complete and easily effected choice as to where to put the data. Let's not adopt the Microsoft approach and assume that users are too stupid to work out that they need to look in the directory in which the program is installed or lack the initiative to make links to folders that they frequently access. This approach actually disempowers the user by well-nigh forcing them into one, ostensibly "beginner-friendly", way of doing things.

TL;DR: IMO, a bad idea. It wastes as much time as it saves, adds complications and takes control away from the user.

[bombcar]

TL;DR: IMO, a bad idea. It wastes as much time as it saves, adds complications and takes control away from the user.

Done correctly, at least on the Mac, and application bundle's a wonderful thing. People can still poke it with a stick if they wish, but otherwise it appears to be a single file that just works.

[CobaltKobold]

Yes. As for mac keybindings, I expect we'll just ship a different interface.txt for macs - once the format is settled.

(Well, it pretty much is, but you never quite know.)

Can I make a request to ship with an interface.txt for laptops, too? All you need to do is swap the secondary scrolls to []-=, so they're off the numpad.

Why not double-bind them by default so it'll work either way?

[jfs]

Let's not adopt the Microsoft approach and assume that users are too stupid to work out that they need to look in the directory in which the program is installed or lack the initiative to make links to folders that they frequently access.

This is going a bit off-topic, but the issue is not that users are "too dumb" to look there. The issue is that software is generally installed in locations that should be considered read-only.
On both Windows and Unix systems (including Mac OS X), the system-wide installation locations for software are only writeable by administrator users, a regular, limited user account doesn't have write access to them. It's both an issue with multi-user systems (such as a computer shared between three members of a family) to avoid mixing different users' data, but also an issue with security/safety, to prevent program files from being changed unwittingly.
In the specific case of Mac OS X, if you have digitally signed software, an entire application bundle is signed as one unit, and changing any one file inside a signed bundle invalidates the signature of the entire bundle: The bundle should be considered one immutable file for most purposes. The same thing applies (should apply) to other program installations.
However, "portable" software is a different issue. Portable as in, software you can carry with you on a removable medium. Dwarf Fortress is designed in the portable model, which happens to be mostly the same model that almost all PC games before the advent of Windows XP used.

In short, there's two good reasons to keep user data separate from program code: It makes it possible to better tamper-proof the code, and it lets many users share one copy of the code without sharing their data.

[Baughn]

jfs is absolutely correct, and making DF properly installable is something that will be done after not too long.

That aside. Does anyone use PARTIAL:N, for N>0?
I rather suspect the answer is yes, but I'd like to know. And please, one "yes" will suffice.

[Andir]

That aside. Does anyone use PARTIAL:N, for N>0?
I rather suspect the answer is yes, but I'd like to know. And please, one "yes" will suffice.

How many "No"s do you want?

[snooptodd]

New minor issue.
http://github.com/Baughn/Dwarf-Fortress--libgraphics-/issues#issue/30

I was unable to load a macro created in windows with the Linux version until I converted it to unix

[zxcvmnb]

Let's not adopt the Microsoft approach and assume that users are too stupid to work out that they need to look in the directory in which the program is installed or lack the initiative to make links to folders that they frequently access.

This is going a bit off-topic, but the issue is not that users are "too dumb" to look there. The issue is that software is generally installed in locations that should be considered read-only.
On both Windows and Unix systems (including Mac OS X), the system-wide installation locations for software are only writeable by administrator users, a regular, limited user account doesn't have write access to them. It's both an issue with multi-user systems (such as a computer shared between three members of a family) to avoid mixing different users' data, but also an issue with security/safety, to prevent program files from being changed unwittingly.
In the specific case of Mac OS X, if you have digitally signed software, an entire application bundle is signed as one unit, and changing any one file inside a signed bundle invalidates the signature of the entire bundle: The bundle should be considered one immutable file for most purposes. The same thing applies (should apply) to other program installations.
However, "portable" software is a different issue. Portable as in, software you can carry with you on a removable medium. Dwarf Fortress is designed in the portable model, which happens to be mostly the same model that almost all PC games before the advent of Windows XP used.

In short, there's two good reasons to keep user data separate from program code: It makes it possible to better tamper-proof the code, and it lets many users share one copy of the code without sharing their data.

Fair point, though I addressed some of the issues in my original post and some don't really apply to DF. Forgive my ignorance. It's an definitely an interesting problem, any way. I suppose it depends if you prefer to have all software using one system that is easy to break, unwieldy and limiting but uniform, disk-space-efficient and (for some other programs) more secure. And indeed, as you say, the situation for a multiple-user computer is different if space is at a premium and all users want the same version of DF but can't be trusted with each admin rights and each others' data, though it would, as you say, be different for a Unix(-like) computer with a superuser.

Out of interest,

also an issue with security/safety, to prevent program files from being changed unwittingly.

What sort of thing are you refering to?

The same thing applies (should apply) to other program installations.

Why? Consistency?

Portable as in, software you can carry with you on a removable medium.

As in "A portable application does not leave its files or settings on the host computer. Typically this means that the application does not write to the Windows registry or store its configuration files (such as an INI file) in the user's profile; instead, it stores its configuration files in the program's directory."? (Wikipedia: Portable application)
That's a Good Thing, but copying over, and keeping track of, saves and raws would be time consuming, error prone and irritating. Why not go the whole way and include everything in one managable folder?

Sigh... I suppose I could move DF into the save folder that it created.

Edit:

and making DF properly installable is something

(my emphasis)

What do you mean by "properly" installable? And what would it actually add apart from the ability to suggest an install location and spam the start menu and desktop with links?

[Baughn]

It would make it possible to install and update it with linux package managers, that's what.

I don't really care about how it works on windows, and you would still be able to use it the way you do now. Basically, there'd be a file like this:

Code: [Select]

mount /usr/games/df
mount $HOME/.df
which distributions could bundle, and which would give DF a search path. It would always write to the last mount-point in the list.

The downloadable packages from bay12games.com would just have "mount .", using the current directory, same as it does now.

EDIT: The above code was written for ease of understanding, not correctness. There would be no point in having the "mount /usr/games/df" line, or indeed "mount .", as it would have to mount the directory the executable is in anyway if it wants to find such a file in the first place.

[goffrie]

Out of interest,

also an issue with security/safety, to prevent program files from being changed unwittingly.

What sort of thing are you refering to?

The same thing applies (should apply) to other program installations.

Why? Consistency?

Portable as in, software you can carry with you on a removable medium.

As in "A portable application does not leave its files or settings on the host computer. Typically this means that the application does not write to the Windows registry or store its configuration files (such as an INI file) in the user's profile; instead, it stores its configuration files in the program's directory."? (Wikipedia: Portable application)
That's a Good Thing, but copying over, and keeping track of, saves and raws would be time consuming, error prone and irritating. Why not go the whole way and include everything in one managable folder?

Sigh... I suppose I could move DF into the save folder that it created.

Edit:

and making DF properly installable is something

(my emphasis)

What do you mean by "properly" installable? And what would it actually add apart from the ability to suggest an install location and spam the start menu and desktop with links?

I'm going to talk from the Linux (or other Unix-like) perspective because that's what I use (and what Baughn uses).

If you have multiple users, you don't want some users screwing with program binaries. In Unix-like systems, executables go in /usr/bin/ which is read-only so that this doesn't happen. You can't put data into /usr/bin/ because it's read-only, and because you want your data to be local to your user, so you put it in your home directory. Of course, most people don't have people they don't know using their computers, but it's consistent with (nearly) every other piece of software on the system.

As it is, Dwarf Fortress isn't "installed" in the sense of putting it into system directories. Instead, it's in your user directory, which is fine for single-user but is a waste of space for multi-user. Again, multi-user isn't a real issue for most people, but again, consistency.

All your saves would go in ~/.df/ (or C:\Users\user\Application Data\Dwarf Fortress\, or whatever). You shouldn't have to care about the raws, although I guess those could be there too.

[Andir]

you want your data to be local to your user, so you put it in your home directory. Of course, most people don't have people they don't know using their computers, but it's consistent with (nearly) every other piece of software on the system.

There are times I wished I had more control over this as well   I don't like that applications that come preconfigured just put stuff in my home folder all willy-nilly.   I want to put my program data in /~/data/<program name>/