xb Universal Level-Description Format?

[SteveB]

Hi there,

 

when I wrote XB games with multiple rooms/levels I usually defined a description string, wrote a little interpreter and stored the levels in DATA statements (or a file). Usually a level had 30 to 60 bytes and the format was depending on the game, universal would be more.

 

I wonder whether there is a generic format to shorten the CALL HCHAR, VCHAR, SPRITE etc already established? One char per command or parameter, no need for seperators etc., i.e. five bytes for a HCHAR with character, row, column and repeat. Using 0-9, A-Z,a-z would give us 0 to 61, whereas I often used ASC(x)-48 which is faster but harder to read ... colon equals 10, D equals 20. With a level editor readability would not really be an issue, would it? Sprites would be positioned according to character coordinates (row*8)-7. CALL HCHAR(5,10,88,3) could be H5AX3 or H5:X3.

 

Does this makes sense? Or is there already something I wasn't able to find because this is hard to google? How to handle char codes beyond 127? Any clever ideas?

 

Thank you

Steve

 

[RXB]

1 hour ago, SteveB said:

Hi there,

 

when I wrote XB games with multiple rooms/levels I usually defined a description string, wrote a little interpreter and stored the levels in DATA statements (or a file). Usually a level had 30 to 60 bytes and the format was depending on the game, universal would be more.

 

I wonder whether there is a generic format to shorten the CALL HCHAR, VCHAR, SPRITE etc already established? One char per command or parameter, no need for seperators etc., i.e. five bytes for a HCHAR with character, row, column and repeat. Using 0-9, A-Z,a-z would give us 0 to 61, whereas I often used ASC(x)-48 which is faster but harder to read ... colon equals 10, D equals 20. With a level editor readability would not really be an issue, would it? Sprites would be positioned according to character coordinates (row*8)-7. CALL HCHAR(5,10,88,3) could be H5AX3 or H5:X3.

 

Does this makes sense? Or is there already something I wasn't able to find because this is hard to google? How to handle char codes beyond 127? Any clever ideas?

 

Thank you

Steve

 

RXB handles Characters 30 to 159 but any characters above 128 interferes with Sprites but you can use both as long as less then 10 sprites.

Also CALL HCHAR like many RXB commands can do more then one call in a single command EXAMPLE:

CALL HCHAR(ROW,COLUMN,CHARACTER,REPETION,ROW,COLUMN,CHARACTER,REPETION,ROW,COLUMN,CHARACTER,REPETION)

CALL VCHAR(ROW,COLUMN,CHARACTER,REPETION,ROW,COLUMN,CHARACTER,REPETION,ROW,COLUMN,CHARACTER,REPETION)

CALL GCHAR(ROW,COLUMN,VARIABLE,ROW,COLUMN,VARIABLE,ROW,COLUMN,VARIABLE)

[Asmusr]

Magellan can export to an XB program. It doesn't use data compression and it doesn't include sprites, but it's probably the closest to a standard that we have.

https://magellan.js99er.net

 

[SteveB]

17 hours ago, RXB said:

RXB handles Characters 30 to 159 but any characters above 128 interferes with Sprites but you can use both as long as less then 10 sprites.

Also CALL HCHAR like many RXB commands can do more then one call in a single command EXAMPLE:

CALL HCHAR(ROW,COLUMN,CHARACTER,REPETION,ROW,COLUMN,CHARACTER,REPETION,ROW,COLUMN,CHARACTER,REPETION)

CALL VCHAR(ROW,COLUMN,CHARACTER,REPETION,ROW,COLUMN,CHARACTER,REPETION,ROW,COLUMN,CHARACTER,REPETION)

CALL GCHAR(ROW,COLUMN,VARIABLE,ROW,COLUMN,VARIABLE,ROW,COLUMN,VARIABLE)

Yes Rich, I see the improvement here.

call vchar(5,10,88,3) -> 27 byte

9D[CALL] C8[Unquotedstring] 05 56 43 48 41 52 B7[(] C8[Unquotedstring] 01 35 B3[,] C8[Unquotedstring] 02 31 30 B3[,] C8[Unquotedstring] 02 38 38 B3[,] C8[Unquotedstring] 01 33 B6[)]

 

call vchar(5,10,88,3,8,10,88,5) -> 45 byte instead of 54 byte

9D[CALL] C8[Unquotedstring] 05 56 43 48 41 52 B7[(] C8[Unquotedstring] 01 35 B3[,] C8[Unquotedstring] 02 31 30 B3[,] C8[Unquotedstring] 02 38 38 B3[,] C8[Unquotedstring] 01 33 B3[,] C8[Unquotedstring] 01 38 B3[,] C8[Unquotedstring] 02 31 30 B3[,] C8[Unquotedstring] 02 38 38 B3[,] C8[Unquotedstring] 01 35 B6[)]

 

Still a lot more than the 6 bytes in my suggestion, but it depends on how large (and fast) the interpreter is whether this really pays off. I read so much about compressed sound I wondered if there were compressed graphics as well. 

 

My second thought about the >127 character is a "pen" solution. First set the character in Hex : $A5 and the do the drawing H5A3. Or always use two bytes for the character in hex: H5AA53. This would still save 22 byte with every HCHAR. Think of 5 levels with 10 xCHAR lines you'll have 1kb saved.

 

Steve

[SteveB]

5 hours ago, Asmusr said:

Magellan can export to an XB program. It doesn't use data compression and it doesn't include sprites, but it's probably the closest to a standard that we have.

https://magellan.js99er.net

 

Great! I didn't know this one... I'll check if one of the outputs qualifies to be compressed in the proposed way.

 

[senior_falcon]

20 hours ago, SteveB said:

Hi there,

 

when I wrote XB games with multiple rooms/levels I usually defined a description string, wrote a little interpreter and stored the levels in DATA statements (or a file). Usually a level had 30 to 60 bytes and the format was depending on the game, universal would be more.

 

I wonder whether there is a generic format to shorten the CALL HCHAR, VCHAR, SPRITE etc already established? One char per command or parameter, no need for seperators etc., i.e. five bytes for a HCHAR with character, row, column and repeat. Using 0-9, A-Z,a-z would give us 0 to 61, whereas I often used ASC(x)-48 which is faster but harder to read ... colon equals 10, D equals 20. With a level editor readability would not really be an issue, would it? Sprites would be positioned according to character coordinates (row*8)-7. CALL HCHAR(5,10,88,3) could be H5AX3 or H5:X3.

 

Does this makes sense? Or is there already something I wasn't able to find because this is hard to google? How to handle char codes beyond 127? Any clever ideas?

 

Thank you

Steve

 

XB256 is a stand alone utility and is also part of XB 2.8 G.E.M. Using XB256 you can define characters from 0 to 255, also any sprites are in a separate location. You can save selected areas of VDP memory such as screens, character definitions, etc. using RLE compression. These can be saved as DATA statements and added to your program. When the program wants to use these they can be loaded wiith a simple  and then restore those areas with CALL LINK("CWRITE",A$) where A$ is the compressed string you just read from a DATA statement.

Also, almost everything built into XB256 can be compiled.

[SteveB]

15 hours ago, senior_falcon said:

XB256 is a stand alone utility and is also part of XB 2.8 G.E.M. Using XB256 you can define characters from 0 to 255, also any sprites are in a separate location. You can save selected areas of VDP memory such as screens, character definitions, etc. using RLE compression. These can be saved as DATA statements and added to your program. When the program wants to use these they can be loaded wiith a simple  and then restore those areas with CALL LINK("CWRITE",A$) where A$ is the compressed string you just read from a DATA statement.

Also, almost everything built into XB256 can be compiled.

With your ISABELLA compiler I can avoid any manual memory access. Back in the days I did only have XB and a CS1, never learned the fancy E/A and memory stuff. RLE compressions sounds good, where can I learn which areas to use and how to reserve them? Everybody but me seems to know by now. There are some other areas where I could benefit from an "array of bytes", where I now use strings, complicated and slow to update.

 

Additionally I will try to do a short demo of my interpreter to see where this leads ... how big, how fast (or slow), now that I know there is no common standard yet. 

My next release of TiCodEd Structured Extended Basic will include XB256 support in the way you can use CALL CWRITE(A$) and it will become CALL LINK("CWRITE",A$) in the generated XB code for all routines. Just a little convinience. I just started testing with XB256 last week and still have shiny eyes when I see what is possible now, even without compiling.