I'm having some trouble with DrawMap_GetTileA (and SetTile, for that matter...). Let's say I have:
DrawMap_GetTileA(I,J,W,1,0,0
I have I and J controlled by the arrow keys. W is 20. length(Str1 is 320 (20x8). The map looks like, for example (1 number per tile):

Code:

I would expect, when I,J is (0,0) for this to return 1, which it does. However, it's also returning 1 when I,J is (1,1). In fact, it returns 1 as long as I<8. Once I>=8 it returns 0 for all J values.

What am I doing wrong?

For set tile, I did the same sort of thing, but before each GetTile call I did:
DrawMap_SetTile(I,J,W,1,2,0,0

When I do this, the GetTile command returns 2, like I'd expect, but it only sets the tile when I=0, and that's the only time GetTile returns the right thing

The getTile function takes PIXEL coordinates, I stuffed up the documentation. Apologies for any inconvenience!

Please retest with pixel coords (or tilecoord* and let me know if its working.

Aha, this works! Thanks so much!

Cool, did you get any speed increase using this method? (Were you using substring stuff earlier?).

Yeah, it seems a little faster this way, which is good. I need to cut out a lot of other code, too. I think if I divide it into more suprograms it'd run faster, but then that's more programs

Feature requests:
- DrawMap with transparency
- Custom fonts (including smaller-than-8x8?)
- 16x16 map and sprites mode

Additionally, does GetKeyArrowsCheckTile report what tile you collided with anywhere? If not, it would be useful if this was stored in Ans or something. Also which key was pressed?

I had asked if any info should be passed back from that function but there were some advantages/disadvantages.

I think at the moment it does place a value from 0-3 in Ans that corresponds to up/down/left/right ... ill have to double check.

The font issue is something that i will definitely be looking into.

Okay, awesome. If it doesn't do that, I think it definitely should--I need to know which direction is pressed in order to face the right direction Additionally, what if other keys are pressed? For example, in BlockDude, you can use F4 and F5 to change direction without moving; can I still detect those key presses? As well as 2nd for lifting the block?

Cool. I think it'd be really neat to have our own fonts, and be able to define the size.

What about the other two things?
- DrawMap with transparency - Allows for layers
- 16x16 map and sprites mode - Allows for bigger sprites/maps more easily. I fake this in DinoPuzz, but it'd be easier and faster if it were built right in.

It will depend on how much code space there is left in the APP. Im not so sure about the 16x16 mode, that one might come later rather than sooner. The transparency idea sounds promising though.

I think that's fine in terms of prioritization. The 16x16 mode is a lot easier to fake if you just think through it. Faking a transparent DrawMap would require drawing each thing in e.g. the upper layer as a sprite, which would be bad.

Transparency would be cool. Some Doors CSE's ASM sprite routines use a special color for transparency that seems to work out pretty well. Also, amount of code space left (before I fix bugs like the Celtic ReplaceLine issue Shaun discovered):

Code:

The sprites themselves already do transparency, it's just the DrawMap method doesn't support it.

Ah, got it, that makes sense. I guess it's possible you might be drawing a tilemap over a background of some sort? To be honest, I'm having trouble envisioning the use case for a tilemap with transparency, except maybe Mario over a parallax-scrolling background or something.

Three big things:

- Layers: You can have a bottom-layer tile map (stuff the player walks over, like the ground) and a top-layer tile map (stuff like tree-tops that the player would go behind). This can give you map a feeling of depth. (Think Zelda, where you can walk under the trees and your character is obscured).

- UI: Similar to layers, you could have your UI such as a HUD or item list be a tilemap, which would render faster than drawing all the sprites on your own.

- Using the same sprites on different-colored background or different base-tiles: Let's say you have a tree sprite that looks good on your grass tile and your swamp tile (or a green background and a brown background), you could just render the base tiles and then the tree tiles (or just clear the screen one color and then render all the tree tiles) without having to have a different tree tile for each environment.

Transparency can be added very easily to the map drawing routines, its only a minor tweak. My issue is frequency of use? Drawing tilemaps each frame is not efficient on the 84C so having layers wouldnt be the best solution from a performance perspective when referring to drawing layers over sprites etc.

It would still be beneficial for the second two.

Any updates on any of the questions/suggestions here?

Well i think ill add the transparency for tilemaps as it could be useful for some stuff. Should i either:

a) add an extra argument to existing map functions
b) create extra functions for transparency in maps

I think if you can keep it backwards compat and add in trans it'd be fine. Make it an optional last param or something like that. Additionally, any thoughts/progress on the other things?

Im not sure about fonts and 16x16 sprites/tiles, but i cant definitely do the return collided tile.