Print

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

[penguinofhonor]

I've noticed something with the partial printing:
Low Numbers: Horrible flickering, renders the game nigh-unplayable
High Numbers: Slows down to a crawl for a couple seconds every 5-10 seconds.

It seems that my number is 10. Although it still occasionally messes with the entire screen when I restore it, it only slightly slows down DF for a couple seconds every 10-15 seconds.

[numerobis]

FYI: on a macbook pro, PARTIAL_PRINT 2 works wonders; it reduces the title page to 6% CPU, and pause to 20%, from 50% and 80% before.  So it's not perfect (those numbers really should be zero in both cases), but it's substantially better; thanks!

[Sukasa]

PARTIAL_PRINT:YES:2 works fine for me, so long as I force triple buffering off in the videocard control panel. nVidia GeForce 8400M GS, Dual-Core Int_el 2Ghz.  I haven't tried :1 yet, but I will next time I start DF.

[Blacken]

So it's not perfect (those numbers really should be zero in both cases)

On the title screen, it may be reblitting certain parts Toady isn't flagging with dirty bits or whatever other partial-print mechanism he's using; in the game itself, there could be all sorts of background calculations we don't know about. And for obvious reasons, they'll never be zero.

Also: is the game doing raw bitmap blits, or is it orthographically projected? I have to think that an ortho projection shouldn't have these issues at all. Blitting is really, really slow.

[Exponent]

Also: is the game doing raw bitmap blits, or is it orthographically projected? I have to think that an ortho projection shouldn't have these issues at all. Blitting is really, really slow.

I'm pretty sure it's using orthographic projected quads (well, paired triangles instead of literal quads, most likely).  That's probably how he is able to do easy scaling and allow for different forms of texel->pixel interpolation in init.txt.  I haven't seen the flickering myself, but from what I've heard, it sounds like it could almost be as simple as not clearing the back buffer before drawing.  Before the partial print code was written, the entire buffer was guaranteed to be overwritten each frame, no matter what, so no clearing was needed.  Now, however, only parts of the back buffer are overwritten, and the 2-frames-old content will remain on the back buffer wherever it isn't overwritten.  But I suppose that this doesn't explain everything.

Thinking about it further, though, I'm not actually sure how I would implement partial printing with a double buffer setup.  I'd probably avoid it altogether.  At least as far as the literal graphics are concerned.  Apparently, the optimization is not a matter of reducing the number of triangles or pixels drawn, but rather reducing the number of tiles that have to be queried in order to figure out which symbol and colors should be drawn.  There should therefore be only one single symbol/color buffer, updated according to the partial-print algorithm.  Then when drawing the actually OpenGL quads, every single tile from the symbol/color buffer should be drawn (thereby overwriting the whole buffer with up-to-date content).  Since there is only one symbol/color buffer, there is no chance that the next frame will have 2-frames-old data, since all that data was overwritten.

Assuming that the speed improvement is indeed from the reduction of tile look-ups rather than triangles/pixels drawn, then I think this would be the perfect way to go, if it isn't already what Toady is attempting to achieve.  If I remember right, I believe some other people have already found the symbol/color buffer in memory; the telnet client comes to mind.  I wonder if Toady is also double buffering this buffer.  If so, that might be the source of the problem, as I don't think that it needs to be double buffered in order to obtain the improved CPU/GPU parallel efficiency.  Only the graphics buffer itself needs to be double buffered.

[Toady One]

Is the display code going to be released to KQ before you take off?

I decided that updating KQ would be a pain compared to gutting DF to a new project, and it's more fun to do a new project anyway.  So TT and I are starting and finishing something today.  This likely means the new project will be total crap and buggy, but it'll have the DF innards.  Should have simultaneous Windows/Mac release, although I can't guarantee that since I have much much less experience with XCode so setting up the project files in time there might stymie me.

I now have a mystery computer that anonymous donor was kind enough to send, and I'm hoping to put Windows and *nix (probably my Ubuntu CD) on there -- somebody linux'd KQ (few people actually), and that should lead to Linux DF and all future games as well, assuming it all works out.  Never set up a dual boot partition thing before if that's the best way to go about it.  The virtual machine was a bit too clunky to let me power onward.  That will be happening next month, at least part of it.  I haven't actually opened the box yet so we'll have to wait and see what's inside!

If so, we might all be able to fix it for our machines and produce appropriate patches while you're off making stone short swords for your barbequeue at the zoo, or whatever your trip is.  Enjoy the vacation!

There will also be fossil digging, I think.  The plan is constantly being morphed, but so far it includes the Portland Zoo, obsidian mining, a lava tube cave walk, a museum and fossil digging.  Plant fossils, rather than trilobites and giant skulls.  Including a place that lets you keep your best three provided the check-out person doesn't deem them rare.  Not sure how hard it is to find any in the first place, but the town itself is named Fossil, so it shouldn't be impossible.  Perhaps it'll spur on the fossil bloat #324 for DF, though I imagine that'll include more trilobites and giant skulls.

[penguinofhonor]

Fossil digging? Oh, how I envy you.

[Richards]

Mystery computer eh?

What are the specifics?

[MaxVance]

Judging by

I'm hoping to put Windows and *nix (probably my Ubuntu CD) on there

it's probably a Mac.

[Toady One]

Is the display code going to be released to KQ before you take off?

Here is definitive proof that forced timetables are bad for game development:

BC (win)
BC (win source)
BC (mac)
BC (mac source)

It crashes if you quit after the title screen.  Easy enough to fix, but I'm out of time (leaving in less than two hours and haven't prepared at all).  It also has various KQ and DF artifacts in the projects (like the compiled name/icons), and... lots of other stuff, but the win/osx code is there.

These releases are all under the BSD license, and any code would need to be under something equivalent or public domain if you want me to use anything.

If you turn the graphics on, you'll get a gnome general "picture" instead of a 'G', and the mechanism is the same as in DF (being the same source file, though the parts leading in don't refer to units or skeletons of course).

If you manage to navigate to a battle, you can get a pretty busy screen for testing.  You'd need to select your province ('a'), your army ('1'), move/attack (enter), select a province letter, then 'enter' to pass the turn.  Space to back out, esc to quit.  The first parts are documented in the sense that there are green DF-style keys, but it's not obvious.  Nor is the game winnable.  Nor is the game fun, though I think it would be pretty straightforward to make it so once the groundwork is in.  Not sure I'm going to bother though, since the time is definitely better spent on my other projects.  I made a bunch of stuff like this when I was in junior high and a bit in high school, and like this one, I never really finished any of them.

You can also record DF-style movies (I think).  The main screens are rendered in one way, and the ESC options screen is rendered in another (both exist in DF as it's always in transition so I thought I'd throw them both in), so you might want to make sure flickering etc. doesn't happen either way.

[penguinofhonor]

Toady, I haven't the slightest idea what that is or what I'm supposed to do. All I know is that if I'm the guys on the left, then I suck at this game.

[olemars]

It's pretty straightforward, I rule a quarter of the map already. You won't get attacked by anyone so just consolidate your forces and conquer away.

What side of the screen your forces enter from during the battles seem to be random (and they switch sides when all survivors have moved across). What I do know is that goblin warriors get slaughtered by the thousands by any enemy.

[penguinofhonor]

Hm, your civ leader is remarkably weak in combat, usually dieing to the weakest of the opponent's troops.

[olemars]

Well, the stats are as follows:

Spoiler (click to show/hide)

Code: [Select]

[NATION:GNOMES]
[LEADER_UNIT:Gnome General:1:1:1:1:'G':6:0:1]
[UNIT:Steam Infantry:1:1:2:2:'g':6:0:0]
[UNIT:Steam Airship:0:3:5:1:'A':3:0:1]
[UNIT:Steam Cannon:0:15:10:5:'C':0:0:1]
[UNIT:Steam Tank:0:10:6:3:'T':2:0:0]
[WORD_LIST:gnomes.txt]

[NATION:BARBARIANS]
[LEADER_UNIT:Barbarian General:3:3:0:0:'B':4:0:1]
[UNIT:Infantry:2:2:0:0:'b':4:0:0]
[UNIT:Archer:1:1:3:1:'a':2:0:1]
[UNIT:Cavalry:3:5:0:0:'C':4:0:0]
[UNIT:Horse Archer:1:5:2:1:'H':2:0:1]
[WORD_LIST:barbarians.txt]

[NATION:WIZARDS]
[LEADER_UNIT:Wizard:0:1:3:3:'W':4:0:1]
[UNIT:Goblin Warrior:1:1:0:0:'g':5:0:0]
[UNIT:Goblin Archer:0:1:2:1:'g':2:0:0]
[UNIT:Minotaur:3:6:0:0:'M':6:0:0]
[UNIT:Dragon:5:10:8:8:'D':2:0:1]
[WORD_LIST:wizards.txt]

[NATION:CRYPTIDS]
[LEADER_UNIT:Sasquatch:2:5:0:0:'S':7:0:1]
[UNIT:Chupacabra:2:2:0:0:'c':6:0:0]
[UNIT:Death Worm:1:1:2:8:'w':4:0:1]
[UNIT:Atmospheric Beast:0:1:15:1:'A':7:0:0]
[UNIT:Sea Monster:5:5:0:0:'S':3:0:1]
[WORD_LIST:cryptids.txt]

The first four numbers are melée attack, life, range and ranged attack respectively, and the letter is their graphical representation. Not sure what the three last numbers are.

So the civ leaders are only mediocre warriors.

[penguinofhonor]

The last three numbers are their color.