Print

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

[Sean Mirrsen]

Custom workshops are already in the next version, so I doubt it's much of a problem for them. Ideally, every workshop could be a separate image file containing all of the workshop in all its stages, and two raw entries like this:

Spoiler (click to show/hide)

[TILE_PAGE:WORKSHOP_MASON]
[FILE:art/workshops/mason.png]
[TILE_DIM:16:16]
[PAGE_DIM:6:6]

[BUILDING_GRAPHICS:WORKSHOP_MASON]
[TILEMAP:3:3] when loading, this much tiles are read along and down for each state
[COMPLETE:WORKSHOP_MASON:0:0:ADD_COLOR] normal sprite
[INPROGRESS1:WORKSHOP_MASON:3:0:ADD_COLOR] early progress sprite
[INPROGRESS2:WORKSHOP_MASON:0:3:ADD_COLOR] late progress sprite
[ACTIVE:WORKSHOP_MASON:3:3:ADD_COLOR] active state sprite

This is presuming that the loading code is set up to automatically split up whole images into tiles. So that you can arrange your workshop however you want without fancy raws setups. Fancy raws setups could be more efficient - so that you could, if you wanted, just set one tile to change when the workshop is active, and avoid wasting RAM - but rather unwieldy.

[zwei]

Custom workshops are already in the next version

And i would assume that any existing workshops got converted to be basically just 'preset' custom workshops, all with graphics definition and whatnot.

[Sean Mirrsen]

No, existing workshops are still hardcoded. Custom workshops still can't handle some of the default ones' properties - like item improvements and creature reactions. But once custom workshops are advanced enough, I would expect the default ones to be fully brought into the raws, yes.

[shiruba]

Custom workshops are already in the next version, so I doubt it's much of a problem for them. Ideally, every workshop could be a separate image file containing all of the workshop in all its stages, and two raw entries like this:

Spoiler (click to show/hide)

[TILE_PAGE:WORKSHOP_MASON]
[FILE:art/workshops/mason.png]
[TILE_DIM:16:16]
[PAGE_DIM:6:6]

[BUILDING_GRAPHICS:WORKSHOP_MASON]
[TILEMAP:3:3] when loading, this much tiles are read along and down for each state
[COMPLETE:WORKSHOP_MASON:0:0:ADD_COLOR] normal sprite
[INPROGRESS1:WORKSHOP_MASON:3:0:ADD_COLOR] early progress sprite
[INPROGRESS2:WORKSHOP_MASON:0:3:ADD_COLOR] late progress sprite
[ACTIVE:WORKSHOP_MASON:3:3:ADD_COLOR] active state sprite

This is presuming that the loading code is set up to automatically split up whole images into tiles. So that you can arrange your workshop however you want without fancy raws setups. Fancy raws setups could be more efficient - so that you could, if you wanted, just set one tile to change when the workshop is active, and avoid wasting RAM - but rather unwieldy.

<dorfvoice> Yes, thats wat im talking about, thats grrrrreeeeaaat!</dorfvoice>

seriously, having a 256 graphic cap sucks, let text be text, let tiles be tiles...
its so annoying when you cant tell what certain symbol means...

also, my girlfriend finds amazing the fact that I play DF because "it looks like computer board with a lot of LEDs blinking, and you keep staring it and using the keyboard, it doenst even appears that you are playing a game."

I agree 100%, since I can play DF in front of everyone in my job, and everyone thinks I am doing some extreme leet hollywood manual computer hacking of sorts.

[PTTG??]

Be careful there... I tired that and it turns out everyone in QA played it...

[Footkerchief]

1) materials get assigned to a "material graphics class"

I was just thinking how this release would make making visualisations harder if materials are no longer classed as 'metal' 'wood' etc. Really all you need are 'material' (maybe a few texture tags like you say) and a color or three.

Yeah, you could certainly get by just knowing which material template the material came from.  The material graphics class thing allows a lot more flexibility though -- essentially it lets you do a concise, arbitrarily specific cascading selection.

[Sean Mirrsen]

It suddenly occured to me that with DF's OpenGL graphics, it isn't totally inconceivable to apply shaders. For example, items made out of metal may receive a faint metallic glint.

[umiman]

Antidepressants don't make you happy. Try a far more illegal drug.

[Footkerchief]

It suddenly occured to me that with DF's OpenGL graphics, it isn't totally inconceivable to apply shaders. For example, items made out of metal may receive a faint metallic glint.

Yeah, 2D normal/specular mapping is very feasible, although there's no point unless a) the tiles are very high-res, probably upwards of 64x64 and b) the game has a notion of directional lighting.

[Sean Mirrsen]

I'm not talking actual lighting, I mean more like some very low-res bumpmapping.

Maybe the object tiles could have an overlay on them, using the original tile's alpha channel. Metal tiles could have a tiny bit of white gradient on them, perhaps with a small animation showing the (stereotypical) white streak shining across the tile. Wood and rock tiles would have some appropriate texture overlaid.

Also, there's no problem with tiles being low-res. DF can handle anything you throw at it, even resizing 64x64 tilesets to 16x16 - with relatively crappy results even on linear sampling, but it preserves quite a bit of detail.

[Footkerchief]

Well, the whole point of bumpmapping and spec mapping is that the texture changes in a non-uniform way as a result of a change in the direction of the light striking it.  What you're describing is not actually bumpmapping, but just different textures depending on material class.  The only difference from my approach is that you're talking about an overlay versus a totally separate texture.  The disadvantage of your approach is that, for example, a glass door must still have the same overall shape as a wooden door -- only its overlay can vary.

[Sean Mirrsen]

No, erm. The actual tile is irrelevant. Tiles and their changes depending on material can be handled separately when full graphics support goes in. I'm talking more about app-side things that will apply effects or textures to items with specific properties - like shiny glass or metal. I mean, of course it can be handled by the tile graphic itself - but in case of the animating "shine" or, for example the water sparkles on a pool or a water elemental, would it not be better to let the graphics engine itself apply it? Less problem for modders, plus pathway towards proper shading when lighting comes in.

Although I'm probably overcomplicating or misunderstanding things. I may even be talking of the exact same thing, just with different words. Sometimes even I can't see my train of thought.

[Footkerchief]

I mean, of course it can be handled by the tile graphic itself - but in case of the animating "shine" or, for example the water sparkles on a pool or a water elemental, would it not be better to let the graphics engine itself apply it?

It really depends.  A lot of people making DF art tend toward a pixellated look, which basically has to be hand-drawn -- doing anything with shaders would just make it a grainy indecipherable mess.  And even if art preferences turn toward higher-res stuff, it's still iffy whether people would ever find much use for it.  Look at the Infinity Engine used in Baldur's Gate, for example.  It was pretty much the pinnacle of isometric graphics -- that engine does an amazing job of compositing high-res sprites for people, clothing, armor and weapons, so that it can render any combination of equipment on a 2D character.  It still didn't attempt anything like shaders or procedural animation.  That's not to say those approaches are total dead ends, just that they're very unlikely pay off in a cost/benefit sense.

[Neonivek]

Well what it can do is apply certain blobs onto the object that is set only to apply to certain edges of an object 

[zchris13]

That entire conversation just had me screaming "GREY GOOOOOO". In my head.

Because that is what it would look like.