Print

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

[Rose]

I was pointed to this. I'll be keeping an eye on it.

[arclance]

Since forcing interface text to the same size as the game tiles is not convenient on modern monitors, it is a project goal to make the interface drawn separately from the world view, preferably with vector fonts.

I would suggest you add a [MENU_TILESET:] to the init file where the tileset/font/vector font used for drawing the interface can be specified.
By making the world and the interface have separate tilesets you can keep punctuation and special symbols in the interface while replacing them in the world view so they both look good.
This would also allow the menu and world to have different native tilesizes so they do not need to be resized just to draw the menu or world.

I would be careful with anything involving drawing vectors as it has the possibility to make the menus draw very slowly due to the number of calculations required to draw a large number of changing vector objects (scrolling menus made up of vector fonts as an example (ex. Trade Menu)) can quickly bring even a powerful computer to its knees (much like Dwarf Fortress).

[Mike Mayday]

Okay. Since I think that the policy on supported tile resolution/aspect ratios and such should be simple, let's limit it to this:

• Game is intended to be played without scaling/stretching or otherwise mutilating the graphics.
• Zoom is intended to be used to get a rough overview of the map, not a pretty one.
• Aspect ratio is defined by the font, that is, the floor tileset.
• If some graphics are of different aspect ratio, then they are uniformly scaled to fit inside the floor tile, centered. Resulting ugliness is the user's fault.

Since forcing interface text to the same size as the game tiles is not convenient on modern monitors, it is a project goal to make the interface drawn separately from the world view, preferably with vector fonts.

Zoom and scaling in my code is implemented by adjusting point sprite size in 1-pixel increments. Thus it is trivial to force scaling to exact integer multiple of pixels in the graphic.
Filtering is either GL_NEAREST or GL_LINEAR. While it's possible to implement some insanely complex scaler in the fragment shader, I don't think it's worth it due to the policy point 1.

How does this sound?

A smart tileset creator will be able to do wonders with this. Linear is, frankly, good enough. Vectors for the menus/interface- not necessary at all. Supporting 32x32 world view and 12x12 (or smaller) interface would be enough to make all graphics creators flip a positive bitch. And a separate tileset for the menus? That would be the limits of my imagination in terms of what a third party might do.

EDIT: Since I've been waiting for pretty much years for this, I just wanted to make sure: is this what you're hoping to achieve?
http://mayday.w.staszic.waw.pl/~mayday/upload/yesplease.jpg

[lxnt]

Tile size is wrong at startup but F10 works now.

Thank you. New version is up. It also tries to set 1:1 zoom if resizing upwards from a size that did not allow 1:1 zoom while keeping 80x25 grid (i.e. too small a window).

I switched to gcc-4.5 on my home machine, please test if this version works with stock libstdc++ on Natty.

I would suggest you add a [MENU_TILESET:] to the init file where the tileset/font/vector font used for drawing the interface can be specified.

That's what I planned to do.

I would be careful with anything involving drawing vectors as it has the possibility to make the menus draw very slowly.

It'll be optional in any case. We'll see what the performance is.

EDIT: Since I've been waiting for pretty much years for this, I just wanted to make sure: is this what you're hoping to achieve?
http://mayday.w.staszic.waw.pl/~mayday/upload/yesplease.jpg

This too. Also the other way around to keep menus readable while zoomed out.

[arclance]

Tile size is wrong at startup but F10 works now.

Thank you. New version is up. It also tries to set 1:1 zoom if resizing upwards from a size that did not allow 1:1 zoom while keeping 80x25 grid (i.e. too small a window).

I switched to gcc-4.5 on my home machine, please test if this version works with stock libstdc++ on Natty.

Tile size is correct at startup now.
Works on my 32bit 11.04 (natty) computer which has the stock libstdc++.

[lxnt]

Tile size is correct at startup now.
Works on my 32bit 11.04 (natty) computer which has the stock libstdc++.

Thank you.

The so-called "stable" version has been uploaded. It fixes a couple of bugs that might have caused intermittent crashes you had experienced. It also is compiled with optimization and w/o debug (thus the size).

This is a direct replacement of any other renderer - it draws stuff identically or as close to as is sensible. It is also faster, easily beating 500 graphic FPS on pause (on my r4850), and not biting off much time out of game engine when in action - but make sure you cap G_FPS at something low and enable SINGLE_BUFFER.

[arclance]

This is a direct replacement of any other renderer - it draws stuff identically or as close to as is sensible. It is also faster, easily beating 500 graphic FPS on pause (on my r4850), and not biting off much time out of game engine when in action - but make sure you cap G_FPS at something low and enable SINGLE_BUFFER.

[SINGLE_BUFFER:YES] in [PRINT_MODE:SHADER] is unusable for me as the game looks like this

Spoiler (click to show/hide)

The dark triangle jumps up and down the screen and blinks on and off rapidly while changing size.
This also happens when using [PRINT_MODE:VBO] but not in other modes.

I see no FPS improvement between [SINGLE_BUFFER:YES] and [SINGLE_BUFFER:NO].  FPS appears identical between these two settings in a 21 year old fort.
I am actually seeing the opposite of you when I test with a three season old fort.
With [SINGLE_BUFFER:YES] I get ~255 FPS in this fort.

Spoiler (click to show/hide)

With [SINGLE_BUFFER:NO] I get ~270 FPS in this fort.

Spoiler (click to show/hide)

I do see a 1 to 2 FPS improvement (35-36 FPS stock to ~37 FPS (much more stable) using shader) over the stock print modes in a 21 year old fort.
Setting [G_FPS_CAP:30] (from 50) got me an improvement of only 1 to 2 FPS. 
I got the same FPS when it was set at 25 (which I don't like to play at).
Moving from Debug build got me about 3 FPS.

FPS at pause is not representative of the FPS you will get in game.
Using your settings I get a FPS of ~190,000 when paused and 37 when unpaused.

Spoiler (click to show/hide)

Spoiler (click to show/hide)

[lxnt]

[SINGLE_BUFFER:YES] in [PRINT_MODE:SHADER] is unusable for me as the game looks like this

...

The dark triangle jumps up and down the screen and blinks on and off rapidly while changing size.
This also happens when using [PRINT_MODE:VBO] but not in other modes.

Sounds like "threaded optimization" bug. I don't have any sufficiently modern Nvidia hardware to test this though.

I see no FPS improvement between [SINGLE_BUFFER:YES] and [SINGLE_BUFFER:NO].  FPS appears identical between these two settings in a 21 year old fort.
I am actually seeing the opposite of you when I test with a three season old fort.

Okay. Look at the console output, the code prints time spent drawing a frame every 5 seconds. If it's about 16-17 ms, your GL driver forces vertical refresh sync at 60Hz.

The whole point of this is to leave G_FPS capped by the game, not by the GL drivers. This way frame is drawn as fast as possible, and the rest of time is spent elsewhere,
not in drivers waiting for the vertical refresh.

If it's about 1-2 ms, then renderer does not waste time. This is visible in game when you pause and graphics FPS starts to climb to about the same value as game engine FPS.
The reason I quoted 500 FPS is that I capped game engine FPS to 500 and on every pause graphics FPS would climb to 500 in several seconds (this gradual rise has something to do with
how graphics FPS is calculated).

That said, I'm reading the code that communicates between rendering and game engine threads. There might be some deficiences whose removal can benefit game engine FPS.




 

[arclance]

Okay. Look at the console output, the code prints time spent drawing a frame every 5 seconds. If it's about 16-17 ms, your GL driver forces vertical refresh sync at 60Hz.

The whole point of this is to leave G_FPS capped by the game, not by the GL drivers. This way frame is drawn as fast as possible, and the rest of time is spent elsewhere,
not in drivers waiting for the vertical refresh.

If it's about 1-2 ms, then renderer does not waste time. This is visible in game when you pause and graphics FPS starts to climb to about the same value as game engine FPS.

It is 0-1 ms no matter what settings I use.  My graphical FPS never climbs above its cap when paused.  Game engine FPS climbs rapidly either to its cap or to a very large value when paused. 

[SINGLE_BUFFER:NO]

Code: [Select]

./df
textures::load(): data/art/Phoebus_20x20.png 320x320 16x16 20x20
textures::load(): data/art/Phoebus_20x20.png 320x320 16x16 20x20
Loading bindings from data/init/interface.txt
textures::load(): data/art/mouse.png 32x32
set_mode(): requesting vsync=0 and singlebuf=0.
set_mode(): SDL_GL_SWAP_CONTROL: 0
set_mode(): SDL_GL_ACCELERATED_VISUAL: 1
set_mode(): SDL_GL_DOUBLEBUFFER: 1
set_mode(): SDL_FULLSCREEN: 0
GLEW: 1.5.2
OpenGL vendor: NVIDIA Corporation
OpenGL renderer: GeForce GT 240/PCI/SSE2
OpenGL version: 3.3.0 NVIDIA 270.41.06
OpenGL GLSL version: 3.30 NVIDIA via Cg compiler
GL_MAX_VERTEX_ATTRIBS=16, needed=7
GL_MAX_VERTEX_UNIFORM_COMPONENTS=4096, needed=9
GL_MAX_FRAGMENT_UNIFORM_COMPONENTS=2048, needed=11
GL_MAX_VERTEX_TEXTURE_IMAGE_UNITS=32, needed=0
GL_MAX_TEXTURE_IMAGE_UNITS=32, needed=3
GL_MAX_VARYING_FLOATS=60, needed=8
GL_MAX_TEXTURE_COORDS=8, needed=2
GL_POINT_SIZE_MIN=0, needed=4
GL_POINT_SIZE_MAX=63, needed=48
makeansitex(): 2.
Embedded shader set 'rect'
Embedded shader set 'cbr_is_bold' x
Using embedded vertex shader code from 'cbr_is_bold'.
Using embedded fragment shader code from 'cbr_is_bold'.
GL_COMPILE_STATUS: true
GL_COMPILE_STATUS: true
GL_LINK_STATUS: true
GL_VALIDATE_STATUS: true
makeansitex(): 2.
gps_allocate(80, 25)
Resetting textures
texdumpst::init(): allocating 2048x288 (max 64x9 32x32 cells)
accepted font texture (name=1): 2048x288px oa
accepted txco texture (name=3): 64x9px oa
reshape(): got grid 0x0 window -1x-1 tile 20x20 texture_ready=1 stretch=0 snap=0
reshape(): final grid 96x50 window 1920x1000 viewport 1920x1000 Psz 20x20
gps_allocate(96, 50)
set_viewport(): got 1920x1000 out of 1920x1000
Frame drawn in 2 msec
Frame drawn in 0 msec
Frame drawn in 0 msec
Frame drawn in 0 msec
Frame drawn in 0 msec
Frame drawn in 0 msec
Frame drawn in 0 msec
Frame drawn in 0 msec
Frame drawn in 0 msec
Frame drawn in 0 msec
Frame drawn in 0 msec
Frame drawn in 0 msec
Frame drawn in 0 msec
Frame drawn in 0 msec
Frame drawn in 0 msec
Frame drawn in 0 msec
Frame drawn in 0 msec
Frame drawn in 0 msec
Frame drawn in 0 msec
Frame drawn in 0 msec
Frame drawn in 0 msec
Frame drawn in 0 msec
Frame drawn in 0 msec
Frame drawn in 0 msec
Frame drawn in 0 msec
Frame drawn in 0 msec
textures::load(): data/save/region60-2_phoebus_2_2/raw/graphics/Beefmo/dorfs.png 240x500 12x25 20x20
textures::load(): data/save/region60-2_phoebus_2_2/raw/graphics/Beefmo/humans.png 240x500 12x25 20x20
textures::load(): data/save/region60-2_phoebus_2_2/raw/graphics/Beefmo/goblins.png 240x500 12x25 20x20
textures::load(): data/save/region60-2_phoebus_2_2/raw/graphics/Beefmo/elfs.png 240x500 12x25 20x20
textures::load(): data/save/region60-2_phoebus_2_2/raw/graphics/Beefmo/koboldz.png 240x500 12x25 20x20
textures::load(): data/save/region60-2_phoebus_2_2/raw/graphics/mayday/creature_birds.png 100x120 5x6 20x20
textures::load(): data/save/region60-2_phoebus_2_2/raw/graphics/mayday/creature_domestic.png 440x120 22x6 20x20
textures::load(): data/save/region60-2_phoebus_2_2/raw/graphics/mayday/creature_large_mountain.png 100x120 5x6 20x20
textures::load(): data/save/region60-2_phoebus_2_2/raw/graphics/mayday/animals.png 240x600 12x30 20x20
textures::load(): data/save/region60-2_phoebus_2_2/raw/graphics/mayday/water.png 80x140 4x7 20x20
textures::load(): data/save/region60-2_phoebus_2_2/raw/graphics/mayday/gibbon.png 80x180 4x9 20x20
textures::load(): data/save/region60-2_phoebus_2_2/raw/graphics/mayday/beasts.png 120x80 6x4 20x20
textures::load(): data/save/region60-2_phoebus_2_2/raw/graphics/mayday/mans.png 240x340 12x17 20x20
textures::load(): data/save/region60-2_phoebus_2_2/raw/graphics/mayday/newbeasts.png 120x160 6x8 20x20
Resetting textures
texdumpst::init(): allocating 2048x2656 (max 64x83 32x32 cells)
accepted font texture (name=1): 2048x2656px oa
accepted txco texture (name=3): 64x83px oa
Frame drawn in 0 msec
Frame drawn in 0 msec
Frame drawn in 0 msec
Frame drawn in 0 msec
Frame drawn in 0 msec
Frame drawn in 0 msec
reshape(): got grid 96x51 window 1920x1025 tile 20x20 texture_ready=1 stretch=0 snap=0
reshape(): final grid 96x51 window 1920x1025 viewport 1920x1020 Psz 20x20
gps_allocate(96, 51)
set_mode(): requesting vsync=0 and singlebuf=0.
set_mode(): SDL_GL_SWAP_CONTROL: 0
set_mode(): SDL_GL_ACCELERATED_VISUAL: 1
set_mode(): SDL_GL_DOUBLEBUFFER: 1
set_mode(): SDL_FULLSCREEN: 0
set_viewport(): got 1920x1020 out of 1920x1025
Frame drawn in 0 msec
[SINGLE_BUFFER:YES]

Code: [Select]

./df
textures::load(): data/art/Phoebus_20x20.png 320x320 16x16 20x20
textures::load(): data/art/Phoebus_20x20.png 320x320 16x16 20x20
Loading bindings from data/init/interface.txt
textures::load(): data/art/mouse.png 32x32
set_mode(): requesting vsync=0 and singlebuf=1.
set_mode(): SDL_GL_SWAP_CONTROL: 0
set_mode(): SDL_GL_ACCELERATED_VISUAL: 1
set_mode(): SDL_GL_DOUBLEBUFFER: 0
set_mode(): SDL_FULLSCREEN: 0
GLEW: 1.5.2
OpenGL vendor: NVIDIA Corporation
OpenGL renderer: GeForce GT 240/PCI/SSE2
OpenGL version: 3.3.0 NVIDIA 270.41.06
OpenGL GLSL version: 3.30 NVIDIA via Cg compiler
GL_MAX_VERTEX_ATTRIBS=16, needed=7
GL_MAX_VERTEX_UNIFORM_COMPONENTS=4096, needed=9
GL_MAX_FRAGMENT_UNIFORM_COMPONENTS=2048, needed=11
GL_MAX_VERTEX_TEXTURE_IMAGE_UNITS=32, needed=0
GL_MAX_TEXTURE_IMAGE_UNITS=32, needed=3
GL_MAX_VARYING_FLOATS=60, needed=8
GL_MAX_TEXTURE_COORDS=8, needed=2
GL_POINT_SIZE_MIN=0, needed=4
GL_POINT_SIZE_MAX=63, needed=48
makeansitex(): 2.
Embedded shader set 'rect'
Embedded shader set 'cbr_is_bold' x
Using embedded vertex shader code from 'cbr_is_bold'.
Using embedded fragment shader code from 'cbr_is_bold'.
GL_COMPILE_STATUS: true
GL_COMPILE_STATUS: true
GL_LINK_STATUS: true
GL_VALIDATE_STATUS: true
makeansitex(): 2.
gps_allocate(80, 25)
Resetting textures
texdumpst::init(): allocating 2048x288 (max 64x9 32x32 cells)
accepted font texture (name=1): 2048x288px oa
accepted txco texture (name=3): 64x9px oa
reshape(): got grid 0x0 window -1x-1 tile 20x20 texture_ready=1 stretch=0 snap=0
reshape(): final grid 96x50 window 1920x1000 viewport 1920x1000 Psz 20x20
gps_allocate(96, 50)
set_viewport(): got 1920x1000 out of 1920x1000
Frame drawn in 2 msec
reshape(): got grid 96x51 window 1920x1025 tile 20x20 texture_ready=1 stretch=0 snap=0
reshape(): final grid 96x51 window 1920x1025 viewport 1920x1020 Psz 20x20
gps_allocate(96, 51)
set_mode(): requesting vsync=0 and singlebuf=1.
set_mode(): SDL_GL_SWAP_CONTROL: 0
set_mode(): SDL_GL_ACCELERATED_VISUAL: 1
set_mode(): SDL_GL_DOUBLEBUFFER: 0
set_mode(): SDL_FULLSCREEN: 0
set_viewport(): got 1920x1020 out of 1920x1025
Frame drawn in 0 msec
textures::load(): data/save/region60-2_phoebus_2_2/raw/graphics/Beefmo/dorfs.png 240x500 12x25 20x20
textures::load(): data/save/region60-2_phoebus_2_2/raw/graphics/Beefmo/humans.png 240x500 12x25 20x20
textures::load(): data/save/region60-2_phoebus_2_2/raw/graphics/Beefmo/goblins.png 240x500 12x25 20x20
textures::load(): data/save/region60-2_phoebus_2_2/raw/graphics/Beefmo/elfs.png 240x500 12x25 20x20
textures::load(): data/save/region60-2_phoebus_2_2/raw/graphics/Beefmo/koboldz.png 240x500 12x25 20x20
textures::load(): data/save/region60-2_phoebus_2_2/raw/graphics/mayday/creature_birds.png 100x120 5x6 20x20
textures::load(): data/save/region60-2_phoebus_2_2/raw/graphics/mayday/creature_domestic.png 440x120 22x6 20x20
textures::load(): data/save/region60-2_phoebus_2_2/raw/graphics/mayday/creature_large_mountain.png 100x120 5x6 20x20
textures::load(): data/save/region60-2_phoebus_2_2/raw/graphics/mayday/animals.png 240x600 12x30 20x20
textures::load(): data/save/region60-2_phoebus_2_2/raw/graphics/mayday/water.png 80x140 4x7 20x20
textures::load(): data/save/region60-2_phoebus_2_2/raw/graphics/mayday/gibbon.png 80x180 4x9 20x20
textures::load(): data/save/region60-2_phoebus_2_2/raw/graphics/mayday/beasts.png 120x80 6x4 20x20
textures::load(): data/save/region60-2_phoebus_2_2/raw/graphics/mayday/mans.png 240x340 12x17 20x20
textures::load(): data/save/region60-2_phoebus_2_2/raw/graphics/mayday/newbeasts.png 120x160 6x8 20x20
Resetting textures
texdumpst::init(): allocating 2048x2656 (max 64x83 32x32 cells)
accepted font texture (name=1): 2048x2656px oa
accepted txco texture (name=3): 64x83px oa
Frame drawn in 0 msec
Frame drawn in 0 msec
Frame drawn in 0 msec
Frame drawn in 0 msec
Frame drawn in 0 msec
Frame drawn in 0 msec
Frame drawn in 0 msec
Frame drawn in 0 msec
Frame drawn in 0 msec
Frame drawn in 0 msec
Frame drawn in 0 msec
Frame drawn in 1 msec
Frame drawn in 0 msec


The reason I quoted 500 FPS is that I capped game engine FPS to 500 and on every pause graphics FPS would climb to 500 in several seconds (this gradual rise has something to do with
how graphics FPS is calculated).

That said, I'm reading the code that communicates between rendering and game engine threads. There might be some deficiences whose removal can benefit game engine FPS.

You should tell us if you have capped your FPS.  My FPS always hits a cap like that no matter what print mode I am using when paused.
Your previous statement makes it sound like your max FPS uncapped is 500 when paused.
You should also state the max FPS you get when not using shader as a reference point since we don't have your computer.

[lxnt]

Well ok. My fault. Should have been more precise.

Anyway, you can measure, benchmark and profile the code as you see fit. It should be taken for granted that on high-spec machines performance gain would be minimal, because in any case time spent on rendering depends only on grid_size, while game FPS depend more on map size and population.

In other news, it seems like I would have to integrate dfhack into the renderer to implement features I promised. This will take some time.

[Rose]

lxnt, I just felt I should mention, it's actually not possible to make Stonesense to work in SDL, due to SDL limitations.

[lxnt]

lxnt, I just felt I should mention, it's actually not possible to make Stonesense to work in SDL, due to SDL limitations.

I know. It'd be more of a rewrite than porting effort. Since rendering is going to be rewritten anyway, and current goal of divorcing interface from map rendering implies stonesense-like fetches of additional data from the game (thus dfhack integration), there isn't much left to port. If one insists on having multiple windows, SDL 1.3 can be brought in.

[Rose]

well, any help you need, I generally hang out on #dfhack on freenode.

[Mike Mayday]

Listen guys I really would like to help with testing the project but I'd need help setting up a proper environment (usb ubuntu plus learning how to compile). If you think it's worth your trouble- shoot!

[arclance]

Listen guys I really would like to help with testing the project but I'd need help setting up a proper environment (usb ubuntu plus learning how to compile). If you think it's worth your trouble- shoot!

Instructions on how to make a Ubuntu usb boot drive can be found here.
If you have an Nvidia graphics card you should install the Nvidia proprietary drivers, they work much better that the open source drivers with Nvidia cards.
A guide on setting up linux to run dwarf fortress can be found here.
The readme lists these dependencies you install them with synaptic package manager.

Code: [Select]

GTK+ 2+
SDL 1.2+
SDL_image
libgl
libglu
There is one more needed in Ubuntu but I don't remember what it is. 
Run Dwarf Fortress in the terminal and the error message should tell you what it is.

You don't need to learn how to compile just to test [PRINT_MODE:SHADER], the version on dffd works on Ubuntu.
Just follow the setup directions in the readme and it should work fine.

If you want to actually play the game in linux dfhack in already compiled for linux.
Dwarf Therpist is not you will need to compile it yourself. 
If you do that I recommend you use this version which has an animal tab and can read physical attributes from Dwarfs.
Instructions for compiling Dwarf Therapist are found here replacing

Code: [Select]

hg clone https://dwarftherapist.googlecode.com/hg/ dwarftherapistwith

Code: [Select]

hg clone https://code.google.com/r/shishimar-dwarftherapist/ dwarftherapistto use the version I recommended.

If you have any problems just ask.