nesdev.comhttp://forums.nesdev.com/ techniques for tracking world position?http://forums.nesdev.com/viewtopic.php?f=2&t=15871 Page 2 of 3

 Author: rainwarrior [ Fri Apr 28, 2017 7:20 pm ] Post subject: Re: techniques for tracking world position? pubby wrote:Just shift right by 4 then divide by 15.Ah, yes that's correct for divison!Realizing I actually meant "modulo" and not division. Sometimes I forget that you don't necessarily get both from the same calculation. (Though there's probably a similar useful composition of modulos.)

 Author: pubby [ Fri Apr 28, 2017 7:59 pm ] Post subject: Re: techniques for tracking world position? For modulo I'd probably just use repeated subtraction (along with 12.4 fixed point)Code:.repeat 5, i    cmp #15 * (%10000 >> i)    bcc :+    sbc #15  * (%10000 >> i):.endrepeatTakes about 25-30 cycles.

 Author: dougeff [ Fri Apr 28, 2017 8:57 pm ] Post subject: Re: techniques for tracking world position? Edit. Removed. It's too late for me to do math.Edit 2.I'm starting to think that the data should be 256x256 sized rooms (16x16 tiles). You will only be displaying 256x240 at most, but the data should be the full 256 (16 tiles high). Then, no math required, except to figure out how to shift each room.I retract my earlier response, pending more contemplation.

 Author: tokumaru [ Fri Apr 28, 2017 10:37 pm ] Post subject: Re: techniques for tracking world position? The problem is that having "dead zones" in your level map complicates physics and collisions. You have to constantly account for that phantom row when calculating distances, moving objects, and so on. Not to mention it can restrict your usage of metatiles larger than 16x16 pixels, since they'll have part of them cut off when used at the bottom of a room. That's a world of little things I'd rather not worry about. Your solution does help with attribute handling though, I'll give you that!Being a huge fan of the MVC model of software development, I consider it poor form to let hardware aspects influence the architecture of your game worlds as much as this (i.e. pretending parts of your level map don't exist). IMO, having 2 separate anchors, one for the model and another one for the view is a much classier and hardware-agnostic solution, but to each his own.

 Author: calima [ Sat Apr 29, 2017 2:13 am ] Post subject: Re: techniques for tracking world position? rainwarrior wrote:pubby wrote:Just shift right by 4 then divide by 15.Ah, yes that's correct for divison!Yup, and if your Y coord doesn't go above 4096, then you can use a simple LUT for the div-by-15. Otherwise a binary search or the wiki's decomposition.

 Author: dougeff [ Sat Apr 29, 2017 5:54 am ] Post subject: Re: techniques for tracking world position? Quote:The problem is that having "dead zones" in your level map I think you misunderstood me. In my concept of 256x256 'rooms'...that is just how the data is stored. The screen is only 256x240, so if you're in the top most of the top 'room' the bottom is cut off. But if you start scrolling down, you see it. Nothing is 'dead zone'.I'm thinking of a top-down all-direction game like Crystalis.I almost feel like slapping together a demo, but I don't have time.

 Author: tokumaru [ Sat Apr 29, 2017 6:35 am ] Post subject: Re: techniques for tracking world position? Sorry, I completely misread what you wrote. I agree with you on levels built of 256x256-pixel screens/blocks/whatever, but then we're back to the original problem of finding the equivalent position of a block from the level map in screen space. The problem of "figuring out how to shift each room" is what can be solved either by a division by 240 (or 15) or the use of 2 synchronized anchors for the camera.

 Author: Bregalad [ Sun Apr 30, 2017 12:51 pm ] Post subject: Re: techniques for tracking world position? Quote:Not to mention it can restrict your usage of metatiles larger than 16x16 pixels, since they'll have part of them cut off when used at the bottom of a room.Actually Castlevania III does that with it's vertical scrolling screen. It seems to work fine. Mega Man games does that too but the verticall scroll is only "quick" scroll without gameplay.Quote:Did someone write a 16-bit division by 240 routine? (I don't see one in the reference you linked, but it would probably be good to have one around.)I was going to write something, but then I undersood it would be better if whoever whants to implement that actually understood everything. In particular, it depends on many screen heigh you have in total. When supporting a heigh of up to 16 screens for instance, doing modulo is as simple as substracting 240*8, 240*4, 240*2 and 240 to a 16-bit integer whenever doing so will not result in a negative number. Quite simple really.The trick to first shift right by 4 is clever, I didn't think about that. Does it work for modulo too, or only for division ? If the initial value fits in 12-bits then it's definitely a must, as it will save the substracting the hassle of doing it on 16-bit values, and doing it on a value that fits in the A register will lead to much shorter/faster simpler code. However, if the scroll values do not fit in 12 bit anyway, it's not worth it as it will not simplify the division operation itself.

 Author: tepples [ Sun Apr 30, 2017 3:13 pm ] Post subject: Re: techniques for tracking world position? You can do mod 240 by shifting right by 4, reducing mod 15, shifting left by 4, and taking the 4 bits from the original value.Or assuming Python 3 division semantics, where // rounds toward negative infinity:Code:def mod_240(x):    return (x % 16) + ((x // 16) % 15) * 16Or in 6502 (untested):Code:.proc get_camera_y_mod_240  tmp0 = \$0000  ; Load camera_y bits 11-4 into A  lda camera_y_lo  asl a  sta tmp0  lda camera_y_hi  rol a  asl tmp0  rol a  asl tmp0  rol a  asl tmp0  rol a    cmp #240  bcc lt240    sbc #240    bcs not30  lt240:  cmp #120  bcc lt120    sbc #120  lt120:  cmp #60  bcc lt60    sbc #60  lt120:  cmp #30  bcc lt30    sbc #30  lt30:  cmp #15  bcc lt15    sbc #15  lt15:  ; Now that we're under \$0F, shift that to the high nibble  asl a  asl a  asl a  asl a  eor camera_y_lo  and #\$F0  ; keep upper 4 bits; take lower 4bits from camera_y_lo  eor camera_y_lo  rts.endprocBut with all the shifting I'm not sure if this'd be faster than a mod 240 that uses 16-bit arithmetic.

 Author: Sumez [ Mon May 01, 2017 1:06 am ] Post subject: Re: techniques for tracking world position? There's a really good algorithm in the thread tokumaru already linked. I'm using a technique very similar to it in my own engine, and as tokumaru also points out in that thread, it's not really bad to just call that once per frame (which makes my code feel more solid than trying to constantly sync up two variables).I still do keep pixel scrolling and nametable variables separately, of course. It helps that my collision map is stored completely independent from my nametable map (even if they seem very closely related), as 2-bit values stored in groups of 16x16 tiles (= 256x256px). I pretend like the missing rows don't exist for everything other than loading in nametables, and it's working fine for me.

 Author: Bregalad [ Mon May 01, 2017 11:06 pm ] Post subject: Re: techniques for tracking world position? Sumez wrote:There's a really good algorithm in the thread tokumaru already linked. I'm using a technique very similar to it in my own engine, and as tokumaru also points out in that thread, it's not really bad to just call that once per frame (which makes my code feel more solid than trying to constantly sync up two variables).So basically, this thread is an exact duplicate of that thread, everything that has been discussed here had already been discussed there, and this was a complete waste of time of ours. Why don't people use the search function.

 Author: rainwarrior [ Mon May 01, 2017 11:20 pm ] Post subject: Re: techniques for tracking world position? Bregalad wrote:So basically, this thread is an exact duplicate of that thread, everything that has been discussed here had already been discussed there, and this was a complete waste of time of ours. Why don't people use the search function.I attempted a search but didn't find anything. Probably more attempts with different search terms would have found it eventually, but I had no way of knowing whether or not such a thread existed.I don't think it's really a waste of time to have a similar discussion 10 years later...

 Author: Sumez [ Tue May 02, 2017 3:02 am ] Post subject: Re: techniques for tracking world position? Agreed, this is an extremely relevant issue for any games wanting to do vertical scrolling on the NES, so it shouldn't necessarily be hidden away in a 10 year old archive. In fact this is a subject that could easily warrant an entire wiki article.The title of the old thread doesn't exactly make it easy to find either. You need to pinpoint the exact problem (which can be really hard to envision until you're already knee deep) and figure division by 15 is actually a solution for that problem (which works for me, but the repeated suggestion of synchornizing two individual values is just as good to me).

 Author: Bregalad [ Tue May 02, 2017 3:15 am ] Post subject: Re: techniques for tracking world position? Sumez wrote:Agreed, this is an extremely relevant issue for any games wanting to do vertical scrolling on the NES, so it shouldn't necessarily be hidden away in a 10 year old archive.As opposed to the WWWthreads board datings from before the 2004 switch, it's not an archive, it's the same message board as here.Quote:The title of the old thread doesn't exactly make it easy to find either.Indeed, neither is the title of this very thread.Quote:I attempted a search but didn't find anything. Probably more attempts with different search terms would have found it eventually, but I had no way of knowing whether or not such a thread existed.Alas, the search function is indeed weak, one single misspellings and the results collapse to none.

 Page 2 of 3 All times are UTC - 7 hours Powered by phpBB® Forum Software © phpBB Grouphttp://www.phpbb.com/