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:
10000000000000000001
10000000000000000001
10000000000000000001
10000000000000000001
10000000000000000001
10000000000000000001
10000000000000000001
10000000000000000001

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? Sad

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 Sad
The getTile function takes PIXEL coordinates, I stuffed up the documentation. Apologies for any inconvenience!

Please retest with pixel coords (or tilecoord*Cool 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 Sad
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.
tr1p1ea wrote:
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.
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 Smile 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?

Quote:
The font issue is something that i will definitely be looking into.
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.
tr1p1ea wrote:
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.
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:
Page 0 is 15879 bytes long (505 bytes to spare)
Page 1 is 13247 bytes long (3137 bytes to spare)
The sprites themselves already do transparency, it's just the DrawMap method doesn't support it.
merthsoft wrote:
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?

merthsoft wrote:
Feature requests:
- Custom fonts (including smaller-than-8x8?)
- 16x16 map and sprites mode [you said it might be a buit on this].

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?
Im not sure about fonts and 16x16 sprites/tiles, but i cant definitely do the return collided tile.
  
Register to Join the Conversation
Have your own thoughts to add to this or any other topic? Want to ask a question, offer a suggestion, share your own programs and projects, upload a file to the file archives, get help with calculator and computer programming, or simply chat with like-minded coders and tech and calculator enthusiasts via the site-wide AJAX SAX widget? Registration for a free Cemetech account only takes a minute.

» Go to Registration page
Page 4 of 8
» All times are GMT - 5 Hours
 
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

 

Advertisement