Mode 52: 2bpp square pixels with scrolling & sprites

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

Re: Mode 52: 2bpp square pixels with scrolling & sprites

Post by Jubatian »

D3thAdd3r wrote: Mon May 28, 2018 1:39 amSeems like 24 byte sprites is already really efficient and I doubt anyone's game hangs in the balance without some 20 bytes variant (which I don't understand actually). With the standard sprite stuff implemented, this is yet another crazy good mode to be used for games that fit it's specs. No developer can come to Uzebox and say Jubatian didn't offer them enough video angles for their particular game :mrgreen:
I implemented most of the sprite support on the weekend, just didn't test it (except for the single pixel output, testing the RAM tile allocator). It is up in the repo including the documentations.

The 20 byte sprites would have been nice if you wanted to have them in RAM (for example some boss image or something alike loaded from SD in a larger game), by using a converter, it wouldn't have been necessary to actually understand the format. It just really didn't get along well with the need of line by line access necessary for blitting onto the RAM tiles. By the way the absolute theoretical minimum is 19 bytes (log2(5^64) is just below 149, bits, so 19 bytes, 5 is the count of possible pixel values: 4 colors + 1 transparency, 64 is the tile size in pixels).
User avatar
Jubatian
Posts: 1561
Joined: Thu Oct 01, 2015 9:44 pm
Location: Hungary
Contact:

Re: Mode 52: 2bpp square pixels with scrolling & sprites

Post by Jubatian »

Basic sprite support is tested, it works!
Plane example
Plane example
m52plane_screenshot.png (14.88 KiB) Viewed 9447 times
The source is up on my fork, here:

https://github.com/Jubatian/uzebox/tree ... ples/plane

I didn't put much effort in cleaning it up proper yet, I want to do a small demo similar to that of Mode 74. The background masking feature is not tested yet, but it is there, it might even work.

The particular plane by the way is a Lisunov LI-2, a russian version of the Douglas DC-3. The HA-LIX is the only one today in airworthy condition, I can actually see this plane flying from times to times here.

EDIT: By the way anyone interested in making a Lightforce music conversion for 4 channels? I mean this one, or something similar (there are several awesome remixes of this tune), it seems fitting with this scene. You have more than 20K, although no PCM channel (I want to keep 36 tiles width, and PCM doesn't fit with that).
Attachments
m52test.uze
The UZE which produces the image
(28.21 KiB) Downloaded 431 times
User avatar
Artcfox
Posts: 1382
Joined: Thu Jun 04, 2015 5:35 pm
Contact:

Re: Mode 52: 2bpp square pixels with scrolling & sprites

Post by Artcfox »

Damn, that looks sweet!
User avatar
ry755
Posts: 226
Joined: Mon May 22, 2017 6:01 am

Re: Mode 52: 2bpp square pixels with scrolling & sprites

Post by ry755 »

Jubatian wrote: Wed May 30, 2018 5:59 pm Basic sprite support is tested, it works!
Wow, that looks really cool!
User avatar
Jubatian
Posts: 1561
Joined: Thu Oct 01, 2015 9:44 pm
Location: Hungary
Contact:

Re: Mode 52: 2bpp square pixels with scrolling & sprites

Post by Jubatian »

Thanks! I gone a bit further to make it look like some proper one-screen demo, it is here attached, and the source is of course available on my experimental branch. Most notably I tested background masking which is proven working. Also I did tests for sprite flipping capabilities (the demo doesn't flip them, I just tried that out), bugs were fixed, and now it works.

I guess if interested, you could checkout the mode and experiment with it, stuff commonly required for a game should work. Just to note: Currently you can use only at most 85 RAM tiles for sprites due to an address calculation limitation, I dunno, there could be valid game ideas which required more (on a narrow screen), even 85 RAM tiles is only 1.3 Kbytes in this mode, so like why not.
Attachments
li2demo.uze
Now it looks somewhat like a proper one-screen demo
(32.53 KiB) Downloaded 399 times
User avatar
D3thAdd3r
Posts: 3221
Joined: Wed Apr 29, 2009 10:00 am
Location: Minneapolis, United States

Re: Mode 52: 2bpp square pixels with scrolling & sprites

Post by D3thAdd3r »

Awesome!
User avatar
Jubatian
Posts: 1561
Joined: Thu Oct 01, 2015 9:44 pm
Location: Hungary
Contact:

Re: Mode 52: 2bpp square pixels with scrolling & sprites

Post by Jubatian »

I added comments to the demo's source, explaining how the mode can be initialized proper. It should contain most tasks what a game could require.

If any of you decided to experiment with the mode, I would like to hear some feedback on how the interface feels like, is it possible to be understood, to be handled. Likely I will modify Mode 748 to match this interface (it doesn't require much, mostly the sprite engine's interface, especially the masking system needs changes), and later a simplified version of Mode 74 might also receive a similar interface.

Another thing is that the mode works with quite normal tiles. Someone having experience with GConvert could add support for it!
User avatar
Jubatian
Posts: 1561
Joined: Thu Oct 01, 2015 9:44 pm
Location: Hungary
Contact:

Re: Mode 52: 2bpp square pixels with scrolling & sprites

Post by Jubatian »

I added the mode to the Wiki, it is here as of now:

http://uzebox.org/wiki/Experimental_and ... ode_52_WIP
User avatar
D3thAdd3r
Posts: 3221
Joined: Wed Apr 29, 2009 10:00 am
Location: Minneapolis, United States

Re: Mode 52: 2bpp square pixels with scrolling & sprites

Post by D3thAdd3r »

Great stuff, I would really like to make some Metroidvania grayscale game with this. Would ram tile tricks work the same as other 8 bit vram modes?
User avatar
Jubatian
Posts: 1561
Joined: Thu Oct 01, 2015 9:44 pm
Location: Hungary
Contact:

Re: Mode 52: 2bpp square pixels with scrolling & sprites

Post by Jubatian »

D3thAdd3r wrote: Sat Jun 30, 2018 3:50 pmWould ram tile tricks work the same as other 8 bit vram modes?
The underlaying mechanism is the same, you can easily have user RAM tiles, and they work just like in Mode 3, you can freely blit sprites over them. So really, you can do anything there! Moreover the ROM/RAM tile split point is a variable (unlike Mode 3 where it is a compile time constant) which you may exploit in your design.
Post Reply