Square kernel, 200x200 pixel goodness!

Topics related to the API, programming discussions & questions, coding tips, bugs, etc. should go here.
User avatar
Jubatian
Posts: 1560
Joined: Thu Oct 01, 2015 9:44 pm
Location: Hungary
Contact:

Re: Square kernel, 200x200 pixel goodness!

Post by Jubatian »

I started writing documentation for this thing. A substantial part of it is already completed, you may check it out here:

https://github.com/Jubatian/Uzebox-Squa ... Manual.rst

For now it should provide the necessities for messing around with Bitmap modes. Still there is a lot of work to do, but it is getting somewhere.
User avatar
Jubatian
Posts: 1560
Joined: Thu Oct 01, 2015 9:44 pm
Location: Hungary
Contact:

Re: Square kernel, 200x200 pixel goodness!

Post by Jubatian »

Nothing really new, just digging up and repurposing some old stuff. Maybe interesting. Resources from the original Outcasts plan.
As it would have looked like in Outcasts
As it would have looked like in Outcasts
m74_dragon.png (36 KiB) Viewed 8319 times
The tilesets and all doesn't look too off when used at square aspect ratio instead, as you can see in the attached demo (just the usual, now the sprite jumble replaced with a few soaring dragons).

I have notes on this green beast, attempting to ram it in the box without SPI RAM as a loaded asset. So 22 tiles are needed for it, 704 bytes of RAM for just storing the loaded-off image, then there is a mess of calculations on this revealing that it took at most 46 RAM tiles when gliding forward Y aligned.

I didn't find character animations, so that I pass for now, with this kernel, I might just not want to use the old resources as they were. Larger sprites maybe, the background also could be a lot better and likes. With the SPI RAM there for sprite data, it is also possible to create rich animations, if I wanted such a soaring dragon, I could even animate that proper.
Attachments
tilestest_with_dragon.zip
Looks a bit better with the dragon
(30.35 KiB) Downloaded 488 times
User avatar
Jubatian
Posts: 1560
Joined: Thu Oct 01, 2015 9:44 pm
Location: Hungary
Contact:

Re: Square kernel, 200x200 pixel goodness!

Post by Jubatian »

Just some bits of ramblings, progress report on this thing.

I am quite disappointed by the current blitting performance. Not that it isn't fast compared to other modes, but this thing potentially has 85 RAM tiles to fill, and it is just frustrating that there is no way to reasonably use all this at maximum height.

So basically I tried to start over from the scratch for the sprite blitter. A new, entirely different blitter with which I aim to be able to output the whole sprite with a single pass on the SPI RAM source data regardless of how it aligns with tiles. This is possible, but the algorithm is possibly the most complex so far of anything I did for the Uzebox. If I can pull it through, the blitter would become almost completely unaffected by alignment except for the need for preparing RAM tiles. So if you were composing sprites over sprites, then the further sprite content would be practically unaffected by alignment - this is actually a very common scenario, all megasprites have this when you are outputting unaligned 8x8 sprite components side by side.

In the end this would probably be noticeably faster than even the normal Mode 74 sprite engine which fetches sprites from the ATMega's Flash.

But still a long way to get there.
User avatar
nicksen782
Posts: 714
Joined: Wed Feb 01, 2012 8:23 pm
Location: Detroit, United States
Contact:

Re: Square kernel, 200x200 pixel goodness!

Post by nicksen782 »

I can see this mode as the new go-to mode. Right now, I think that mode is Mode 3 or Mode 1. You are doing great and I really like the demos. I was looking into developing a C sprite engine in Mode 3 that would also handle the background tile restore. I got stalled on that. I think this new kernel and demo will probably be a better fit.
User avatar
Jubatian
Posts: 1560
Joined: Thu Oct 01, 2015 9:44 pm
Location: Hungary
Contact:

Re: Square kernel, 200x200 pixel goodness!

Post by Jubatian »

By the way the changes I am trying to push through wouldn't affect the C interface, so if you would like to, you can start experimenting. The results of what I am trying to accompish would only be a faster sprite system, without any changes in the exposed functions.

By the way if you don't like the square form, later it would be possible to realize other video modes based on this kernel. I just like this due to the square pixels, making it easy to pixel for, and easy to port to other systems without needing too much graphics processing (like I mentioned for the Emscripten CUzeBox, in High Quality mode it spends about half of its time not by struggling to emulate the AVR, but, ridiculous as it is, shovelling pixels to the screen).

Somebody could possibly add the 4bpp tiles to GConvert, too, I use the same format (high nybble for left pixels of pixel pairs) for all the 4bpp modes I designed. I dunno whether it has Mode 13 support, if it has, maybe however the palette was added could be reused (the tiles of Mode 13 are different, quite complex to grasp due to that it uses a wicked trick to get 15 colours in one fewer cycle per two pixels than Mode 74).
Post Reply