Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - jacobly

Pages: 1 ... 4 5 [6] 7 8 ... 14
76
Let me know if this works.

77
CircleF( is on the Vars Window menu for now.
CircleF(X,Y,R)Draws a filled circle with center (X,Y) and radius R on the main buffer.
CircleF(X,Y,R)rDraws a filled circle with center (X,Y) and radius R on the back buffer.
CircleF(X,Y,R,BUF)Draws a filled circle with center (X,Y) and radius R on the specified buffer.
CircleF(X,Y,R,BUF,MODE)Draws a cleared/inverted/filled circle with center (X,Y) and radius R on the specified buffer. Mode 0 is clear, Mode 1 is invert, and Mode 2 is fill.

78
Computer Programming / Re: [C#] Scan-line flood-fill
« on: March 02, 2012, 09:40:41 pm »
Imagine:
-----
| # |
|###|
|   |
| X |
|   |
|###|
| # |
-----


First, it fills the scanline.
-----
| # |
|###|
| # |
| # |
| # |
|###|
| # |
-----


Then it scans the (now longer) black scanline, and fills adjacent areas.
-----
|###|
|###|
|###|
|###|
|###|
|###|
|###|
-----


Which I don't believe is what you want. :)

Edit: (btw, I'm just going by what your code says, I haven't looked at the algorithm.)

79
Computer Programming / Re: [C#] Scan-line flood-fill
« on: March 02, 2012, 09:28:59 pm »
--snip-- More importantly, you fill the scanline before you scan the pixels adjacent to the scanline, so you can no longer use the pixels in the scanline to know how far to go. The easiest thing I can think to do is to record the lowest and highest values of y while you fill the scanline, and later only look at adjacent pixels up to those values.
:)

80
Computer Programming / Re: [C#] Scan-line flood-fill
« on: March 02, 2012, 08:52:08 pm »
One thing I noticed is that current is not updated before every while loop, which is probably what is causing it to stop. More importantly, you fill the scanline before you scan the pixels adjacent to the scanline, so you can no longer use the pixels in the scanline to know how far to go. The easiest thing I can think to do is to record the lowest and highest values of y while you fill the scanline, and later only look at adjacent pixels up to those values.

81
The Axe Parser Project / Re: [Axiom] Advanced Graphics [in development]
« on: February 27, 2012, 04:44:01 pm »
Circles anyone? :D

Hint: trying pressing arrow keys, +, -, *, /, enter, and clear to exit.

82
Axe / Re: Axe Q&A
« on: February 16, 2012, 09:00:48 pm »
A random question that I have been wondering:

does the peephole optimizer optimize stuff like this?

Code: [Select]
:A-(-[negative]2)->A

Axe already optimizes something like A−⁻2➔A even without peephole opts :D
(As long as you leave off the parenthesis)

Was the problem of Pause 0 freezing the calc for 30-something seconds ever fixed, or does it still act like Pause 65536?

Yes, Pause 0 acts like Pause 65536. You can avoid this by doing something such as
Code: [Select]
:If A
:Pause
:End
or if you use it multiple times
Code: [Select]
:Lbl Pause
:Return!If
:Pause
:Return

83
Computer Projects and Ideas / Re: Fixed-Memory Flood Fill Pseudocode
« on: February 13, 2012, 04:01:48 pm »
In those screenshots, the screen is being updated 4-5 times per frame, so the program is spending most of the time updating the screen. Also, I haven't even started optimizing the code, and I have some ideas for how to optimize the algorithm. In fact, filling a blank screen from the center without updating the screen currently takes only 10 seconds (That's 24x faster than the screenshot ;D).

Edit: Updating every 256'th frame looks like this:

84
Computer Projects and Ideas / Re: Fixed-Memory Flood Fill Pseudocode
« on: February 13, 2012, 05:24:05 am »
I am working on converting this algorithm to z80 assembly, so I thought I would post some screenshots.

85
Computer Projects and Ideas / Re: Fixed-Memory Flood Fill Pseudocode
« on: February 10, 2012, 03:45:24 am »
To be consistent, each case in the main loop should probably end with continue main loop. Also, I don't see any code that sets MARK2.

86
The Axe Parser Project / Re: Bug Reports
« on: February 04, 2012, 01:09:18 pm »
I forgot to mention that for the new sprite routines, p_DrawSteal has to be changed to:
Code: [Select]
p_DrawSteal:
.db 2
pop ix
otherwise drawing sprites to arbitrary buffers doesn't work :/

87
Hmm, I wonder if there could be a way to copy multiple lines...? You would need to find a way to show what was selected, though, probably :/

You could do something similar to what emacs does (yank and kill). Then you could copy multiple lines without the need for selection. :D

88
Axe / Re: Axe Q&A
« on: January 31, 2012, 11:43:05 pm »
To display a signed number, you can do:
Code: [Select]
:Lbl DspSI
:!If r₁≥≥0
:−r₁➔r₁
:Disp '⁻'▸Char
:End
:Disp r₁▸Dec
:Return

As for the cursor and pen locations, it's usually easier to keep track of them yourself. If you really need to get them, I guess you could do this:
Code: [Select]
:{ᴇ844B} .cursor row
:{ᴇ844C} .cursor column
:{ᴇ86D8} .pen row
:{ᴇ86D7} .pen column

89
Axe / Re: Axe Q&A
« on: January 27, 2012, 12:25:09 pm »
is there any way to draw a single column of pixels that's faster than drawing the same column with Pt-On(?
If you already use Rect( somewhere else, then you should use Rect(X,0,+1,63).
If you already use Line( somewhere else, then you should use Line(X,0,X,63).
If you use both, then I guess the above Rect( command is slightly smaller.
Also, it seems that Rect( is 47 cycles faster (about how long it takes to subtract two variables).

90
TI Z80 / Re: TinyCraft [Axe]
« on: January 27, 2012, 11:43:36 am »

Pages: 1 ... 4 5 [6] 7 8 ... 14