2024-06-30 00:36:09 <zelgomer    > say i write a word that takes an execution token which will be passed one argument and may access the stack underneath if it chooses. do you think that's implied, or should it be mentioned in the comment?  : foo ( i*x xt ( i*x a -- j*x b)) ... ;  versus  : foo ( xt ( a -- b)) ... ;
2024-06-30 00:37:17 <zelgomer    > well, actually   : foo ( i*x xt ( i*x a -- j*x b) -- j*x -1 | j*x 0) ... ;  versus  : foo ( xt ( a -- b) -- -1 | 0) ... ;
2024-06-30 00:37:23 <zelgomer    > this is getting hairy
2024-06-30 00:55:10 <crc         > I don't normally include a stack comment for the xt being passed in, prefering to document that separately.
2024-06-30 00:55:45 <zelgomer    > "separately" meaning in a shadow page or something?
2024-06-30 00:55:48 <crc         > as you note, including the xt's stack comment as a nested thing can get hairy
2024-06-30 00:56:19 <crc         > I have a documentation block for each word with space for longer descriptions/notes and usage examples
2024-06-30 00:57:30 <zelgomer    > alright, thanks. so given that, still would you use  : foo ( i*x xt -- j*x) ;  or would you let the reader assume or the documentation block describe that xt can manipulate the underlying stack if it chooses to?
2024-06-30 01:02:00 <crc         > I assume the reader will refer to the documentation for full details; for me the basic stack comments are mostly just a quick reminder of the quantity/type of data being passed in & returned. For me, it'd probably look like: `:foo (...q-?) ;` (... is my notation for taking in an arbitrary number of values, and ? for returning an arbitrary number of values)
2024-06-30 01:02:57 <zelgomer    > i see. thanks!
2024-06-30 01:03:58 <zelgomer    > and re: "stack comments are mostly just a quick reminder" -- psh, what do you think i am, a technical writer? :)
2024-06-30 01:21:32 <thrig       > ( It was a dark and stormy stack
2024-06-30 04:07:19 <zelgomer    > )
2024-06-30 04:13:42 <thrig       > it was the best of stacks, it was the worst of stacks, now is the winter of our stacks,
2024-06-30 10:43:32 <vms14       > i keep being amused by the simplicity of examples like this
2024-06-30 10:43:35 <vms14       > : BREAKFAST HURRIED? IF CEREAL ELSE EGGS THEN CLEAN ;
2024-06-30 11:50:21 <dave0       > it's nice how it reads like how you speak
2024-06-30 15:05:59 <zelgomer    > YES THAT LIKE JUST SPEAK I
2024-06-30 15:08:09 <zelgomer    > and yeah in my experience the contrived examples are rarely representative of forth in practice
2024-06-30 17:53:12 <veltas      > crc: Commenting on your graphics notes, the leap to 3D just requires non-integer coordinates (e.g. 1/10th or 1/100th or whatever pixels) or you get the playstation 1 vertex wobble
2024-06-30 17:53:36 <veltas      > And ability to transform the fill texture
2024-06-30 17:59:49 <veltas      > There's a lot more to say about this and am willing to talk about it but won't barage you now
2024-06-30 18:18:22 <veltas      > And I agree stack comments are just quick use, the technical notation that e.g. the standard uses for everything is not worth writing in source/screens
2024-06-30 19:55:49 <crc         > veltas: I'll welcome any information that's helpful in getting to supporting 3D. It'll likely not be something we start on in the short term (so probably not this year), but it's definitely something we want to support.
2024-06-30 19:59:03 <GeDaMo      > I believe this algorithm is the basis for hardware rasterizers in GPUs https://www.cs.drexel.edu/~deb39/Classes/Papers/comp175-06-pineda.pdf
2024-06-30 20:02:21 <MrMobius    > crc: pic32 is a neat chip if you haven't seen it and comes I throughhole so very accessible even if you're new to hardware
2024-06-30 20:03:19 <MrMobius    > you could do some parallel graphics processing with a handful of those
2024-06-30 20:32:51 <veltas      > GeDaMo: Very nice reference
2024-06-30 20:35:33 <crc         > GeDaMo: thanks; I've downloaded a copy & will read through it later this week
2024-06-30 20:35:35 <GeDaMo      > I think rasterizers are still fixed function in GPUs, I was curious how they worked
2024-06-30 20:35:51 <veltas      > I think so too
2024-06-30 20:36:38 <veltas      > I know interestingly implementations aren't fast for tiny triangles, a shader-based rasteriser can be faster
2024-06-30 20:37:48 <GeDaMo      > Also Michael Abrash once worked on a software DirectX7 renderer https://www.drdobbs.com/architecture-and-design/optimizing-pixomatic-for-x86-processors/184405765
2024-06-30 20:37:51 <crc         > re: PIC32, looking at it now. I think I've seen these before (IIRC, RetroBSD runs on this architecture; I had helped a little with porting an older RetroForth to it a few years back)
2024-06-30 21:32:49 <veltas      > The only issue with first paper is it's not very introductory, it assumes you understand all the concepts.  But I think all the concepts can be googled if necessary
2024-06-30 21:34:13 <veltas      > The paper is great though, the rasterisation info in there is better than anything I've seen elsewhere, is it a 'standard' algorithm?
2024-06-30 21:34:33 <veltas      > Weird how all the people who write articles about software rasterisation seem to be working off of inferior approaches
2024-06-30 21:39:51 <GeDaMo      > https://www.scratchapixel.com/lessons/3d-basic-rendering/rasterization-practical-implementation/overview-rasterization-algorithm.html
2024-06-30 21:45:15 <veltas      > GeDaMo: That's exactly what I'm talking about, one of the first things that comes up when you google and their algorithm is abysmal
2024-06-30 21:45:54 <veltas      > That algorithm will run unboundedly slower than the first paper you posted's algorithm
2024-06-30 21:46:32 <veltas      > It iterates over a 2D bounding box of the triangle, and triangles can (and often are) be very very thin and diagonal
2024-06-30 21:46:41 <GeDaMo      > Interestingly, they refer to the Pineda paper
2024-06-30 21:46:51 <veltas      > So in practice that algorithm will run 100, 500, 1000% slower than the Pineda algorithm
2024-06-30 21:46:57 <veltas      > Depending on the triangle
2024-06-30 21:47:18 <crc         > I've forwarded the paper to Arland; he'll hopefully have some time to read through it over the next few days. (since he's already done some 3D work in the past, he should be able to follow it more quickly than I can)
2024-06-30 21:48:51 <veltas      > In the paper they specifically move across the boundary to find the starting pixel of a scanline, rather than just drawing a 2D box, and even explain how to integrate clipping efficiently into this
2024-06-30 21:49:22 <veltas      > I suppose I shouldn't be surprised an old paper is better written than some web article
2024-06-30 21:50:26 <GeDaMo      > Like I said, I wondered how the hardware rasterizers worked and that's the paper I ended up on
2024-06-30 21:51:16 <veltas      > Nice
2024-06-30 21:51:35 <veltas      > You're always full of good references :P
2024-06-30 21:51:48 <GeDaMo      > I read a lot :P
2024-06-30 21:51:59 <GeDaMo      > I don't necessarily understand everything I read :|
2024-06-30 21:53:19 <veltas      > I'm gainig a slow burn appreciation for papers
2024-06-30 21:54:07 <GeDaMo      > When I first got access to the Internet in the mid 90s, the research papers were the best part! :P
2024-06-30 21:54:35 <veltas      > All been downhill since
2024-06-30 21:56:26 <thrig       > but there's more cat photos?
2024-06-30 21:57:15 <GeDaMo      > http://tubbypaws.blogspot.com/2008/03/meow-you-can-has-lolcats.html
2024-06-30 22:02:14 <vms14       > ahahah wtf
2024-06-30 22:02:16 <vms14       > "OH NOEZ CEILING CAT IS WATCHING ME FAP!"