Print

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

[mifki]

Thanks all for the support!

Of course it's a bit sad the story of TWBT will be over and forgotten eventually. But I started TWBT because I personally couldn't play with the graphics as it was back then (mainly the unreadable text due to single text/map tileset). Then I added more and more features, the second most important one for me being multilevel rendering. But the original intention was just to make the game visually not so painful - if it had better graphics back then, I would just play it (and wouldn't probably have done my other DF projects, but that's another question). So I'm certainly happy that now everyone will be able to just play the game with enjoyable UI - the goal is achieved, one way or another. I, too, can stop developing (TWBT) and start just playing, which I also will be happy to do.

I probably missed some of the discussion, but I didn't quite understand who's going to develop the new rendering code. Kitfox? To protect Toady's main code, will it be a separate library again, sort of a new libgraphics? Because I hope all of the current TWBT features will be available, and the new rendering engine will be updated from time to time unlike the current graphics code which was also done by a separate developer and hasn't been touched after that. If not, depending on how it's done, maybe it will be easier now to change/extend rendering? Even though I'll probably be happy with what the game will have out of the box, there will always be thing other people would want to see, for example, animations, which definitely won't be in DF for now as I understand.

The development and even, sadly, bugfixing isn't active enough lately due to the lack of time for all my online and offline projects. But surely I'll update TWBT until a version with new graphics is available.

[ragundo]

Mifki, I think that no one is more adecuate for developing that new library than you.

Toady and Kitfox, you are hiring people for the music, and new tilesets, etc. Do the same with the graphics library.

Just my 5 cents

[Meph]

Tarn himself does the coding. No one else has access to the source code. Kitfox only does bureaucratic and PR things.

For things like animations, which might be a bit of a stretch due to the high number of sprite, my hope is to convince Tarn to at least add the capabilities, and let the community figure out the rest.

[Pvt. Pirate]

Tarn himself does the coding. No one else has access to the source code. Kitfox only does bureaucratic and PR things.

For things like animations, which might be a bit of a stretch due to the high number of sprite, my hope is to convince Tarn to at least add the capabilities, and let the community figure out the rest.

that would be absolutely ACE!

[PatrikLundell]

I was afraid Toady would do the graphics engine coding, given how unhappy he was with not being able to update the existing one due to lack of insight in how it worked. This means another derail from the derail from the detour from the path to the Big Wait, unfortunately. It would certainly make sense if Toady at least had a discussion with mifki to speed up the process through the pitfalls, but I suspect that goes contrary to how Toady work and works.

[mifki]

Tarn himself does the coding. No one else has access to the source code. Kitfox only does bureaucratic and PR things.

This worries me now. When I though someone experienced with creating modern game UI was going to do that, I was more confident it would be done, well, in a modern way and would include all the features we want. Partly because of the said experience, partly because it wouldn't take time from the game development itself and thus not be restricted by the time available.

I'll list all TWBT features again, can you tell which ones you have discussed with Tarn for inclusion in the new engine already? Or maybe the list will remind you to talk to him about something.

* Separate map/text tileset. Always requested but never implemented is a separate world map tileset.
* Multilevel rendering. On desktop, the top X levels are rendered and visible on screen. On iOS, all levels are visible but only the top X levels are updated, the others are shown in grayscale to indicate the tiles may be outdated.
* Overrides to display individual tiles for item types, subtypes and materials, with some support for animation and randomisation.
* Multilayer rendering - items, buildings and creatures have transparency and rendered on top of the ground tiles, not instead of them. Currently two layers only, ideally need to handle creatures on top of buildings (on top of the floor).
* Support for only parts of tiles to have material colour and parts have constant colour.
* Minor, but there's an option to hide stockpile backgrounds unless in [q], [p] or [k] modes.
* Exporting full size screenshot of fortress map as it's rendered by TWBT. Mentioning this because DF currently have map export, so that will need to be updated too.

[Shonai_Dweller]

Coding and designing aren't the same thing (necessarily). There's no reason Tarn can't take advice on how to implement a UI from the experienced team he's now associated with, all of whom have a vested interest in seeing DF be successful.

[waterphage13]

Tarn himself does the coding. No one else has access to the source code. Kitfox only does bureaucratic and PR things.

This worries me now. When I though someone experienced with creating modern game UI was going to do that, I was more confident it would be done, well, in a modern way and would include all the features we want. Partly because of the said experience, partly because it wouldn't take time from the game development itself and thus not be restricted by the time available.

I'll list all TWBT features again, can you tell which ones you have discussed with Tarn for inclusion in the new engine already? Or maybe the list will remind you to talk to him about something.

* Separate map/text tileset. Always requested but never implemented is a separate world map tileset.
* Multilevel rendering. On desktop, the top X levels are rendered and visible on screen. On iOS, all levels are visible but only the top X levels are updated, the others are shown in grayscale to indicate the tiles may be outdated.
* Overrides to display individual tiles for item types, subtypes and materials, with some support for animation and randomisation.
* Multilayer rendering - items, buildings and creatures have transparency and rendered on top of the ground tiles, not instead of them. Currently two layers only, ideally need to handle creatures on top of buildings (on top of the floor).
* Support for only parts of tiles to have material colour and parts have constant colour.
* Minor, but there's an option to hide stockpile backgrounds unless in [q], [p] or [k] modes.
* Exporting full size screenshot of fortress map as it's rendered by TWBT. Mentioning this because DF currently have map export, so that will need to be updated too.

The development of graphical DF is in too early phase now. TWBT gives more graphical content than "new" version. It don't have overrides and multilevel. There are so many tilesets are depending on TWBT. Please, don't stop updating.

[Heretic]

Looks really like DF in agony now.TWBT is dead, DFHack is probably too, utilites and tilesets too. Terrifying.

[Toady One]

Hey!  Some of those features are already in the trailer, right?  I'm not a graphics guru by any stretch, but I read through and basically understand the SDL code, then produced the transparency/edging/etc. features that we have so far.  I'll also be able to decouple the grid, do the fonts, etc. etc.  There might be some bumps, but I think it's premature to panic.  Also, the executables are going to be about the same as before, the mem address hack stuff I put in (with mifki's help as I recollect?) will all still be there in the same way, and I don't have a problem doing more of that if it helps.

edit: and when I say "do the fonts", I don't mean draw them myself, ha ha ha.  Support.  Support the text apart from the graphics with different grid sizes.  Not sure I want to dive into more true type stuff, since that has been iffy and isn't my realm.

[mifki]

I'm not worried about DFHack, no need to panic about that. Of course, there will be a lot of work because of data structures changes, and also because I guess we won't have an open-source libgraphics anymore and it was very useful to understand how the game and UI loops work (but Toady can help us here I guess, also there was an SDL_NumJoysticks() hook for DFHack).

Hey!  Some of those features are already in the trailer, right?

Meph mentioned the screenshots they're showing were done in photoshop. But the trailer is a real game video then?

I'm not a graphics guru by any stretch, but I read through and basically understand the SDL code, then produced the transparency/edging/etc. features that we have so far.  I'll also be able to decouple the grid, do the fonts, etc. etc.  There might be some bumps, but I think it's premature to panic.

That's good to hear really, although when talking about rendering thousands of tiles (and possibly multiple layers/elements for them), it's very important to optimise it properly. I'm afraid just using SDL (and not manually crafted OpenGL code) may not work (or CPU usage will be too high). Another problem is the number of different tile images that may not fit in one GPU texture anymore - so the texture switching needs to be done efficiently as well. The modern approach would be of course to use shaders that are perfect for rendering repeating grids (and nowadays there's no real need to worry about any hardware that might now support them or OpenGL in general). Please do run some tests so that any performance issues are apparent while it's not too late.

But first of all am I even right thinking that you ditched libgraphics code and replaced with all new game loop/rendering code? If not, what parts are you reusing?

edit: and when I say "do the fonts", I don't mean draw them myself, ha ha ha.  Support.  Support the text apart from the graphics with different grid sizes.  Not sure I want to dive into more true type stuff, since that has been iffy and isn't my realm.

Some people may be unhappy without TTF but yeah it adds a lot of unnecessary complexity to the code I guess.

[Toady One]

Yeah, the trailer is a real game video (what I spent a week on earlier when I didn't have a dev log.)

I'm building on the old code currently - and I haven't found a reason to change the basic structure there yet (certainly there'll be extra grids etc. in time.)  Every surface there was already allocated separately; the atlas is long gone apparently, and there isn't any large-scale swapping or binding.  It just blits separate little surfaces from a non-texture-atlas catalog by index and coloration (as the number of textures grows, pulling from that catalog might also need to be checked?  Not sure what experiences people have had there if any.)  It only refreshes tiles that are updated (though of course when you scroll, most tiles are changed, so you can't 100% rely on that - so it's important to make sure there aren't tons of layers used everywhere), and that carries over to multiple layers -- I just have a few extra flags to check on the refresh.  There's *potentially* an optimization problem there, doing a few extra checks on the screen texture index arrays, but so far so good (that is, 100 FPS on my crappy computer, and I also get 100 FPS when I just draw every tile.)

My plan is to release all of my code changes, just as I've been doing up to this point.  The free Dwarf Fortress Classic Linux version will have the same folder as usual, with all the same files (and any new ones), and that'll be the same (basically) as the Steam code.  My understanding is that the licenses from the contributors are in order - at the time, I requested BSD/MIT or equivalent/looser licenses, as I wanted anybody to be able to use the code in their projects, no matter if they were commercial or not, as a condition of using the code myself.

So yeah, I'm going to be sharing all of the new rendering stuff, in basically the same format as before, and between classic and steam it shouldn't be all that different.  That's the plan anyway!  Certainly if there are issues, hashing them out now rather than later is good.

[mifki]

Ok sorry then I got confused by your old statements (that you could not make changes to libgraphics because you didn't understand it or something else).

Every surface there was already allocated separately; the atlas is long gone apparently, and there isn't any large-scale swapping or binding.  It just blits separate little surfaces from a non-texture-atlas catalog by index and coloration.

Every tile is drawn separately? Now I'm worried again because doing many drawing calls is one thing that's VERY bad with OpenGL. Of course it will work but at a cost of enormous CPU usage (which possibly will cause other problems with time).

My plan is to release all of my code changes, just as I've been doing up to this point.  The free Dwarf Fortress Classic Linux version will have the same folder as usual

That's great. Btw, what's the reason libgraphics is a separate binary on Linux only and compiled in on other platforms? If it were separate on all platforms, we could make changes/optimisations to it even without DFHack (as long as they don't need any additional game data of course).

[Toady One]

Ok sorry then I got confused by your old statements (that you could not make changes to libgraphics because you didn't understand it or something else).

I didn't back then, since I hadn't looked at it and didn't have an expectation of being able to pick it up quickly, since I'd never used SDL before.  Sorry if the way I stated that made people nervous.  I won't say I understand all of it now yet either, but the overall processes are making more sense to me.

Every tile is drawn separately? Now I'm worried again because doing many drawing calls is one thing that's VERY bad with OpenGL. Of course it will work but at a cost of enormous CPU usage (which possibly will cause other problems with time).

This is how it works in the currently released version people play now.  I'm not sure how the SDL blits work down where they hit OpenGL, and yeah, I'd anticipate them to be slow (given how texture binds have worked in my own side projects not in SDL), but I'm not changing it too much from how it currently works, and it's pretty fast there?  Or has 44.12 been having trouble on some cards?

That's great. Btw, what's the reason libgraphics is a separate binary on Linux only and compiled in on other platforms? If it were separate on all platforms, we could make changes/optimisations to it even without DFHack (as long as they don't need any additional game data of course).

I just don't know how to set up a DLL properly on windows...  I'm really tired right now (sorry! no sleep!) but there was some part of that which was quite irritating to get hooked up.  On OSX I know absolutely nothing.  For the process of the original ports, just getting it working on one OS was sufficient for everybody to work without having to see the rest of the code.

[lethosor]

For reference, there are circular dependencies between DF and libgraphics (at least one of which is a vtable). Linux's linker handles that fine, and macOS's should be able to with an extra flag. Windows really doesn't like that, though - I tried coming up with a way to make it work involving dynamically loading symbols a few years back, and ended up confusing Toady and myself. It's probably doable, but would take a questionable amount of effort.