Print

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

[Snuggles]

Hoy, glad to be here, and, well, sorry to bring up a sore subject.  I'm an artist (oh-God,-what-have-I-done,) and I've been reading up on the debate that's making the rounds on all this.  I've been playing with a little idea that could have a lot of potential for fixing this problem without bugging Toady (much.)

But I'll clear the air first; I don't have any problem with the ASCII themed tileset.  I don't think they 'aren't pretty enough,' and their relative age doesn't bother me.  The main reason this is an issue is the difficulty with which new users, and the majority of traditional gamers/others out there, have adjusting, or even playing at all.  The problem here (a message to all those vehemently opposing any sort of graphical boost,) isn't that people want next-gen graphics that display a ton of information.  The average user doesn't mind having to click on a Dwarf to find out his preference, injuries and mindset.  The average user doesn't mind having to click on a generic looking sword to find out that it's actually an exquisite ebony jewel-laden magical blade.  The average user just wants to look at the screen and see an elephant where there's an elephant.  (Honestly, most people wouldn't really care that you can't see that it's a 3-legged african albino clone elephant from mars from its plain, generic elephant model/sprite.  People would complain, but they always do, and by god this is problem solving here.  Complaints that implementing graphics is impossible because of the amount of assets needed are a little unfounded because of this reason; generic is fine.)

The work happening on the tileset is great, and once it's rounded out and finished, it'll be a fantastic system to work with.  This is just a little idea about how far the graphics could go with as little distraction for Toady as possible.  ...So I'll get on with it already.

What's the potential for outside programs that create alternate graphical front-ends for Dwarf Fortress?

Would it now, without even a lick of Toady's help, be possible to make a program that would run alongside DF (ontop of it), reading what's going on in DF and displaying it in its own custom format and then sending commands entered by the user into the frontend back to DF?  It would be a bit silly to have an entirely seperate program running for it, and I'm not sure how bad the lag between the two would be, but...?  It doesn't seem entirely preposterous to think that most modern computers could run DF and a seperate graphical application simultaneously.

Or, for the purpose of keeping things clean for the Toadster, what sort of work would it require to make it possible to switch off DF's native front-end and route all the information that would normally be displayed,  (And the display information only, which is already available when we play the game, so it'll remain completely closed-source,) to a seperate program entirely?  

Apologies for my wide lack of code expertise, this just came to me as a big, possible solution to a lot of accessibilty and graphical problems.  With a large enough force of dedicated programmers and workers, DF could practically be molded into, say, a Dungeon Keeper visually stylized game that could appeal to thousands of new players.  

The ramifications, of course, wouldn't solely be graphical, either.  Front ends would obviously also function as alternate GUIs.  Users (with code know-how) could arrange and customize things as-they-see-fit, with the right time and effort.  We could see DF frontends that provide users with dynamic ways of streamlining information; side-windows that provide brief information on highlighted objects and a full report at a request without having to switch screens or sacrifice productivity, front-ends that watch for 'important events' and provide an easy to us zoom-to function and/or thumbnails of the event.  Quick-keys for common tasks...well, it seems like the possibilities are pretty much endless.  

Silly as it sounds, I have this dream of how awesome it would be to see an entire fortress bustling with semi-3D activity.  Of course, the only 3D objects would be characters for ease of animation, and even then they would be probably under 100 tris each (imagine the 3D models you see on the DS nowadays,) and color coded for profession.  With only like 3  or 4 animations.  ...Seriously, that's all you really need, anyway.  With a good art director at the helm this sort of presentation would be so freaking effective.  Makes me wanna pen an asset list as I type.  Apologies for the ridiculous length, I just get that way sometimes.

[TakiJap]

I like the idea and hope that it'd be possible to do. Although I fear that animated models just wouldn't fit to other graphics.

I would be more than happy with just unanimated 2D sprite characters going around in a 3D fortress with possibly ASCII textures on walls and such. Even better would be if I could see outsides of the fortress in 3D view and even adventure in 3D world with 2D sprite '@'.

Which leads me to another idea I'd want there to be. I really would like to have a simple third party program which would show a simple picture of my adventure mode character and his equipment. It's nice to have every piece of clothing viewable in the inventory, but there's just too many of them for my memory. Darn difficult to picture what my character looks like, when I can't remember even half of what his wearing.

[flap]

Must be possible through hacking. The second proposal would be much easier to execute.

But now, is someone ready to spend time on that ?

I might be able to help for the part "writing a program getting what you are wearing". But I would definitionally not go to the point is draws what the character looks like.

[TakiJap]

I could do the graphics if you'd really want to go through coding it. I would appreciate it very much.

[lumin]

quote: I would be more than happy with just unanimated 2D sprite characters going around in a 3D fortress with possibly ASCII textures on walls and such. Even better would be if I could see outsides of the fortress in 3D view and even adventure in 3D world with 2D sprite '@'.

This is very similar to what was done in the original "DOOM" game.  The sprites were 2D, but when you walked by them, the image always turned to face you.  

If there's a 3D look I'd like to see in DF, it would be identical to the look of Dungeon Keeper when moving in first-person mode.  When I played DK, I used to spend hours just walking around the caves/dungeons as a creature admiring the eerie sense of clausterphobia.  The graphics were nothing spectacular, in fact, the low resolution left a lot for the imagination.

[Keiseth]

You're quite right that the average user doesn't mind seeing a generic sword but finding out it's some incredible chainsaw sword of excessive violence.

Hell, I grew up with an NES. I moved backwards into ASCII graphics after I saw a webcomic spoofing NetHack. "Whoa.. That's... God, I'd love to play that just to annoy the hell out of everyone who walks by my computer!" and it escalated from there.

Heh, remember all the old NES games? Final Fantasy had a thousand recolors of the same sprites for new enemies. Megaman; you could switch to some sort of fire weapon and you'd just change color. But nobody cared! Nowadays, when you switch to a "fire weapon", your character immolates with impressive three dimensional lighting effects casting six shadows across a high resolution texture on the floor. XD

Actually, Dwarf Fortress has incredible ASCII graphics. I went and played another Roguelike lately and I was sort of depressed with the character set. DF has interesting symbols to represent things whereas a lot of Roguelikes just have letters and a couple keyboard symbols. DF has spoiled me, I think!

[Snuggles]

I was more using the 3D thing at the end as just a possibility.  For the most part, the important thing about the concept is that it would enable people to mold DF's graphical stylings and interfaces into whatever they wanted to do (and have the means to accomplish,) I just honestly have no idea how feasible it is.  

Early Doom or Dungeon Keeper would still be a great style to work in, though, too.  

[claymore666]

i pretty much refuse to play DF until there's a graphical frontend with a point and click interface.

I will help anyone looking to make a graphical frontend (ultima online style perhaps??).  I am adept and all aspects of computing but havent made games except for a bit of scripting/ hacking.

email:  claymore_666@hotmail.com

Anyone interested in perhaps a tile designer or anything? email me!

[DJ]

I'd help if this project got started. I know a bit about coding, but I never did any memory hacking so I'm not sure I'd be of much use there.

I could also do graphics, though I'm not sure how good I am. Here's a screenshot of a game I'm making (it's been on hold for months now):

That's all done in MS Paint. I've discovered the wonders of GIMP since then, and this is an example of what I can do with it (note the horrible angle of legs):

[penguinofhonor]

.

[0x517A5D]

I must agree, it would be really cool to do this.

But even before this could start to be, the game would need to be decoupled from the current graphics engine.

There are dozens or hundreds of places that assume the viewport is 80 by 25.

I can't tell from the game's executable how much is hardcoded and how much is wrapped in nice #define constants, but the situation doesn't look good.

[Sofaspud]

(Disclaimer: I work professionally as a developer who specializes in integrating different applications -- making them 'play nice' together, if you will.)

Part of the problem with this proposal is that DF is a fast-moving target right now.  You've got, basically, three options that I can see to get the information you would need to DO this stuff:

1) Hook into the window and monitor it as DF updates it.  This is quick and easy to do, but is very, very ugly.  The main problem with it is latency: reading the display is (relatively) slow, and then you have to interpret it, plus, you're only seeing the top 'layer' at that time (what about when multiple objects overlap, and DF flashes between them to show that?).  By the time you've drawn your own output, DF has moved on another (wild guess) ten frames.  It could be done, but I doubt anybody would be happy with the results.  This DOES have the advantage of being relatively version-independent, though.

2) Through some clever memory manipulation, it would be possible to read the state of DF at any given time and bypass (or rather, ignore) its drawing routines entirely.  You would read the state of the world directly from memory (which is lightning fast compared to reading the display window) and interpret and display it yourself.  Problem is, nobody knows at this point how Toady actually references the world, or what the world map 'looks' like.  It would require some massive effort to map this out.  In addition, I suspect Toady represents portions of the world with functions rather than a 1-to-1 map (ore veins, flora on the surface, etc), which would make it harder (possibly impossible) to interpret, if true.  Finally, this is incredibly version-dependent, and with new versions coming out every couple of weeks it may or may not be feasible.  (If the memory structures stay stable from version to version, you might only have to find the right 'offset' to begin from; if they change, all bets are off  

3) Convince Toady to develop an API of some sort.  In essence, decouple the graphics engine from the game engine.  This is the ideal solution, but requires massive effort on Toady's part, since he's not willing (with good reason) to open it to other developers.  Toady's got better things to work on, at the moment, I would assume.    This is grunt-work, pure and simple; it entails going through the code almost line-by-line, looking for instructions that reference the display and replacing them with ones that reference the (yet-to-be-created) display *engine*.  Then he'd have to create the engine itself and make sure it's working, just to keep DF where it's currently at.  Only after that was done could he move on to the last necessary step, which is documenting how DF references the engine.  After all that, and only then, would it be possible for others to develop their own display engines, with full whizz-bang 3D graphics and so on.

[sphr]

@Sofaspud

1) not feasible, unless DF caps it's framerate and runs like a trottled turtle.

2) you may want to read the memory hacking pages on wiki.  There is already an active group diligently mapping out the memory structures.  Those are the same guys that brought the utilities to us.  anyway, better than 1) but prob still not feasible.  read/write from shared memory is always tricky and in this case, one party is totally ignorant and non-cooperative.  Not safe too unless you suspend the DF process everything you do some bulk read/write.  Now imagine DF keeps getting suspended and resumed repeatedly....  maybe it'll reach the current speed in say a machine a couple of years from now...

3) As a professional developer, you should know above all others that ideal and achievable are very distinct.  I think from reading the dev notes, toady does have plans to free up some of the 80x25 hardcoding, which will be the first step towards decoupling the ui.  But frankly speaking, after I get used to the ui, I'll rather that he spend time on more important stuff, but it could be just me.  lol, between say offering nicer gfx to attract new players and adding new features/bugfixes, I'll say sorry to new players. sorry    But no other comments on this, as this is really Toady's say.

sidenote: I dunno if it is just me getting used to the game or what, but I don't really find the gfx part insufficient, especially after the ability to use custom creature tiles is added.  But it could just be my eyes getting used to the "raw code".... hey look, a Lady in Red!

[0x517A5D]

quote:Originally posted by sphr:
<STRONG>sidenote: I dunno if it is just me getting used to the game or what, but I don't really find the gfx part insufficient, especially after the ability to use custom creature tiles is added.  But it could just be my eyes getting used to the "raw code".... hey look, a Lady in Red!</STRONG>

It took me about my first day of playing to be able to "see the Matrix."  Since then, I've tried a couple of the graphics font mods, but have always reverted to the bog-standard 640x300 font (doubled to 1280x600).  I was already used to Roguelike games, and I value the instantly-recognizable information in the standard font.

Edit: Once I figured out that the weird workshop tiles are a representation of how it would look vertically, I was happier.

[ December 30, 2007: Message edited by: 0x517A5D ]

[0x517A5D]

quote:Originally posted by Sofaspud:
<STRONG>2) Through some clever memory manipulation, it would be possible to read the state of DF at any given time and bypass (or rather, ignore) its drawing routines entirely.  You would read the state of the world directly from memory (which is lightning fast compared to reading the display window) and interpret and display it yourself.  Problem is, nobody knows at this point how Toady actually references the world, or what the world map 'looks' like.  It would require some massive effort to map this out.  In addition, I suspect Toady represents portions of the world with functions rather than a 1-to-1 map (ore veins, flora on the surface, etc), which would make it harder (possibly impossible) to interpret, if true.  Finally, this is incredibly version-dependent, and with new versions coming out every couple of weeks it may or may not be feasible.  (If the memory structures stay stable from version to version, you might only have to find the right 'offset' to begin from; if they change, all bets are off  
</STRONG>

I have found the draw-character routine that is used by all font-related output.  (It may not be used for the creature graphics sets.)  It would be possible to hook that with a custom debugger, walk the stack to see what kind of output it is, and branch accordingly.  Hard, may not actually be feasable, but is possible.  Anyway, that would at least avoid race conditions.  The bad side of that is you'd still be restricted to the 80x25 window.  Another bad side is that breakpoints cost lots of cycles -- much more than a normal context switch.

Or you could hook the flush-output-buffers routine, and at that time do the memory parsing as you envision.  Again, that buys you immunity from race conditions.  But is harder, as you'd have to display everything without context clues -- you would essentially be reimplementing the entire display system.  Without having the source code to study.  And you would still have to parse the 80x25 viewport at some point, to look for those popup messageboxes if nothing else.

Actually, I'm envisioning a hybrid system.  The standard 80x25 is still displayed, and in another window, the alternate view.

Version-dependency can be worked around to some extent.  All of my utilities are written to attempt to be version-independent, so it can work.

I do wonder how Toady feels about us talking about abusing his precious baby on these forums that he runs himself.