|
ForumsSega Master System / Mark III / Game GearSG-1000 / SC-3000 / SF-7000 / OMV |
Home - Forums - Games - Scans - Maps - Cheats - Credits Music - Videos - Development - Hacks - Translations - Homebrew |
![]() |
Goto page Previous 1, 2, 3, 4 |
Author | Message |
---|---|
|
![]() |
Need it on z88dk!!! | |
![]() ![]() |
|
|
![]() |
I'm sure it won't take long :) | |
![]() ![]() ![]() |
|
|
![]() |
It's in now :) | |
![]() ![]() ![]() |
|
|
![]() |
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. | |
![]() ![]() ![]() |
|
|
![]() |
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. | |
![]() ![]() |
|
|
SMS_addThreeAdjoiningSprites?
![]() |
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) |
|
![]() ![]() ![]() |
|
|
![]() |
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! | |
![]() ![]() |
![]() |
Goto page Previous 1, 2, 3, 4 |