I assume the speed issue is the result of repeatedly allocating and freeing the memory for Ans?
That appears to be the case.
Question: Does the new xLIBC version work with very large string files? (such as 60 KB large)

Also, is there a command to store a string to Str0-Str9 without copying it to Ans first? For example, something like real(6,3,"HELLO WORLD, MY NAME IS "+Sub("JAMESDAVIDMATT JOEY ",L1(25)*5+1,5)+"!",6) that would store to Str6 and work with strings of any size (or at least up to 8 KB or so).

The current issue is that when we need to copy a map to a string for use with the DrawMap command, it takes a crapload of RAM (enough RAM for the program containing the string data, plus twice or three times the RAM required to store the string).
tifreak8x wrote:
Thanks a ton good sir Smile

I'll have to set up a screenshot or two up, to show off how things look in LibHelper so you can see what all I've done with the data you've put in the wiki Smile




That shows off your table of getkey values. I sadly don't have more of the xlib stuff yet, I might post more if you're interested in seeing them Smile
DJ: The problem is that the argument buffer is just that, a buffer; so it has a size limitation. This would mean that such a function would not be plausible.

Nice tifreak!

tifreak here is some information on the updated/added functions:


Code:
SETUPCOLOURMODE: (TIOS VALUES):
-------------------------------
real(0,3,VALUE
VALUE defines action to take:
0 = FULL colour
1 = 8COLOUR
2 = COLOURINVERT
3 = COLOURINVERTOFF (restore to normal)
4 = FILLSCREEN
5 = SETCOLOUROFFSET (DCSE8.1)

To invert the colours on the screen you would do:

real(0,3,2

To restore the colours back to normal you can do:

real(0,3,2

This is because inverting something twice will restore it back to nomral.

To restore the colours back to normal when you dont know the previous state of the screen:

real(0,3,3

To FILL the screen (active GRAM side only) with a colour from the standard xLIB 256 colour palette:

real(0,3,4,COLOUR,UPDATELCD

To set the COLOUR_OFFSET value which is used by sprite and shape routines (note that VALUE is between 0-255)
This will change the colour values per pixel of sprites as they are drawn to the LCD. It can be used for
special effects (magic animations for example):

real(0,3,5,VALUE

=================================================================================================================

GETKEY UP/DOWN/LEFT/RIGHT CHECKTILE LIST (DCSE8.1):
---------------------------------------------------
real(2,5,USERVAR_X,USERVAR_Y,VALUE_X,VALUE_Y,USERVAR_MAPWIDTH,COLLISIONTILE,MAPSTRING,X0,Y0,X1,Y1
USERVAR_MAPWIDTH = width of tilemap in tiles (uservar 0-255)
COLLISIONTILE = upper limit of walkable tiles (any tile less than this will be walkable)
MAPSTRING = string variable holding tilemap data (0-10)
X0 = left x coordinate of collision box
Y0 = top y coordinate of collision box
X1 = right x coordinate of collision box
Y1 = bottom y coordinate of collision box

This function is the same as the above however it will return information regarding any keypresses and
any collided tiles in a 'real list' contained in with the format:

{KEY_PRESS, NUM_COLLIDED_TILES, COLLIDED_TILES_LIST} where:

KEY_PRESS = -1,0,1,2,3 = NOARROW,UP,DOWN,LEFT,RIGHT
NUM_COLLIDED_TILES = number of tiles collided against given the arguments in the call
COLLIDED_TILES_LIST = list of tiles collided against given the arguments in the call


GETKEY UP/DOWN/LEFT/RIGHT/DIAGONAL CHECKTILE LIST (DCSE8.1):
------------------------------------------------------------
real(2,6,USERVAR_X,USERVAR_Y,VALUE_X,VALUE_Y,USERVAR_MAPWIDTH,COLLISIONTILE,MAPSTRING,X0,Y0,X1,Y1
refer to the above function, adds diagonal keypresses as well

=================================================================================================================

DRAWSPRITECHECKCOLLISIONA (TIOS VALUES, DCSE8.1):
-------------------------------------------------
real(4,6,COUNT,X,Y,W,H,CX0,CY0,CW0,CH0....CXn,CYn,CWn,CHn
COUNT = number of coordinates to check against
X = master X to test list of coordinates against
Y = master Y to test list of coordinates against
W = master W to test list of coordinates against
H = master H to test list of coordinates against
CX0 = first X to test against master X
CY0 = first Y to test against master Y
CW0 = first W to test against master W
CH0 = first H to test against master H
CXn = nth X to test against master X
CYn = nth Y to test against master Y
CWn = nth W to test against master W
CHn = nth H to test against master H

nth should be equal to COUNT

This function will test the rectangular coordinates specified by the 'master X,Y,W,H' against each iteration of rectangular
coordinates from CX0,CY0,CW0,CH0 to CXn,CYn,CWn,CHn and will return

0 or 1 in Ans where 0 = no collision between the 'master set' and the list and 1 = a collision with at least 1 set is found
A list of collided coordinate indexes in the user-defined 'real list' "XL" in the format:

{TOTAL_COORDS_COLLIDED,INDEX0...INDEXn} Where:
TOTAL_COORDS_COLLIDED = total number of rectangular indexes in the call that collide with the 'master set'
INDEX0 = first index where 0 = the rectangular coordinates [CX0,CY0,CW0,CH0] and n would equal the [CX0,CY0,CW0,CH0]

Note that user-define list "XL" is overwritten if it already exists

For example

Rectangles at:

X = 10
Y = 10
W = 8
H = 8

Tested against others where:

X = 15
Y = 15
W = 8
H = 8

X = 48
Y = 32
W = 16
H = 16

X = 8
Y = 0
W = 64
H = 16

Like so:
 

The call would be: real(4,6,3,10,10,8,8,15,15,8,8,48,32,16,16,8,0,64,16

And the result would be:
Ans = 1
XL = {1,2,0,2


Ans=1 = collision found
{1 = collision found (would be 0 if no collisions occured)
2 = number of collisions found
0 = collision with index 0
2 = collision with index 2

Index 1 is the square for which there was no collision.

You can check if there is a collision by using:

If Ans
If LXL(1)

Or by a similar method.


DRAWSPRITECHECKCOLLISIONB (USERVAR VALUES, DCSE8.1):
----------------------------------------------------
real(4,7,COUNT,X,Y,W,H,CX0,CY0,CW0,CH0....CXn,CYn,CWn,CHn
COUNT = number of coordinates to check against
X = master X to test list of coordinates against (uservar)
Y = master Y to test list of coordinates against (uservar)
W = master W to test list of coordinates against (uservar)
H = master H to test list of coordinates against (uservar)
CX0 = first X to test against master X (uservar)
CY0 = first Y to test against master Y (uservar)
CW0 = first W to test against master W (uservar)
CH0 = first H to test against master H (uservar)
CXn = nth X to test against master X (uservar)
CYn = nth Y to test against master Y (uservar)
CWn = nth W to test against master W (uservar)
CHn = nth H to test against master H (uservar)

This function is the same as above however it takes references to USERVAR values as opposed to values directly.


DRAWSPRITESEQUENTIALLISTA (TIOS VALUES, DCSE8.1):
-------------------------------------------------
real(4,8,X,Y,WIDTH,HEIGHT,XOFFSET,YOFFSET,TRANSINDEX,UPDATELCD,PICINDEXSTART,PICINDEX0
X = x value
Y = y value
WIDTH = width of sprite in 8x8 chunks (an 8x8 sprite is 1, 16x16 is 2, 12x12 is also 2 etc)
HEIGHT = height of sprite in 8x8 chunks (an 8x8 sprite is 1, 16x16 is 2, 12x12 is also 2 etc)
XOFFSET = offset for x value
YOFFSET = offset for y value
TRANSINDEX = transparent colour index, and colour in the sprite that matches this will be drawn transparent (0-255)
UPDATELCD = 0/1 to update LCD after drawing
PICINDEXSTART = pic index to start drawing from (in following list)
PICINDEX0 = pic index in sprite data sheet

This function will draw a sprite that of any size as per the same fashion as DRAWSPRITEA with the only difference
being that you DONT need to specify each PICINDEX for a largesprite, rather you only need to specify the FIRST PICINDEX.
This means that your 8x8 sprite chunks will need to follow each other in your TILEPIC in SEQUENTIAL ORDER. The makeup of
a large sprite is the same:

16x16 sprite list layout:

---------
| 1 | 3 |
---------
| 2 | 4 |
---------

24x24 sprite list layout:

-------------
| 1 | 4 | 7 |
-------------
| 2 | 5 | 8 |
-------------
| 3 | 6 | 9 |
-------------

For both of the above you only need to specifiy the PICINDEX '1' (along with appropriate WIDTH/HEIGHT ETC) to draw.

The advantage is that you save space in BASIC code, speed of execution and you can maximise the space in your TILEPICS.
The drawback is that the layout of sprites requires more work when creating your TILEPICS.

You can use the PICINDEXSTART argument to have largesprite 'frames' as each PICINDEX you supply will be the STARTING INDEX
for each frame so having:

real(4,8,10,10,2,2,0,0,248,1,0,10,20

Will draw a 16x16 sprite with the 4 '8x8 chunks' starting at INDEX 10 (10,11,12,13). If you change the PICINDEXSTART
argument to 1 then the 16x16 sprite will be made up of the 4 '8x8 chunks' starting at INDEX 20 (20,21,22,23).


DRAWSPRITESEQUENTIALLISTB (USERVAR VALUES, DCSE8.1):
----------------------------------------------------
real(4,9,USERVAR_X,USERVAR_Y,WIDTH,HEIGHT,XOFFSET,YOFFSET,TRANSINDEX,UPDATELCD,PICINDEXSTART,PICINDEX0
X = x value (uservar 0-255)
Y = y value (uservar 0-255)
WIDTH = width of sprite in 8x8 chunks (an 8x8 sprite is 1, 16x16 is 2, 12x12 is also 2 etc)
HEIGHT = height of sprite in 8x8 chunks (an 8x8 sprite is 1, 16x16 is 2, 12x12 is also 2 etc)
XOFFSET = offset for x value
YOFFSET = offset for y value
TRANSINDEX = transparent colour index, and colour in the sprite that matches this will be drawn transparent (0-255)
UPDATELCD = 0/1 to update LCD after drawing
PICINDEXSTART = pic index to start drawing from (in following list)
PICINDEX0 = pic index in sprite data sheet

This function is the same as above however it takes references to internal USERVARS as opposed to values directly


DRAWSPRITETILEBGLISTA (TIOS VALUES, DCSE8.1):
---------------------------------------------
real(4,10,LISTCOUNT,LISTWIDTH,HEIGHT,XOFFSET,YOFFSET,TRANSINDEX,UPDATELCD,MAPWIDTH,MAPSTRING,X0,Y0...Xn,Yn
LISTCOUNT = number of tiles in list
WIDTH = width of sprite in 8x8 chunks (an 8x8 sprite is 1, 16x16 is 2, 12x12 is also 2 etc)
HEIGHT = height of sprite in 8x8 chunks (an 8x8 sprite is 1, 16x16 is 2, 12x12 is also 2 etc)
XOFFSET = offset for x value
YOFFSET = offset for y value
TRANSINDEX = transparent colour index, and colour in the sprite that matches this will be drawn transparent (0-255)
UPDATELCD = 0/1 to update LCD after drawing
MAPWIDTH = width of tilemap
MAPSTRING = string variable holding tilemap data (0-10)
X0 = first X value to draw tile at
Y0 = first Y value to draw tile at
Xn = last X value to draw tile at
Yn = last Y value to draw tile at

This function will draw the tiles for width*height at the sprite coordinate listed from X0,Y0 to Xn,Yn. The resultant tiles
will be aligned to the map (it will only draw at intevals of 8-pixels). This is useful for restoring a tilemap background
that has been overwritten by a list of sprites. As mentioned this function is the same as DRAWSPRITETILEBG just with a list.


DRAWSPRITETILEBGLISTB (USERVARS VALUES, DCSE8.1):
-------------------------------------------------
real(4,10,LISTCOUNT,LISTWIDTH,HEIGHT,XOFFSET,YOFFSET,TRANSINDEX,UPDATELCD,MAPWIDTH,MAPSTRING,X0,Y0...Xn,Yn
LISTCOUNT = number of tiles in list
WIDTH = width of sprite in 8x8 chunks (an 8x8 sprite is 1, 16x16 is 2, 12x12 is also 2 etc)
HEIGHT = height of sprite in 8x8 chunks (an 8x8 sprite is 1, 16x16 is 2, 12x12 is also 2 etc)
XOFFSET = offset for x value
YOFFSET = offset for y value
TRANSINDEX = transparent colour index, and colour in the sprite that matches this will be drawn transparent (0-255)
UPDATELCD = 0/1 to update LCD after drawing
MAPWIDTH = width of tilemap (uservar 0-255)
MAPSTRING = string variable holding tilemap data (0-10)
X0 = first X value to draw tile at (uservar 0-255)
Y0 = first Y value to draw tile at (uservar 0-255)
Xn = last X value to draw tile at (uservar 0-255)
Yn = last Y value to draw tile at (uservar 0-255)

This function is the same as above how it takes references to internal USERVARS as opposed to direct values in the call

=================================================================================================================

DISPLAYBGPIC32 (TIOS VALUES, DCSE8.1):
--------------------------------------
:"APPVARNAME
real(5,6,UPDATELCD
UPDATELCD = 0/1 to update LCD after drawing

This function will display a custom 32 colour 160x120 image (scaled to fullscreen) appvar (name stored as a string in ANS).

To display a bgpic named "BGTEST":
:"BG32TEST
:real(5,6,1

=================================================================================================================

FILLRORTATECOLOURSRECTANGLE (TIOS VALUES, DCSE8.1):
---------------------------------------------------
real(7,13,X0,Y0,WIDTH,HEIGHT,UPDATELCD
X0 = left x value
Y0 = top y value
WIDTH = width of rectangle
HEIGHT = height of rectangle
UPDATELCD = 0/1 to update LCD after drawing

This function draws a filled rectangle starting at X0,Y0 for WIDTH,HEIGHT. Any pixles that it overlaps
will be rotated according to the value of COLOUR_OFFSET (see SETUPCOLORMODE in the SETUP section)


Thsi has also been placed on the Wiki.
Alright, thanks! I'll see about updating LibHelper, and getting it caught up Smile
I have updated the DCS wiki as well, any new functions have DCSE8.1 beside them.
I saw, that's what I'm using to update as it's slightly easier to read there. I'm up to GetKey completed, working in order of real( values, seems to make the work a little easier.

http://dcs.cemetech.net/index.php/DCSE:BasicLibs:ManagePic Could you clarify on this?

more specifically:

To display a bgpic named "BGTEST":
"BG32TEST
real(5,6,1

Should the string not be BGTEST? Or am I missing something?
Yeah you are correct, the string needs to match the appvar ... so much for copy+paste Smile.

This has been rectified, thanks for pointing it out Smile.
No problem! Thanks for clearing it up!

All I have left to add to LibHelper is the wall of text for DrawSprite :p I am in the first section, at the examples. I have all the other sections completed and added to Libhelper, just need to finish the rest of DrawSprite.
tr1p1ea, you have two real(4,10,...s there. Looking at the code, it seems like the second one should be real(4,11. Is that accurate?
Nice pickup, yes that should be 11!
tr1p1ea wrote:
Nice pickup, yes that should be 11!
Excellent, glad I was right about that. I'm fixing up the Doors CSE SDK for the new libraries in Doors CSE 8.1, so I was going through the data you gave to tifreak and wanted to make sure I didn't have any errors. Smile
*bump* Is there an accepted way of displaying multiple background images packed together in a single AppVar? This is for an educational program that I'm writing, and for five different backgrounds, I'd rather not provide five different AppVars. Thanks in advance! For bonus points, I'd like to also be able to pack some strings at the beginning of the AppVar, before the image data.
Nice idea Kerm, you will need to copy the data to page $84 (MemB) for xLIB to use it. There are no other requirements for the routines.

Oh it should be noted that there is a routine that can write a tile to graphics mem from a string? http://dcs.cemetech.net/index.php/DCSE:BasicLibs:ManagePic#LoadSingleTile.28TI-OS_Values.29

Though the tiledata will be twice the size.


EDIT - I added support to extract a 'frame' out of an appvar so that you can pack data together. Its only a concept at this point and as such will only work with frames of the same type (bgpic, bgpic32).


5 frames in 1 appvar (bgpic32 so its 60160 bytes)

This will help reduce the number of appvars needed in a project.

I guess it would be nice to be able to pack tiledata and a background image in 1 file? I could modify it so that you can specify an offset as opposed to a frame number (of fixed size).
oh that's nice. Very Happy What would be cool too is if we could do that with sprite sheets too. Reuben 1 and 2 have like 7 tile sheets.
Bug report: I think that DrawSpriteSequentialListA (real(4,8,...)) does not properly obey the transparent color index argument. I tried using a pink background, index 248, and while real(4,0,...) properly made it transparent, DrawSpriteSequentialListA did not.
Thanks Kerm, I think i have located the issue and will be testing shortly.
tr1p1ea wrote:
Thanks Kerm, I think i have located the issue and will be testing shortly.
Many thanks! By the way, I'm not sure if we've discussed this before, but do you have a Mercurial client like TortoiseHG installed? If you don't object, both of our lives would be easier if you were versioning your changes in the Doors CSE repo. Smile
Thats a good idea, I will look at installing that over the weekend!

EDIT - I fixed the silly bug and to prove it I made these very quick xLIBC walking demos! (These uses the fixed transparency sprite routine):

16x16 sprite test:


xLIBC Zelda walking demo!!!:


The first are just resized tiles that DJ posted on omni a while back. The zelda tiles I got from somewhere a while back and the character is inspired by some of the rougelike 8x8 sprites getting around - however I added different directions and proper walking animations Smile.
  
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, 4, 5, 6, 7, 8  Next
» View previous topic :: View next topic  
Page 6 of 8
» All times are UTC - 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