Login [Register]
Don't have an account? Register now to chat, post, use our tools, and much more.
The keys+checktile command currently returns what arrow is pressed to Ans. I suppose i could include a variant that shows what tile has been collided with? What would be the best case where there are actually 2 tiles that have been collided with? Im not sure a list in Ans is a great idea.
Under what scenarios are there two tiles being collided with?
Well sprite coordinates are not limited to 8x8 chunks, so if you are at say 4,4 for example you are overlapping 4 different tiles.

When walking you can collide with 2 tiles next to each other.
Ah, right, I see. Hmm. What's so wrong with a list in Ans? Just make it always a list.
Eightx84 wrote:
Is gCn an option?


calcNet 2.2 (or greater) may be implemented into the *next* version of DCSE, but I believe we are only working on getting a super stable starter shell out right now.
tr1p1ea wrote:
The image format is:

[32bytes palette data (made up out of xLIBC colours so 1-byte per colour]
[12000bytes 160x120 pixels data where each byte is a palette index 0-31]

Note that the images are stored by 'column' from top down ... and to make things interesting each index is 5-bits and they are packed into each byte. So the first 8-pixels will look like this:

00000111 11222223 33334444 45555566 66677777

Hence 12000 = 160x120x5/8

Hopefully this makes sense?
What happens when there are fewer than 32 colors?
If its fewer than 32 just pad the palette with any value to ensure that it is 32 bytes long.
Alright cool, that's what I did ��
Support for diagonal arrow key presses is something I'm sure BASIC programmers would enjoy.
Good idea, xLIBC's getkey has support for it, but it would be nice to be able to toggle the TIOS if need be.
It'd be cool if there were an "arbitrary sized sprite" function or something. This would be similar to have Celtic handles sprites, but it could be AppVar based instead. An appvar contains just the sprite data for one sprite, and I can draw that to the screen.
merthsoft wrote:
It'd be cool if there were an "arbitrary sized sprite" function or something. This would be similar to have Celtic handles sprites, but it could be AppVar based instead. An appvar contains just the sprite data for one sprite, and I can draw that to the screen.


This sounds like a great idea! Why not be able to store multiple sprites into an AppVar as well? Maybe add an option to select the sprite based on the number sent to the routine?
MateoConLechuga wrote:
merthsoft wrote:
It'd be cool if there were an "arbitrary sized sprite" function or something. This would be similar to have Celtic handles sprites, but it could be AppVar based instead. An appvar contains just the sprite data for one sprite, and I can draw that to the screen.


This sounds like a great idea! Why not be able to store multiple sprites into an AppVar as well? Maybe add an option to select the sprite based on the number sent to the routine?
That's what it already does, but it uses a specific format. If you just want 1 or 2 big sprites, it'd be nice to just have a couple appvars for that.
Well there is the 'LOADSINGLETILE' function that takes a hex string for an 8x8 sprite and writes it to a tile in mem ... no appvars needed at all if you wanted to include the sprite data in the program itself. It would just require you to write to multiple tiles to build a larger sprite i suppose.

Also i have decided to add a getkey function that can return a real list in Ans with various information. Some people expressed interest in having collided tiles in this list, the only issue i have is that this number could be large. It can be up to 4 tiles for an 8x8 sprite, but for a 16x16 sprite it could be 9 tiles and even worse for a 32 sprite (25 tiles!).

Ideas?
I think that's good. Even if the list is huge, dealing with lists is pretty quick. For example, you might need to know if one of the tiles is 34 or something, and you can just do cumSum(34=Ans, which is quick. If you have to do something specific with each collided tile it might take a while, but I think it's better to have that than not have access at all, in which case the user has to manually query the map.
Ok well i guess i can just dump all collided tiles to a list, now to mod the routines!

HHmm.. the only other problem is that the collided tiles werent the only pieces of data that i was going to store. I was thinking:

{KEY, MAPX(WINDOW), MAPY(WINDOW), MAPX(SCROLL), MAPY(SCROLL), COLLIDED_TILE_LIST...}

KEY = value corresponding to UP/DOWN/LEFT/RIGHT
MAPX(WINDOW) = appropriate MAPX if you want to scroll map by screens
MAPY(WINDOW) = same as above but for MAPY
MAPX(SCROLL) = appropriate MAPX if you want to scroll by tile
COLLIDED_TILE_LIST = list of collided tiles
Can you put the first four at the end of the list instead? Then you can just like
Ans->L1
dim(L1)-4->dim(L1
To chop off those pieces.
I guess it comes down to frequency of use ... is searching for a certain tile used more often than using a key for sprite direction etc?

I can separate out the functions but that might make it even more confusing?
I think it's probably best to return the static things as Ans, and then have a separate call to get the last collided tiles. The overhead of an additional call is worth saving on the confusion, I think.
Working on a function to enable checking of sprite collisions (or any rectangular coordinates).

This means that you can do:

real(4,6,LISTCOUNT,X0,Y0,W0,H0, X1,Y1,W1,H1...XnYnWnHn

And it will test X0,Y0,W0,H0 against the other sets of box coordinates and return a Real List in Ans containing:

{COLLISION (0 or 1), NUMBER OF COLLIDED COORDINATES, INDEX OF COLLIDED COORDINATES IN LIST (in original real( call)}

The coordinates are pretty much rectangles with a X,Y,WIDHT,HEIGHT eg:

real(4,6,2,10,10,10,10,15,15,10,10,25,25,10,10

will return:

{1,1,0

{1 = 1 to say a collison was found
{1 = only 1 of the coordinates passed collided
{0 = the first set of coordinates collided (note that 0 = first set to test against)

real(4,6,3,10,10,10,10,25,25,10,10,18,18,10,10,15,15,10,10

will return:

{1,2,1,2

{1 = 1 to say a collison was found
{2 = 2 of the coordinates passed collided
{1 = the 2nd set of coordinates collided
{2 = the 3rd set of coordinates collided

If there is no collision the result is:

{0,0

Thoughts?
  
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
» Goto page Previous  1, 2, 3 ... , 16, 17, 18  Next
» View previous topic :: View next topic  
Page 17 of 18
» 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