DAllegro and D confusing output...

no-reply@allegro.cc (Chris Katko) — Sat, 28 Oct 2017 13:10:00 +0000

[edit 1] DOOOOH. I accidentally placed my color code above allegro_init. UHGGGHHH.

[edit 2] WAIT. Now THIS is still really confusing. If I printf with floats, they display correctly:

(RGBA)
501961 0.250980 0.501961 1.000000
501961 0.250980 0.501961 1.000000
501961 0.250980 0.501961 1.000000

Now watch what happens when I use printf unsigned int:

1056997505 1056997505 255        2011460928
0          0          2013416856 0
1056997505 1056997505 2013416888 2011460928

What the heck is going on? Are there multiple "float" values for the same thing? Why would they change going from one variable to another, and why ONLY when using printf with integer output?

Here's both output, at the same time, so you can be sure there's no other data changes:

printf("%12u %12u %12u %12u - %12f %12f %12f %12f \n", c.r, c.g, c.b, c.a, c.r, c.g, c.b, c.a);

  1056997505   1056997505          255    991089984 -     0.501961     0.250980     0.501961     1.000000 
           0            0    993045912            0 -     0.501961     0.250980     0.501961     1.000000 
  1056997505   1056997505    993045944    991089984 -     0.501961     0.250980     0.501961     1.000000

Using ul instead of u (unsigned long) doesn't help either.

[orignal post:]

I keep getting strange problems. One is, printf doesn't seem to always output.

But the DAllegro specific issue...

#SelectExpand
  1
  2struct player_t
  3{
  4ALLEGRO_COLOR c;
  5
  6void setup(ALLEGRO_COLOR c)
  7  {
  8  color = c;
  9  printf("%i %i %i\n", c.r, c.g, c.b);
 10  }
 11
 12void draw(float offset_x, float offset_y)
 13  {
 14  al_draw_circle(x - offset_x, y - offset_y, 10, al_map_rgb(255,0,255), 2);
 15  }
 16  
 17}
 18
 19player_t [2] players;
 20
 21
 22void initialize()
 23  {    
 24  printf("---------------\n");
 25  ALLEGRO_COLOR x = al_map_rgb(128, 64, 128);
 26  printf("%i %i %i\n", x.r, x.g, x.b); //first line output
 27
 28  g.players[0].setup( x ); //second line output
 29  g.players[1].setup( al_map_rgb(128, 64, 128) ); //third line output
 30
 31  printf("---------------\n");
 32  
 33  //...
 34  }

Output:

---------------
0 0 255
0 0 -111424104
0 0 -111424072
---------------

First, why is R=0, G=0 in the first line?

Secondly, why does the color data explode when I store it in a struct?

I'm looking into this problem because I'm writing something super-simple and trying to draw my "players" with a set color. And whenever I pass the data, they go invisible.

I thought structs were value-types, so they should copy in just fine. And if they're going out of scope, shouldn't that be a segfault?

Hmm...

no-reply@allegro.cc (SiegeLord) — Sat, 28 Oct 2017 23:36:59 +0000

Chris Katko said:

Why would they change going from one variable to another, and why ONLY when using printf with integer output?

You're running into the gnarly details of the calling convention (probably optlink, if you're on Windows). Floating point values and integer values are probably placed in different memory locations, and by asking it to decode integers when you're passing floats, you're likely reading garbage.

no-reply@allegro.cc (Chris Katko) — Sun, 29 Oct 2017 02:59:37 +0000

I'm running Linux, but the same may apply. It's certainly a head scratcher for me.

no-reply@allegro.cc (DanielH) — Tue, 31 Oct 2017 03:59:39 +0000

I've never used D, but

Float: 0.501961

Actual float value stored in memory: 0.5019609928131103515625

Breakdown:
float = sign : exponent : mantissa

sign: 0
exp: 01111110
mantissa: 00000001000000010000100

Binary: 00111111000000001000000010000100
Hex: 0x3f008084
Integer: 1056997508

no-reply@allegro.cc (Chris Katko) — Tue, 31 Oct 2017 04:14:41 +0000

Yes! But perhaps I didn't make it clearer. Why does the value change... once it's stored into a class method?

The only possibility (which I don't think exists on further exploration) was that there were multiple bitfield values that equal a float value and somehow it was "converted" to the second one in some kind of casting or something. But I think that's false.