Bay 12 Games Forum

Please login or register.

Login with username, password and session length
Advanced search  

Poll

After experimenting with the options, how is 40d13? Problems only count if the defaults don't work.

Faster than 40d, no problems
- 42 (26.1%)
Faster than 40d, problems
- 72 (44.7%)
No slower than 40d, no problems
- 14 (8.7%)
No slower than 40d, problems
- 16 (9.9%)
Slower than 40d, no problems
- 2 (1.2%)
Slower than 40d, problems
- 3 (1.9%)
Doesn't work (please explain)
- 12 (7.5%)

Total Members Voted: 160


Pages: 1 ... 133 134 [135] 136 137 ... 147

Author Topic: FotF: Help test the output code for the next version of DF (40d13)  (Read 376471 times)

Baughn

  • Noble Phantasm
  • The Haruhiist
  • Hiss
    • View Profile

First off - gridsize and fullgridsize are presently deprecated, and have no actual function. They'll be removed shortly.

Zooming in with mousewheel down works as you'd expect if you turn black_space off. With black_space on, what would you like it to do? I'm open to suggestions.

My math for scaling may be slightly off. I was going to re-check that a while ago, but forgot; I'll do that now. (Well, after sleep..)
Logged
C++ makes baby Cthulhu weep. Why settle for the lesser horror?

Michael

  • Bay Watcher
    • View Profile

Zooming in with mousewheel down works as you'd expect if you turn black_space off. With black_space on, what would you like it to do? I'm open to suggestions.
The point of blackspace is to sacrifice some screen real-estate in return for 1:1 mapping between font design pixels and screen pixels, for a crisp look.

Since the point is to keep things crisp, integer scaling of the font (8x8 becomes 16x16) would be reasonable.  However, only one step of this will be available most of the time, since most resolutions and fonts will not be able to support 80x25 after tripling.

On a CRT monitor, it would be possible to support more steps by switching the physical resolution.  However, that should be avoided on LCDs, since that just asks the hardware to do the same uglification.

It would also be fair to ignore blackspace when zooming in, since what is really important is that the starting (and F12) scaling be crisp.  Since my font does not divide my resolution, it can only be clear with blackspace on.

Note that multiple fonts also provide a way out -- for example outright substituting an 12x24 for an 8x16 font depending on desired zoom.
Logged

Andir

  • Bay Watcher
    • View Profile

Note that multiple fonts also provide a way out -- for example outright substituting an 12x24 for an 8x16 font depending on desired zoom.
That would require the implementation of multiple tilesets for different zoom levels... in other words, overly complicated tilesets.

I would personally say that you can probably remove the blackspace setting and keep the height/width clamped at multiples of the tile height/width.  It's a simple modulus operation to allow that.  The downside is that the border will "jig" a little.  The only other way I can see it working better would be to place the border and menus on a separate layer and zoom only the map view but I think this might require a bit more help from Toady to accomplish.
Logged
"Having faith" that the bridge will not fall, implies that the bridge itself isn't that trustworthy. It's not that different from "I pray that the bridge will hold my weight."

rowdy

  • Escaped Lunatic
    • View Profile

Since the point is to keep things crisp, integer scaling of the font (8x8 becomes 16x16) would be reasonable.  However, only one step of this will be available most of the time, since most resolutions and fonts will not be able to support 80x25 after tripling.


If a high enough resolution font (or ttf) was used, any arbitrary scaling factor would appear crisp and we could avoid the need for integer scaling.
Logged

torbenh

  • Escaped Lunatic
    • View Profile

hi...  i am on gentoo 64bit...
my 32bit gtk is a bit old and doesnt have libgio (i dont think df is directly using it, but the .exe is
linked against it. (i just faked the existence of libgio-2.0.so by copying libglib.so over, and that works)

would be nice, if -lgio would get removed from the link flags of the .exe

it also pulled in a fairly new version of libstdc++ which required me to upgrade to gcc-4.3.2
is that really necessary ?

somehow the reaction to keypresses is a bit laggy with the current git.
(this might be due to my 32bit opengl and intel gma965)

have you thought about using the pixel shader to render characters ?
this might be a good start:
http://lumina.sourceforge.net/Tutorials/Hello_World.html


keep up the good work.
Logged

G-Flex

  • Bay Watcher
    • View Profile

Since the point is to keep things crisp, integer scaling of the font (8x8 becomes 16x16) would be reasonable.  However, only one step of this will be available most of the time, since most resolutions and fonts will not be able to support 80x25 after tripling.


If a high enough resolution font (or ttf) was used, any arbitrary scaling factor would appear crisp and we could avoid the need for integer scaling.

Using truetype fonts (or any "real" font) would be a step backwards when it comes to user customizability and graphics support, though.
Logged
There are 2 types of people in the world: Those who understand hexadecimal, and those who don't.
Visit the #Bay12Games IRC channel on NewNet
== Human Renovation: My Deus Ex mod/fan patch (v1.30, updated 5/31/2012) ==

Antsan

  • Bay Watcher
    • View Profile

df13head on Ubuntu 8.10:
I am using the Character Set by Spreggo. In previous versions it worked just fine, in the new version several layer-types appear not as intended but as 1, ü or other letters instead of the ones that where there before.
Logged
Taste my Paci-Fist

Rose

  • Bay Watcher
  • Resident Elf
    • View Profile

Since the point is to keep things crisp, integer scaling of the font (8x8 becomes 16x16) would be reasonable.  However, only one step of this will be available most of the time, since most resolutions and fonts will not be able to support 80x25 after tripling.


If a high enough resolution font (or ttf) was used, any arbitrary scaling factor would appear crisp and we could avoid the need for integer scaling.

Using truetype fonts (or any "real" font) would be a step backwards when it comes to user customizability and graphics support, though.

True type is not the only vector based possibility.

I'll start making a CSV ASAP
Logged

Ergzay

  • Bay Watcher
    • View Profile

I have been using 40d13 on the mac for a little while and I haven't read through most of this topic (just the most recent page). This is the first OpenGL version I have used as I only became a Dwarf Fortress convert about a week ago. Here is my list of bugs/problems I've found.

#1: I see this has been fixed, but mentioning anyway. The mouse and designations do not work well with each other. The game constantly sees the mouse as stuck down.
#2: The designation menu and several other menus, including the build menu are all distorted. The (key) icons are shifted to the left directly on the text. It makes it impossible to read some. The issue becomes obvious when you resize the menu to make it wider. Somehow, both equal space indentation (based on length of option) (which would work fine had left centered text been on) and right centered text for the keys have gotten turned on which causes them to sit on top of each other.
#3: The new syntax of the interface.txt file is causing problems. I use a laptop keyboard so I often reassign many of the numpad keys (I hate people relying on numpads) to normal key settings. Notably I set all the SECONDSCROLL_etc keys to the - = [ ] keys. BUT, with this new syntax when I try and use ] it treats it as the end of line character and doesn't use it. [ and ] should never be used begin of line and end of line characters. Use newline/linebreak characters and space characters instead of : [ and ]. Syntax should be:
BIND THE_PARAM
KEY thekey
KEY thekey
etc
This would improve readability and be just as good.
#4: This could not be a bug. Because I was so used to the (what I see now) extremely slow framerate of the old version when I leave the game on 100 fps cap it runs so ridiculously fast that many of my legendary/perfectly agile miners occasionally will blink out of existence while moving over rocks sitting on the ground and will often flicker around because of it. I am on Standard print mode.

Last I have a few questions that I have not been able to find any answers for.
1. What do all the PRINT_MODE settings do, in detail? A technically oriented answer would be great. Also what does the SINGLE_BUFFER option do.
2. Does G_FPS_CAP do anything anymore? I have tried changing and I cant not notice any difference between 20 and 60.
3. What does TEXTURE_PARAM do?
4. Does the PRIORITY option have any effect on Linux or Mac?
5. Does AUTOBACKUP work on manual saves and where do the saves get put?
Logged

Veroule

  • Bay Watcher
    • View Profile

#2: Right justified: Known issue, I am pretty sure it is something Toady has to fix.
#3:  INTERFACE.TXT:  The syntax is not going to change.  It was designed to be similar to the format for the raws.  You can use both : and ] as bindings.  It is most readily done in the bindings view, but if you want to do it manually they are named colon and rbracket respectively.
Logged
"Please, spare us additional torture; and just euthanise yourselves."
Delivered by Tim Curry of Clue as a parody of the lead ass from American Idol in the show Psych.

Corona688

  • Bay Watcher
    • View Profile

4. Does the PRIORITY option have any effect on Linux or Mac?
Nope, since
a) you need root permissions to increase priority.  Anyone can decrease their own priority though ;)
b) UNIX has decent, automatable tools to modify priority already without needing to bodge priority options into existing programs.
c) UNIX has finer-grained priority opions than "high" and "low".
Logged
You never know when you might need a berserk dwarf to set loose somewhere.

Ergzay

  • Bay Watcher
    • View Profile

I forgot to report two other items.
#5: Whenever the Mac OS X version of the app quits I get a Segmentation Fault message in terminal and a "This application has unexpectedly quit." window.
#6: Some icons are not displaying right. It appears randomly and one door will all of a sudden go solid black. Many of the other icons of the same type appear fine but a few random ones will not. Its as if the non alpha layer of the image set I'm using (mayday) doesn't get its color defined. They appear as a pitch black outline of the icon.
Logged

Andir

  • Bay Watcher
    • View Profile

c) UNIX has finer-grained priority opions than "high" and "low".
To be fair, Windows actually has a two tier scheduling capacity.

User controllable/process priority tree:
    IDLE
    BELOW_NORMAL
    NORMAL
    ABOVE_NORMAL
    HIGH
    REALTIME

And each of those process priorities have thread priorities:
    IDLE
    LOWEST
    BELOW_NORMAL
    NORMAL
    ABOVE_NORMAL
    HIGHEST
    TIME_CRITICAL

Compared to Unix process/user definable niceness that can be -20 to 20 (41) [plus posix threading priority as well] Unix is just easier to decipher since they are raw numbers.

It's a little more difficult than "high" and "low". ;)
Logged
"Having faith" that the bridge will not fall, implies that the bridge itself isn't that trustworthy. It's not that different from "I pray that the bridge will hold my weight."

Antsan

  • Bay Watcher
    • View Profile

Forgot one problem:

During world generation (except when rivers and lakes are generated) and when exporting images the screen doesn't update anymore. This doesn't make the program unusable but is really annoying, because I would like to know, how many worlds have been rejected and how long I have to wait to continue.

Again, I am using the most recent head-version on Kubuntu8.10
Logged
Taste my Paci-Fist

jupotter

  • Bay Watcher
    • View Profile

Hi there

I use linux's version of 40d13+head, on Ubuntu 9.4. The game run perfectly, but when I enter in any game mode (Forteress and adventurer), the key are completly messed: the arrow keys makes the screen move diagonaly, the d open the Depot menu, pause/unpause is on the z key ans he spacebar don't work at all. But in fullscreen menu, everything works as expected. I've got a french azerty keyboard, but I never had any problem before.

Beside that, the game run really faster on pause (around 1000FPS with a G_FPS at 20), but when I unpause the game, it fall around 30. I use Mayday's graphics with a 1280*800 screen and a 80*25 grid, in windowed.
The zoom is just... wooaahhh :o Nice job!
Logged
Pages: 1 ... 133 134 [135] 136 137 ... 147