Print

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

[lxnt]

I can get Microsoft Visual Studio 2012, and try this out.

It has better C++11 support btw.

Thank you.

I made it to compile and run with VS 2010 Express since. Any extra testing is always very welcome of course.

If you want to stick this into DFhack (which can be done, actually) the only MSVC you need is 2010.

Well, I'd like to stick DFhack into this, not the other way around. To this end, I'd like suggestions on the API to do that, assuming DFhack be loaded as a module on startup.

The shim would have to have a dependencies function, depending on the platform and simuloop interfaces, and some means to become activated, pause simuloop to mess with the internals, etc?

I guess UI can be handled in a separate thread and a separate window or something.

Would very much appreciate suggestions on this.

[Rose]

Dfhack has the abillity to replace the renderer used by DF, which is exactly what you need. Not to mention giving full access to the internals of the game

[lxnt]

Dfhack has the abillity to replace the renderer used by DF, which is exactly what you need. Not to mention giving full access to the internals of the game

No, Japa, DFhack just won't cut it. The combined metahack level will make it all crash and burn.

[arclance]

I can get Microsoft Visual Studio 2012, and try this out.

It has better C++11 support btw.

Thank you.

I made it to compile and run with VS 2010 Express since. Any extra testing is always very welcome of course.

This is why you use VS 2010 and not something else for things like this and dfhack.

Note that if you're going to write a plugin, you must compile it with VS2010 - VS2012 will not work because it'll use the wrong C runtime (msvcr110 instead of msvcr100) and thus use the wrong heap (for malloc/free and operator new/delete).

It might appear to work for simple tasks such as "reveal", but if the plugin tried to allocate memory and DF then tried to free it (e.g. with the "trigger siege" sample I just posted earlier), it would cause the game to crash.

I did not know the actual reason before.

[lxnt]

Bummer.

Got seriously fed up with C++ doing the TTF font rendering (twin threadsafe LRU caches) (and not to mention the tabulation hack, brrr). Did it in plain C, ditched SDL_ttf in favor of HarfBuzz+Freetype, but too exhausted to integrate it yet. Will first test it all in fgtesbed. No idea how to get it go faster than craaawl in (not yet implemented) full-software SDL mode _and_ not spray hacks all over the code either.

This full-feature-parity-with-the-g_src-but-modular-maintanable-and-extensible goal is quite an undertaking after all. Not to mention nothing's yet done on the sound side.

--

./lxnt

[Thundercraft]

Question: If you do manage to "stick DFhack into this" would that, in theory, allow one to get a version of this to run on Windows?

Also, I'm having a hard time finding screenshots of this thing. Most of the image links in this thread are either broken or lead to DFFD files that have since been removed.

If you've gotten the combined 32x32 or 20x20 world view and 12x12 interface to work, I'd love to see it.

[lxnt]

Well, ok. Status update.

The goal of the entire project at this point was and is an source-level unified cross-plaform renderer. Apart from TTF font rendering it had been reached.

This means that in the perfect universe, where the work would have been merged into the DF, there would be no artificial barriers for writing multiple renderers across the platforms, be they Linux, OSX or Windows.

This in turn means that whatever rendering bug fixes and features were to come up, they would be a recompile away from being accessible not only to Linux users, but to all. Also this would simplify DFHack (and anything else) integration.

As for the lack of screenshots - it's because the project's first and foremost goal is to produce exact same result as the stock GL renderer, and since that goal was attained about a year ago, there isn't anything new to display. Now, the separate fgtestbed project while not playable, had something above and beyond, but mainly in flexible redefinition and animation of stock tilesets, so again nothing that can really be shown in static.

EDIT: stupid rant removed.

[lxnt]

TTF over OpenGL:

[Vince]

Oh, that looks nice.

[insanemal]

It seems this has gone missing from DFFD... Or is it available some otherway and I missed the post?

EDIT: Also did anybody contact Toady about this. I saw a comment by him recently (possibly the June report) about not being able to implement something because he did not know how the graphics system worked. Could be that all this awesome work might be something he would like to pick up?

[lxnt]

It seems this has gone missing from DFFD... Or is it available some otherway and I missed the post?

It's so heavily bug-ridden there wasn't much sense uploading the binaries.
But I put today's build here: http://sourceforge.net/projects/tolisnitem/

To run, being in a copy of  Dwarf Fortress directory where you un7zipped the archive, type:

Code: [Select]

./libs/Dwarf_Fortress

for the ttf + opengl3,

./libs/Dwarf_Fortress sdl2gl2

for opengl2 version, or

./libs/Dwarf_Fortress ncurses

for the pure text version.

It will most likely crash on you. Shouldn't corrupt your saves, though.

If it refuses to launch, remove libs/libgcc_s.so.1 and libs/libstdc++.so.6 files.

If it doesn't look like TTF is working, make sure the size in  [TRUETYPE:size]  token in the init.txt equals your tileset vertical size.

[lxnt]

EDIT: Also did anybody contact Toady about this. I saw a comment by him recently (possibly the June report) about not being able to implement something because he did not know how the graphics system worked. Could be that all this awesome work might be something he would like to pick up?

I think you refer to this:

Toady, how hard do you think it is to implement the fourth thing the in eternal suggestion voting (Full graphics support) and how high is it in your priority list?

Will we be able to use graphic sheets for plants like we can with creatures at some point?

As far as I know, implementing things like item or map tiles won't work without multiple texture atlases, or something, and I don't know how to do that in the new graphics code.

The most straightforward way would be for the game code to draw the map using internal tile types, plus supply some kind of material color, or code, and maybe have a default translation table from tile types to font/tileset characters somewhere in the raws,
or give it somehow to the graphics code. Then leave actual translation to the renderer plugin, which will be free to load additional graphics and whatnot.

Currently it does that conversion from tile types to characters internally, which results in the limits that can only be overcome with dfhack methods, and that would be slow and cumbersome.

In fact, there's a prototype of just such renderer I wrote before starting work on this modular stuff. Link's in the signature.

The hardest part I think would be persuading Toady that he doesn't need to do everything himself, and that he won't lose any control that way.

The whole idea with pluggable renderers is to separate game from graphics, so that Toady can be sure that no matter what he changes in the game, he won't need to touch graphics side, and existing graphics code will continue to work, and on the other hand, that graphics code can be updated without any need for Toady's attention, much less for recompiles or, Armok forbid, any modifications to the game code.

[lxnt]

~

[Taffer]

EDIT: Also did anybody contact Toady about this. I saw a comment by him recently (possibly the June report) about not being able to implement something because he did not know how the graphics system worked. Could be that all this awesome work might be something he would like to pick up?

I think you refer to this:

...[snip]

The most straightforward way would be for the game code to draw the map using internal tile types, plus supply some kind of material color, or code, and maybe have a default translation table from tile types to font/tileset characters somewhere in the raws,
or give it somehow to the graphics code. Then leave actual translation to the renderer plugin, which will be free to load additional graphics and whatnot.

Currently it does that conversion from tile types to characters internally, which results in the limits that can only be overcome with dfhack methods, and that would be slow and cumbersome.

In fact, there's a prototype of just such renderer I wrote before starting work on this modular stuff. Link's in the signature.

The hardest part I think would be persuading Toady that he doesn't need to do everything himself, and that he won't lose any control that way.

The whole idea with pluggable renderers is to separate game from graphics, so that Toady can be sure that no matter what he changes in the game, he won't need to touch graphics side, and existing graphics code will continue to work, and on the other hand, that graphics code can be updated without any need for Toady's attention, much less for recompiles or, Armok forbid, any modifications to the game code.

He may be open to having somebody else work on the graphics code. It's worth sending him an e-mail, if you haven't already. If memory serves he's expressed confusion over the graphics code several times now, and if the status quo is to wait for Baughn to reappear, then perhaps he'd be similarly open to having yourself look at things, given that you've already demonstrated the desire and ability to do so.

[lxnt]

He may be open to having somebody else work on the graphics code. It's worth sending him an e-mail, if you haven't already. If memory serves he's expressed confusion over the graphics code several times now, and if the status quo is to wait for Baughn to reappear, then perhaps he'd be similarly open to having yourself look at things, given that you've already demonstrated the desire and ability to do so.

Well, the existing graphics code shows its age, so to say, and it wasn't exactly pretty to begin with.

I think best time for any discussion of doing something about graphics would be after this year's release is out and most egregious
 bugs are fixed in the point releases. Say, somewhere about the next Future of the Fortress question submission time after the release goes out.

Until that time, I'll be engraving polishing.