Print

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

[pndrev]

It might be interesing to see if the maps can be exported to Cube. It's a free engine for FPS shooters, which seems simple enough that an exporter could be a possibility.

http://cubeengine.com/

[Dadamh]

(It even looks like a Doom level.)

That gave me an idea... A 3Dwarf to WAD converter. Or maybe turning 3Dwarf into an FPS that loads everything from creatures to traps from the save and turns them into their equivalents in the FPS.

The WAD converter could work if each floor was a separate level, but I don't see multi-floored spaces working.  you could fake it in the build engine, but I'm not sure why you'd want to.

I don't know anything about the cube engine.

[Draco18s]

Well,at least the original doom(s) were not fully 3D (i.e. nothing was ever stacked)...

Correct, it was 2.5D
They used a greyscale "heightmap" for the levels and faked it.  It was still impressive for the time though.

[baczek]

but a MAP/BSP for quake1/2/3/4 could be made just fine, pretty easily at that.

[Reasonableman]

I'm preeeeetty sure that Cube, and more usefully, Sauerbraten, use some kinda weird map type that would be difficult to convert to.

[isitanos]

(It even looks like a Doom level.)

That gave me an idea... A 3Dwarf to WAD converter. Or maybe turning 3Dwarf into an FPS that loads everything from creatures to traps from the save and turns them into their equivalents in the FPS.

Hey, that's actually a GREAT idea. We have to find the best 3d engine/map format for the task.

[TheSpaceMan]

It would still require a lot of optimization. There is a reason many fps focus on large high detail objects instead of a few low poly objects. It could still be done. For easy calculation in a bad optimization scenario each tile of the df map would require 8 vertex points. lets say the area is for the sake of it 256*256. That would give us 65536 tiles. with 65536 * 8 vertex points.
That is 524 288 vertex points still not to bad if using a high end machine it wouldn't be that bad. The problem is. Since all this would be individual tiles. Then we have 65536 draw calls. Thats bad. Thats the number we want to decreses.

How?

By merging vertex points at the edges of each object, that allow us to render many tiles with one draw call.

The thing to think about here is that each material, shader and texture combination would result in individual draw calls and thus also need to be handled.

Optimizing the view would be the real bitch. I think really few FPS games would handle it in a good world.

[Snookle]

How?

There are some pretty common techniques to solve the problems you've outlined:

1) Back-face culling
2) View frustum culling
3) Geometry batching
4) Geometry paging

All of these have fast and efficient solutions that any decent real-time 3d renderer should have implemented.

If anyone is serious about using a 3rd party renderer for 3Dwarf (which is a good idea, why re-invent the wheel?), then I'd suggest looking at Ogre3D.

As an aside, has anyone considered using the .FDF-MAP format (as used by the DF Map Archive) as a means of getting map information? By the looks of it, it should give a lot more information (in terms of units and building placements) than memory hacking for a lot less work. The only problem I can see (this is without looking at the .FDF-MAP format) is that some tile information is obscured by buildings/units. This could be solved by some clever situational analysis of the obscured tile to try and figure out what it is.

[Mel_Vixen]

Why anyway hacking the memory? Wouldnt be the hack of the Mapfile be more efficent?

[ChJees]

Go on and learn the Save data structure then .

It is not "just" . Unless ToadyOne gives out specifications on how the saves are structured so will it be hard.

[TheSpaceMan]

How?

There are some pretty common techniques to solve the problems you've outlined:

1) Back-face culling
2) View frustum culling
3) Geometry batching
4) Geometry paging

All of these have fast and efficient solutions that any decent real-time 3d renderer should have implemented.

If anyone is serious about using a 3rd party renderer for 3Dwarf (which is a good idea, why re-invent the wheel?), then I'd suggest looking at Ogre3D.

As an aside, has anyone considered using the .FDF-MAP format (as used by the DF Map Archive) as a means of getting map information? By the looks of it, it should give a lot more information (in terms of units and building placements) than memory hacking for a lot less work. The only problem I can see (this is without looking at the .FDF-MAP format) is that some tile information is obscured by buildings/units. This could be solved by some clever situational analysis of the obscured tile to try and figure out what it is.

Yes. All this help to a degree still its a lot of optimization. Guess I am a bit damaged from hanging around with people where some one get an idea and expect the code to take a day becouse "boxes must be easy to render" and stuff like that. It's entirly doable. And yes I wonder the same thing. Why focus on the memory when you could try to extract static data from the map.

About just learnign the Save data strucuture, don't see why this should be harder then memory hacking currently going on.

Side note. We have all the data we need in the file depot thingie. the maps there contain enough detail to create an entire level in 3D and is allready split up into diffrent Z levels. Diffrent symbols for stuff. Yes you still won't get an artifact bracelet that looks like the description but i can't belive anyone was expecting that.

[Mithaldu]

I suggest you look at the data in question yourself before you make assumptions like that.

[TheSpaceMan]

Anyone know how the current web mapviewer works?

[Baboonanza]

I'm actually working on a more advanced renderer at the mo. and to be honest the concern about performance is largely unneccessary.

My current fortress (relatively small  <60 dwarves) on an 18x18x34 map (6 region squares, 288x288x544) tiles is rendered with:
452272 triangles
328313 verticies (optimal sharing isn't always possible because of texture-coord issues)
24 textures (this will probably go up, I'm using the same texture for multiple materials at the moment)
only 1 draw call per texture using 1 vertex buffer and 1 index buffer for all geometry
per-pixel lighting (simple) and shadow mapping
And performance is fine, and much much faster than 3Dwarf on my Radeon X800. It even runs without GPU shaders on the GeForce2MX at work (although a bit slowly)

TBH using a 3D-party renderer would only help with certain things. The difficult work is in the geometry creation, but it would help with things like dynamic LOD for trees and best case senarios such as when the view is inside. What it probably wouldn't help with is the exterior view (worst-case) where you just want to push geometry as fast as possible to the GPU and using paging/BSP/occlusion culling might just increase the overhead. I also suspect that the nature of the geometry combined with the floating viewpoint maps isn't very well suited to the usual optimisation techniques for landscapes.
But then I'm only an amateur so I may be wrong , and writing the renderer is mainly the point of the exercise for me.

Also I think the reasons people have been focused on hacking memory rather than the save file is:
1- There is already some info on it from tool writers who need to hack the running process anyway
2- Perhaps most importantly it's much easier to find the information, since you can step through the assembler in a debugger to find where things are. With so little information on the internal data structures used this is really the only way - just finding the type of material used for a virgin rock tile requires knowledge of 4-5 different structures.

As for using the file-depot format, I've looked at it and I'm not sure it contains enough information. There is no actual data on the type of the tiles, just the image.

I'll be releasing my renderer when it's finished, or nearly so (I'll probably release before implementing good trees, since these are a real PITA). As I have the geometry anyway I could also export it to some other format, but that's not high on my list of priorities

[Mithaldu]

I'd love to see how a faster engine would look. :O

Two questions:

1. open source? if so, what language?
2. how do you get the data to display stuff?