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

[Baughn]

I'm doing something like that already, naturally.

[Veroule]

Sure, your code is where I got the inspiration for that. I pointed it out earlier, even.

Your current code:

Spoiler (click to show/hide)

void renderer::display()
{
  const int dimx = init.display.grid_x;
  const int dimy = init.display.grid_y;
  static bool use_graphics = init.display.flag.has_flag(INIT_DISPLAY_FLAG_USE_GRAPHICS);
  if (gps.force_full_display_count) {
    memcpy(screen_old, screen, dimx*dimy*4*sizeof *screen);
    if (use_graphics) {
      memcpy(screentexpos_old, screentexpos, dimx*dimy*sizeof *screentexpos);
      memcpy(screentexpos_addcolor_old, screentexpos_addcolor, dimx*dimy*sizeof *screentexpos_addcolor);
      memcpy(screentexpos_grayscale_old, screentexpos_grayscale, dimx*dimy*sizeof *screentexpos_grayscale);
      memcpy(screentexpos_cf_old, screentexpos_cf, dimx*dimy*sizeof *screentexpos_cf);
      memcpy(screentexpos_cbr_old, screentexpos_cbr, dimx*dimy*sizeof *screentexpos_cbr);
    }
    // Update the entire screen
    enabler.update_all();

Use a swap on the screen and screen_old after the update_all() and those nasty memcpy's go away.  Basically, remove the memcpy's and assignments into the _old buffers, and put the swap after the call to renderer:display.  Swap is changed to get rid of the 3rd buffer, but does swap the pointers for the 2 buffers.  gps.screen and the render.screen point to the same buffer for the next draw.

An yes, all the enabler calls used to resize the grid haven't been rewritten to handle async yet. I'm working on it.

They shouldn't need a full rewrite, they have to be run from the correct thread.  It looks like everything in the async stuff is blocking correctly so I think it likely the crash is just caused by the GL commands occuring from the wrong thread.

[Veroule]

Only other bug I see is that the keybinding screen does not draw consistently.  It looks like you just need to move the "  enabler.flag|=ENABLERFLAG_RENDER;" out of feed and into logic.  Same with various macro screens.

Otherwise it seems to be totally ready for bigger testing.  Nice work.

[Baughn]

That's sorted the zoom commands and fullscreen. Still got to fix the movie stuff. Which is a little hard without any movies, I should see if I can get the intro movie working.

[vyznev]

I'm doing something like that already, naturally.

OK then, sorry for the needless post, then. 

I just wasn't sure what the problem with the 10 ms granularity would be, then.  Surely the timing loop should compensate for any extra delays by just sleeping less (or not at all) on the next iteration?  Sure, that might result in it sleeping 10 ms every tenth iteration rather than 1 ms every iteration, but it's not like a human can really notice a 10 ms jitter, anyway.

Anyway, I'm probably just making myself look stupid and should go read the code before commenting on it.

[Baughn]

Humans are surprisingly good at noticing jitter, even to the millisecond level. 

But yeah, it's probably overkill to even think about this. It's mostly just that I'm a perfectionist, and I'm totally out of low-hanging or even high-hanging fruit, so I'm looking for rare fruit growing at the peak of mount olympus.

[kutulu]

Huh.  I just noticed that I cannot zoom in/out when using any of the 2D print modes.  STANDARD works fine, though.  This is happening on a Linux machine using d19, and a Windows machine using d19_2.  (In both cases, STANDARD allows me to zoom, but it doesn't seem to handle the tile background properly and the framerate is lower.)

--K

[Baughn]

It's called "2D" for a reason. Without using opengl, there's no reasonable way to zoom.

The framerate drop (though a bit unusual) should be mitigated by the threading in the next version - removed, if you have a dual-core.

[Baughn]

Veroule: I was swapping arrays at the wrong time, in exactly the right way to make it appear to not be drawn. Or to totally mess up the display if framerate is less than 2x display rate. Well, fixed now.

[Veroule]

Also the change back to a calculated sleep was not an issue.  I had to disable the the code for adjusting the resolution to compile.  After think about it I realized why it isn't an issue, the gfps cap that is being used for the calculation will always be <=50 making the calculation come out over 20 everytime.

Speaking of that don't forget to put protections for setting those values back in.  A division by 0 protection is a must.

I will take a look at all the new stuff.

[rdwulfe]

Hey Baughn, sorry for not getting back to you sooner, but life got busy. Been messing around with d19_2 and it seems a vast improvement, +10 fps based on what the FPS in the parenthesis says, and it FEELS much faster, overall. More responsive, smoother, and this is in comparison to d16 which was the fastest DF for me so far. 40-60 dwarves and a FPS of 60-80 (depending on how many of them I have running to throw away rocks. ) is pretty amazing, really. Great work!

[Zwaryczuk]

Yep. If you've got a dual-core, you'll be looking at a pretty solid speedup. If you're not.. well, actually you might still get a speedup (the reasons are pretty complex), just not as big of one.

Sweet! Is this going to be added in with DF2010 or shortly thereafter?

[Leotto]

Sweet! Is this going to be added in with DF2010 or shortly thereafter?

If it's in DF2010 we get all the related benefits, if it's added after release we get DF2010 just that much sooner.

Win\Win, IMHO.

[Veroule]

Everything seems to check out fine.  Hopefully Toady will have time to push out a D20 so you can get a larger group of testers before it goes into the final merge.

But yeah, it's probably overkill to even think about this. It's mostly just that I'm a perfectionist, and I'm totally out of low-hanging or even high-hanging fruit, so I'm looking for rare fruit growing at the peak of mount olympus.

Your mission should you truly seek the Golden Apple of Calixti: Write a new options screen allowing users to control all graphical items on the fly.  They should be able to load different tile sets, adjust the fps caps and display thereof, change between drawing modes, turn on graphical tile usage, adjust the PP count, and change the colors.

If you make it able to save out to the init.txt while still preserving the comments then you will also be given the Sacred Cherry of Cthullu.

[assimilateur]

If you've got a dual-core, you'll be looking at a pretty solid speedup. If you're not.. well, actually you might still get a speedup (the reasons are pretty complex), just not as big of one.

I'm going to go ahead and register my cautious enthusiasm because of this.