This page is a mirror of Tepples' nesdev forum mirror (URL TBD).
Last updated on Oct-18-2019 Download

help decide how to program things: Sprite Metatiles|Updated

help decide how to program things: Sprite Metatiles|Updated
by on (#109372)
Okay, first off this isn't some wimpy code example or something. This is more aimed at specific, but more complex, part for NES code. This one I'm working on now is metasprites. This is a over view of very fine details of the engine:

The game will have an object system with X objects, assigned at compile time. Basically, a program goes through each object, pulls it's metasprite (When this gets done and written, then I'll add animation frames), and then basically says "Process this" to another program, the decoder+OAM rotation program.

The decoder program first looks at the number of tiles, the first byte in a header that contains the tiles used. The second and third bytes in the header are the x pixels used, Y pixels used for flipping. But the OAM routine has two sets of pointers. One that points to $00 and $40 at the beginning. What it does is takes the object number EOR'd with the frame number and the first bit is then used to select the $00 or $40 index. If the object gets the $00, the first (least index) is copied to the index variable to use. The X is then put to another variable to know the origin later. If the object gets the first index, which decreases to put the OAM in the screen, it checks to see if we have enough tiles. If so, we take the 2nd index, subtract the "requested tiles" and then put that OAM index to the variable to use later. If there's not enough tiles requested, then we use the first index value but then use and tell the program the 2nd one is still the origin. We can do this because there's also a count that counts down each time a tile is put on the screen, so we KNOW we will never over run another tile.

Okay, now that that is said, we have a problem. I disable sprites who's coords overflow and are not on the right side of the screen. In the engine, if the Object YX flip bits are set, I add the X/Y offsets in the header. If they go to the wrong side of the screen, I set a bit in a variable called TestShowing. Those bits go "00YX.0000" so far, which are the disable bits for the bases of the sprite. But after each tile movement, I am going to set the two high bits to test if it's BACK on a good side of the screen. So we have "YXYX.0000". Basically I am going to load the value, ASL twice, EOR with the original, and then and #%11000000. If it's not zero, the tile does not get written. We have a problem with this if the backwards buffer is going because it starts in the middle of OAM data, it can't subtract down like would be easy because we have to keep sprite priority in order.

Would your solution just be keep the empty spaces in OAM regardless? My solution is looking like I will take how many tiles are not used, and move the OAM objects down, and then when setting the new location, just make sure the tiles used get subtract, which isn't too bad, but might not be worth the CPU. Just wondering what you guys think on this one, as it's trick, complex, and might have places for optimization just from my way of attacking it.

Disclaimer: don't expect working code today, hopefully in the next few days. I have about...175 lines of code so far, not even close to done with this program, and have not tested any part once. So it'll probably take a little bit to debug after I get the way I want it to work down. But, every line of code is very well commented so it shouldn't be hard at all to debug.
Re: Help me decide how to program things. (Sprite Metatiles)
by on (#109378)
Having "empty" space in your OAM is not a problem at all. As long as they are at an offscreen location they won't interfere with your other sprite rendering. It will not help efficiency to compact this space (probably the opposite, since it may take you more time to compact it). I wouldn't bother trying to do this until/unless you run out of space and want to have more sprites.
Re: Help me decide how to program things. (Sprite Metatiles)
by on (#109379)
Well, the thing is I might not run out of space if I did adjust the OAM position for backwards writes if I check after and move if there were. But that's one vote for just screw it, basically? :)

Also, side note, is when I run out of tiles, the one that ran out of tiles will be the first object processed. Weather it will be the first in OAM is a 50% chance, so if there's more than 8 sprites on a scanline and it's not the first object, it won't be shown again. But as long as there's more tiles on the frame than could be handled, it'll show the 3rd because it'll then be in the front end.

Right now I'm thinking the same thing, any unrendered tiles will just have a Y position of FF. That should be good enough, I don't need to use every tile every frame, I'll have to flicker sometime, if I ever used that many.
Re: Help me decide how to program things. (Sprite Metatiles)
by on (#109385)
I have to admit that I didn't quite understand the reason for holes in the OAM. In my own engine, I do all the range checking while outputting the sprites, so if X or Y happen to be out of range I simply don't increment the sprite index, so that the next sprite will use the slot that was left unused (it doesn't matter that some of the data for the other sprite was written already, as it will be overwritten).
Re: Help me decide how to program things. (Sprite Metatiles)
by on (#109386)
It wouldn't have any holes in OAM if it would put all the tiles there, but if it only puts 4 tiles of a sprite of 8, the data would be 4 bytes of OAM data, and then 4 blanks to where nothing was put down. And since it's moving backwards, it has to start from the deepest part to not overlap it. Would a few images help? It is kinda hard to understand...the holes also woul only ever happen in the decreasing array, never in the forward moving one. :)
Re: Help me decide how to program things. (Sprite Metatiles)
by on (#109438)
I too was having some difficulty understanding the full process. But from what I gather, with the way metasprites are rendered in your engine, under certain circumstances you may end up with gaps in your sprite page (for sprites sticking off screen). If I'm understanding correctly, I don't think it'll matter too much. If you are saying "render this object", you should assume the risk of the whole object being on screen, and taking up each sprite slot. If it really saves you time, and you otherwise have a very efficient engine, then I'd vote for "screw it".

If I were going to offer a suggestion for fixing it, I'd probably vote for rewriting the whole rendering method. I haven't dealt with a need for priorities in mine (only flickering sprites when there are more than 8 per scanline), but I'm sure there's a way you could rework some of your code so that you wouldn't have that problem in the first place. I know that's not really helpful, and it sounds like a pain in the ass. But sometimes it's better to start over than patch up what you have.
Re: Help me decide how to program things. (Sprite Metatiles)
by on (#109439)
Celius wrote:
...sometimes it's better to start over than patch up what you have.

Sometimes it's better to get your project done than to worry about how elegant the underlying code is.

The way 3gengames is assigning sprite memory does not sound like how I would approach the task, but if it's not causing him a problem I don't actually think it's worth expending effort to "fix". I don't know what his game looks like, or what its needs are. If the needs are already met, the only reason to rework this code is for the learning experience maybe.
Re: Help me decide how to program things. (Sprite Metatiles)
by on (#109449)
Gonna shower and then post a semi-animation about that I mean to clear it up. And this engine will used in all my games and projects from now on once I finish it, with modification as needed/optimized. I'm not that deep in to it, it's only 170 lines of code. About 50 would need changes to change how it works completely so it's not out of hand yet. :) But yeah, sorry, I'm pretty bad at explaining stuff how other people would need it explained, because in my head it is a lot smoother with the things I want to accomplish with it.
Re: Help me decide how to program things. (Sprite Metatiles)
by on (#109491)
Okay, here it is. Leaving out the other ideas of the engine.

There's two indexes. One that points at the beginning of OAM, one at the last entry of OAM. They converge towards each other, or to the middle of the OAM data. Sprites with lower OAM entries are displayed first. Sprites can be layered. In order to keep priority, everything bust be written from the beginning of a buffer, to the end, weather it be the first index or second. If index 1 is used, it uses the pointer directly, because it is already moving deeper in to OAM. If the second index is being used, it must "reserve" OAM space by subtracting the current positioning with the tiles needed.

Code:
[Entry 00] <-Index one points here.
[Entry 01]
[Entry 02]
[Entry 03]
...
[Entry 3C]
[Entry 3D]
[Entry 3E]
[Entry 3F]
[Entry 40] <Index two points here. Is actually same as first index, because there's only 3F OAM entries.


if index 1 has 4 tiles to put down, it puts them in entry 00 to 03. If index 2, the decreasing index, it has to reserve 4 sprites. It takes the current position, subtracts 4, and then says "Well that's index $3C, so we start there." but lets say only 3 tiles get put on the screen of four because one object moves, to the other side, our OAM will now be:

Code:
[Used Entry 00] ;Tile 1 of 4
[Used Entry 01] ;Tile 2 of 4
[Used Entry 02] ;Tile 3 of 4.
[Entry 03] <Index 1 points here.
...
[Used Entry 3C] <Index 2 points here. 1 of 4
[Used Entry 3D] 2 of 4
[Used Entry 3E] 3 of 4
[Entry 3F] 4 of 4, with Y coord of FF.


If the increasing OAM has only 3 of 4 tiles put down, we can just ignore everything and not put the tile, and upload the new pointer position at the end of OAM updates. But with the decreasing one, we have to point it at the first used position, because otherwise we don't have free OAM spaces. This leaves one unused OAM space.

But if only one tile of an object with 1 tile displayed and 8 tiles total or so gets put in the decreasing OAM, we lose 7 tiles! I just think that that's a ton to lose, and would like to avoid it. So I was just throwing idea out of transferring the entries all down X spaces if this happens, and if it would be worth the CPU time, as I'm predicting this way in general would be pretty high CPU usage, although it would get a "perfect" OAM rotation, too, as long as you use under 65 tiles per frame.

So, is it easier/better engine design to just use a different way of processing objects (Like starting with Object 0, then 8, then 4, then 12, then 1, then 9, then 5, then 13, etc.) instead of doing it like this, where we want to put the tiles in a different index that moves in different directions each frame?

ETA:Maybe it's easier to decompress to a buffer first, and then handle the OAM spot after the decompression instead of at the same time? That way you can keep priority easy and then also shuffle it easily. Only problem is it adds 2x the data movement from RAM, but it could be worth it if it saves tile space every frame.
Re: Help me decide how to program things. (Sprite Metatiles)
by on (#109492)
rainwarrior wrote:
Celius wrote:
...sometimes it's better to start over than patch up what you have.

Sometimes it's better to get your project done than to worry about how elegant the underlying code is.

The way 3gengames is assigning sprite memory does not sound like how I would approach the task, but if it's not causing him a problem I don't actually think it's worth expending effort to "fix". I don't know what his game looks like, or what its needs are. If the needs are already met, the only reason to rework this code is for the learning experience maybe.


True; I've suffered from both sides of the spectrum. When I started out, my code was such sloppy garbage that I had to start over with everything because it got out of hand. But then after that, I went the polar opposite direction and spent so much time planning that I got barely anything done. I kept asking myself how I could make it perfect and presenting myself with "what if" scenarios so much that I could barely make sense of anything.

Much like writing a book, you should have drafts and revisions. And there comes a point where the benefits of perfect code don't make the experience any better for the user. Depends on the situation.

3gengames wrote:
But if only one tile of an object with 1 tile displayed and 8 tiles total or so gets put in the decreasing OAM, we lose 7 tiles!


That is quite a bit. I would focus on finding a way to calculate the amount of tiles needed before getting to the code that writes them. You already have code that handles each tile to not write it if its off screen, right? And the empty tiles will all exist at the end of the reserved segment? If you simply knew how many tiles would be used prior, it would make life a lot easier. The code for getting the count could be a simple loop that calculates tile coordinates and does an INC TileCount if they are on screen. That would be my suggestion.
Re: Help me decide how to program things. (Sprite Metatiles)
by on (#109533)
Well, the metasprite is compressed, so it's not really doable to decide before hand, so I was thinking of having two different engines. Have the engines be used if it's increasing, or decreasing. If decreasing, it'll write to a buffer. If not, it'll write to OAM directly. I think that's the best day to go around it, really...hmm...
Re: Help me decide how to program things. (Sprite Metatiles)
by on (#109703)
I guess that would work. It would likely reduce complexity to just be able to copy it all over in the end, and ultimately save time. I figure a simple loop to copy the data over from the buffer to the sprite page one sprite at a time would take about 40 cycles per iteration. Any other work around would need to perform better than that. Plus, that loop could be pretty small, so it might be worth it to go this route.
Re: Help me decide how to program things. (Sprite Metatiles)
by on (#109704)
Yep, basically I chose to reserve an array of (MaxTilesUsed) for an array. Every time I store a tile, the STA is either STA Buffer,X or STA SpritePage,X. Then store the X index used back until we store the next tile after decode. Then when it's all done, if it's the first index, it's perfect. Nothing needs to be done. But if it's index one, I'm just going to use an X index into buffer loop to write the buffer to Y. With that, writing the sprite data backwards, it'll be written forwards to the sprite page, keeping the sprite tiles index! So I'll program it, and when it's all debugged and 100%, I'll post the source. Odds are this will be less than 256 lines. Probably more if you add more complex "commands" you add to the system, I'm only using 4 of 8 right now. But I'll post back when I get it done, it'll be a while, but it'll be done well.
Re: Help me decide how to program things. (Sprite Metatiles)
by on (#109710)
I was going to create a new thread, but seems best to keep the discussion in a current active thread.

Right now I am working on the same kind of thing, but I would like the meta-sprite engine/code to handle clipping at screen edges so a meta sprite can scroll off screen without wrapping. How do you (plan to) handle that? The best I've come up with is to have a 8th bit for the meta-sprite screen coords. This means for example that I you could imagine the screen is 512 pixels wide which results in 128 'pixels' of off-screen on either side of the actual and then clip (skip copy to OAM) if the tile to be drawn falls in that range.
Re: Help me decide how to program things. (Sprite Metatiles)
by on (#109711)
My idea is to take the coords of the sprite. A sprite without flipping will ALWAYS be on the good side of the screen (0 to FF, no wrapping) but when a sprite is moved in any way, I calculate if it's on or off the screen. First one is the flipping X/Y coord changes, or the base value on/off screen flags. I put those in to a flag that looks like YX00.0000. A 1 in any spot means the result was off the screen. Then I shift right twice so it's 00YX.0000. Every time the X or Y coord switches sides of the screen, the flag gets set. The first two are if it switches sides of the screen in any way at all, not just going off the screen. So the flags then look like YXYX.0000 with the highest being the movement off the base screen and the bold being the "base" on/off the screen values. I will then LDA with that flag byte, shift it left twice so the YX values line up, and then EOR with the sprite flag, and then AND #%11000000. If it's not zero, the sprite isn't displayed because either the X or Y coord are off the screen. If it started off the screen, then came on, it would be 1,1 which then goes to 0 so that's how it works.

At least this is the plan, haven't gotten that far yet, but that's how I fully plan on doing it. :) If it doesn't make sense, I'll explain it again. I explain much better 2nd time around.
Re: Help me decide how to program things. (Sprite Metatiles)
by on (#109855)
I have it finished, I believe. I'll throw together a ROM for others to test as I've not tested it that much, I've been modifying it every compile, with the first compile attempt was at about 300 lines of program...with over 30 errors! Weren't big though, just some typos, and a few because the variables were named different from what I had, only took 5 minutes to fix all 30 errors. And first compile, it actually showed a sprite! One of two, but it showed it! It didn't clear OAM too though, that bug was fixed, along with all others that I know of, and here's the final features:

Flip on X,Y,X+Y, or no axis's.

Not display sprites that travel to the other side of the screen.

Be able to bring in sprites from all sides of the screen, so you can put a sprite at $F8 that's 2 sprites wide, the the F8 sprite will not display, but the 00 one will.

Rotates OAM automatically (Up to 16 sprites on a scanline don't flicker too bad. Any more than that, though, has some processing problems where some just don't get displayed ever. Looking to fix later)

And that's about it. As for the speed, it looks to take about 8.5 scanlines for the Boo sprite. And then about 9.5 for the Megaman. Is this good, bad, ugly for an OAM engine like this?

The ROM below you can run this and move the sprite around the screen. (The screen wraps so you can see it come in from all locations) but there's only 1 object. Move with the D-Pad, B changes the sprite, and select+start both do flips so you can see all combinations at work.

You can add up to 15 more "objects" with FCEUX hex editor to see the OAM flickering. The object memory is 16 bytes per array, with 4 data arrays in $100 to $13F. $100 is the X coord. $110 is the Y coord. $120 is the attributes (X/Y/P bits at YXP0.0000)+enabled flag (0000.000E)+on/off current base screen flag (000Y.X000). (YXPYX00E) The last array at $130 is the object value. Either 0 (Boo) or 1 (Megaman).

Well, finally here's the goods:

ROM:
https://docs.google.com/file/d/0B1laUfq ... sp=sharing

Source:
https://docs.google.com/file/d/0B1laUfq ... sp=sharing

ANY input would be appreciated, good or bad. And if you have any ideas how to do anything better, I'm all ears.
Re: Help me decide how to program things. (Sprite Metatiles)
by on (#109904)
I'll be updating the ROM soon to include a feature to make new objects with the A button so you I can test it on my NES. But I've been thinking how to make it faster...and I think I found a way. What about just straight up decompressing to WRAM at the beginning of a level all metadata needed to WRAM? Think that's a good option? Instead of looking up index of compressed tile in ROM, you could just decompress all the tile and attribute data to WRAM, and then move it with before it's put on the screen. Seems like it'd be worth it with how many cycles it takes for 8 objects, it takes up basically half the screen time.
Re: Help me decide how to program things. (Sprite Metatiles)
by on (#109911)
Movax12 wrote:
Right now I am working on the same kind of thing, but I would like the meta-sprite engine/code to handle clipping at screen edges so a meta sprite can scroll off screen without wrapping. How do you (plan to) handle that? The best I've come up with is to have a 8th bit for the meta-sprite screen coords. This means for example that I you could imagine the screen is 512 pixels wide which results in 128 'pixels' of off-screen on either side of the actual and then clip (skip copy to OAM) if the tile to be drawn falls in that range.


Did you mean a 9th bit?

In my engine, the coordinates of the objects are 16 bits, but also the hardware sprite coordinates are calculated as 16 bit values. If the high byte is anything but 0, do not draw the sprite. So the coordinates would end up as $FFxx if they were off the left edge, and $01xx if they were off the right edge. It might seem slow to deal with 16 bit values for each coordinate, but I've optimized the math to really ignore/discard the high byte of the result. I only have to do like a BCS statement after a certain addition to see if its off screen. This will ensure every part of the metasprite that's on screen is rendered, no wrap around.

Some people take the all or nothing approach where you draw the sprites only if the entire object is on screen. This is an okay solution for small objects, in my opinion, but looks bad for bigger ones.
Re: Help me decide how to program things. (Sprite Metatiles)
by on (#109914)
Try this out. Uses the same metasprite source as above, just implemented a way to check OAM rotation and such.

https://docs.google.com/file/d/0B1laUfq ... sp=sharing

Controls: D-Pad to move, Start+select to flip on axis's, B to swap between megaman and boo sprites. And lastly, hold A and start to create a new object. Hold A and press select to delete the current object and go back 1 more.

This way of doing things also considers the single sprite display window as 1 of 4 nametables, basically like the NES's base nametables. If it goes to any other of the "screens" (Aka outside the current window), those sprites aren't displayed. The high bits for those, though, will be handled by the camera system, not the metatile system. That seem okay?

Are there any obvious features I've missed? Feedback? One thing I'm curious to know from you guys is...how inefficient is it compared to what it could be? :o :|
Re: Help me decide how to program things. (Sprite Metatiles)
by on (#109918)
I think it is not bad performance wise. I'd like to think my code is pretty good, and your seems a touch faster, but I think that is your OAM rotation may be faster and probably mostly that you are using 8x16 sprites.

This seems to help with speed, since megaman is 7 sprites, where in my code it megaman is 10. I might consider switching to 8x16 but it can (and here with megaman, it does) leave holes in the pattern table. As well, your clipping at the top of the screen clips 16 pixels as soon as the top one is out of range, which probably isn't a big deal.

I'm surprised by how much CPU this takes up :(.

Note there is a bug in my code where megaman does not flip properly, still a wip. This comparison is based on the first code posted by 3gengames, I didn't try the latest. As well if you run these in NintendulatorDX it will show you cycles used.
Re: Help me decide how to program things. (Sprite Metatiles)
by on (#109921)
Celius wrote:
Did you mean a 9th bit?



Yes. Thinking bits 0 to 7 and then 8th. 8th bit for x, y coord is stored in metasprite object attribute byte.
Re: Help me decide how to program things. (Sprite Metatiles)
by on (#109922)
Okay, sweet. Thanks for the comparison, ours both seem pretty good. I may optimize it by putting a lot of the variable in to ZP, as right now only a total of 4 variables are in zeropage, and one if used for the "metatile file" pointer (LDA [ZP],Y) and the other is just a jumper, for a JMP [Indirect]. I believe I can get a decently big performance helping (Guessing about 5-10%? Maybe more?) if I unload just 8 or so to ZP. It seems worth it to me, so I'll probably do that. But ours are pretty close! Interesting to see, any chance of you posting your code? And my metatile rotation is as described above, the decreasing buffer just gets shoved to VRAM from a buffer, while increasing gets just put straight to OAM.

Also, if my objects go over the tile limit of the PPU, the object which got shafted on the sprites for that frame will for 100% certain have all tiles in OAM the following frame. Not a big deal, but it does it. Mixing those with OAM rotation and all that crap don't garuntee it will be displayed, however. But, up to 16 tiles per scanline work well, so I'll just have to live with telling everyone not to abuse the 8 sprites/scanline very much, to keep it in the limit.

Are you going to release your source? I won't use it, just wanting to see how you go about things instead. :)

ETA: Also, yeah mine clips the top 16 pixels. I just tested it on my TV and only the top 3 or so pixels were shown at all. On an HDTV it'll be worse, but there's not much I can do about it. Also, I'm going to change it to at compile time. You will select which type of sprites you use, either 8x8 or 8x16 and it'll either INC 1 or 2 tiles, it'll depend on the flag. Source doesn't do that yet, and don't consider it useable by any means. For all I know it could have a "seecret" game breaking feature, so I wouldn't recommend using it. But I could add it to read PPUCtrlRAM byte to dynamically do sprite Y sizes, but I don't think any project will switch back and forth, so I'll probably keep it the way it is right now. And I also tested mine on my NROM-256 test cart today, it worked just fine. Exactly like in FCEUX, so that's always a plus. :P
Re: Help me decide how to program things. (Sprite Metatiles)
by on (#109923)
3gengames wrote:
Are there any obvious features I've missed? Feedback? One thing I'm curious to know from you guys is...how inefficient is it compared to what it could be? :o :|

I doubt that many people have timed their own routines. :) Would be interesting to see a comparison of different people's routines' performance for rendering the same meta sprite. Comparing is hard though because of different feature sets (performance depends on stuff like clipping, sprite cycling method, etc).

Movax12 wrote:
I'm surprised by how much CPU this takes up :(.

In my game sprite rendering was the single most CPU intensive task. Can't remember what it was percentage wise, but it was my go-to routine to optimize when I wanted to get rid of some lag frames (and it worked).
Re: Help me decide how to program things. (Sprite Metatiles)
by on (#109926)
I shoved 6 byte to zeropage, the performance improved a little, but not very much on a per-sprite basis, despite most of the code now being zero page instead of normal RAM. Pretty much only the tile buffers, OAM writes, and a few index retrieves/uses/stores are the only thing not in zero page, so there's not much more to be done really.

ETA: Did the font on the forum get smaller?
Re: Help me decide how to program things. (Sprite Metatiles)
by on (#109927)
3gengames wrote:
ETA: Did the font on the forum get smaller?

Not for me. Did you try Ctrl+Zero?
Re: Help me decide how to program things. (Sprite Metatiles)
by on (#109972)
thefox wrote:
Movax12 wrote:
I'm surprised by how much CPU this takes up :(.

In my game sprite rendering was the single most CPU intensive task. Can't remember what it was percentage wise, but it was my go-to routine to optimize when I wanted to get rid of some lag frames (and it worked).


Pretty sure it was for me too, but the on-the-fly map decompression routine is another contender. I'd have to go home and count cycles to see how long it takes.
Re: help decide how to program things: Sprite Metatiles|Upda
by on (#109973)
Some source here: http://mynesdev.blogspot.ca/2013/03/met ... -code.html

Just the one file, I have a lot going on in the background, I'm not going to post everything. That is still in a testing state and I'm going to implement it as an easy to interface to unit/library.
Current status is much improved, still debating 8x8 or 8x16 sprites, but I can process 40 sprites (4 megamans) in ~6600 cycles. Seems not too bad.

It can do everything a normal sprite can do with optional clipping/wrapping. Megaman's metasprite only takes up 13 bytes too!

The metaspite format I tried to keep as low level and similar to the hardware. I want to think of this as a driver. Objects are a higher level, and there is not a proper definition of height/width, I'm going to have to handle that in the object level.

Ideas from many people implemented, thanks for sharing. 3gengames , tokumaru, Celius, Bregalad are obvious names that somehow helped by posting their ideas. #nesdev is a help too.
Re: Help me decide how to program things. (Sprite Metatiles)
by on (#109976)
Celius wrote:
the on-the-fly map decompression routine is another contender.

I have to agree with this. Decompressing the map into metatiles, the metatiles into tiles, and then all the attribute work... all of that adds up to a lot of cycles.
Re: help decide how to program things: Sprite Metatiles|Upda
by on (#110213)
So I am still playing around with this. Speed is a priority for me: I think this is an idea worth pursuing though it means more code (ROM). I decided to try a method of checking quickly if the sprite is entirely offscreen or onscreen to save cycles. It seems to work well. I also implemented flipping inside the metatile engine, since I need to have width and height information. This thing will clip at y > 238 as well.

Press start to switch control to another megaman. If you move them all offscreen, onscreen or to the screen edges you can see the change in processing time. There is one small bug that is a bit tricky to fix. Source posting here.
Re: help decide how to program things: Sprite Metatiles|Upda
by on (#110214)
Ah, so basically do a first compare to check if the X location+Width && Y location+Height is still on the screen, and then if so just decode the whole thing straight to save time? I'll probably go back and add that, I can add spare code, too. I mean, the routine is only...0x240 bytes, about...0x300 or so isn't too bad at all. Good idea!