Print

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

Faster than 40d, no problems

42 (26.1%)

Faster than 40d, problems

72 (44.7%)

No slower than 40d, no problems

14 (8.7%)

No slower than 40d, problems

16 (9.9%)

Slower than 40d, no problems

2 (1.2%)

Slower than 40d, problems

3 (1.9%)

Doesn't work (please explain)

12 (7.5%)

Total Members Voted: 160

[dwarfed one]

Output takes only 1/3 of screen in new version. Changed output grid to [80:50] and speed droped 2 times. Windowed mode much faster than fullscreen, as it was in all d40 before. Any printout modes except STANDARD leading to fierce flickering or crash.

[Shoku]

It has to do with the way the tiles are handled. There is color A B C... this is easiest to see with smoothed and then engraved floors (if you have them obscured.) If you've got one of those tilesets where a smoothed floor is basically a + but an engraved floor has extra lines making it into a spiral or laying down a bunch of small squares in the corners. The game makes both of those from the same tile in the font file.

So engravings have a hidden third color, while smoothed floors don't...?

Now, with doors you've surely noticed that sometimes it is a black border with a whatever color door in the middle but other times it is a black door-shape in the middle with a whatever color frame. Again, same tile but the game is looking at the colors in the image file and deciding how to draw them in the game.

But its the same tile...  How does looking at the colors in the image file tell it when to draw which?

Now with engravings transparency is the color that shows up in addition to what there was smoothed (instead of perhaps just inverting it so that your screen became a glob of white, gray, or microcline-blue.)

What is this third color and where does it come from?

or you can make something like a barrel have some 50% transparency that will make it actually, say, act like a shadow instead of just some third color that may or may not be appropriate.

And make your pumps more barrel-like than ever   So it will draw the underlying floor tile, then the barrel on top?  Or the underlying tile color, then the barrel on top?

So with one of the fonts I used way back when the floor is a + with a little o in the middle. It uses two different shades of gray which the game would replace with the colors of the rock the floor was made of. All of the other space is full of neon pink, which the game chooses to not draw letting the black underneath show through. When you engrave this it then shows color everywhere the pink was and black everywhere the grays were.

Since I started using d11 and got a tileset with transparency the floor tile is much the same but instead of pink there is transparency. When engraving these floors the transparent parts still behave rather like the pink but the grays seem to stay as they are. This would still lead to annoyingly bright floors except that this tileset has also got a layer of black over most of it and like red, black gets drawn just as it is.

-actually my pumps don't look like barrels. I might just be the particular materials I'm using having a particular color combination but all I see is a block of color with a % in the middle and then a color % in a block of black.

So the real benefit of having transparency is not that you get to have actually blank squares instead of pink ones but that you can have partially transparent pixels which mostly just get used for shadows but it's one more tool and I like what the tile set I use has done with it.

[Baughn]

I've fixed the outstanding zoom bugs (I hope I didn't miss anything), made the fullscreen resolution picking automatic (you can still pick one, but it defaults to auto) and made the game automatically decide the grid size on startup (so no more calculators needed).

The newest code is in 40d13-head, as usual.

[Baughn]

Finally, added a border around the tile textures so adjacent tiles never bleed into the one DF's trying to draw. Zoom should look better now, as well as black-space:no modes.

[Random832]

Let me repeat that another way so it might sink in...40d11 exclusively used SDL's keysym.  It didn't work for some Dvorak users because the OS layout translation is done with the Unicode translation.

Then SDL is broken and you should use the OS key codes directly.

[Baughn]

Don't start.

DF runs on three separate OSs. Writing code directly against all three would make the project quite considerably larger, and it'd amount to rewriting SDL anyhow.

[Corona688]

Don't start.

DF runs on three separate OSs. Writing code directly against all three would make the project quite considerably larger, and it'd amount to rewriting SDL anyhow.

That sounds really, really odd that SDL would be translating unicode to decode keypresses.  I've done a fair bit of work with SDL, internal and external, and hadn't observed that yet, though I'd need to re-review the keyboard code to be sure.  SDL can do unicode translation, but its an option you must enable with a function call.  If you're enabling it, I'd suggest not, since I still have no conception of what utility unicode would be for DF.

[Baughn]

It's mainly for text input, where we want want " to be bound to " instead of shift-2 being bound to ".

[Corona688]

It's mainly for text input, where we want want " to be bound to " instead of shift-2 being bound to ".

Oh, I see.

Its not like we have the entire world of keyboards to support though, just English ASCII ones.  A lookup table would do the job without all the unicode baggage, and could be fairly trivially customized.  There's really no point in unicode until ASCII letters are no longer contained in the tileset.

Code: [Select]

/* By default, contains translations for QWERTY */
char lcase[]={
        -1, -1, -1, -1, -1, -1, -1, -1,
        -1, -1, -1, -1, -1, -1, -1, -1,
        -1, -1, -1, -1, -1, -1, -1, -1,
        -1, -1, -1, -1, -1, -1, -1, -1,
        -1, -1, -1, -1, -1, -1, -1, 39,
        -1, -1, -1, -1, 44, 45, 46, 47,
        48, 49, 50, 51, 52, 53, 54, 55,
        56, 57, -1, 59, -1, 61, -1, -1,
        -1, -1, -1, -1, -1, -1, -1, -1,
        -1, -1, -1, -1, -1, -1, -1, -1,
        -1, -1, -1, -1, -1, -1, -1, -1,
        -1, -1, -1, 91, 92, 93, -1, -1,
        96, 97, 98, 99, 100, 101, 102, 103,
        104, 105, 106, 107, 108, 109, 110, 111,
        112, 113, 114, 115, 116, 117, 118, 119,
        120, 121, 122, -1, -1, -1, -1, 0,
        };
char ucase[]={
        -1, -1, -1, -1, -1, -1, -1, -1,
        -1, -1, -1, -1, -1, -1, -1, -1,
        -1, -1, -1, -1, -1, -1, -1, -1,
        -1, -1, -1, -1, -1, -1, -1, -1,
        -1, -1, -1, -1, -1, -1, -1, 34,
        -1, -1, -1, -1, 60, 95, 62, 63,
        41, 33, 64, 35, 36, 37, 94, 38,
        42, 40, -1, 58, -1, 43, -1, -1,
        -1, -1, -1, -1, -1, -1, -1, -1,
        -1, -1, -1, -1, -1, -1, -1, -1,
        -1, -1, -1, -1, -1, -1, -1, -1,
        -1, -1, -1, 123, 124, 125, -1, -1,
        126, 65, 66, 67, 68, 69, 70, 71,
        72, 73, 74, 75, 76, 77, 78, 79,
        80, 81, 82, 83, 84, 85, 86, 87,
        88, 89, 90, -1, -1, -1, -1, 99,
        };

int get_letter(const SDL_Event *event)
{
  switch(event->type)
  {
  case SDL_KEYDOWN:
    /* Is this printable ASCII? */
    if(lcase[event->key.keysym.sym] >= 0)
    {
      if(event.key.keysym.mod & KMOD_SHIFT)
        return(ucase[event->key.keysym.sym]);
      else
        return(event->key.keysym.sym);
    }
    break;
  default:
    break;
  }

  return(-1);
}

int load_custom_keymap(void)
{
  FILE *fp=fopen("data/init/keymap.bin", "rb");
  if(fp == NULL)
    return(-1);

  fread(lcase, 128, 1, fp);
  fread(ucase, 128, 1, fp);
  fclose(fp);
  return(0);
} I might be able to produce a DVORAK file on request.

[Corona688]

Then SDL is broken and you should use the OS key codes directly.

SDL is not broken.  It can report keys in two ways.  It can have a sort of 'arcade' mode in which all keys are independent -- you could have left-shift as for gas pedal, right-control as brakes, etc, also providing a bitmask of what combination of ctrl and alt keys are pressed during other keypresses.  D11 uses this mode only, and nothing in that information tells you when shift and \ are supposed to mean ? instead of |.  Hence the dvorak problem.

It also has a unicode mode, which adds an extra value encoding what the key combination actually means, which should fix the dvorak problem.

I was so happy with the D11 keyboard code though.  :/  It had quirks but not game-breaking bugs.  Seems a shame to ditch it.

[Baughn]

It's mainly for text input, where we want want " to be bound to " instead of shift-2 being bound to ".

Oh, I see.

Its not like we have the entire world of keyboards to support though, just English ASCII ones. 

Speak for yourself. I didn't pick 'shift-2 as "' by accident; I'm not using an english keyboard, and so the default keybindings for DF were all wrong.

[Baughn]

Then SDL is broken and you should use the OS key codes directly.

SDL is not broken.  It can report keys in two ways.  It can have a sort of 'arcade' mode in which all keys are independent -- you could have left-shift as for gas pedal, right-control as brakes, etc, also providing a bitmask of what combination of ctrl and alt keys are pressed during other keypresses.  D11 uses this mode only, and nothing in that information tells you when shift and \ are supposed to mean ? instead of |.  Hence the dvorak problem.

It also has a unicode mode, which adds an extra value encoding what the key combination actually means, which should fix the dvorak problem.

I was so happy with the D11 keyboard code though.  :/  It had quirks but not game-breaking bugs.  Seems a shame to ditch it.

I kind of agree, but Veroule's worked a lot more on it than me. For now it's better just to trust that he'll fix the issues eventually.

[Veroule]

Corona is right in the description of what SDL has available.

It isn't so much Dvorak or any other keyboard, as it is the use of OS remapping.  What I really wanted to just do is tell everyone using a physical Qwerty with a Dvorak mapping is to just go buy a Dvorak.   Of course that would be silly.

Windows preforms those remappings in its TranslateMessages API call.  SDL doesn't use that call unless the the Unicode is on, and then it goes all the way.  Which is why I figured I might as well make the bindings able to handle those values.

It's mainly for text input, where we want want " to be bound to " instead of shift-2 being bound to ".

Oh, I see.

Its not like we have the entire world of keyboards to support though, just English ASCII ones.  A lookup table would do the job without all the unicode baggage, and could be fairly trivially customized.  There's really no point in unicode until ASCII letters are no longer contained in the tileset.
--snipped code--

No we don't have to support all keyboards in the world; we will just selectively support the keyboards of all users of DF.  The lookup table is provided by the OS, why should another one be included?  If you are saying that current OS's have a lot of extra baggage, then I must agree.

I don't really think there will ever be a reason to remove the common letters and symbols used by English and many other languages, but at some point more symbols and letters will probably be added.  It takes the same number of clock cycles to compare 1 byte, 1 word, or 1 dword on 32 bit systems.  64 bit systems will do a qword comparison in the same number of clock cycles.  Why stay limited to a single byte.

One comment on your code, expect it to crash frequently.

[Baughn]

..also, you really, really shouldn't be worried about the CPU cost of keyboard input. Ever.

Perhaps for programs that read bulk input from pipes it might be a concern, but not for something like this. There's just no way you should ever notice the CPU cost.

[William]

My sub-menus seem to be screwed up. I've tried different rendering options with the same result, and also, the new one crashes me, but Toady mentioned that it probably would. Here is a screen capture of what I'm talking about: