My First OS
» > >
» Goto page Previous  1, 2, 3  Next
» View previous topic :: View next topic  
KermMartian wrote:
I'll be honest, it's a bit of an uncomfortable gray area, because on the one hand I am using bits of code in those line-drawing routines that are not originally mine, but on the other hand I've heavily modified them to improve bugs and shortcomings in the originals as well as some needs for those routines specific to Doors CS. I'm not sure exactly where that stands, and since MOS doesn't come with an explicit source code license (or indeed any explicit license) I guess I need to err on the side of caution and say that those line drawing routines (as you took them from the Doors CS 6 source; the DCS7 source has overhauled MOS-compatible line routines) are still mostly at the whim of the original MOS license.


That isn't a gray area at all. It doesn't matter *at all* how much you have improved/fixed it, you stole code. Unless, of course, you got permission (which is doubtful, because it still wouldn't be a gray area then).
There are only two kinds of programming languages: those people always bitch about and those nobody uses. (Bjarne Stroustrup)
Kllrnohj wrote:
KermMartian wrote:
I'll be honest, it's a bit of an uncomfortable gray area, because on the one hand I am using bits of code in those line-drawing routines that are not originally mine, but on the other hand I've heavily modified them to improve bugs and shortcomings in the originals as well as some needs for those routines specific to Doors CS. I'm not sure exactly where that stands, and since MOS doesn't come with an explicit source code license (or indeed any explicit license) I guess I need to err on the side of caution and say that those line drawing routines (as you took them from the Doors CS 6 source; the DCS7 source has overhauled MOS-compatible line routines) are still mostly at the whim of the original MOS license.


That isn't a gray area at all. It is very cut and dry, actually. You *stole* code. The very thing you have ranted about others doing you are guilty of yourself. It doesn't matter *at all* how much you have improved/fixed it, you stole code. Unless, of course, you got permission (which is doubtful, because it still wouldn't be a gray area then).
I got permission from DWEdit/Dan Weiss, who disassembled the MOS routines to use in CrunchyOS, and presumably got permission, then bequeathed the routines unto me for Doors CS since he wasn't going to be updating CrunchyOS any more. It's all water under the bridge, since that was DCS6 and DCS7 has much-improved MOS libraries.

Anywho, back on-topic Anakclusmos' sprite ideas.
Indeed, back on topic, halfway anyway Razz

I started rewriting my own line routines, so far I have this, It can draw lines going left-2-right, right-2-left, up-2-down, or down-2-up. It does horizontal and vertical lines perfectly, but when doing diagonal you get a weird angled line (mainly cause i havent figured out a way to calculate slope and all that junk on the link ben posted)

Code:
;-----> DrawLine
;input:   h=x1 l=y1 d=x2 e=y2
DrawLine:
  ld a,d
  sub h
  jr nc,dl_loop      ;make sure x2 > x1
  ex de,hl
dl_loop:
  push de
  call PixelOnC
  pop de
  ld a,h
  inc h
  sub d
  ld a,e
  jr nz,dl_updatey   ;cont if not vert line or x end
  cp l
  ret z         ;done if y end
  dec h         ;dont inc if vert line
dl_updatey:
  sub l
  jr z,dl_loop      ;if y2-y1=0 dont change
  jr c,dl_moveup   ;if y2-y1<0 move upward
  inc l
  jr dl_loop
dl_moveup:
  dec l
  jr dl_loop


Check out my new sigs too, i made them myself!
Just gettin back in da groove
Very nice on all counts; good luck with the line-drawing routine.
I was thinking about making a sig with something about knowing z80 assembly, but nothing came into mind...Just so you know, the "Almighty Know it all", and the "TI-83+ User" were the sigs I made, feel free to use the "TI-83+ User" one if you want but the know it all's mine Razz

I actually posted that routine cause I need a little help, I cant figure out how I should calculate the increment and decrement of the y when doing diagonal lines, any further explanations or suggestions other the the link ben gave?
Just gettin back in da groove
I think that the math in that link is pretty straightforward, as long as you understand the necessary bit manipulations behind it. Smile

Regarding signatures, have you looked at these general Cemetech signatures? There should be some calculator-specific ones in there somewhere.
The math check the position of the y using the value "error". Error is a fractional number, here lately I've been having one continuous longlasting brain fart and am struggling to consentrate.Can you give me a better explanation on how to apply it in z80?

Id like to note that BC is unused in my current code
Just gettin back in da groove
Error is an integer. Bresenham's line routine only uses addition and subtraction, plus a single shift right to initialise the error (dividing by two). If you understand how the algorithm works, then this version should make sense.
Thanks, that version makes a lot more sense.
Just gettin back in da groove
This may be of some use.
Drew "Sir Cmpwn" DeVault
YEEESSSSS!!! I got it! Here's my finished line routine, it works regardless of which direction you draw the line!


Code:
;-----> DrawLine
;input:   h=x1 l=y1 d=x2 e=y2
DrawLine:
  ld a,d
  sub h
  jr nc,dl_FixedLR   ;make sure x2 > x1
  neg
  ex de,hl
dl_FixedLR:
  ld b,a      ;b=deltax
  sra a
  ld ixh,a      ;ixh = error
  ld a,e
  sub l
  ld c,a
  jr nc,dl_loop
  neg
  ld c,a
dl_loop:
  push bc \ push de
  call PixelOnC
  pop de \ pop bc
  ld a,h
  inc h
  sub d
  jr nz,dl_updatey   ;cont if not vert line or x end
  ld a,e
  cp l
  ret z         ;done if y end
  dec h         ;dont inc if vert line
dl_updatey:
  ld a,ixh
  sub c
  ld ixh,a
  jr nc,dl_loop
  add a,b
  ld ixh,a
  ld a,e
  sub l
  jr z,dl_loop      ;if y2-y1=0 dont change
  jr c,dl_moveup   ;if y2-y1<0 move upward
  inc l
  jr dl_loop
dl_moveup:
  dec l
  jr dl_loop

I'll definately be using this from now on, kicks the MOS routines butt in size specs
Just gettin back in da groove
Yes, but your speed is going to be horrendous. You repeatedly need to find the pixel using PixelOnC. Smile Plus, it can only turn pixels on, not invert or erase them. I'm sure you'll soon find solutions, though.
I guess that kinda sucks Razz, I guess i could rewrite it to find the first pixel with GetPixel, add 96 to hl for y inc, and just inc hl for the x. Ill give it a solid try
Just gettin back in da groove
A faster way is to store the pixel mask and address in the graph buffer rather than the pixel coordinates. Add (or subtract) 12 to the address to move up or down and rotate-with-carry to move left or right. If carry is set after the rlc/rrc operation you would then need to increment/decrement the address.
Smile great minds think alike, before I saw your message I done exactly that.Getting it to draw the line is easy now, it getting it to stop thats the problem...I'm using hl for the current byte, b for deltaX, c for deltaY, de is the second coordinates, ixh is the error integer, and ixl is the pxl mask.I really don't want to create a buffer, but at the same time I dont want to disable interrupts to use exx and ex af,af'.I might have no choice though...
Just gettin back in da groove
I thought this was for your own OS? If so, don't waste the shadow registers on your ISR.
benryves wrote:
I thought this was for your own OS? If so, don't waste the shadow registers on your ISR.
What do you suggest instead, pushing and popping the registers around the ISR, I presume?
Exactly. Interrupts will only be fired a few hundred times a second or so, whereas you could use the shadow registers tens of thousands of times per second. It makes sense to use the slow way to preserve registers when dealing with code that is infrequently executed and save the fast way to preserve registers to deal with code that is frequently executed.
In an OS, you can easily sacrifice size for speed. I encourage you to use the fastest method you can find, without regard for size (unless it is absurdly large).
Drew "Sir Cmpwn" DeVault
benryves wrote:
Exactly. Interrupts will only be fired a few hundred times a second or so, whereas you could use the shadow registers tens of thousands of times per second. It makes sense to use the slow way to preserve registers when dealing with code that is infrequently executed and save the fast way to preserve registers to deal with code that is frequently executed.
Definitely, I agree with you there. With a new OS he has that option, which is helpful. It's my understanding that in the TI-OS, any routine that uses the shadow registers will ld a,i \ push af \ di and pop af \ ret po \ ei \ ret around the relevant sections of code, on the assumption that the interrupt will trash the shadow registers, and thus I've always had to follow the same in my own code to have any chance of playing nice with the interrupt.
  
Register to Join the Conversation
Have your own thoughts to add to this or any other topic? Want to ask a question, offer a suggestion, share your own programs and projects, upload a file to the file archives, get help with calculator and computer programming, or simply chat with like-minded coders and tech and calculator enthusiasts via the site-wide AJAX SAX widget? Registration for a free Cemetech account only takes a minute.

» Go to Registration page
My First OS
» Goto page Previous  1, 2, 3  Next
» View previous topic :: View next topic  
Page 2 of 3
» All times are UTC - 5 Hours
 
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

 

Advertisement