Print

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

[corvvs]

A friend of mine came up with this idea the other day (I haven't convinced him to make a forum account yet, but he's definitely into DF) -- since the graphics are done with OpenGL, it shouldn't be difficult to slide sprites from tile to tile between world sim "frames" by interpolating their position.

So rather than Urist the miner "hopping" from square to square up the corridor, she smoothly (or at least more smoothly) strolls. It could be accomplished in as few as 2 or 3 rendering frames and still make a noticeable difference in the perceived motion of the dwarves.

[theJ89]

Dwarf Fortress renders it's graphics in ASCII style, though. That means all of the graphics (including the UI) are drawn on an invisible grid. Only one tile is drawn per grid space, and things like replays and the UI rely on this fact. Breaking this would mean restructuring how the rendering engine and replays work. That, and people's expectations would be raised so that not only sprites but anything else that moves would be expected to animate smoothly, which frankly is an unnecessary distraction on the part of the developer.

[corvvs]

Dwarf Fortress renders it's graphics in ASCII style, though. That means all of the graphics (including the UI) are drawn on an invisible grid. Only one tile is drawn per grid space, and things like replays and the UI rely on this fact. Breaking this would mean restructuring how the rendering engine and replays work. That, and people's expectations would be raised so that not only sprites but anything else that moves would be expected to animate smoothly, which frankly is an unnecessary distraction on the part of the developer.

Why would replays and the like care? The actual position of the dwarf during world sim would be at x,y tile. It's only when it moves to a new tile that for a couple of 30ths of a second the position is DISPLAYED as x+0.33,y; x+0.66,y; x+1,y. The replays of the movie engine, as they use the same internal renderer, would already take that into account, and it wouldn't even break the DFMA movie archive, since the "sliding" is an artefact of the renderer, not actually a change to the internal structure.

Also, what the heck moves in the game other than sprites? In fact, what the heck is even displayed on the screen other than sprites?

[theJ89]

Dwarf Fortress renders it's graphics in ASCII style, though. That means all of the graphics (including the UI) are drawn on an invisible grid. Only one tile is drawn per grid space, and things like replays and the UI rely on this fact. Breaking this would mean restructuring how the rendering engine and replays work. That, and people's expectations would be raised so that not only sprites but anything else that moves would be expected to animate smoothly, which frankly is an unnecessary distraction on the part of the developer.

Why would replays and the like care? The actual position of the dwarf during world sim would be at x,y tile. It's only when it moves to a new tile that for a couple of 30ths of a second the position is DISPLAYED as x+0.33,y; x+0.66,y; x+1,y. The replays of the movie engine, as they use the same internal renderer, would already take that into account, and it wouldn't even break the DFMA movie archive, since the "sliding" is an artefact of the renderer, not actually a change to the internal structure.

Also, what the heck moves in the game other than sprites? In fact, what the heck is even displayed on the screen other than sprites?

What I'm saying is, the sprites are drawn on a grid. What gets drawn on a specific tile depends on what the highest z-priority object occupying that tile is (IE floor < item < dwarves < miasma). While the dwarf is moving from tile to tile he is not being drawn on either tile, instead a separate, non-gridlocked sprite must be drawn between the two. This means making changes to the way rendering of the world is carried out, since before this the only thing rendered were gridlocked objects.

As far as I could tell the replays seem to save the frames as a map of characters. You'd have to add onto that by storing that plus the positions of any non-gridlocked sprites. This would mean the replay format would be changed.
And I guess "move" was the wrong term, I meant anything that animates would be expected to animate smoothly, such as water or gas clouds.

[corvvs]

Dwarf Fortress renders it's graphics in ASCII style, though. That means all of the graphics (including the UI) are drawn on an invisible grid. Only one tile is drawn per grid space, and things like replays and the UI rely on this fact. Breaking this would mean restructuring how the rendering engine and replays work. That, and people's expectations would be raised so that not only sprites but anything else that moves would be expected to animate smoothly, which frankly is an unnecessary distraction on the part of the developer.

Why would replays and the like care? The actual position of the dwarf during world sim would be at x,y tile. It's only when it moves to a new tile that for a couple of 30ths of a second the position is DISPLAYED as x+0.33,y; x+0.66,y; x+1,y. The replays of the movie engine, as they use the same internal renderer, would already take that into account, and it wouldn't even break the DFMA movie archive, since the "sliding" is an artefact of the renderer, not actually a change to the internal structure.

Also, what the heck moves in the game other than sprites? In fact, what the heck is even displayed on the screen other than sprites?

What I'm saying is, the sprites are drawn on a grid. What gets drawn on a specific tile depends on what the highest z-priority object occupying that tile is (IE floor < item < dwarves < miasma). While the dwarf is moving from tile to tile he is not being drawn on either tile, instead a separate, non-gridlocked sprite must be drawn between the two. This means making changes to the way rendering of the world is carried out, since before this the only thing rendered were gridlocked objects.

Yes, sort of. The only thing being drawn is still "gridlocked" objects. It's only in between world-sim frames that the extra rendering frames would come into account. I get the feeling you're not understanding due to confusion between the two uses of the word "frames". Think "FPS_CAP" (world-sim) vs. "G_FPS_CAP" (rendering frames).

As far as I could tell the replays seem to save the frames as a map of characters. You'd have to add onto that by storing that plus the positions of any non-gridlocked sprites. This would mean the replay format would be changed.
And I guess "move" was the wrong term, I meant anything that animates would be expected to animate smoothly, such as water or gas clouds.

You don't need to store the positions of "non-gridlocked" objects because there is no such thing. There are transient positions for sprites in between world-sim frames. And I understood what you meant. But there are two possibilities for the movement of fluids. 1) the state is created from scratch between every frame - in this case there IS no "movement", therefore no extra rendering, because it wouldn't make sense. But I don't think that's what the game currently does, as you can tell which direction a river is flowing by watching it. So 2) the state is updated and individual tiles are kept track of between every frame - in this case you get your smooth animation for free (algorithm-wise, not necessarily CPU-wise) because the state of one water tile sprite moving to another location tile would be noted by the renderer.

[Capntastic]

I think the core issue is that as it is now, units move between tiles instantly, and having them slide would add a mechanical "where in transit is this unit" thing for the game to consider, ergo adding more time between frames, and thus more general 'lag'.

[G-Flex]

It wouldn't affect the simulation at all, though.

It would, however, add a bit of graphical overhead, especially since you can't get away with running the game at 15 GFPS anymore.

[corvvs]

Sure you could. It's just that 15GFPS wouldn't mean "15 frames per second hard realtime graphic updates" -- it would mean "render what is happening on the screen 15 full times per second". If you notice, this isn't a change in meaning either - that's what it does now.
If there were two interpolated positions rendered for each graphic update, DF would be updating the framebuffer 45 times per second.

The GFPS value basically means "how often do you want to pause simulation so we can show you what's been happening?" It's not tied to the simulation speed the way it is in Quake. With this suggestion, I'm saying during that pause the screen can be redrawn more than once, with interpolated values used to give the idea of movement.

[QuakeIV]

Sure you could. It's just that 15GFPS wouldn't mean "15 frames per second hard realtime graphic updates" -- it would mean "render what is happening on the screen 15 full times per second". If you notice, this isn't a change in meaning either - that's what it does now.
If there were two interpolated positions rendered for each graphic update, DF would be updating the framebuffer 45 times per second.

The GFPS value basically means "how often do you want to pause simulation so we can show you what's been happening?" It's not tied to the simulation speed the way it is in Quake. With this suggestion, I'm saying during that pause the screen can be redrawn more than once, with interpolated values used to give the idea of movement.

When the computer lowers to 15 FPS its completely incapable of simulating the world any faster, as in it cant show what happened in that time if it hasnt figured out WHAT happens in that time.

[G-Flex]

I have no idea what you mean by that and I know it's not true.

I've personally had the game running at far, far faster than the graphical FPS was at the time.

The game knows what's going on even if the graphics renderer doesn't. They're separate entities, and the game can easily update the graphics 10 times per second while running 30 simulation frames during that same period.

[Rowanas]

Have you ever set the fps to 1000 while keeping the GFPS to 15? It's... beautiful.

[Draco18s]

I have no idea what you mean by that and I know it's not true.

I've personally had the game running at far, far faster than the graphical FPS was at the time.

The game knows what's going on even if the graphics renderer doesn't. They're separate entities, and the game can easily update the graphics 10 times per second while running 30 simulation frames during that same period.

That is not true for Dwarf Fortress.  The defaults are an FPS cap of 100 and a GFPS cap of 30.

That means that the game is updating behind the scenes 100 times a second, but the screen is refreshing 30 times a second.

HOWEVER, if the game ends up with enough object to start causing serious lag, and your FPS drops to 15, that means the screen is updating twice as fast as the game can process things behind the scenes.  "Frames" that aren't graphicall in this game mean "world unit increments of time;" it takes an non-agile dwarf 10 "frames" to walk one square.  The more agile the dwarf, the less time it takes to move.

[G-Flex]

I have no idea what you mean by that and I know it's not true.

I've personally had the game running at far, far faster than the graphical FPS was at the time.

The game knows what's going on even if the graphics renderer doesn't. They're separate entities, and the game can easily update the graphics 10 times per second while running 30 simulation frames during that same period.

That is not true for Dwarf Fortress.  The defaults are an FPS cap of 100 and a GFPS cap of 30.

That means that the game is updating behind the scenes 100 times a second, but the screen is refreshing 30 times a second.

HOWEVER, if the game ends up with enough object to start causing serious lag, and your FPS drops to 15, that means the screen is updating twice as fast as the game can process things behind the scenes.  "Frames" that aren't graphicall in this game mean "world unit increments of time;" it takes an non-agile dwarf 10 "frames" to walk one square.  The more agile the dwarf, the less time it takes to move.

I know what frames are and I'm not sure why you're explaining this to me.

Quake said that the game cannot run the simulation at a higher rate than the graphical updates, which, as we've both just explained, is false.

[corvvs]

I added this to the Eternal Suggestion poll.

[Jay]

What is all this nonsense?
For one..

The defaults are an FPS cap of 100 and a GFPS cap of 30.

My vanilla copy (just downloaded a minute ago): [G_FPS_CAP:20]

Why are we arguing about something that cannot be implemented?
The game runs faster then it displays in 80% of cases, and our dwarves can take corners around walls such that a tween effect would cause them to "slide" through walls.
IE:

Code: [Select]

. . . . O
.XX X X X       
.X        D - Dwarf
.X        O - Destination
DX       X - Wall
If you're running at the default 100 FPS and 20 GFPS, that is 5 frames per graphics update.
Assuming that said dwarf moves every frame, which is possible with an agile dwarf, you'll have him move here before the graphic updates.

Code: [Select]

. . D . O
.XX X X X       
.X        D - Dwarf
.X        O - Destination
.X       X - Wall
Would the OP please care to explain how tweening would work in this instance?