00:00
00:00
Kiloru
all systems nominal

Enkinaru @Kiloru

Age 30, Male

Soviet Russia

Joined on 1/24/13

Level:
16
Exp Points:
2,610 / 2,840
Exp Rank:
24,037
Vote Power:
5.78 votes
Rank:
Civilian
Global Rank:
94,798
Blams:
11
Saves:
46
B/P Bonus:
0%
Whistle:
Normal
Medals:
167

Crypts of Kayith Ulnorr devlog 3

Posted by Kiloru - 22 hours ago


I am getting cheeky

iu_1404713_4468939.gif

I am just considering variants of how combat can work (and seriously considering going the action way because i am dreading dynamic menus so much, yep)

Tried making sheathing/unsheathing mechanic

It is not visible on the gif, but switching states looks kinda glitchy (because i am swapping spritesheets), maybe will have to stuff it all into one spritesheet, which would honestly suck


Tags:

Comments

If I've read stuff correctly, the sprite Tile Data resides in Blocks 0 and 1, at $8000–87FF and $8800–8FFF (https://gbdev.io/pandocs/Tile_Data.html#vram-tile-data), and you can't use Block 2 for it. Most likely, changing a sprite sheet causes GBStudio to dump a whole lot of data from either read-only memory or RAM into Blocks 0 or 1 at once, which I suspect might be really slow, because this article (https://camendesign.com/code/gameboy-pop-tile), when updating the Tile Map, says "Assuming 32 tiles (...), this is roughly 2'304 cycles. V-blank is said to be 4'560 cycles long", which means you will struggle to update even 64 Tile Map entries, which are in VRAM and are 64 bytes in total, while each 8x8 tile in Tile Data is 16 bytes, which means you will struggle to update 4 8x8 tiles, which is exactly one animation frame of your character. So to switch a sprite sheet, which should be 3 directions (up, down, right) of standing still frames and 3 directions of walking animations, each 2 frames, so 3 + 3 * 2 = 9 frames, each frame being 4 tiles, is 36 tiles to update, and you can't update even 4 of them in a single V-blank. Game Boy is so slow you can't even update the protagonist's animations one frame at a time to maintain 59.7 FPS. The only solution I can think of is have her stand still for a few frames using her standing sprite, which you already have, and during this standing you can gradually dump her first animation frame of sword unsheathing into VRAM in place of her walking animation that should already be there that you don't need anymore. After she switches to her sword unsheathing's first animation frame, you must play not for one frame, but for at least 2 frames, in order to get ready her second frame of sword unsheathing, and so on. You can prepare her animation frames as she plays animations, as long as she plays each frame slowly enough. I don't think GBStudio would handle this automatically or provide easy ways to do something like that. This definitely requires manual low level control which might not even be compatible with GBStudio's graphical engine. Or grab their source code and modify their engine to support "streaming animations" I guess one would call it lol https://github.com/chrismaltby/gb-studio Or maybe it already has that and just messes something up, for example updates more tiles in Tile Data than necessary due to some error. Anyway, a sad sight, some animations just have to be gutted from the game like that

H o l y h e l l, man, you probably did more research than me at this point xD and nah, I lack both skills and desire to poke my nose into source code, I'll definitely break more things than fix lmao

So far the best workaround I've found was simply hiding player sprite for 1 frame, swapping spritesheet and showing it again. The flicker is still noticeable, but its already infinitely better than random misplace sprite pieces (and physical screen's onion skin effect should mask it pretty well anyway)

Also got suggestion in gbs discord that if both spritesheet have the same "default" state, the transition may look clean (and what a coincidence, both states have repeating tiles, so I may as well try it, too)