Print

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

[lxnt]

[ README | Download | Source code  ]
 
26 June 2013.

About half a year ago this project morphed from simply patching up graphics code to an all-out attempt to bring graphics, and all other supporting code up to date.

As of today, it reached feature-parity with the old code, some amount of bugs present nonwithstanding.

For more information please see the README link above, and read the tail of this topic.

Spoiler: Older message text (click to show/hide)

11 November 2011.
The so-called "stable" version has been uploaded. It fixes a couple of bugs that might have caused intermittent crashes. 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.

23 October 2011.

Creatures are drawn exactly as in other GL renderers. For now.

22 October 2011.

Zoom works at last. On to getting creatures drawn the right way.

17 October 2011.

Added some docs in form of an README file.

Windows builder and testing are needed.

16 October 2011.

Source code is now hosted at github: here

Another interim release.
Highlights:
 support for non-square graphics and for stretch when zooming.
 shader source code embedded into the library to simplify deployment
 new configuration tokens:

Code: [Select]

[DUMP_SCREEN:0]
[TEXTURE_PARAM:NEAREST]
[VERTEX_SHADER:data/vertex.shader]

[FRAGMENT_SHADER:data/fragment.shader]

DUMP_SCREEN controls screen dumping for consumption by the testbed. 0 - disabled, >0 - dump screen every this frame.
TEXTURE_PARAM - now honored by the renderer
VERTEX_SHADER/FRAGMENT_SHADER - override embedded shaders with ones loaded from given files.

Python testbed non-functional at the moment, as the screen dump format changed.

http://dffd.wimbli.com/file.php?id=5044



To introduce myself to glsl and also get rid of graphics-related slowdowns, I implemented PRINT_MODE:SHADER. Almost.

The goal is to offload entire render to the GPU. As such, my code does absolutely nothing with screen[] and screentexpos[] arrays apart from uploading them as vertex buffer objects.  Everything gets done on the videocard.

This is very much a work in progress, so bugs are there and features are not. Resize window at your own risk.
 Requirements are: GLSL 1.20, which implies OpenGL2.0+.

Code works for me at ubuntu maverick 32bit + radeon 4850
OpenGL renderer string: Mesa DRI R600 (RV770 9440) 20090101 x86/MMX+/3DNow!+/SSE2 TCL DRI2
Should work on any 2xxx/3xxx/4xxx radeon with open-source drivers. No idea re windows or nvidia.

Limitations: 16x16 graphics only,  resize messes things up, creatures are not drawn correctly. Phoebus graphic/tile set is recommended.

Archive contents: eclipse project. Debug/libprint_shader.so - replace your libs/graphics.so to try it out.
vertex.shader and fragment.shader go into data/ directory.

t3.py - python testbed. works on screen and texture dumps (dump code disabled right now).
An example dump is included, launch like: python t3.py screendump 10

[NobodyPro]

Forgive me if I'm a little very suspicious what with your one post and gibberish username. In layman's terms, what is this and how have you done it?

[magistrate101]

Forgive me if I'm a little very suspicious what with your one post and gibberish username. In layman's terms, what is this and how have you done it?

To answer the first half of your laymen's terms question, it is a program/script that uses a different renderer than regular df, and thus offloads graphics-related computations entirely onto the GPU (From what I can get out of it, anyways)
I have no idea HOW, as I am not a coder.
edit:

Spoiler: A comment he left in the code (click to show/hide)

Code: [Select]

"""
    okay. we in fact twist vertex coordinates to correspond to backwards ordering of the
    screen, screentexpos and friends. uploaded on resize.
    then we just upload screen, screentexpos and friends as attr arrays. Phew.

    upload font as texture. texcoords from screen[] values computed as below.
    upload ascii color conversion table as texture.
    upload all graphics as one texture.

    upload mapping from screentexpos[] values to texcoords as vec4 texture:
     gvec = (offsettop, offsetleft, offsetbottom, offsetright), normalized,
     something like
     

    somehow upload all graphics as textures, and keep'em somewhat organized.
    most practical way is to assemble them into xlarge POT textures. and bind them all.
    GL_RGBA32F or non-normalized GL_RGBA16U or two GL_RGBA8U textures, one with top/left,
    other with right/bottom


"""

[lxnt]

More development ensued.

Zoom/resize fixed to more-or-less playable state.
I made an attempt to save screen[] contents from being overwritten with creatures, so that in graphics mode they can be drawn on top of floors, grass, etc. Not guaranteed to work in all cases. It would be much better if the core game did not overwrite screen[] array with characters for creatures if in graphics mode and there's something to put into screen_texpos[].
Putting 'action animation' code into yet another layer would be even better.

As for what this thread is about: yes, it's about making graphics snappy, especially when zoomed out.

As for how I did it - I used OpenGL point sprites instead of two triangles per tile, and I moved whatever graphic-related calculations were done on CPU to the GPU. These were - calculating offsets (in the single texture image) for each tile and uploading each tile individually (with about 3700 tiles that was slow) - on each resize. This particularly slowed down loading a saved game.

Calculating and uploading colors and texture coordinates for each tile, or, alternatively, finding out which tiles changed. Uploading triangle data - 6x number of tiles. Both done to draw each frame. Either way, when zoomed out to 256x256 tile screen this was way too slow too.

Result: zoom in/out feels much better. Also you can see barrels behind dwarves that drink from them.


Question for developers: what is textures::clone_texture() for?

[magistrate101]

Code: [Select]

Traceback (most recent call last):
  File "C:\df_opengl\t3.py", line 422, in <module>
    loader = FrameLoader(sys.argv[1])
IndexError: list index out of rangewhat?

edit: using windows8 (df works fine on it, and so does python), using python 2.6.6.
edit2: I don't get a single hit offa google for your question on "textures::clone_texture()" 

[lxnt]

The error you encountered means that it expected an argument (three actually) but did not get one.

usage: ./t3.py <screendump-filename> <desired-fps> <start_frame>

It also expects texdump0002.png and shaders in the current directory.
A screendump and texdump are supplied, erm, were supplied in previous version (forgot it this time), so get it and try running it like :

./t3.py screendump 10 0

screendump was generated by dumping every 4th or 5th frame, so playback is jerky.

Controls: mouse wheel - zoom, left mouse button and space - pause/unpause, right mouse button drag - panning, esc - quit


textures::clone_texture() is an internal df function that gets called from core game, so the question was directed more at people familiar with code we don't get to see, i.e. Toady.

[magistrate101]

The error you encountered means that it expected an argument (three actually) but did not get one.

usage: ./t3.py <screendump-filename> <desired-fps> <start_frame>

It also expects texdump0002.png and shaders in the current directory.
A screendump and texdump are supplied, erm, were supplied in previous version (forgot it this time), so get it and try running it like :

./t3.py screendump 10 0

screendump was generated by dumping every 4th or 5th frame, so playback is jerky.

Controls: mouse wheel - zoom, left mouse button and space - pause/unpause, right mouse button drag - panning, esc - quit


textures::clone_texture() is an internal df function that gets called from core game, so the question was directed more at people familiar with code we don't get to see, i.e. Toady.

Thanks, and the information is nice to know, I suppose

edit: zooming crashes it, and all I see is grey with white and black dots :\

[lxnt]

Testbed's code somewhat lagged behind c++ code, so crashes are not that surprising.

I'll be releasing a version later this week that would have all functionality standard print_mode has, both in c++ and python code. Then will be time for thorough testing.

[lxnt]

bump. see top post.

[Mike Mayday]

This is quite interesting.
Would you be able to make it so that zooming only affects the world view and not the menus?

[lxnt]

Would you be able to make it so that zooming only affects the world view and not the menus?

I'm not sure if it's impossible. Seems like the entire interface is drawn through the code in g_src/interface.cpp,
and if it's in fact so, this is what I'll be doing after I fix zoom/resize.

[Mike Mayday]

Oh my godddd the implications of this...

EDIT: just to be sure: my dream is for the interface to be displayed at 16x16 px (can be downscaled 32x32px, I don't mind) while the world view would be displayed at 32x32px (and using 32x32px icons, not upscaled 16x16 ones).

[lxnt]

EDIT: just to be sure: my dream is for the interface to be displayed at 16x16 px (can be downscaled 32x32px, I don't mind) while the world view would be displayed at 32x32px (and using 32x32px icons, not upscaled 16x16 ones).

I have separating map and interface zoom and fonts in plans - see the readme file for what exactly I do plan.

However, I'm no artist, someone would have to actually draw tile/graphics sets in resolutions you want.

[kingofthescots]

I hope someone compiles this for windows soon. This looks like quite an interesting development, and I'd like to see it in action.

[Mike Mayday]

EDIT: just to be sure: my dream is for the interface to be displayed at 16x16 px (can be downscaled 32x32px, I don't mind) while the world view would be displayed at 32x32px (and using 32x32px icons, not upscaled 16x16 ones).

I have separating map and interface zoom and fonts in plans - see the readme file for what exactly I do plan.
However, I'm no artist, someone would have to actually draw tile/graphics sets in resolutions you want.

That would be yours truly.