AxTile.uvOffset + AxTile.uvBounds for Tile scroll animation

Discuss suggestions to improve the Axel library.

Re: AxTile.uvOffset + AxTile.uvBounds for Tile scroll animat

Postby chamberlainpi » Thu May 03, 2012 7:31 pm

Haha, just when I thought I was ready to implement this into Axel, a number of problems came up. Well, challenges I should call'em, not problems!

So for developers who are dealing with larger texture files that would contain tile IDs way above 128, I need to deal with reducing the number of constants down to the bare minimum necessary. In other words, I need to "default" the static (non-scrolling) tiles to be associated with one common pair of vertex-constants (4 & 5, perhaps), and only make the necessary vertex-constants associations after those first two constants (6 & up...) with the tile-types that requires scrolling. I had the wrong approach of associating ALL tile-types to their own pair of Vertex-Constants, which doesn't take too long to eat up all the Vertex-Constants resources!

The next problem / challenge, is that if certain tiles are to default to a common pair of vertex-constants, where vc5 would be their shared Start X, Start Y, Width and Height... that would be incorrect! It would need to refer to its original UV mapping rather than looking it up in the constants. How though? ... perhaps with the conditional opcodes I could pull something off... OR.... just revert back to rendering the original "AxTilemap" way.

So, I think the solution is to build two separate sets of vertex-data: One for static tiles, and another for scrolling tiles.

The render phases could be setup in such a way that one indexbuffer passes for the static tiles, then a different indexbuffer passes for the scrolling tiles. The vertex-data would just have to be stored in that specific order, so that it isn't disorganized like:
- static tile, static tile, SCROLLING tile, static tile, SCROLLING tile;

but rather all grouped consecutively by type:
- static tile, static tile, static tile, SCROLLING tile, SCROLLING tile;

There could even be detection, whenever the tilemap changes position on screen, to toggle on/off the scrolling shader. If no scrolling tiles occupy the screen area, don't bother changing program / vertex-buffers / index-buffer, there's just no need for it.

Anyways, I'm sure I'll figure this out with a bit more time. I'm happy at least I got this far!

Minimizing draw-counts is almost a full-time job of its own!
chamberlainpi
Master Sergeant
 
Posts: 32
Joined: Thu Apr 05, 2012 8:51 am
Location: Fredericton, NB

Previous

Return to Suggestions

Who is online

Users browsing this forum: No registered users and 1 guest

cron