Forums

Sega Master System / Mark III / Game Gear
SG-1000 / SC-3000 / SF-7000 / OMV
Home - Forums - Games - Scans - Maps - Cheats - Credits
Music - Videos - Development - Hacks - Translations - Homebrew

View topic - devkitSMS/SMSlib - missing/requesting features

Reply to topic Goto page Previous  1, 2, 3, 4
Author Message
  • Joined: 28 Jan 2017
  • Posts: 548
  • Location: Málaga, Spain
Reply with quote
Post Posted: Thu Oct 12, 2017 12:04 pm
Need it on z88dk!!!
  View user's profile Send private message
  • Joined: 05 Sep 2013
  • Posts: 3763
  • Location: Stockholm, Sweden
Reply with quote
Post Posted: Thu Oct 12, 2017 12:44 pm
I'm sure it won't take long :)
  View user's profile Send private message Visit poster's website
  • Joined: 17 Nov 2015
  • Posts: 97
  • Location: Canada
Reply with quote
Post Posted: Fri Oct 13, 2017 2:12 am
It's in now :)
  View user's profile Send private message Visit poster's website
  • Joined: 25 Jul 2007
  • Posts: 716
  • Location: Melbourne, Australia
Reply with quote
Post 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?
  View user's profile Send private message
  • Site Admin
  • Joined: 19 Oct 1999
  • Posts: 14688
  • Location: London
Reply with quote
Post 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.
  View user's profile Send private message Visit poster's website
  • Joined: 25 Jul 2007
  • Posts: 716
  • Location: Melbourne, Australia
Reply with quote
Post 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 :)
  View user's profile Send private message
  • Site Admin
  • Joined: 19 Oct 1999
  • Posts: 14688
  • Location: London
Reply with quote
Post 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.
  View user's profile Send private message Visit poster's website
  • Joined: 05 Sep 2013
  • Posts: 3763
  • Location: Stockholm, Sweden
Reply with quote
Post Posted: Sat Oct 14, 2017 3:30 pm
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.
  View user's profile Send private message Visit poster's website
  • Joined: 05 Sep 2013
  • Posts: 3763
  • Location: Stockholm, Sweden
Reply with quote
Post Posted: Mon Nov 06, 2017 1:30 pm
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 :)
  View user's profile Send private message Visit poster's website
  • Site Admin
  • Joined: 19 Oct 1999
  • Posts: 14688
  • Location: London
Reply with quote
Post 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
  View user's profile Send private message Visit poster's website
  • Joined: 05 Sep 2013
  • Posts: 3763
  • Location: Stockholm, Sweden
Reply with quote
Post Posted: Mon Nov 06, 2017 10:03 pm
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?
  View user's profile Send private message Visit poster's website
  • Site Admin
  • Joined: 19 Oct 1999
  • Posts: 14688
  • Location: London
Reply with quote
Post 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.
  View user's profile Send private message Visit poster's website
  • Joined: 05 Sep 2013
  • Posts: 3763
  • Location: Stockholm, Sweden
Reply with quote
Post Posted: Tue Nov 07, 2017 8:49 am
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...)
  View user's profile Send private message Visit poster's website
  • Joined: 05 Sep 2013
  • Posts: 3763
  • Location: Stockholm, Sweden
Reply with quote
Post Posted: Tue Nov 07, 2017 11:20 am
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
  View user's profile Send private message Visit poster's website
  • Joined: 05 Sep 2013
  • Posts: 3763
  • Location: Stockholm, Sweden
Reply with quote
Post Posted: Fri Nov 10, 2017 10:02 am
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. :)
  View user's profile Send private message Visit poster's website
  • Joined: 05 Sep 2013
  • Posts: 3763
  • Location: Stockholm, Sweden
Reply with quote
Post Posted: Mon Nov 13, 2017 12:02 pm
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!
  View user's profile Send private message Visit poster's website
  • Joined: 28 Jan 2017
  • Posts: 548
  • Location: Málaga, Spain
Reply with quote
Post 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.
  View user's profile Send private message
  • Joined: 05 Sep 2013
  • Posts: 3763
  • Location: Stockholm, Sweden
Reply with quote
Post Posted: Fri Dec 01, 2017 1:56 pm
I have no idea - does the MSX has the same SN76489 anyway?
  View user's profile Send private message Visit poster's website
  • Site Admin
  • Joined: 19 Oct 1999
  • Posts: 14688
  • Location: London
Reply with quote
Post 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.
  View user's profile Send private message Visit poster's website
  • Joined: 28 Jan 2017
  • Posts: 548
  • Location: Málaga, Spain
Reply with quote
Post 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.
  View user's profile Send private message
  • Joined: 26 Jul 2020
  • Posts: 7
Reply with quote
SMS_addThreeAdjoiningSprites?
Post Posted: Wed Jan 27, 2021 4:35 pm
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?
  View user's profile Send private message
  • Joined: 05 Sep 2013
  • Posts: 3763
  • Location: Stockholm, Sweden
Reply with quote
Post Posted: Wed Jan 27, 2021 4:56 pm
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)
  View user's profile Send private message Visit poster's website
  • Joined: 26 Jul 2020
  • Posts: 7
Reply with quote
Post Posted: Wed Jan 27, 2021 5:09 pm
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.
  View user's profile Send private message
  • Joined: 05 Sep 2013
  • Posts: 3763
  • Location: Stockholm, Sweden
Reply with quote
Post Posted: Wed Jan 27, 2021 6:08 pm
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*

  View user's profile Send private message Visit poster's website
  • Joined: 26 Jul 2020
  • Posts: 7
Reply with quote
Post Posted: Wed Jan 27, 2021 6:38 pm
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!
  View user's profile Send private message
Reply to topic Goto page Previous  1, 2, 3, 4



Back to the top of this page

Back to SMS Power!