Re: [Ohrrpgce] SVN: jay/4381 Getting it closer to actually working (doesn't crash anymore, but it isn
> From: Mike Caron
> Sent: Friday, June 03, 2011 3:14 PM
>
> On 03/06/2011 2:34 PM, Jay Tennant wrote:
> >> From: Ralph Versteegen
> >> Sent: Friday, June 03, 2011 11:47 AM
> >>
> >> On 3 June 2011 06:00, Jay Tennant wrote:
> >>>> From: subvers...@hamsterrepublic.com
> >>>> Sent: Thursday, June 02, 2011 12:45 PM
> >>>> To: ohrrpgce@lists.motherhamster.org
> >>>> Subject: [Ohrrpgce] SVN: jay/4381 Getting it closer to actually working
> >>>> (doesn't crash anymore, but it isn
> >>>>
> >>>> jay
> >>>> 2011-06-02 10:45:09 -0700 (Thu, 02 Jun 2011)
> >>>> 94
> >>>> Getting it closer to actually working (doesn't crash anymore, but it
> >>>> isn't drawing right yet).
> >>>
> >>> Oh, it's drawing *mostly* correct. That's encouraging! :)
> >>
> >> Sounds good! So do you have a test program? Actually, I'll add a
> >> function to allmodex.bas to draw transformed rects, and can stick a
> >> test of it in the 'secret_menu' in custom.
> >
> > I'm running a test program of it right now, but it's so disappointing: the
> > overflow problem. If I have a fixed point number divided by a very small
> > fraction (say 1/65536th) I get a terribly inaccurate number. I don't want
> > to switch to floating point, but I don't think I have much choice. Is there
> > a solution to this that I'm not getting?
> >
> > Where the issue arises: the rasterizer evaluates a surface to be drawn to
> > one line at a time. The first pass is simply to figure what range of pixels
> > on each line is to be evaluated. The second pass (after all line's pixel
> > ranges are figured) is to interpolate the edge values across the line for
> > each pixel. The error is occurring during the first pass, in figuring the
> > left-most and right-most boundary of a line of pixels to be rasterized.
> >
> > For each line, I take the slope of the edges of the triangle and find all
> > x-intercepts. The left-most intercept and the right-most intercept
> > (as long as they're within range of the triangle) are the boundaries of
> > the pixels.
> >
> > I realize they're some optimizations I could perform (like calculating the
> > edge slopes once), but the error occurs when an edge is almost completely
> > vertical. The fixed point integer can't represent +/- infinite, so an
> > overflow/underflow occurs in determining slope (dy / almost 0).
> >
> > I think the solution is using floating point math for this section. Can
> > you think of another solution? Other than that, the rasterizer's working
> > pretty nicely. I'll commit the code when I'm able to.
>
> Does you algorithm allow for swapping axes? Eg,
>
> if(dy > dx) {
> //swap values, and flip the result turn-ways
> }
>
> I don't know if this is possible in your case, however.
What a clever way around that! I think this will solve the problem! :D
When I'm free later, I'll use that method and commit the (hopefully
working) code.
___
Unlimited Disk, Data Transfer, PHP/MySQL Domain Hosting
http://www.doteasy.com
___
Ohrrpgce mailing list
ohrrpgce@lists.motherhamster.org
http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
Re: [Ohrrpgce] SVN: jay/4381 Getting it closer to actually working (doesn't crash anymore, but it isn
On 03/06/2011 2:34 PM, Jay Tennant wrote:
From: Ralph Versteegen
Sent: Friday, June 03, 2011 11:47 AM
On 3 June 2011 06:00, Jay Tennant wrote:
From: subvers...@hamsterrepublic.com
Sent: Thursday, June 02, 2011 12:45 PM
To: ohrrpgce@lists.motherhamster.org
Subject: [Ohrrpgce] SVN: jay/4381 Getting it closer to actually working
(doesn't crash anymore, but it isn
jay
2011-06-02 10:45:09 -0700 (Thu, 02 Jun 2011)
94
Getting it closer to actually working (doesn't crash anymore, but it isn't
drawing right yet).
Oh, it's drawing *mostly* correct. That's encouraging! :)
Sounds good! So do you have a test program? Actually, I'll add a
function to allmodex.bas to draw transformed rects, and can stick a
test of it in the 'secret_menu' in custom.
I'm running a test program of it right now, but it's so disappointing: the
overflow problem. If I have a fixed point number divided by a very small
fraction (say 1/65536th) I get a terribly inaccurate number. I don't want
to switch to floating point, but I don't think I have much choice. Is there
a solution to this that I'm not getting?
Where the issue arises: the rasterizer evaluates a surface to be drawn to
one line at a time. The first pass is simply to figure what range of pixels
on each line is to be evaluated. The second pass (after all line's pixel
ranges are figured) is to interpolate the edge values across the line for
each pixel. The error is occurring during the first pass, in figuring the
left-most and right-most boundary of a line of pixels to be rasterized.
For each line, I take the slope of the edges of the triangle and find all
x-intercepts. The left-most intercept and the right-most intercept
(as long as they're within range of the triangle) are the boundaries of
the pixels.
I realize they're some optimizations I could perform (like calculating the
edge slopes once), but the error occurs when an edge is almost completely
vertical. The fixed point integer can't represent +/- infinite, so an
overflow/underflow occurs in determining slope (dy / almost 0).
I think the solution is using floating point math for this section. Can
you think of another solution? Other than that, the rasterizer's working
pretty nicely. I'll commit the code when I'm able to.
Does you algorithm allow for swapping axes? Eg,
if(dy > dx) {
//swap values, and flip the result turn-ways
}
I don't know if this is possible in your case, however.
--
- Mike Caron
___
Ohrrpgce mailing list
ohrrpgce@lists.motherhamster.org
http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
Re: [Ohrrpgce] SVN: jay/4381 Getting it closer to actually working (doesn't crash anymore, but it isn
> From: Ralph Versteegen > Sent: Friday, June 03, 2011 11:47 AM > > On 3 June 2011 06:00, Jay Tennant wrote: > >> From: subvers...@hamsterrepublic.com > >> Sent: Thursday, June 02, 2011 12:45 PM > >> To: ohrrpgce@lists.motherhamster.org > >> Subject: [Ohrrpgce] SVN: jay/4381 Getting it closer to actually working > >> (doesn't crash anymore, but it isn > >> > >> jay > >> 2011-06-02 10:45:09 -0700 (Thu, 02 Jun 2011) > >> 94 > >> Getting it closer to actually working (doesn't crash anymore, but it isn't > >> drawing right yet). > > > > Oh, it's drawing *mostly* correct. That's encouraging! :) > > Sounds good! So do you have a test program? Actually, I'll add a > function to allmodex.bas to draw transformed rects, and can stick a > test of it in the 'secret_menu' in custom. I'm running a test program of it right now, but it's so disappointing: the overflow problem. If I have a fixed point number divided by a very small fraction (say 1/65536th) I get a terribly inaccurate number. I don't want to switch to floating point, but I don't think I have much choice. Is there a solution to this that I'm not getting? Where the issue arises: the rasterizer evaluates a surface to be drawn to one line at a time. The first pass is simply to figure what range of pixels on each line is to be evaluated. The second pass (after all line's pixel ranges are figured) is to interpolate the edge values across the line for each pixel. The error is occurring during the first pass, in figuring the left-most and right-most boundary of a line of pixels to be rasterized. For each line, I take the slope of the edges of the triangle and find all x-intercepts. The left-most intercept and the right-most intercept (as long as they're within range of the triangle) are the boundaries of the pixels. I realize they're some optimizations I could perform (like calculating the edge slopes once), but the error occurs when an edge is almost completely vertical. The fixed point integer can't represent +/- infinite, so an overflow/underflow occurs in determining slope (dy / almost 0). I think the solution is using floating point math for this section. Can you think of another solution? Other than that, the rasterizer's working pretty nicely. I'll commit the code when I'm able to. ___ Unlimited Disk, Data Transfer, PHP/MySQL Domain Hosting http://www.doteasy.com ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
Re: [Ohrrpgce] SVN: jay/4381 Getting it closer to actually working (doesn't crash anymore, but it isn
On 3 June 2011 06:00, Jay Tennant wrote: >> From: subvers...@hamsterrepublic.com >> Sent: Thursday, June 02, 2011 12:45 PM >> To: ohrrpgce@lists.motherhamster.org >> Subject: [Ohrrpgce] SVN: jay/4381 Getting it closer to actually working >> (doesn't crash anymore, but it isn >> >> jay >> 2011-06-02 10:45:09 -0700 (Thu, 02 Jun 2011) >> 94 >> Getting it closer to actually working (doesn't crash anymore, but it isn't >> drawing right yet). > > Oh, it's drawing *mostly* correct. That's encouraging! :) Sounds good! So do you have a test program? Actually, I'll add a function to allmodex.bas to draw transformed rects, and can stick a test of it in the 'secret_menu' in custom. ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
Re: [Ohrrpgce] SVN: jay/4381 Getting it closer to actually working (doesn't crash anymore, but it isn
> From: subvers...@hamsterrepublic.com > Sent: Thursday, June 02, 2011 12:45 PM > To: ohrrpgce@lists.motherhamster.org > Subject: [Ohrrpgce] SVN: jay/4381 Getting it closer to actually working > (doesn't crash anymore, but it isn > > jay > 2011-06-02 10:45:09 -0700 (Thu, 02 Jun 2011) > 94 > Getting it closer to actually working (doesn't crash anymore, but it isn't > drawing right yet). Oh, it's drawing *mostly* correct. That's encouraging! :) ___ Unlimited Disk, Data Transfer, PHP/MySQL Domain Hosting http://www.doteasy.com ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
[Ohrrpgce] SVN: jay/4381 Getting it closer to actually working (doesn't crash anymore, but it isn
jay 2011-06-02 10:45:09 -0700 (Thu, 02 Jun 2011) 94 Getting it closer to actually working (doesn't crash anymore, but it isn't drawing right yet). --- U wip/rasterizer.cpp ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
