Print

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

Faster, no (unknown) problems

Faster, problematic

Same speed, no (unknown) problems

Same speed, problematic

Slower, no other (unknown) problems

Slower, problematic

Doesn't work at all

[The-Moon]

Don't worry, I'm hard to offend. Word of advise, though, since you're apparently not that used to programming:

Everything is harder than it seems. The devil's in the details, and the details are fractal and have tentacles.

Multicore programming, in particular. That's.. well, it /seems/ pretty easy, and it /is/ pretty easy in principle, but it basically doesn't work (without excessive effort) in imperative languages.

Trying to retrofit it into an existing imperatively-languaged program that was never intended for the purpose, such as DF - well, I'd rather face down a rampaging carp.

Hehe nope, ive been programming for 12 years, ive only recently started learning sdl.

sdl is a pain in the ass tho, but once you finaly get sdl installed it seems to work just fine.

Ive done multicore coding before, i know its very possible and easy to do(if you know what your doing that is), but it does take alot of work to setup. But its not that hard.

But even if you optimize the graphical engine to use opengl and such, that will never be enough to fix the speed problems df has. The only thing which can fix that is using multicores.

Honestly DF does more then most ps3 games, and ps3 games run on multicores. DF needs the same.

We honestly should be putting more effort into setting up some way to let toady multicore DF without too much of a head ache. Thats what we really should be putting our efforts into.

We know this isn't a total solution to DF's speed issues.  The reason people are working on this stuff is because it's the part Toady was willing to release.  He's not willing to release the parts of the source that would allow others to work on multithreading, pathfinding, etc.  You've had this conversation before so let's please not derail this thread with it.

No im not getting into it, i know ive talked about this and said my part, not much more to say of course

Not derailing this thread no more then i have *sigh*

[Orkel]

Played a 3 year fort with this, no crashes and it runs fast. I'm pleased.

[Sizik]

What do the different FPS: x (y) / z numbers mean, anyway?

[CobaltKobold]

Edit: on an unrelated note Baughn, to help testing you should probably put a benchmark fortress for download. It would make FPS reports a little bit more meaningful and comparable.

Reinhammers is what they've been using. But as Baughn says it is "all simulation no graphics"

subscribble

You know, you don't have to comment to subscribe to a thread... you can click on the 'notify' button at the top and bottom of the thread.

"new replies to your posts" is gener'lly consideredto have friendlier interface, for some reason.

Follow-up to the previous d18 thread and this question:

Quote from: Mondark on March 04, 2010, 02:36:09 PM
    or use GNU Screen to allow other people to watch, or interact in real time with the game.

Please explain how you did this. I desire it.

This really isn't the job for GNU screen -- it's a job for dgamelaunch!

Pssst. The reason Baughn put in ncurses is...someone made a working public server patch thingy.

The most brutal starting conditions I could come up with (16 x 16, as many Z levels as I could find (19), every game feature present, spending all my starting points on cats (you get 187)).

Try a 16x16 on a volcano with brook, so you get all possible hidden features-the chasm should eat your fps right up.

Sizik:

Anyway, it goes "FPS (G_FPS) / old_FPS".

[Malicus]

What do the different FPS: x (y) / z numbers mean, anyway?

x is the "smoother" FPS counter from d18, and y is the graphical frames per second.  z is the old FPS counter from before then that jumps around a lot.  (People seem to want both x and z around.)

The most brutal starting conditions I could come up with (16 x 16, as many Z levels as I could find (19), every game feature present, spending all my starting points on cats (you get 187)).

Try a 16x16 on a volcano with brook, so you get all possible hidden features-the chasm should eat your fps right up.

I've generated mountains with actual cliffs in the same region tile as deep sea using the world painter.  They have...  lots of z-levels, especially if you get the whole region.  Make sure that that area is volcanic enough for magma, and THAT would be absolutely brutal starting conditions.  Then again, that's not really testing what we're here to test...  also, such an area would surely require use of Embark Anywhere, which may or may not work with this version (I haven't tested it).  You may have to import the save from 40d or something.

[seigenblues]

Ive done multicore coding before, i know its very possible and easy to do(if you know what your doing that is), but it does take alot of work to setup. But its not that hard.

Ok, if you've been programming for twelve years, then you know that there's a big difference between "setting something up" and "retrofitting existing code." One is straightforward, maybe even simple.  the other is a signficant undertaking depending on the complexity & design of the original. 

...and if you've got that kind of experience, then you should have an idea of the complexity & design of the DF codebase just based off the bug reports we're seeing.

Better yet, if you've been in the industry, you know that the two worst words in the world are "legacy code"

And we know Toady's legacy is already secure! [/pun]

BTW, hats off to Baughn for his incredible work on this thankless task.

GOOD JAEORB

[Diablous]

Probably should help...

Using my fort, TwilightShadow, about 6 years old. 148 dwarves, none idle, 199 animals that belong to my dwarves, chasm that has nothing in it, magma pipe, brook, cold area, 15 different perpetual motion machines all hooked together, and 13047 stones F.Y.I.

40d: Parial Print: No -> 13fps
         Yes:2-> 20-40. Usually stays at 32.

40d18: STANDARD - 12 (12)
40d18: PARTIAL:0 - 12 (12)
40d18: ACCUM_BUFFER - 9 (9)
40d18: FRAME_BUFFER - 14 (14)
40d18: VBO - 13 (13)
40d18: 2D - 30 (19)
40d18: 2DHW - 30 (19)
40d18: 2DASYNC - 27 (19)

40d19: STANDARD - 16 (16) /16
40d19: PARTIAL:0 - 30-40 (19) / 30-40  (note: If moves so much that I can't really find an average #)
40d19: SHADER - Crashes
40d19: ACCUM_BUFFER - 25 (19) /28 Weird dimming thing.
40d19: FRAME_BUFFER - 20-40 (18-19) / 20-40  (This shifts so damn much)
40d19: VBO - 13 (13) /13
40d19: 2D - 35 (18) / 20-40 (Lots of shiftin for the last one)
40d19: 2DHW - 30-40 (18) / 30-40  (Shifting again)
40d19: 2DASYNC - 30-40 (18) / 30-40 (Shifts)
 
And here is a pic of the dimming thing:

Spoiler (click to show/hide)

 
Meh. I'm happy with what you've done. It's faster, so thanks.

[The-Moon]

Ive done multicore coding before, i know its very possible and easy to do(if you know what your doing that is), but it does take alot of work to setup. But its not that hard.

Ok, if you've been programming for twelve years, then you know that there's a big difference between "setting something up" and "retrofitting existing code." One is straightforward, maybe even simple.  the other is a signficant undertaking depending on the complexity & design of the original. 

...and if you've got that kind of experience, then you should have an idea of the complexity & design of the DF codebase just based off the bug reports we're seeing.

Better yet, if you've been in the industry, you know that the two worst words in the world are "legacy code"

And we know Toady's legacy is already secure! [/pun]

BTW, hats off to Baughn for his incredible work on this thankless task.

GOOD JAEORB

Yes i am perfectly well aware of how hard it is to change current code into a multi core / server client code. Yes i know this all too well, big pain in the ass. But that doesnt dismiss the fact, its going to need to be done at some point, which we dont needs get into on this topic. Just replying to you.

I have full awareness of how big a project of DF is. Yes. And i challenge toady not. Appologize if i have seemed to be that way, toady has done a great thing with DF, which im sure will inspire all of us to do good with our own programs

Programming is a hobby for me, i frame houses with my dad for a living, so i may not have much room to talk as everyone else here, but im not completely stupid to computers and programs. And i appologize if i have seemed like im trying to put my self out as knowing programming like i been in the industry for years, just a hobby for me, my appologizes.

(Edit: Just to point out, im new at sdl lol. But not to programming, that code i posted is just a sloppy quick mock up of some working SDL code, i have much much better coding skills then that....)

Toady is fucking great i love him and DF, only thing i regret is not having the extra money to donate more to him

Damn right, i looked at the code he has done good work, i couldn't touch him no wheres near. I tip my hat to him, he is much more skilled then me and i apologize for my rude comments.

[shadow_slicer]

Missed the post, I think.. or forgot...

Shift-left/up/down/right are defined in terminfo, so I'm going to do that properly in a bit. Thanks for the thought, though.

As I mentioned in my d18 post, only shift-right and shift-left are defined in terminfo/termcap (see the list of defined capabilities). I have even dumped the terminfo entries for several terminal types and there were no entries for shift-up or shift-down.

Curses already uses the shift-right and shift-left from terminfo, and it seems to work for most terminals. I have tested it with my modified code and KEY_SRIGHT and KEY_SLEFT were being recognized. Even without changing the code you can still tell if it will work or not if curses eats the character (i.e. nothing happens when is pressed instead of opening the recording menu).

There may be a problem with urxvt's terminfo entry however. I have not tested it in urxvt on Linux, but using cygwin's urxvt over ssh the shift-left and shift-right were sending a different escape sequence than the one in terminfo for some reason (though in urxvt the escape sequence may be configurable using .XResources  ).

As for shift-up and shift-down, I am as certain as I can reasonably be that they are not present in either terminfo or termcap. Of course, if someone has found a reference that shows how to get shift-up and shift-down from terminfo, I would love to have a look at it. As it stands, I just put the most likely ones in the code posted previously (and it fortunately worked in every terminal I've tried, including urxvt).

So in summary:
You may want to add the KEY_SRIGHT and KEY_SLEFT entries to the input_ncurses function, since I have verified they work and this only involves a 2 line change.

Shift-up and shift-down can probably wait until you have time to check my research.

[isitanos]

Edit: on an unrelated note Baughn, to help testing you should probably put a benchmark fortress for download. It would make FPS reports a little bit more meaningful and comparable.

Reinhammers is what they've been using. But as Baughn says it is "all simulation no graphics"

So, maybe upload that Reinhammers save somewhere and hand Baughn the link to he can post it on the OP? Or would another community fortress be more appropriate?
Also, I don't really understand the "all simulation no graphics" comment: is Reinhammers so heavy on the CPU that it prevents correctly evaluating the graphics framerate?

Or maybe Baughn should just voice in when someone mentions a good fortress (such as Diablous' TwilightShadow maybe?) and say "damn, this looks like a good benchmark, could you upload it to XYZ and send me the link?"

Edit: ideally the save should be done at the right place for the benchmark, so we just have to load game, look at FPS for a minute, then kill df and move to another display mode. No moving around the map or switching levels, that sounds like a benchmark-screwing activity.

[CobaltKobold]

Someone did, I'm fairly sure, which is why you keep getting people who are using it.

I am, howe'er, unable to find it presently.

[Meteorswarm]

The sizing issue in ncurses fixed itself, but when I try to play it in gnome-terminal, xterm or non-graphical console, any of the "special" characters get expanded to something ugly and long, which screws up the alignment of, well, everything.  A sample line:

-b~V~H...........................==================MMMM..M.M..M........M....".................."...........".................MMMM-       M ;: Movies                    M

this line crosses a field, a wall, a stockpile (the =), another wall, some rocks, some rock and then the menu.  The -b~V~H appears on every line where the vertical border is supposed to be, and similar strings appear where dwarves are, where trees are, etc.

Is this something you know about (and will hopefully fix ) or is it something on my end?  I'm running Ubuntu and haven't done anything weird to my terminals.

[darkrabite]

Also, I don't really understand the "all simulation no graphics" comment: is Reinhammers so heavy on the CPU that it prevents correctly evaluating the graphics framerate?

Exactly the problem, need a fort with more graphic stuff going on and less dwarves and pathing.

edit: what i mean is, a fort like reinhammer has so much pathing going on, i think the barrier to fps is its cpu bound.  imo after reading the pathfinder project thread.

waterfalls,chasms, rivers, etc would be good.  I dont have a fort worth a damn or i'd put one on dffd

[The-Moon]

Also, I don't really understand the "all simulation no graphics" comment: is Reinhammers so heavy on the CPU that it prevents correctly evaluating the graphics framerate?

Exactly the problem, need a fort with more graphic stuff going on and less dwarves and pathing.

waterfalls,chasms, rivers, etc would be good.  I dont have a fort worth a damn or i'd put one on dffd

Wouldnt say we need more graphical stuff going on dont need that hehe, but having more detailed landscapes would be better.

[koitsu]

The sizing issue in ncurses fixed itself, but when I try to play it in gnome-terminal, xterm or non-graphical console, any of the "special" characters get expanded to something ugly and long, which screws up the alignment of, well, everything.

I'm not 100% certain of this in the case of DF, but I'm incredibly familiar with ncurses + terminals + locale + character encoding on *IX machines.  The *IX build of DF appears to use ncursesw, which is ncurses but with "wide character support", meaning it supports the use of Unicode (specifically UTF-8).  "Wide character support" translates to two (or more!) bytes being used to define a character.  Look up "UTF-16" on Wikipedia for example.

You should check to see what your character set is both in your shell (under gnome-terminal, xterm, rxvt, Konsole, etc.) by using the "locale" command.  Provide the output here and we can probably help you more.  You should also check what kind of character encoding the terminal emulator is set up for; some may default to UTF-8, others may default to iso-8859-1.  You'll need to find the correct one that works with DF (Baughn can probably state which its been tested on).

There's also some added complexity with regards to terminal emulators (gnome-terminal, xterm, rxvt, Konsole, etc.) and what fonts they use.  AFAIK the emulator and underlying font subsystem on X has to know how to handle Unicode in the case of UTF-8, otherwise if the font lacks support for that, you end up with gobbledegook.

I've a feeling DF has only been tested on iso-8859-1 or UTF-8 locales.