|
Math help, please |
23yrold3yrold
Member #1,134
March 2001
|
I'll start a new thread for this, since it's buried in other threads where no one will see it I'm trying to save time by skipping offscreen pixels en masse in my little column blitter, but it's messing the texture up a bit. I'm attaching a screenie (the jagginess only appears in walls taller than the screen) and posting the code; does anyone see the problem?
Thanks -- |
aybabtu
Member #2,891
November 2002
|
Hmm...would this work?
Maybe that doesn't help with the speed, though... |
Bob
Free Market Evangelist
September 2000
|
if(tall > SCREENHEIGHT) if(y + tall > SCREENHEIGHT) ? -- |
23yrold3yrold
Member #1,134
March 2001
|
Bob: same diff. y == (tall - SCREENHEIGHT) / 2 I'd forgotten about y and tried using that, and got the exact same results ...
Probably faster though ... there I go; optimizing my errors again -- |
Richard Phipps
Member #1,632
November 2001
|
What happens if you make srcy a float? It looks to me that it's slightly off in the starting values for some lines in a pattern which suggests a rounding error in the start y to me.. worth a try I guess.
|
23yrold3yrold
Member #1,134
March 2001
|
srcy is used to reference a pixel, which means it has use only as an int. I would round it later anyway. -- |
Richard Phipps
Member #1,632
November 2001
|
I'm looking at your picture again where the outlines of the bricks go jaggy. The gaps between the jaggies get bigger as the texture is scaled bigger. There seems to be a general downwards shifting until the texture is drawn jumped up and then it falls down again. It still looks like rounding errors to me. srcy = num / tall; If this line is off by only one on some lines it will produce a jagged effect. (I could be TOTALLY wrong, but could you try it and see?)
|
23yrold3yrold
Member #1,134
March 2001
|
No difference at all; sorry -- |
Richard Phipps
Member #1,632
November 2001
|
Peter Hull
Member #1,136
March 2001
|
Probably it makes a very slight difference but you can take the 'if' out of the loop I think: Pete
|
Fladimir da Gorf
Member #1,565
October 2001
|
It look like you're not taking in account that the top of the current stretched pixel is above the screen. I have the strangest feeling that the problem lies in: num += 64;
which doesn't take in account that you're not starting the pixel rendering from the zero offset.
OpenLayer has reached a random SVN version number ;) | Online manual | Installation video!| MSVC projects now possible with cmake | Now alvailable as a Dev-C++ Devpack! (Thanks to Kotori) |
23yrold3yrold
Member #1,134
March 2001
|
Quote: which doesn't take in account that you're not starting the pixel rendering from the zero offset. But I am atarting the pixel rendering from 0. The while loop is fine; it's the if statement gumming up the works. At first I thought you might be on to something setting y to something other than 0, but num is equal to the sub-pixel offset of the texel, so that should be okay. I think. Here's my most recent revision (which isn't a whole lot different than the last one, but I'll comment it) ...
I renamed 'num' to 'step' for clarity. 'num' was a holdover from the Bresenham function I modified for this -- |
Fladimir da Gorf
Member #1,565
October 2001
|
OK, I didn't make it clear - I think you should subtract something from step before entering the loop. Looking at the screenshot it looks like if all the stretched pixels in the top of the screen are lined up. [edit] Yeah, testing the code it seems the problem is that the y-coordinates get rounded down to the nearest texture pixel. OpenLayer has reached a random SVN version number ;) | Online manual | Installation video!| MSVC projects now possible with cmake | Now alvailable as a Dev-C++ Devpack! (Thanks to Kotori) |
23yrold3yrold
Member #1,134
March 2001
|
Actually, I tried subtracting step from 64. But it didn't help -- |
Fladimir da Gorf
Member #1,565
October 2001
|
And it seems that richard is right - if the wall is close enough, srcy will never be anything else than zero. OpenLayer has reached a random SVN version number ;) | Online manual | Installation video!| MSVC projects now possible with cmake | Now alvailable as a Dev-C++ Devpack! (Thanks to Kotori) |
23yrold3yrold
Member #1,134
March 2001
|
I would probably buy this if you showed me some code that fixes it, since the texture coordinate is definitely not 0 (it's off by a little, not half the texture!) EDIT: Bwa ha ha! That biotch is fixed!!
I was modulo'ing by 64 when I should have used tall. Now I just need to fix that little tiny unrelated texture artifact and I'm done! Woo-hoo! -- |
Fladimir da Gorf
Member #1,565
October 2001
|
Strangely, if I comment out the following lines it seems to work smoothly: if(num >= tall) { srcy = num / tall; num &= 63; } I don't know if commenting them out just ruins the whole idea, though. OpenLayer has reached a random SVN version number ;) | Online manual | Installation video!| MSVC projects now possible with cmake | Now alvailable as a Dev-C++ Devpack! (Thanks to Kotori) |
23yrold3yrold
Member #1,134
March 2001
|
Quote: Strangely, if I comment out the following lines it seems to work smoothly: Yes, it does, but the idea is to skip offscreen pixels en masse. The while loop does it, but it's loads slower ... EDIT: Yeah, I didn't know for sure if %= was a valid operator -- |
Fladimir da Gorf
Member #1,565
October 2001
|
If you change it to this, it seems to work as well: if(num >= tall) { srcy = num / tall; num %= tall; // Note this line // } I think it basically does the same thing as the while(num >= tall) -loop [edit] Finally, I ended up with the following code:
Works damn fast. OpenLayer has reached a random SVN version number ;) | Online manual | Installation video!| MSVC projects now possible with cmake | Now alvailable as a Dev-C++ Devpack! (Thanks to Kotori) |
Richard Phipps
Member #1,632
November 2001
|
cough Quote: And it seems that richard is right - if the wall is close enough, srcy will never be anything else than zero. SMUG MODE: hehehehe! It must be my lucky day, I answered a maths question and got it right! |
Fladimir da Gorf
Member #1,565
October 2001
|
23, I still think you should use my version instead OpenLayer has reached a random SVN version number ;) | Online manual | Installation video!| MSVC projects now possible with cmake | Now alvailable as a Dev-C++ Devpack! (Thanks to Kotori) |
23yrold3yrold
Member #1,134
March 2001
|
My version works and has less code in that loop (which gets called for every wall pixel onscreen). And RP was not right .... Anyway, expect me to post again shortly about that last texture artifact if I can't lick it ... -- |
Fladimir da Gorf
Member #1,565
October 2001
|
"less code in that loop" Which executes slower Especially the while loop thingy. EDIT: One more thing: if( srcy >= 64 ) is the same as if( srcy & 0x40 ) but slower... OpenLayer has reached a random SVN version number ;) | Online manual | Installation video!| MSVC projects now possible with cmake | Now alvailable as a Dev-C++ Devpack! (Thanks to Kotori) |
Richard Phipps
Member #1,632
November 2001
|
ok, I was on the right track! |
23yrold3yrold
Member #1,134
March 2001
|
Quote: Which executes slower Especially the while loop thingy. Sorry, I'm not the one with a divide. My code is much quicker for close walls, and for distant wall the drawing is minimal anyway; I'm getting over 100 fps under any circumstances now. I'll use that (srcy & 0x40) though EDIT: I tried your code; I lost 20 fps ... -- |
|
|