Bay 12 Games Forum

Please login or register.

Login with username, password and session length
Advanced search  

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - mifki

Pages: 1 [2] 3 4 ... 99
16
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).

17
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.

18
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.

19
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.

20
Interestingly, although I don't personally like neither Meph's nor Mayday's styles - sorry guys, just too dim and detailed for my liking, so I play with Spacefox - these new screenshots look very light and clean. How did you do that?:)

Hey mifki! To be honest, much of what was in "my" first tileset wasn't my work. My personal style is indeed closer to Spacefox's and I'm trying to enforce it in this project quite a bit, much to Meph's chagrin >_< But yes, it will be harder to maintain in-game if we let the game modify the colours, which I'm trying to avoid.

Oh it explains then :)

21
Interestingly, although I don't personally like neither Meph's nor Mayday's styles - sorry guys, just too dim and detailed for my liking, so I play with Spacefox - these new screenshots look very light and clean. How did you do that?:)

(Just to be clear, Meph's hi-res and hi-detail tiles are gorgeous per se, so I wasn't quite correct talking about the style, it's more about usability of such style in game for me.)

22
DF General Discussion / Re: Upcomming announcement....
« on: March 13, 2019, 04:28:01 pm »
This is nothing but a prelude to the death of Dwarf Fortress. Every developer who has pulled this has sold out, and before long the free version is missing major features and updates, sometimes delayed by months, sometimes not present at all, and eventually? It stops being updated all together. All of those excited in the moment will, in but a few years, know exactly what I'm talking about when it inevitably comes.

So just buy the paid version then, what's the problem?
Why should I have to with a game that was previously free? That's why it's called selling out.

I can understand that, but buying simply solves your problem. If you're worried about getting updates and getting them first, I think it's easier (and fair) to pay once and receive updates for years. And with DF there's no worry about developers taking money and stopping development after some time as it happens often.

23
DF General Discussion / Re: Upcomming announcement....
« on: March 13, 2019, 03:45:46 pm »
This is nothing but a prelude to the death of Dwarf Fortress. Every developer who has pulled this has sold out, and before long the free version is missing major features and updates, sometimes delayed by months, sometimes not present at all, and eventually? It stops being updated all together. All of those excited in the moment will, in but a few years, know exactly what I'm talking about when it inevitably comes.

So just buy the paid version then, what's the problem?

24
Will TWBT continue to be developed after the release of the "new" version of DF?

I guess no as the will be no need for it.

25
This is a great app, it’s enabled me to play DF again.  The option to subscribe to a server through the app is genius. All works so smoothly.

Thanks!

I couldn’t see how to set up the direction on archery targets.  Ended up moving the save to PC to reset the direction.  In hindsight I could just have reorientated the archery range to the default direction, and left it at that.

Ooooops. It was there, probably I broke it at some point.

I hope this gets updated to the later versions of DF, but understand that this takes no small amount of effort.

Yeah, now that DFHack  0.44.12-r2 is finally available, support for it is expected very soon.

26
the anatomy looks strange, but it's a great sight nonetheless (as always!) :)

What to read on dwarven anatomy?  :D

27
Is there a way to debug twbt while running DF? I experience random CTDs while using Mephs tileset and they don't seem to be related to anything I do. Interestingly they dont happen if I turn display mode to standard deactivating twbt and I did not experience one if I turn redraw_all to 0 (but this can be a coincidence). stderr.log and all other output files do not mention anything after crashing.

What OS are you using?

28
Utilities and 3rd Party Applications / Re: RELATIONSHIP_ID's in DFHACK.
« on: December 04, 2018, 11:04:11 pm »
Ah, right, unit.relationship_ids only stores some of the relationships, the first 10. I can't say right now where the remaining ones are stored.

29
Utilities and 3rd Party Applications / Re: RELATIONSHIP_ID's in DFHACK.
« on: December 04, 2018, 06:52:27 pm »
Code: [Select]
lua @df.unit_relationship_type

30
Utilities and 3rd Party Applications / Re: DFHack plugin embark-assistant
« on: December 03, 2018, 05:45:58 am »
Fuel: I have to look at it before answering, as such a functionality would require means to figure out how to determine if a mineral can be used as fuel (as the logic shouldn't be dependent on what's in the vanilla raw set).

Coke itself as fuel is hardcoded, then you need to find all reactions that produce it and see what their reagents are. Of course theoretically you can have complex reactions with multiple reagents or reaction chains instead of the default ones, but I think some simplified checks are enough.

Pages: 1 [2] 3 4 ... 99