*gfx++ - Socoder

-=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- (c) WidthPadding Industries 1987 0\|113\|0 -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=-
Socoder -> Off Topic -> *gfx++
Sun, 27 Jan 2019, 14:05
spinal	So, why does this int8_t wide = gfx; // first byte is width gfx++; int8_t high = gfx; // second byte is height gfx++; --v work, but this int8_t wide = gfx++; // first byte is width int8_t high = gfx++; // second byte is height --v completely fudge everything up? -=-=- Check out my excellent homepage!
Sun, 27 Jan 2019, 14:05
spinal	note to self, don't put code in the shoutbox, it doesn't work. -=-=- Check out my excellent homepage!
Sun, 27 Jan 2019, 16:09
Jayenkai	I don't mess about with stuff like that. Although I have the ability to a+=b, I'll still often times use a=a+b because I know that the latter will always do what I expect it to do. I've learned over the years that different compilers tend to understand things in slightly different ways, and my last year of c++ has been choc-full of these kinds of examples. Heck, just the other day, I had a really odd issue with values where "Float x-1" was apparently rounding itself back up to x, for stupid dumbass reasons. Lesson. Specify everything, and don't assume that things will always compile the way they did the first time!! In this case.. wide might equal the pointer to gfx, or the value of gfx. .. then adding one to gfx after the fact. Or it might also be the value of gfx + 1, or it might be pointing to the location of gfx +1... it depends on what's compiling it, and what rule that compiler has. -=-=- ''Load, Next List!''
Mon, 28 Jan 2019, 01:35
spinal	The odd thing I found with the above code, was that that was the only part of the function that seemed to break. void twoBitTile(int x1, int y1, const uint8_t gfx){ int8_t wide = gfx; // first byte is width gfx++; int8_t high = gfx; // second byte is height gfx++; uint16_t tileBuffer[widehigh]; uint8_t pix; uint8_t picOffset = 0; int pc = 0; for(int y=0; y<high; y++){ for(int x=0; x<wide; x+=4){ pix = gfx++; tileBuffer[pc++] = game.display.palette[((pix >> 6)&3) +272]; tileBuffer[pc++] = game.display.palette[((pix >> 4)&3) +272]; tileBuffer[pc++] = game.display.palette[((pix >> 2)&3) +272]; tileBuffer[pc++] = game.display.palette[((pix )&3) +272]; } } game.display.directTile(x1, y1, x1+wide, y1+high, tileBuffer); } --v pix = gfx++; --v is fine, even int8_t wide = gfx; // first byte is width gfx++; int8_t high = *gfx++; // second byte is height --v Even seems to work just fine. -=-=- Check out my excellent homepage!
Mon, 28 Jan 2019, 03:46
shroom_monk	C++ operator precedence is well-defined, not compiler specific. See here: en.cppreference.com/w/cpp/language/operator_precedence. Though Jay's advice is still wise: it is often better for write your code more explicitly even if it's longer, to make sure it does what you want! After all, no-one really wants to memorise the entire operator precedence table... Anyway, looking at the table on the page linked above, it says that post-increment (gfx++) has higher precedence than pointer deferencing (gfx). So gfx++ will always be interpreted as (gfx++). Thus int8_t wide = gfx++; int8_t high = gfx++; --v is equivalent to int8_t wide = (gfx++); int8_t high = (gfx++); --v Since x++ is post-increment, and returns the original value of x before it was incremented, you are correct that this should be equivalent to int8_t wide = gfx; gfx++; int8_t high = *gfx; gfx++; --v which is equivalent to your code that apparently works, as the extra dereferences on lines 2 and 4 don't do anything. How exactly is your code going wrong in the two different versions? If you step through with a debugger, what is happening to the values stored in your variables? The one thing that strikes me as possibly problematic about your larger code snippet is that wide and high are signed integers, while gfx is an array of unsigned integers. Your declarations of wide and high are implicitly casting from unsigned to signed, meaning that any values greater than 127 stored in gfx will be lost (overflowing, I assume) when you assign wide and high. I'd suggest making wide and high have type uint8_t instead, like pix already does. -=-=- A mushroom a day keeps the doctor away... Keep It Simple, Shroom!