nesdev.org

That's what I figured. I'm trying to see how I can handle the collision detection sanely, without needing to resort to a modulo, as each box is 24 pixels by 24 pixels (a 3x3 set of tiles).

-Thom

The modulo is the problem here, given an integer divide by 24 such as: ;; void __fastcall__ div24(unsigned char d); _div24: lsr lsr lsr sta TEMP lsr lsr adc TEMP ror lsr adc TEMP ror lsr rts How can I determine a modulo? Is it sitting here in temp at some point? -Thom

Day 3 of still trying to hammer through the controls, still stuck. The intended behavior is to have the player traverse into an opening only if their feet are all the way at the extreme end of the box, if they aren't, then the player moves in the last successful direction until the feet touch the bo...

Hello, everybody. A bit further, I have player movement working, except: * of course, timer state needs to be extended a bit to have the pop-out action * right now all box calculations are done with the top left x,y, which makes player movement with the sprite quite funny if you traverse an intersec...

Yes, BIT was literally designed for situations, like this.

-Thom

A little refactoring of my macros to make them saner, and the collision code became simpler to write, and the bugs went poof: #define STAMP_NUM_FIELDS 8 // Number of fields in each stamp slot #define STAMP_NUM_SLOTS 8 // Number of slots in stamp structure #define STAMP_CENTER_BIAS_X 12 // Offset to ...

Is there a complimentary routine for returning the modulus? I'm needing to do fine adjustment of the division to indicate whether I am actually as far into a box as I can be physically.

-Thom

Looks like enemy collision detection needs a bit of work (I need to add a bit of fudging to allow the monsters to go into the box, as well as some bias correction, but if you look at the radar output, you'll see the collision code is acting as expected) https://www.youtube.com/watch?v=QV_Tf5Mdmf4 -T...

A quick video status report:

https://www.youtube.com/watch?v=BLIaZFthB5o

-Thom

Implemented first passes of initial enemy placement, and radar. (need to re-order radar bits a bit to make it easier to select the correct tile for display.)



Radar is implemented as background tiles, saw no need to waste perfectly good sprites for it.

-Thom

Now status is slowing down a bit, as I slog through entering tables and data for animation and start implementing the frame loop for the main part of the game. I am currently using a very naive vram update scheduler, interleaving parts of the vram to be updated across four different frames, as it is...

Needed more room in my sprite chr bank, so I used NESST's remove duplicates feature. Fantastic feature indeed..in fact, both YYCHR and NESST are fantastically indispensable tools, hats off to Shiru and YY. Now, assembling metasprites is like a twisted jigsaw puzzle. yay. http://i.imgur.com/ZrjM1RL.p...

Wound up using omegamatrix's div by 24 routine: ;Divide by 24 ;15 bytes, 27 cycles _div24: lsr lsr lsr sta temp lsr lsr adc temp ror lsr adc temp ror lsr rts As it turns out, I was being derp by not realizing that I needed to count pixels, not boxes for the divisor, thanks tepples. :) -Thom

So it's division by 24 (which may involve division by 3 or 6 as an intermediate step) to convert from sprite coordinates to metatile coordinates, then multiply by 10 or by 6 (depending on whether row-major or column-major) to convert metatile coordinates to an address in the backing map. I don't se...

(this is for Wizard of Wor)

Nah, I just need to be able to calculate from a sprite position the nearest dungeon box that he's in (the dungeon is implemented as a 10x6 array of squares), so that I can implement collision detection and the like.

-Thom