Closed torch2424 closed 6 years ago
Sprites may be unoptimized.
Don't need to load all attributes, need to check whether or not we even need to show the Sprite earlier
Try to render pixels for the entire line in the tile. Instead of going one by one.
Perhaps wrap I in a for loop, and increment manually, depending how much of the tile we were able to put out.
Won't require an array, just put an inner for loop, that will run the code of determining the pallete color 0-8 times
Record When the Timer TMA changes in memory and record in a static variable when it does that way we don't have to check if it did every batch process
When drawing tiles, Often times they repeat (Floor on the ground, Walls, etc...).
If I remember correctly, tilemap / tile data cannot change while you are drawing a scanline.
With the other graphics performance fix above. If the tilemap Id has the same as the previous tile (meaning they map to the exact same tile data, exact same image), simply copy the calculations for the previous tile, and display that for the scan line :)
This is of course, if we cannot do the tilemap cache due to Assembly script limitations (though was just mentioned static arrays are coming soon! 😄 )
Keep this in mind for all the new graphics hacks: https://github.com/LIJI32/GBVideoPlayer/blob/master/How%20It%20Works.md#hblank-and-sub-hblank-tricks
Also, graphics hacks are valid because tiles can't update in this time: http://gbdev.gg8.se/wiki/articles/Video_Display#VRAM_.28memory_at_8000h-9FFFh.29_is_accessible_during_Mode_0-2
Also, Batch processing Graphics and Disabling Scanline Graphics definitely introduce some bugs and break games like megaman 2. But games like Pokemon play fine without it. Should mention it in docs.
Assemblyscript now has an initial Static array implementation. Should super help with caching :)
https://github.com/AssemblyScript/assemblyscript/compare/2c0ddf4f8098...be66abbd783f
Super helpful notes from ISSOtm, which in discord, they Licensed under MIT haha!
Sprite code is supppeeerrr unoptimized, can definitely make some assumptions of whether or not we should be drawing sprites much earlier on
Don't grab the data bytes for CPU, instead, Ctrl f, and replace them as function calls
Re org backgroudnWindow.ts Make it more like The Debug where we detrmine palette and other things before, that way we can pass around easier :)
Optimizing has been a ton of fun. But here's what I'm learning (shoutout to @binji):
Ask yourself these things:
"What can I pull out of the main loop?" "What can I assume will not change?" "What can I assume has not changed until a write to memory?" "What can be cached to speed up.individual loops?"
Some Quick ideas:
Interrupts enabled/requested registers. If both are less than or equal too zero, skip.
Tile caching. Would require Assembly script maps to be completed. Could cache tiles, and discard them if we find that they changed.
Add more checks in memory.
Watch the ultimate Gameboy talk, with performance in mind