Print

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

Higher speed, no problems

Higher speed, problems

Same speed, no problems

Same speed, problems

Lower speed, no problems

Lower speed, problems

[Konpeito]

Based on my experience:
1. You're using something other than [PRINTMODE:STANDARD]
2. There is a bug that makes it think that it needs to do a redraw, but only manages to clear the window. Do something else that actually forces a redraw (the easiest is changing the zoom level and resetting it)

PRINTMODE was in STANDARD, I played with it trying to fix this, ended up setting it back to STANDARD.

I tried zooming out, in, etc while the screen was black. Didn't do anything.

[Baughn]

Pretty sure that's Yet Another Thing That's Fixed In 40d17. Wait and see.

I really hope Toady gets better soon..

[lokis]

Hello, I just start playing a few days ago, i`m still learning how to play, but i`m having one problem. Sometimes my game does not run, i start the dwarfort.exe, and the game window does not appear, but i see that the process dwarfort.exe is running in the task manager and consuming 49% of CPU.
I`ve done this to solve:
I made a .bat that executes dwarfort.exe, this sometimes make the game run normally.
If i can`t run the game with the .bat, I have to delete the save folder, and the game runs fine again. (but obviously, i lose all my world)

I`ve searched for this, but found nothing, anyone knows what problem this could be?

Thanks in advance, and sorry for my english. 

EDIT: I`m running the d16 version on Windows XP SP3, without mods, tilesets, or anything extra.

[Shurhaian]

Speaking of zoom, I personally rather dislike it. I would greatly enjoy having a way to set the zoom factor to exactly 1, or just plain turn off zoom, even when running OpenGL; the quality loss is horrible on my display, and my CPU is already so limited that zooming out to have more tiles visible causes noticeable slowdowns anyway.

Failing that, having a way to reset to 1:1 would be lovely. It's a bit vexing to accidentally nudge the mousewheel and have to fiddle with getting it exactly right again.

[dorf]

Failing that, having a way to reset to 1:1 would be lovely.

IIRC, you can do that with the F12 button.

[Baughn]

You should be able to turn it off by removing the zoom in/out mappings in the interface menu.

Alternately you could use one of the 2D modes in 40d17, which are unable to zoom. 

[Shurhaian]

...Right. I was hoping that an init option to turn off zooming would be a fairly quick way to get around requiring either a moderately ugly hack on the user's part or using a nonoptimal render mode that's already been stated as being slower, but apparently I was mistaken. Sorry for bothering.

[Michael]

Speaking of zoom, I personally rather dislike it. I would greatly enjoy having a way to set the zoom factor to exactly 1, or just plain turn off zoom, even when running OpenGL; the quality loss is horrible on my display, and my CPU is already so limited that zooming out to have more tiles visible causes noticeable slowdowns anyway.

Speaking of zoom, in the suggestion forum I've re-iterated my longstanding proposal to have zoom switch between different sized fonts, rather than scale a single font -- and added it to Eternal Suggestions.

http://www.bay12games.com/forum/index.php?topic=47374.0

You'd probably like the kind of Zoom I'm campaigning for.  You could have, in addition to your favorite font, a Zaratustra microfont for birds-eye views, and a massive font to use all the screen real estate in worldgen/site selection.  All in crisp 1:1.

[Shurhaian]

A tilepage-switching "zoom" function is a neat notion indeed, though it may be beyond the scope of the d## series and require more of Toady's intervention, and may be liable to wait for a presentation update.

I like the notion, and it could also imply that you could use a different tileset for the world display than for the menus(thus reducing/eliminating the readability problems of graphic-heavy tilesets), which would only be for the good.

[Michael]

A tilepage-switching "zoom" function is a neat notion indeed, though it may be beyond the scope of the d## series and require more of Toady's intervention, and may be liable to wait for a presentation update.

I don't see any problem.  The code already supports two fonts -- one for Fullscreen and one for Windowed.  It's just a matter of generalizing to have two or more different Fullscreen layouts.

I like the notion, and it could also imply that you could use a different tileset for the world display than for the menus(thus reducing/eliminating the readability problems of graphic-heavy tilesets), which would only be for the good.

But this does need Toady, I suspect.

I haven't seen the code myself, but the fact that dye colors are stored as separate RGB values but are crushed to one of the regular 16 for display, strongly suggests that the core and graphics communicate over a CGA-like buffer with only 16 bits per cell - 4 for FG color, 4 for BG color, 8 for glyph.  Adding another 94 glyphs for genuine text would break the 8-bit limit.

Then again, somehow supplemental creature graphics work, so something else must be going on....

[Shurhaian]

What I was getting at would be a much more complicated function than the difference between fullscreen and windowed: it would be using different tilepages for different portions of the screen. Perhaps the same logic that goes into switching between windowed and fullscreen modes could be used to change tilepages on the fly in general - this would be a boon for trying out new tilesets, even if the changes are not persistent without going in and manually editing the init.txt.

I don't run DF in fullscreen(I don't like the effort my system goes through to switch graphic modes, and I like having utilities visible as I play), so a way to make this work in windowed mode, not just fullscreen, would be appreciated.

But yeah, so would opening up the graphics in general; allowing graphics for not just CREATURE:{CREATURENAME}, but e.g. OBJECT:BED. Maybe even trees, if someone is feeling really ambitious. And allowing dyes to be shown in their full colour, for that matter. Or just opening colours into RGB values in general; that might be better and/or easier than handling dyes as a special case.

[Michael]

What I was getting at would be a much more complicated function than the difference between fullscreen and windowed: it would be using different tilepages for different portions of the screen.

The graphics code might not know what parts of the screen are menu and what parts are world.  And even if it did, it might have to swap tilesets several times in rendering a single frame, producing an unacceptable framerate.

But what I'm asking is simple.  F11 already swaps the display type and the font -- I just want a command that changes the font leaving the display type the same.

[Baughn]

...Right. I was hoping that an init option to turn off zooming would be a fairly quick way to get around requiring either a moderately ugly hack on the user's part or using a nonoptimal render mode that's already been stated as being slower, but apparently I was mistaken. Sorry for bothering.

Geez. Well, what about setting the zoom setting to 1 in init.txt? That should turn it into a no-op.

[Baughn]

Runtime switching of the font, perhaps using a menu showing the possible options in data/art...

Well, it should be relatively doable, but I won't/can't do it right away. Both I and Toady are too busy at the moment, but I'll keep it in mind for later.

[Baughn]

Hello, I just start playing a few days ago, i`m still learning how to play, but i`m having one problem. Sometimes my game does not run, i start the dwarfort.exe, and the game window does not appear, but i see that the process dwarfort.exe is running in the task manager and consuming 49% of CPU.
I`ve done this to solve:
I made a .bat that executes dwarfort.exe, this sometimes make the game run normally.
If i can`t run the game with the .bat, I have to delete the save folder, and the game runs fine again. (but obviously, i lose all my world)

I`ve searched for this, but found nothing, anyone knows what problem this could be?

I've seen quite a few people with this problem, but I honestly have no clue whatsoever what the cause might be. It doesn't happen here, or apparently for Toady, which rather jinxes any possibility of figuring it out in a reasonable timeframe.

There are a few options, but for the time being I'd like you to wait for 40d17 and try the 2D mode there, so we can be sure the problem isn't on the opengl side of things.