Forums

Need it on z88dk!!!

I'm sure it won't take long :)

It's in now :)

sverx wrote

update rolled. 1bpp tiles can be loaded using SMS_load1bppTiles() and SMS_configureTextRenderer() sets which offset will be applied to each ASCII char to generate the tile number, which can be quite 'abused' as you can also force that to use sprite palette or tile priority or even flipping tiles horizontally and/or vertically, as in my tests (see the attached image)

the 'autoSetUp' function will be released later, when I'll have a font to include - and a nice name for it. It'll take some time :|

Just a question regarding the screenshot of the text, you have multicoloured text. Is that just from duplication of the font or is there some trickery to change the palette on the fly?

The source is in the same post, the same font is loaded multiple times with different palette initialisation indices.

Ah fair enough, that's pretty much how I already am doing it. I was hoping for some raster trickery to avoid duplicate tile data :)

You can do that, you can even do old school copper bars. Something like a title screen probably has plenty of spare time to waste on it.

djbass wrote

I was hoping for some raster trickery to avoid duplicate tile data

That wouldn't give you multicolored text on the same line... apart from that, it would surely work.

I started refactoring SMS_copySpritestoSAT code.

In my plans both SMS_copySpritestoSAT and UNSAFE_SMS_copySpritestoSAT would be rewritten to trasfer to VRAM only the used part of the SAT table, making the operation cost variable according to number of sprites used, instead of the current implementation where the cost is fixed (10916 and 3283 cycles, respectively). Also, the new code will be almost pure Z80 asm, to squeeze every possible cycle.

At the same moment, the refactoring will make SMS_finalizeSprites useless, and will be then removed.

SMS_copySpritestoSAT seems to be already working properly, and it's even faster than the current UNSAFE_SMS_copySpritestoSAT when the number of used sprites is less than 40.

As for UNSAFE_SMS_copySpritestoSAT, to refactor that I need some more time, as the Z80 is missing instructions as CALL (16-bit reg) or similar (yes, there's JP (HL) or JP (IY) - I'll probably use that... or SMC in RAM, I still have to see what works better...)

I will post an update when the stuff is baked :)

You can call an address in a register as so:

CallHL:
jp (hl)

...

ld hl, label
call CallHL

Yes, the base is that one, unfortunately the called function needs some value passed through HL, which means I have to use

JP (IY)

instead.

BTW what's the fastest way to calculate the address? I need to jump into a block of 128 OUTI instructions, I have both the start and the end address of the block, and the number of OUTI to be performed (1 to 64)... any suggestion?

If possible, align the table to a multiple of 256 bytes and then you just load the high byte to iyh and 128 minus the byte count to iyl. The alignment means the high byte is unaffected by the byte count.

no, it's impossible actually. I'm in the crt0 and starting at $0100 would make the table overflow into $0200 (it's 128 OUTI and a RET) which is something I don't want.

(mmm... well, maybe I could place it at $0080... let me see...)

OK, it wouldn't save many CPU cycles but it would waste some bytes into crt0, which is something I don't find convenient, so I won't move the OUTI block to $0080.

this is the new code, which is quite cumbersome IMHO - so if anyone has suggestions on how to make that clearer/faster/smaller it's welcome :)

in pseudocode:
- if SpriteNextFree is 0 : write End Of Sprite marker in SAT and leave (there are no sprites to copy)
- calculate jump address as OUTI64 + (64-SpriteNextFree)*2
- if SpriteNextFree isn't 64 : write End Of Sprite marker in SAT
- calculate jump address as OUTI128 + (64-SpriteNextFree)*4

void UNSAFE_SMS_copySpritestoSAT (void) {
SMS_setAddr(SMS_SATAddress);
__asm
ld a,(#_SpriteNextFree)
or a
jr z,_no_sprites
ld b,a
ld a,#64
sub a,b
add a,a
ld c,a
ld b,#0
ld hl,#_OUTI64
add hl,bc
ex de,hl
ld hl,#_SpriteTableY
call _start_cpy
ld a,(#_SpriteNextFree)
cp #64
jr z,_no_sprite_term
ld a,#0xD0
out (c),a
_no_sprite_term:
__endasm;
SMS_setAddr(SMS_SATAddress+128);
__asm
ld a,(#_SpriteNextFree)
ld b,a
ld a,#64
sub a,b
add a,a
add a,a
ld c,a
ld b,#0
ld hl,#_OUTI128
add hl,bc
ex de,hl
ld hl,#_SpriteTableXN
_start_cpy:
ld c,#_VDPDataPort
push de
pop iy
jp (iy)
_no_sprites:
ld a,#0xD0
out (#_VDPDataPort),a
__endasm;
}

edit: quick fix
edit: again

I got carried away and I'm rewriting the function to load STMcompressed tilemaps in Z80 asm too, so that it's both faster and smaller. :)

devkit just updated!

now both SMS_copySpritestoSAT and UNSAFE_SMS_copySpritestoSAT have been rewritten and they now copy only what's needed, thus making that operation faster... of course unless you're always using all the 64 sprites.
(also, if you're never using all the sprites, you can now have a few more available tiles in VRAM)

Also, SMS_finalizeSprites is now completely useless and has been deprecated. Stop using it ASAP. The function will be dropped sometime in 2018.

Finally, SMS_loadSTMcompressedTileMapArea has been rewritten in native Z80 asm, thus it's smaller - and way faster.

Let me know if you find any bug - hopefully not!

Ummm....

Psglib on msx/msx2

Some thoughs? Sorry, It is not a sms question. Have to test this weekend.

I have no idea - does the MSX has the same SN76489 anyway?

Different chip, but maybe a similar space optimisation from VGM is possible. See also http://www.chrismcovell.com/texts/binarystar-tech.html where something related is done.

Yeah It is not the same. I though It was the same but i was wrong. Will try wyztracker.

Would SMS_addThreeAdjoiningSprites be a generally useful function, or does it go too close to meta-sprite territory?

I have a lot of chunky 3x2 tile objects in a game I'm working on, so it would be a good optimisation. Maybe it would be better if I added it as game code though? What do you think?

well I think I can add that, as the library is anyway made of separate modules that are included only when used...

but yeah in general I think it's very bordering the meta-sprites - SMSlib doesn't support them, I guess because there are too many different ways to represent meta-sprites and I don't favor any of them (but of course any specific implementation is possible)

It would be amazing if you get chance to add that, thank you. And very much appreciate the API in SMSLib, it's a pleasure to work with.

if you want to test that SMS_addThreeAdjoiningSprites - please let me know if it works as intended, I'll push the release later.

(I'm waiting SDCC to fix a bug before pushing releases)

SMSlib.lib.zip (8.76 KB)

with SMS_addThreeAdjoiningSprites *untested*

That works perfectly, thank you! It saves 10 scan lines when drawing 4 of the 3x2 meta-sprites, which is a very nice saving. Thanks for looking at that so quickly and for the sneak preview!

Author	Message
eruiz00 Joined: 28 Jan 2017 Posts: 390 Location: Málaga, Spain	Posted: Thu Oct 12, 2017 12:04 pm
	Need it on z88dk!!!

sverx Joined: 05 Sep 2013 Posts: 2859	Posted: Thu Oct 12, 2017 12:44 pm
sverx Joined: 05 Sep 2013 Posts: 2859	I'm sure it won't take long :)

Alcoholics Anonymous Joined: 17 Nov 2015 Posts: 97 Location: Canada	Posted: Fri Oct 13, 2017 2:12 am
	It's in now :)

djbass Joined: 25 Jul 2007 Posts: 589 Location: Melbourne, Australia	Posted: Sat Oct 14, 2017 3:37 am
	sverx wrote update rolled. 1bpp tiles can be loaded using SMS_load1bppTiles() and SMS_configureTextRenderer() sets which offset will be applied to each ASCII char to generate the tile number, which can be quite 'abused' as you can also force that to use sprite palette or tile priority or even flipping tiles horizontally and/or vertically, as in my tests (see the attached image) the 'autoSetUp' function will be released later, when I'll have a font to include - and a nice name for it. It'll take some time :\| Just a question regarding the screenshot of the text, you have multicoloured text. Is that just from duplication of the font or is there some trickery to change the palette on the fly?

Maxim Site Admin Joined: 19 Oct 1999 Posts: 13547 Location: London	Posted: Sat Oct 14, 2017 6:59 am
	The source is in the same post, the same font is loaded multiple times with different palette initialisation indices.

djbass Joined: 25 Jul 2007 Posts: 589 Location: Melbourne, Australia	Posted: Sat Oct 14, 2017 10:42 am
	Ah fair enough, that's pretty much how I already am doing it. I was hoping for some raster trickery to avoid duplicate tile data :)

Maxim Site Admin Joined: 19 Oct 1999 Posts: 13547 Location: London	Posted: Sat Oct 14, 2017 10:46 am
	You can do that, you can even do old school copper bars. Something like a title screen probably has plenty of spare time to waste on it.

sverx Joined: 05 Sep 2013 Posts: 2859	Posted: Sat Oct 14, 2017 3:30 pm
sverx Joined: 05 Sep 2013 Posts: 2859	djbass wrote I was hoping for some raster trickery to avoid duplicate tile data That wouldn't give you multicolored text on the same line... apart from that, it would surely work.

sverx Joined: 05 Sep 2013 Posts: 2859	Posted: Mon Nov 06, 2017 1:30 pm
sverx Joined: 05 Sep 2013 Posts: 2859	I started refactoring SMS_copySpritestoSAT code. In my plans both SMS_copySpritestoSAT and UNSAFE_SMS_copySpritestoSAT would be rewritten to trasfer to VRAM only the used part of the SAT table, making the operation cost variable according to number of sprites used, instead of the current implementation where the cost is fixed (10916 and 3283 cycles, respectively). Also, the new code will be almost pure Z80 asm, to squeeze every possible cycle. At the same moment, the refactoring will make SMS_finalizeSprites useless, and will be then removed. SMS_copySpritestoSAT seems to be already working properly, and it's even faster than the current UNSAFE_SMS_copySpritestoSAT when the number of used sprites is less than 40. As for UNSAFE_SMS_copySpritestoSAT, to refactor that I need some more time, as the Z80 is missing instructions as CALL (16-bit reg) or similar (yes, there's JP (HL) or JP (IY) - I'll probably use that... or SMC in RAM, I still have to see what works better...) I will post an update when the stuff is baked :)

Maxim Site Admin Joined: 19 Oct 1999 Posts: 13547 Location: London	Posted: Mon Nov 06, 2017 5:23 pm
	You can call an address in a register as so: CallHL: jp (hl) ... ld hl, label call CallHL

sverx Joined: 05 Sep 2013 Posts: 2859	Posted: Mon Nov 06, 2017 10:03 pm
sverx Joined: 05 Sep 2013 Posts: 2859	Yes, the base is that one, unfortunately the called function needs some value passed through HL, which means I have to use JP (IY) instead. BTW what's the fastest way to calculate the address? I need to jump into a block of 128 OUTI instructions, I have both the start and the end address of the block, and the number of OUTI to be performed (1 to 64)... any suggestion?

Maxim Site Admin Joined: 19 Oct 1999 Posts: 13547 Location: London	Posted: Tue Nov 07, 2017 6:20 am
	If possible, align the table to a multiple of 256 bytes and then you just load the high byte to iyh and 128 minus the byte count to iyl. The alignment means the high byte is unaffected by the byte count.

sverx Joined: 05 Sep 2013 Posts: 2859	Posted: Tue Nov 07, 2017 8:49 am
sverx Joined: 05 Sep 2013 Posts: 2859	no, it's impossible actually. I'm in the crt0 and starting at $0100 would make the table overflow into $0200 (it's 128 OUTI and a RET) which is something I don't want. (mmm... well, maybe I could place it at $0080... let me see...)

sverx Joined: 05 Sep 2013 Posts: 2859	Posted: Tue Nov 07, 2017 11:20 am
sverx Joined: 05 Sep 2013 Posts: 2859	OK, it wouldn't save many CPU cycles but it would waste some bytes into crt0, which is something I don't find convenient, so I won't move the OUTI block to $0080. this is the new code, which is quite cumbersome IMHO - so if anyone has suggestions on how to make that clearer/faster/smaller it's welcome :) in pseudocode: - if SpriteNextFree is 0 : write End Of Sprite marker in SAT and leave (there are no sprites to copy) - calculate jump address as OUTI64 + (64-SpriteNextFree)2 - if SpriteNextFree isn't 64 : write End Of Sprite marker in SAT - calculate jump address as OUTI128 + (64-SpriteNextFree)4 void UNSAFE_SMS_copySpritestoSAT (void) { SMS_setAddr(SMS_SATAddress); __asm ld a,(#_SpriteNextFree) or a jr z,_no_sprites ld b,a ld a,#64 sub a,b add a,a ld c,a ld b,#0 ld hl,#_OUTI64 add hl,bc ex de,hl ld hl,#_SpriteTableY call _start_cpy ld a,(#_SpriteNextFree) cp #64 jr z,_no_sprite_term ld a,#0xD0 out (c),a _no_sprite_term: __endasm; SMS_setAddr(SMS_SATAddress+128); __asm ld a,(#_SpriteNextFree) ld b,a ld a,#64 sub a,b add a,a add a,a ld c,a ld b,#0 ld hl,#_OUTI128 add hl,bc ex de,hl ld hl,#_SpriteTableXN _start_cpy: ld c,#_VDPDataPort push de pop iy jp (iy) _no_sprites: ld a,#0xD0 out (#_VDPDataPort),a __endasm; } edit: quick fix edit: again

sverx Joined: 05 Sep 2013 Posts: 2859	Posted: Fri Nov 10, 2017 10:02 am
sverx Joined: 05 Sep 2013 Posts: 2859	I got carried away and I'm rewriting the function to load STMcompressed tilemaps in Z80 asm too, so that it's both faster and smaller. :)

sverx Joined: 05 Sep 2013 Posts: 2859	Posted: Mon Nov 13, 2017 12:02 pm
sverx Joined: 05 Sep 2013 Posts: 2859	devkit just updated! now both SMS_copySpritestoSAT and UNSAFE_SMS_copySpritestoSAT have been rewritten and they now copy only what's needed, thus making that operation faster... of course unless you're always using all the 64 sprites. (also, if you're never using all the sprites, you can now have a few more available tiles in VRAM) Also, SMS_finalizeSprites is now completely useless and has been deprecated. Stop using it ASAP. The function will be dropped sometime in 2018. Finally, SMS_loadSTMcompressedTileMapArea has been rewritten in native Z80 asm, thus it's smaller - and way faster. Let me know if you find any bug - hopefully not!

eruiz00 Joined: 28 Jan 2017 Posts: 390 Location: Málaga, Spain	Posted: Fri Dec 01, 2017 1:41 pm
	Ummm.... Psglib on msx/msx2 Some thoughs? Sorry, It is not a sms question. Have to test this weekend.

sverx Joined: 05 Sep 2013 Posts: 2859	Posted: Fri Dec 01, 2017 1:56 pm
sverx Joined: 05 Sep 2013 Posts: 2859	I have no idea - does the MSX has the same SN76489 anyway?

Maxim Site Admin Joined: 19 Oct 1999 Posts: 13547 Location: London	Posted: Fri Dec 01, 2017 2:53 pm
	Different chip, but maybe a similar space optimisation from VGM is possible. See also http://www.chrismcovell.com/texts/binarystar-tech.html where something related is done.

eruiz00 Joined: 28 Jan 2017 Posts: 390 Location: Málaga, Spain	Posted: Fri Dec 01, 2017 8:35 pm
	Yeah It is not the same. I though It was the same but i was wrong. Will try wyztracker.

MrBurrito Joined: 26 Jul 2020 Posts: 7	SMS_addThreeAdjoiningSprites? Posted: Wed Jan 27, 2021 4:35 pm
MrBurrito Joined: 26 Jul 2020 Posts: 7	Would SMS_addThreeAdjoiningSprites be a generally useful function, or does it go too close to meta-sprite territory? I have a lot of chunky 3x2 tile objects in a game I'm working on, so it would be a good optimisation. Maybe it would be better if I added it as game code though? What do you think?

sverx Joined: 05 Sep 2013 Posts: 2859	Posted: Wed Jan 27, 2021 4:56 pm
sverx Joined: 05 Sep 2013 Posts: 2859	well I think I can add that, as the library is anyway made of separate modules that are included only when used... but yeah in general I think it's very bordering the meta-sprites - SMSlib doesn't support them, I guess because there are too many different ways to represent meta-sprites and I don't favor any of them (but of course any specific implementation is possible)

MrBurrito Joined: 26 Jul 2020 Posts: 7	Posted: Wed Jan 27, 2021 5:09 pm
MrBurrito Joined: 26 Jul 2020 Posts: 7	It would be amazing if you get chance to add that, thank you. And very much appreciate the API in SMSLib, it's a pleasure to work with.

sverx Joined: 05 Sep 2013 Posts: 2859	Posted: Wed Jan 27, 2021 6:08 pm
sverx Joined: 05 Sep 2013 Posts: 2859	if you want to test that SMS_addThreeAdjoiningSprites - please let me know if it works as intended, I'll push the release later. (I'm waiting SDCC to fix a bug before pushing releases) SMSlib.lib.zip (8.76 KB) with SMS_addThreeAdjoiningSprites untested

MrBurrito Joined: 26 Jul 2020 Posts: 7	Posted: Wed Jan 27, 2021 6:38 pm
MrBurrito Joined: 26 Jul 2020 Posts: 7	That works perfectly, thank you! It saves 10 scan lines when drawing 4 of the 3x2 meta-sprites, which is a very nice saving. Thanks for looking at that so quickly and for the sneak preview!

Forums

View topic - devkitSMS/SMSlib - missing/requesting features