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:

Mode 52: 2bpp square pixels with scrolling & sprites

Post by Jubatian »

Yet another video mode under construction, here now comes the obligatory chaotic colorful mess of test image (with attached UZE file):
Mode 52 experimental
Mode 52 experimental
m52_experimental.png (33.36 KiB) Viewed 10856 times
What the experiment shows are ROM and RAM tiles (192 ROM tiles fetching crap from the code, 64 RAM tiles pre-filled to be flat), the plain 2 bits per pixel tiled mode with various display width settings on the same screen, with horizontal scrolling. It is a Timer1 terminated mode.

The mode takes about 8 Kbytes total, the rest are mostly kernel stuff in the UZE. Of course it doesn't have a sprite blitter yet, but I have its mechanisms planned out.

What the mode has or will have in addition:
  • Arbitrary vertical splits, the same like Mode 748 has.
  • Arbitrary ROM / RAM tile split.
  • Reloading Color 0 and/or Color 1 for every scanline if desired.
  • Attribute mode for Color 0 if compiled in (about 2Kbytes extra).
  • Attribute mode for Colors 1,2,3 with RAM tiles only if compiled in (about 6Kbytes extra).
  • Attribute + X Mirror mode: Color 2,3 can have attributes, up to 128 RAM tiles only, bit 7 is an X mirror flag (about 6Kbytes extra).
  • Sprite blitter similar to Mode 74, including support for 4 color + transparency mask sprites (if you need all the colors).
I already created the code for the various attribute modes as well, they are proven possible, and are already more-or-less added (needing mostly testing). The Attribute + X Mirror mode could be particularly interesting for displaying complex images from RAM (so you can have a visually diverse game on an unexpanded Uzebox).

The sprite blitter by the current sketches should become capable of similar performance to Mode 74's, maybe it could be even faster.

By technology the mode is a mix of Mode 13, Mode 40 and CunningFellow's Tempest mode, employing some unusual tricks to trim down size to an acceptable level. For RAM footprint, it could compete with Mode 72 while providing a very different look and feel. 5 cycles per pixel is nearly square (it is still a little wide), so you would be able to pixel to this without the necessity of tailoring graphics to a weird pixel aspect ratio.

Of course I also try to provide a simpler interface than before, it will be a bit more complex to handle than Mode 40, but it won't be any near the difficulty of Mode 748 (much less Mode 74 which is sure a beast to tame).
Attachments
m52test.uze
Mode 52 experimental
(18.42 KiB) Downloaded 431 times
CunningFellow
Posts: 1445
Joined: Mon Feb 11, 2013 8:08 am
Location: Brisbane, Australia

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

Post by CunningFellow »

Again - you are a coding machine.

Great work. And it is in my favorite 5clk per pixel aspect ratio :)
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! With this I also aim for having a clean C interface, that is, no icky pointer to int conversions and similar stuff. Something which could allow reasonably easy ports if someone implemented the mode natively (for example on PC, which such pointer conversions would hinder).

Now the video part seems completed, I think the video generation features work proper. Next would be the sprite engine, but I might push it onto my Git fork before that if anyone was interested in the technology, or wished to do some early experimenting.
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 it to my Uzebox fork, currently it is here:

https://github.com/Jubatian/uzebox/tree/mode52

A messy example similar to that in the top post is included:

https://github.com/Jubatian/uzebox/tree ... mples/junk

The video frame driver should be mostly complete. Sprite engine doesn't exist yet, however some hints are already there, particularly in the documentation, providing some indications on its future capabilities. Neither there are any generators, however the format of the tiles shouldn't be too complex.
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 »

Impressive resolution, this one could be really useful for the right situation!
CunningFellow
Posts: 1445
Joined: Mon Feb 11, 2013 8:08 am
Location: Brisbane, Australia

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

Post by CunningFellow »

D3thAdd3r wrote: Sat May 19, 2018 7:32 pm Impressive resolution, this one could be really useful for the right situation!
Agreed. I think the right situation could be ports of Amstrad CPC mode1 games particularly the Isometrics like Knight Lore, Head Over Heals, or the one I wanted to d Spindizzy.

That was why I had my eye on 2BPP 5Clock modes. Jubatian the coding machine beat me to it though. Not only is he fast he also did scrolling and an arbitrary RAM/ROM split. My mode on paper had no scrolling and fixed 128x RAM and 128x ROM tiles.
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 »

Woah! I am definitely interested in this video mode. :-)

Nice work Jubatian!
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 »

Checked out the code, very clean and the comments really help to get a general overview. Amazing how you shoehorned in that resolution....I don't know what/how you are doing the attributes stuff, but it looks pretty intense :) Wasn't sure what implications messing with "sync_pulse" variable would have, but now I see that you need only fix it at the end?

Code: Select all

#if (M52_RESET_ENABLE != 0)
	lds   r24,     m52_reset + 0
	lds   r25,     m52_reset + 1
	mov   r1,      r24
	or    r1,      r25
	brne  lares            ; Zero: No reset, perform a normal return
#endif
	ret
#if (M52_RESET_ENABLE != 0)
lares:
	ldi   r22,     lo8(M52_MAIN_STACK - 1) ; Set up main program stack
	ldi   r23,     hi8(M52_MAIN_STACK - 1)
	out   STACKL,  r22
	out   STACKH,  r23
	clr   r1               ; For C language routines, r1 is zero
	push  r24              ; Return address is the reset vector
	push  r25
	reti
#endif
I have not tried to use this yet, but I think you have this option in all these modes and the concept is quite neat. Games with higher ram tiles counts are probably going to need something like this, as otherwise missing a frame can become an avalanche(and wasting more time drawing ram tiles just to finish late then draw over them again before next frame). Is there any special considerations or non-obvious design elements in other parts of the mode required for this which would prevent it from being used in other modes? Probably one of the better ideas come up with for actually making a big sprite game work well.
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: Thu May 24, 2018 6:32 amWasn't sure what implications messing with "sync_pulse" variable would have, but now I see that you need only fix it at the end?
You can do anything within the scanline loop, the only thing to pay attention is the inline mixer, there is nothing else to coexist with. Then before returning, you restore stuff for the kernel. Although it is not relied upon yet, but this would allow using the GPIO regs both by the kernel and the video mode: The video mode's frame code could save them on entry, and restore on exit (the old Mode3 used the GPIO regs, I eliminated that).
D3thAdd3r wrote: Thu May 24, 2018 6:32 amI have not tried to use this yet, but I think you have this option in all these modes and the concept is quite neat. (...) Is there any special considerations or non-obvious design elements in other parts of the mode required for this which would prevent it from being used in other modes?
No, you could add it to any mode. It works very well for Mode 74 and similar 4bpp stuff as with this, you can share the main program stack with the 256 byte palette buffer, which is a lot (Flight of a Dragon uses it). If you designed a mode requiring any kind of buffer, this can be done. For this Mode 52 there is no such benefit, only the deterministic frame rate.

I might drop that 4+1 color sprite support though, at least that 20 byte variant which I described in the current manual. It could work, but to combine it proper with sprite X mirroring and arbitrary placement would be a nightmare to implement. So, at least for now, 4+1 color sprites would take 24 bytes, an ordinary transparency mask + tile, possibly interleaved line by line (Which would be easier if SPI RAM sprite support was needed later. By the way 5cy / pixels is also a nice number for the SPI RAM, allowing easy display of 2bpp material. Anyway, my motivation for this mode is a complex game without the SPI RAM, so that will wait!).
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 »

Seems 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:
Post Reply