Irgendwer Posted April 24, 2009 Share Posted April 24, 2009 (edited) *** deleted *** Edited April 24, 2009 by Irgendwer Quote Link to comment Share on other sites More sharing options...
Heaven/TQA Posted April 24, 2009 Author Share Posted April 24, 2009 well... in MADS you would have something like this: sqrtabl :256 .byte <[#*#] sqrtabh :256 .byte >[#*#] so in theory: ldy #monster_type_id lda mx sec sbc px bpl eor #$ff clc adc #1 tax lda sqrtabl,x sta temp+1 lda sqrtabh,x sta temp2+1 lda my sec sbc py bpl eor #$ff clc adc #1 tax lda sqrtabl,x clc temp adc #0 lda sqrtabh,x temp2 adc #0 cmp monsterdistance,y bcc yes_collision no_collision just out of my head... Quote Link to comment Share on other sites More sharing options...
Rybags Posted April 24, 2009 Share Posted April 24, 2009 You could probably lose that first CLC - when you've got that underflow condition the Carry should already be cleared for you. Quote Link to comment Share on other sites More sharing options...
JamesD Posted April 24, 2009 Share Posted April 24, 2009 (edited) That looks pretty good. I'd like to see how well it actually works. The only problem I see is now that monsterdistance is now pre-squared and you can't check (x2-x1) or (y2-y1) against it to bail out of the routine early to save some clock cycles. A very rough estimate puts it at 40+ clock cycles but I ddidn't use a book so that could be way off. The table of squares still take quite a bit of memory too. I don't see a shift to divide by 2 did I miss something? I suppose you don't have to check distance every vblank or all monsters every vblank. (you aren't moving everything every frame right?) With 50 or 60 vblanks / sec, if you check 1 monster every vblank, you end up updating 50 monsters in 1 sec or 10 monsters at least 5 times / sec. And once a monster has seen/smelled you could update those more often if needed, it just depends on how much time you have to play with. Edited April 24, 2009 by JamesD Quote Link to comment Share on other sites More sharing options...
JamesD Posted April 24, 2009 Share Posted April 24, 2009 If you really need more range than 1 shift gets you, you can try shifting twice. I have my doubts about how well it would work though. That would result in 4 pixels variance. Quote Link to comment Share on other sites More sharing options...
Heaven/TQA Posted April 24, 2009 Author Share Posted April 24, 2009 need to check tonight. right now the game cycle is done 1 monster per frame. but not sure if this approach is actually faster then the "old" one with the CMPs and the DXTABs... Quote Link to comment Share on other sites More sharing options...
JamesD Posted April 24, 2009 Share Posted April 24, 2009 If you really need more range than 1 shift gets you, you can try shifting twice. I have my doubts about how well it would work though. That would result in 4 pixels variance. Actually, it would vary by location since we are talking about squaring and adding two numbers. Dropping that much precision could be ugly. Quote Link to comment Share on other sites More sharing options...
Heaven/TQA Posted April 24, 2009 Author Share Posted April 24, 2009 bool Circle::isOverlapped(const Circle &another) { double t = pow(another.x - x, 2) + pow(another.y - y, 2); double dist = sqrt(t); double sumR = another.r + r; return dist <= sumR; } Quote Link to comment Share on other sites More sharing options...
JamesD Posted April 24, 2009 Share Posted April 24, 2009 (edited) Overlapping circle observations... 2D array, 2D array, SQRT. That's three table lookups and two have a multiply involved. That's gotta cost some serious clock cycles. It's also 2 arrays. 1 for pow and 1 for sqrt. So it's also two memory pages. Ouch I'm still not sure I follow the double circle idea. I guess you could wear different armor that makes you more or less detectable. Some could be visible and others could be stink. For example... dead hide of impenetrable beast could protect well but gets you mobbed by monsters. You could have stealth armor (ooooooooo... stealth!!!!) that makes you less visible. But then you could do that just by using a subtract factor for the final distance which would be faster. <edit> Correction, add factor. To subtract just use a negative number. Edited April 24, 2009 by JamesD Quote Link to comment Share on other sites More sharing options...
Rybags Posted April 24, 2009 Share Posted April 24, 2009 I don't get a double-circle concept either. I suppose you might take the philosophy that if the player's circle of influence touches the monster, then that entitles him to some defensive ability against attack. It seems all this is getting kinda complicated... do you think the end result will be better using all this complexity? Quote Link to comment Share on other sites More sharing options...
JamesD Posted April 24, 2009 Share Posted April 24, 2009 pow as in power. Ok, so if it's always a power of 2 it's a multiply or a table lookup. My bad. Quote Link to comment Share on other sites More sharing options...
JamesD Posted April 24, 2009 Share Posted April 24, 2009 I don't get a double-circle concept either. I suppose you might take the philosophy that if the player's circle of influence touches the monster, then that entitles him to some defensive ability against attack. It seems all this is getting kinda complicated... do you think the end result will be better using all this complexity? I can see the player circle from the detectability (stealth, stink, shiny, noisy) standpoint but you don't need a circle, just added/subtracted distance. There should be no circle, only distance. It just happens to form a circle around a monster or the player. You might need a distance calculation from the player to calculate the effectiveness of a spell or accuracy of an arrow. But then it's still just distance you are calculating and you could check the results outside a callable distance routine. Quote Link to comment Share on other sites More sharing options...
JamesD Posted April 24, 2009 Share Posted April 24, 2009 (edited) From the detectability standpoint there is a lot of potential to mess with the player. Some armor might be required to kill a boss... but if it put it on too soon it can tire you, make you sweat, attract too much attention too soon and get you killed. The longer you wear a heavy piece of armor the greater the distance you are detectable from. That might be fun to throw at the player but the complexity might be a bit much for the memory. Edited April 24, 2009 by JamesD Quote Link to comment Share on other sites More sharing options...
Heaven/TQA Posted April 24, 2009 Author Share Posted April 24, 2009 well... actually i brought the 2 circle stuff in the discussion which maybe can lead to a circle with radius 1 might be the player...or circle of 4/8 pixel... the only goal right now is to have a quick and good looking solution of player putting the monsters in hunting mode... Quote Link to comment Share on other sites More sharing options...
JamesD Posted May 23, 2009 Share Posted May 23, 2009 This isn't related to the current task but I thought you might find it useful... or at least interesting. A* Algorythem Quote Link to comment Share on other sites More sharing options...
Heaven/TQA Posted May 23, 2009 Author Share Posted May 23, 2009 thanks... always good to learn new stuff... now I remember that I had implemented the manhattan distance or taxi cab... forgot the name... Quote Link to comment Share on other sites More sharing options...
Heaven/TQA Posted June 2, 2009 Author Share Posted June 2, 2009 ok... got it run on my real setup and I have to admit that the sprite routine is quite good...better 50fps "feeling" on real machine than in any emulator... again...nothing can beat the real thing... but still have to fix the damned sprite garbage sometimes appears on the screen. Quote Link to comment Share on other sites More sharing options...
Heaven/TQA Posted June 7, 2009 Author Share Posted June 7, 2009 after weeks of weeks hunting a nasty sprite bug it seems that I am on the right track... got the routine isolated which produced the artifacts... puh... let me see if I can kill that bug... Quote Link to comment Share on other sites More sharing options...
Heaven/TQA Posted June 7, 2009 Author Share Posted June 7, 2009 (edited) it's definitly this routine and it's logic: check_background: lda nxpos lsr lsr sta checkb0+1 lda nypos tay lsr lsr lsr tax lda linetab2l,x clc checkb0 adc #0 sta v0 lda linetab2h,x adc #0 sta v0+1 ldx #1;depends on even ypos 2 or 3 lines checked tya and #7 beq checkb1;only 2 lines inx checkb1 ldy #0 sty temp checkb2 lda temp ora (v0),y checkb4 iny ora (v0),y checkb5 iny ora (v0),y sta temp checkb6 tya clc adc #$26;next line tay checkb3 dex bpl checkb2 lda temp rts so... actually I am checking the background buffer each time a sprite moves... so as you can see I am always checking 2x3 or 3x3 cells in the backbuffer... not that this is even not necessary the ora'ing is wrong, too as it gives "wrong" results... f.e. this is the backbuff on the new position AAA AAA AAA results in A assume that the monster sprite is now moving 1 pixel to the right... and the backbuff would look like this: .AA .AA .AA so actually the collum is free to move but the routine would give me A as result and so that movement would be rejected... or ..A BBB BBB and it seems that there are cases where my set_monster routine would act wrong by this check background logic... I will make tests now with a checkup, checkleft, checkright and checkdown special routines... Edited June 7, 2009 by Heaven/TQA Quote Link to comment Share on other sites More sharing options...
Heaven/TQA Posted June 8, 2009 Author Share Posted June 8, 2009 i don't really get it... maybe I am really stupid...now the third time I am rewriting the sprite routines... maybe you can help here... can you play around with this build and try to recreate the garbage where the sprite engine misses to erase the same sprite and moves on to next position and draws the sprite??? under which circumstances in your oppinion does it appear??? sprite10.zip Quote Link to comment Share on other sites More sharing options...
JamesD Posted June 8, 2009 Share Posted June 8, 2009 (edited) i don't really get it... maybe I am really stupid...now the third time I am rewriting the sprite routines... maybe you can help here... can you play around with this build and try to recreate the garbage where the sprite engine misses to erase the same sprite and moves on to next position and draws the sprite??? under which circumstances in your oppinion does it appear??? I can't get it to create garbage but if you go to the right edge of a dungeon and then go up or down it moves the character to the left a space and then up or down. <edit> Oops... spoke too soon. The garbage is a sprite image you can run over and it never moves. It appears to happen at the spawn points. Are you sure it's not a setup issue? Edited June 8, 2009 by JamesD Quote Link to comment Share on other sites More sharing options...
JamesD Posted June 9, 2009 Share Posted June 9, 2009 I found some additional issues. 1. When trying to exit a room it drew a character outside the room. This happened once. I was above the door and walking left when it happened. 2. Monster disappeared once. It was a monster that was just spawning and I somehow managed to walk over it. Once I moved it appeared again. 3. Crashed after waling all over the place. Quote Link to comment Share on other sites More sharing options...
Heaven/TQA Posted June 9, 2009 Author Share Posted June 9, 2009 Thanks James... will look into the spawn routine, too... in the debug build you should only walk from room #1 to room #2 as the other rooms are drawn but I am not telling the monster engine that we are in a new room... and the monsters are only walking into one direction to make it easiert to hunt the bug... you can press option/select/start to show the back buffer at any time. I can recreate the bug when bumping in one monster from the right side and then tease it...so move little bit away and then again back... Quote Link to comment Share on other sites More sharing options...
JamesD Posted June 9, 2009 Share Posted June 9, 2009 Thanks James... will look into the spawn routine, too... in the debug build you should only walk from room #1 to room #2 as the other rooms are drawn but I am not telling the monster engine that we are in a new room... and the monsters are only walking into one direction to make it easiert to hunt the bug... you can press option/select/start to show the back buffer at any time. I can recreate the bug when bumping in one monster from the right side and then tease it...so move little bit away and then again back... I downloaded the file and just clicked on it. It wasn't limited to 2 rooms whatever I ran. If it's caused by interaction between the character and baddies the only thing I can think of that would do that is if the location was updated before erasing the old position. After playing with it some more, it also marked a spot on the backbuffer as occupied and didn't clear it. So there is a spot on the screen you can't walk through even though nothing is there. Quote Link to comment Share on other sites More sharing options...
Heaven/TQA Posted June 9, 2009 Author Share Posted June 9, 2009 it was "limited" because I haven't transfered the "enter new room" code except for "draw_new_room"... Quote Link to comment Share on other sites More sharing options...
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.