Looks great. If someone were to come up with a way to make this real without making it too tasking on the ol' processor, I would never leave my home again.Quite honestly, the graphics resolution and style depicted above used to be run on 486 class processors. Today's processors and GPUs could handle that hundredfold.
if unrevealed tiles are... Well, not revealed.
Ohh, a reveal feature? Does it break Magma stuff like reveal usually does?My guess, looking at how it works, no. Tweak flags tiles as revealed, whereas that is supposed to read the tiles and display them, I think.
Good lord that is beautiful. It would be really hard to make ramps and stairs look that good though.Thanks for the compliment! On the note of ramps and stairs, I don't see making them respect local terrain being that hard... besides, a lot of 3D engines already take ramp direction into account, and stairs are a logical extension.
¬
¬
¬
───
⌐
⌐
⌐Honestly, I'd be happy with the color palette used in the mock ups. The problem with 3D viewers is always going to be that they're never going to look great from -every- angle. At least with the Isometric method, everything will look exactly as it's meant to from a given rotation.
Just posting to say that this topic brought me to an entirely different task. So, I open the DF.exe with a hexviewer to see whether, by chance, the code is still legible... no chance. I do, however, see the menu strings and stuff.
Now I'm currently translating Dwarf Fortress to German. It will probably be ugly and is most definitely a shitload of hard work. But it's getting done =)
Now I'm currently translating Dwarf Fortress to German. It will probably be ugly and is most definitely a shitload of hard work. But it's getting done =)
I'm no programmer, but something I've always wondered about; wouldn't one method of doing this be to use a custom tileset in DF (designed to be easily recognizable to the GUI program), and have the GUI program quite literally 'look at' the DF window to get its information?
A method would be to "inject" the graphical isometric engine code into the DF executable, substituting the calls to the "ascii" standard renderer with calls to the Iso renderer. That would require a major understanding of DF rendering engine internals, but is feasible. Hard, but feasible.The graphics have been completely reworked through the new OpenGL/SDL 40d# versions linked in the News links up top.
Mmm, Kobold Quest still uses the same engine as DF? If yes, it's opensource and one could take a look at it to ease the search for the right instructions in the DF executable.
Now I'm currently translating Dwarf Fortress to German. It will probably be ugly and is most definitely a shitload of hard work. But it's getting done =)
One of the bigger problems in doing a translation is that often the target language's phrases are longer than the English ones. This is especially common in German, as it is a wordy, agglutinative language.
>>I am working my way around it by abridging which, in some cases, provides garbled stuff, but the goal of the project is not to provide a perfect translation, just an (mostly) understandable one. But, pretty much, I am building that entire project on one of my unproven assumptions, so it may just as well go haywire.
The utility German Menu -- Deutch Menue (http://dffd.wimbli.com/file.php?id=913) shows one way around that, by allocating entirely new memory and changing the string pointers in the code.
>>Above my league.
That utility is open source under the MIT license -- feel free to do whatever you like with it.
The other problem in doing a translation is that the strings in DF are "merged" -- that is, when multiple pieces of code use the same string, they all point to a single copy of that string. The above utility does not solve that. (I have some thoughts on a solution, but nothing written.)
>> Nothing I can do about.
The third problem, which I have no ideas on solving, is phrase ordering. If the target language has different noun/verb ordering, for instance, most of the sentences which are built from multiple pieces (e.g. a piece of text, then a dwarf name, then another piece of text) will be ungrammatical.
>>That is, I most probably won't be able to solve the grammar problems. But if you can make out the meaning, it's okay for me.
I thought the data of your whole embark location is stored in your memory. You just read that out and visualize it. Every input from the GUI would have to be forwarded to DF, tough.
A method would be to "inject" the graphical isometric engine code into the DF executable, substituting the calls to the "ascii" standard renderer with calls to the Iso renderer. That would require a major understanding of DF rendering engine internals, but is feasible. Hard, but feasible.
Also, I heard a rumor about the graphics library being made public in the next release, so this may become infinitely more feasible.
this looks so awesome. the graphics remind me of the game xcom: UFO defense which was another awesome game.
A method would be to "inject" the graphical isometric engine code into the DF executable, substituting the calls to the "ascii" standard renderer with calls to the Iso renderer. That would require a major understanding of DF rendering engine internals, but is feasible. Hard, but feasible.
One of the bigger problems in doing a translation is that often the target language's phrases are longer than the English ones. This is especially common in German, as it is a wordy, agglutinative language.
>>I am working my way around it by abridging which, in some cases, provides garbled stuff, but the goal of the project is not to provide a perfect translation, just an (mostly) understandable one. But, pretty much, I am building that entire project on one of my unproven assumptions, so it may just as well go haywire.
The utility German Menu -- Deutch Menue (http://dffd.wimbli.com/file.php?id=913) shows one way around that, by allocating entirely new memory and changing the string pointers in the code.
>>Above my league.
That utility is open source under the MIT license -- feel free to do whatever you like with it.
The other problem in doing a translation is that the strings in DF are "merged" -- that is, when multiple pieces of code use the same string, they all point to a single copy of that string. The above utility does not solve that. (I have some thoughts on a solution, but nothing written.)
>> Nothing I can do about.
The third problem, which I have no ideas on solving, is phrase ordering. If the target language has different noun/verb ordering, for instance, most of the sentences which are built from multiple pieces (e.g. a piece of text, then a dwarf name, then another piece of text) will be ungrammatical.
>>That is, I most probably won't be able to solve the grammar problems. But if you can make out the meaning, it's okay for me.
So, I just tried my work up to this point out. Turns out, a) doing strings longer than the original english string length seems to mess the system up. A shame.
And b) there seems to be a hardcoded plural somewhere, which is also looking uglier than I'd tolerate. Alas, I didn't figure out how to convert the hex into legible code I'd be able to hack into, so I'm pretty much stuck.
This looks absolutely beyond amazing. Isometric tile games are by far my favorite...
I've been fooling around writing an isometric engine actually and made quite a bit of progress... (mouse-clicking is finished except for stacked objects)
If you don't mind me asking, what pseudo 3d tiling program did you use to create those graphics?
Depending on the language you will be writing this in I might be very interested in helping...
Cool. But won't you need to make to make the background in that transparent?
Also, thus far I don't have a programming language of choice, as I can barely program my way out of a paper bag. A few semi-interested folks on IRC have mentioned C++ (the only language I can use semi-effectively). Did you have any ideas?
Terribly hard. Trust me on this. Injected code is hard.
Hard, but feasible.
Actually, I don't know much about this, but can you read the map information somehow while you play Dwarf Fortress or how was this going to be accomplished?
I already have been working on a design idea for this. It is possible to hook the SwapBuffer function, in the SwapBuffer function it snapshots memory and pipes changes to whoever is interested. I was/am planning on stuffing code for that in my opengl32.dll wrapper.A method would be to "inject" the graphical isometric engine code into the DF executable, substituting the calls to the "ascii" standard renderer with calls to the Iso renderer. That would require a major understanding of DF rendering engine internals, but is feasible. Hard, but feasible.
Terribly hard. Trust me on this. Injected code is hard.
What I think would be feasible is injecting hooks which pass a windows message to the rendering process. "Hey, I have finished a game frame, so copy my memory now." Sending a message is easy.
Then stall until they either get a message back (receiving a message is hard, since we would have to hook the game's actual message loop), or wait for a memory location's value to change (easier, but wastes CPU cycles).
Oh, the renderer could put DF to sleep then wake it up again. No problems there. And thinking about it, the DF hook should attempt a context change to the renderer immediately after sending its message. (How? Sleep(0)?)
The renderer should be multithreaded and "double-buffered" so that it can render from the previous frame while sucking the current frame out of DF. It should not be a lock-step process. (Except on a single-core system, which might see minor gains by being lock-step.)
Lots of should's. I can do a hook as described above, I can't do the other stuff.
please don't pester him, I don't want him to commit suicide from the stress you'd impose on himA method would be to "inject" the graphical isometric engine code into the DF executable, substituting the calls to the "ascii" standard renderer with calls to the Iso renderer. That would require a major understanding of DF rendering engine internals, but is feasible. Hard, but feasible.
I'm sorry, but that's not feasable, it's close to impossible. Instead of dreaming up all kinds of almost-impossible solutions, we need to convince Toady that a graphical overheal should be a higher priority than some of the other stuff he's working on ;)
Terribly hard. Trust me on this. Injected code is hard.Hard, but feasible.
Never said it would be easy. ;)
...So my opinion is that any work in this area should be at least a thought experiment, at most an organized, concerted effort to figure out how the hell one would actually go about controlling a game that seems to be so well suited to 2d layers and not isometric slices. That way the Bay12 Team has a good starting place at worst, a detailed design document at best.
but I don't think it makes much sense to focus purely on dreaming up a design without ever intending to implement it.Exactly. Remember the site finder utility? By LordZ's logic, that utility never should have been made, which doesn't sound like a good thing to me. Just because Toady might go Syler on a utility is not a reason to give up on actually making it.
.O. .O. .O.
OD. ODO ODO
... ... .O. and rotations, just to point out the useful ones.OO. OOO
OD. ODO
... OOOI saw one mockup with a strange octagon thing that was supposed to sort-of-work in all cases, but I think just plonking down a square-filling cube might be best.Can anybody answer me: what's the point in 2d sprites in 3d GUI thread? They are really beautiful (nice job Solifuge), but we'll need 3d objects, not sprites, right?Yeah...I think Solifuge meant 2D Isometric GUI, not 3D.
On the side, Sol, you'd need a few more than two door tiles:The tileset is far from complete. I'd want different textures and colors for different stone, smoothed, and constructed wall types, boarder tiles to transition between grass and dirt, etc. I'm cranking them out at a slow pace, but more than these are done. My brother slapped together a Simple HTML Map Editor (http://glenholdampf.dynalias.com/files/iso/editor.php) for testing tiles, and just for general mucking around with them too, if anyone wants to play with them.
Welcome to the forum, Jonas. That looks like a great start. There are no current 2D isometric visualizers I know of, although the 3D visualizer Khazad (http://www.bay12games.com/forum/index.php?topic=41927.0) has an isometric mode.
Anyway, I'm dabbling with some isometrics myself, and using DFhack I made some stuff.Wait, are these already ripped from the game (I mean terrain info), with the objects like trees, and your visualizer builds the picture based on it? If so, great :). At first I was afraid that this is another discussion thread with great ideas, artist and people talking but nobody taking the main role, but if you did it, that's a good starting point :D. Too bad I am a dabbling coder, using python and C here and there without much knowledge, but at least I will be one of those many who will praise your work and offer 2d images/3d models :).
Greetings jonask84, glad to hear your a fan of Khazad, I'd love to get some feedback on any problems/difficulties you experienced so we can try to adress them. Navagation is a primary concern of mine and a big challenge in 3D space.Honored to meet you Impaler! Let me tell you straight away I love your code, and let me also extend my thanks for making it so clear and easy to understand :)
I's good to see that progress is being made on a 2D isometric engine. Though I'm using 3D isometric, the 2D style is certainly a concept that should be explored. I'ts also good to see that Peterix's dfHack library is getting used, it's really serving the purpose of getting people over the 'hump' of reading data from DF and right into the meat of making a renderer. Good luck and keep in touch, I imagine we can share design tips and strategies.
What you really want is the 40d## I/O source, which is probably publicly available.Some code comes with the d## linux version, at least.
hmm...if DF supported transparencyThe 40d# versions do. That's what the deal is with some of the newer tilesets, like PTTGV5.
To put it bluntly though... it doesn't matter. You can't do psuedo isometric because each tile is in the same row. Where iso requires alternating rows. Not only that, the tiles are not placed via central coordinates. Each tile uses an x,y linked to the top/left corner. I would actually love to see the builds use a center point and align each tile to that. You could have oversize tiles and allow them to overlap textures for better transitions.hmm...if DF supported transparencyThe 40d# versions do. That's what the deal is with some of the newer tilesets, like PTTGV5.
If you PM me your email
One, look at the full text of what I said. Two, click on the spoiler. For this style tile(north=up-right) what was top left corner of 0,0 is now at (tilesize(rows-1),0) instead of the origin.One, what I was talking about is putting a tile set in the engine as it is now. It's impossible. Two, don't talk to me that way. (it's late, I'm grumpy and your post sounds condescending.) The game engine would have to change for that to even work. When it was mentioned that the current engine has transparency, I stated the blunt obvious that it wouldn't work with the tiles as they are now where (0,0) is top/left and not staggered. You'd need code changes and simply plugging in an isometric looking tile set WILL NOT work.
in tiles:
(+1, 0) -> (+1/2, +1/4)
(0, +1) -> (-1/2, +1/4)
Like I (and Toady) said: "draw order and locations". Transparency raises the issues of maybe needing to draw the underlying tile as well as unit/item, but if you're drawing anything with an alpha channel (which we can now do) then it just means draw tile then item, if you want to use painter's algorithm:
1
2 2
3 3 3, etc. (With multiple z, you would just do each column bottom to top in that order- but then, you probably want to do occlusion checking, so you're not rendering every single cube each frame)
(http://i12.photobucket.com/albums/a226/Figgin/Dwarf%20Fortress/NewRamps.gif?t=1254730747)My votes go to A or C ... I'm not a fan of the rotund hills which I will now deem nippills. (nipple hills)
1111111
1222221
1233321
1232321
1232321
1221221
1111111
222
212
111
Maybe it's just the mockup - I'd love to see those for variants in a hilly landscape or something. :)
Maybe it's just the mockup - I'd love to see those for variants in a hilly landscape or something. :)
This is an interesting point -- it wouldn't be difficult to change the ramp style based on the tile type. Natural rock/earth could use a "smooth" style like B, and constructed ramps could use a more angular style like A.
After seeing the hill mockup A reminds me of an Escher drawing.
it IS happening. We're quite a bit on the way already. stay tuned :)HURRAH!!!!
any updates ??? we cant let this idea/project die