Page 1 of 9

Mode 72 development

Posted: Mon Jan 16, 2017 12:08 pm
by Jubatian
Announcing yet another video mode's development now: Mode 72!
  • 7 cycles / pixel, 160 pixels wide + 2 x 16 pixels borders (192px total)
  • Code tiled scrollable background, 8x8 tiles, up to 16 colors
  • Real-time rendered sprites, sprite mode 0 has 18 x 8 pixels wide 2bpp sprites of which 9 may display on a scanline
  • VSync mixer only
  • No video related VSync tasks (unlike Mode 2)
  • 40 tiles wide (320 pixels, 3.5 cycles / pixel) optional text mode overlays on the top / bottom
Mode72 prototype test screenshot
screenshot.png (7.83 KiB) Viewed 7297 times
For now the video mode frame is complete and sufficiently tested, it behaves correctly. Sprite mode 0 is tested as the attached prototype demonstrates. The background is there, just filled with a dummy blank tile (no code tile generator yet).

Each sprite can have arbitrary Y size (0 - 127 pixels, 0 turns the sprite off), may use any 3 colors, and can be X mirrored. They are fetched from RAM, so some copying may be necessary in games (but very little, just ROM => RAM transfers). These sprites are rendered real-time with no VSync tasks. This means for each of the 18 sprites you have a 8 byte structure to fill in (X:Y position, sprite data location in RAM, height, X mirror flag, the 3 colors), and the video frame will display the sprite accordingly. This means in this mode you will have lots of CPU time for your game logic (you only have a VSync mixer to deal with), and the RAM consumption is also low (no RAM tiles).

The border may be controlled by flags, and may also be sourced from a per-scanline color list (only allocated if enabled). This color list may also source background colors (for the game area and the text overlays), or alternatively you may use it to select a logical scanline for the background on every physical scanline (for various vertical effect, in a racing game this would be used to create hills and valleys).

Per-scanline parallaxing of the background is also supported (not tested yet of course, but the code is there). These would allow the mode to realize an Outrun style racing game.

The overall timing of the mode matches that of an NTSC Commodore 64 (including the text overlays), so it might be used for C64 ports or C64 style games (I will later build a sprite mode for this with 12 pixels wide sprites like the C64 had in multicolor mode).

When there are too many sprites on a scanline, they alternate in an interlaced manner. You may see this in action in the demo (in CUzeBox the frame merge option accessible with F7 smooths this out). A limitation here is that sprites are arranged in fixed pairs, so for example sprite 0 can not coexist with sprite 1 on the same scanline etc. (which you may need to pay attention when designing a game).

Re: Mode 72 development

Posted: Mon Jan 16, 2017 5:38 pm
by D3thAdd3r
It is a sweet mode. I could see a vertical shooter utilizing this to the max.

Re: Mode 72 development

Posted: Wed Jan 18, 2017 4:21 pm
by Jubatian
Yet another example, now the background is also added (after successfully finishing a code tile generator), the tileset just cannibalized from FoaD.
An example with background
screenshot2.png (13.88 KiB) Viewed 7243 times
An important feature, horizontal scrolling is visible in action. With this all the most important features of the mode are proven to be functional. Also a different border generation mode is visible (extending the background & boundary lines into the borders instead of using a single border color).

Re: Mode 72 development

Posted: Fri Jan 20, 2017 5:36 am
by D3thAdd3r
Looking good, that is really a barrage of sprites.

Can the code rows be reused, and if so is that totally automatic during the graphics conversion process or requires something run time?

Re: Mode 72 development

Posted: Fri Jan 20, 2017 6:24 am
by Jubatian
Code row reuse is a property of the codetile generator, it already works (I implemented the compression in it right away). FoaD's tileset (about 120 or so tiles as of now, didn't count) is very complex, some reusing is in place, but not much (its resulting size isn't significantly smaller than if I used a "normal" code tile table, but still should be smaller by a little). With low color count backgrounds you would get very noticable results (for example an Atari VCS port might get away with around 5-7 Kbytes of which 4 Kbytes are the 8 x 256 word rjmp tables matching tile rows with code blocks).

The only hindrance of course is that it isn't gconvert. I use the same principle like for Mode 90: I wrote a small C program which can include a Gimp-produced header, and generate you an assembly file (.s) which you can compile and link with your game.

For the sprites this should be the most generic use case, lots of 8 pixels wide sprites (so same format), offering 72 pixels coverage at most per scanline. With other sprite modes it should be possible to go up to about 100 pixels (wider sprites, less overhead, more time for filling the line buffer, otherwise it is also possible to drop color loads or mirroring capability to get valuable cycles, which I will use for sprite modes including 4 pixels wide sprites intended for bullets or other projectiles). For simple looking games (such as Atari VCS) it would also be possible to design a 1bpp sprite mode which could provide better coverage (although the current 9 x 8 px wide is I think exactly the max. what the VCS could do for player sprites).

Re: Mode 72 development

Posted: Fri Jan 20, 2017 7:12 pm
by D3thAdd3r
Very cool. I really really want to do Pitfall, eh I am going to "some day". Like you say on the simple graphics stuff like Atari 2600/VCS this works very well. I believe you are right to say that it matches or supersedes nearly everything the VCS can do on sprites/ball/missiles(5 sprites max per line, though can be double or quadruple width), so I would say there is a way to make it work great for *any* such game. Importantly, it is exactly the logical resolution of the VCS, which there is simply no way to fake well on a higher resolution mode;it would look differently and the gameplay would feel different unless you awkwardly framed off 160 pixels in the middle of the screen.

A game like Pitfall or nearly any Atari game would reuse lots of rows with the many solid colors. I was trying to think of anything the VCS could do, that this could not. Yars Revenge was the only candidate I could come up with, it draws that colorful/random bar by interperetting it's own game code as graphics data. With the fact those games are generally very small, you could simply have lots of random looking tiles and use those. I am not sure I understand the sprites in this one, you need to blit the sprite data to a buffer prior but this is "blit" tile aligned and the video modes takes it from there and offsets it during frame rendering? In that case, there is sort of a ram_tiles trick like mode-3-likes where there are some interesting possibilities.

Re: Mode 72 development

Posted: Sun Jan 22, 2017 11:40 pm
by Jubatian
No RAM tiles anywhere in this one. It has a line buffer, during the display of the scanline it fills the line buffer up with the next scanline (carefully interleaved code so the newly written tile data never overrides what is being displayed), then in the hsync it blits visible sprite scanlines onto this prepared line buffer. That's how it can support overlapping sprites properly (contrary to Mode 2 which only uses a partial line buffer). So there is only a 256 byte buffer (into which the scanlines are rendered as described above), and like Mode 74, it would be possible to share it with the main program stack. You may realize trick using sprites, but it works rather like conventional old-school video chips (like the VICII of the C64 or the original Gameboy) than like normal Uzebox modes. Nothing happens in VBlank, all of this is done within the video frame.

The Atari VCS has 4 "pixels" wide blocks for background (2 x 20 "pixels" total, a mirrored playfield), normally only two colors in a scanline. Yars Revenge as I checked sticks to this for the randomized blocks (2 colors only in a scanline). This means for a VCS color pair (black + something), you only need 4 rows (code block), so if you used 16 colors, that's 1 + 16 + 16 + 16 = 49 rows (but you may also use the per scanline BG color replace if you prefer to have a larger "palette", then it is only 4 rows). This would only take 5.5 kilobytes (49 rows) of ROM (only different rows matter for ROM usage).

Re: Mode 72 development

Posted: Thu Jan 26, 2017 3:52 pm
by Jubatian
Source is up!

Also the last fundamental feature is added:
Mode 72 with text overlays
screenshot3.png (13.81 KiB) Viewed 7119 times
Maybe this is also the highest resolution which is possible to be achieved without fully going to code tiles (3/4 cycle alternating, the lpm instruction is the hard constraint which requires adjacent pixels to be 4 cycles apart). If I design a 12 pixels wide sprite mode, then it could be used to build C64 style games (note: I accidentally committed the Sprite mode 1 code in which I started to do this, it is not functional! For now use Sprite mode 0 only).

For documentation, check the example and open the source files, I think they fairly well describe what you can do (notably on the top of videoMode72.s the video frame's regions are described, what belongs to them, how you can alter them).

EDIT: I completed and tested Sprite mode 1, it works. It gives you 14 x 12 pixels wide sprites of which 7 can display on a scanline (well, it seems impossible to get 8 of them like the C64's VIC-II does), giving 84 pixels coverage (contrary to 72 with 9 x 8 pixels wide sprites on a scanline in Sprite mode 0).

Re: Mode 72 development

Posted: Sat Jan 28, 2017 5:03 pm
by Jubatian
I created a bunch of sprite modes for the mode, now there are seven of them.

Particularly interesting modes are probably the followings (if you want to make shooters):

Mode 4: This has 10 x 12 pixels wide sprites and 10 x 4 pixels wide bullets, up to 5 of the 12 pixels wide sprites and 4 of the 4 pixels wide sprites may display on a scanline. It might work particularly well for C64 style games (which in Multicolor mode has 12 pixels wide sprites).

Mode 6: This has 8 x 16 pixels wide sprites and 12 x 4 pixels wide bullets, up to 4 of the 12 pixels wide sprites and 4 of the 4 pixels wide sprites may display on a scanline. Slightly larger coverage per scanline than Mode 4 (64 pixels versus 60 for the main sprites) and more bullets to work with.

These modes are also quite ridiculous for that I think I literally use every single cycle of the 1820 per scanline to generate them... Maybe there is a nop somewhere though which I couldn't exploit for something ridiculous :lol:

(If you check out the mode to experiment, keep in mind that you have to enable the sprite modes you want using M72_SPRITE_MODES, see the videoMode72.def.h file for details. You can have multiple sprite modes enabled, but since they are unrolled code, it isn't exactly beneficial to have everything. By default only sprite mode 0 is enabled which you can see in the demos posted here)
Sprite mode 6 test, just by modifying the example program
screenshot4.png (11.7 KiB) Viewed 7053 times
If you did any experimenting with the mode, for the new version you will need to adjust the game area's VRAM pointers (m72_rowoff) since its format was changed to gain some cycles. Check the updated documentation in videoMode72.s or the example if you used that.

Re: Mode 72 development

Posted: Wed Feb 08, 2017 9:55 am
by Jubatian
Just some notes.

I added the mode to the Wiki some time ago, I think it is roughly feature complete for a functional first iteration (maybe this will be the "final" by interface). There are many possibilities though which aren't reasonably possible to be added to the mode directly.

  • Sacrificing some horizontal coverage it is possible to add more sprites to be multiplexed. Currently M72 has 20 sprite slots, but nothing really prevents having more, especially if there is no need fo X mirroring capability. So if you have some specific idea demanding lots of sprites (like some more intense scrolling shooter), I could create a variant for it.
  • Fixed sprite height for a partition of sprites can further increase the multiplexing capability (most useful possibly to get more bullet sprites).
  • I used 2bpp sprites since I believe they are about the most optimal balance between colors & coverage. It is possible however to have 1bpp or 4bpp as well, or even 5 colors + transparency (one byte encodes 3 pixels, this case you get 6 states for a pixel: 6 x 6 x 6 = 216), or maybe 2 colors + transparency for a slightly larger coverage than 2bpp (one byte encoding 5 pixels, 3 states per pixel: 3 x 3 x 3 x 3 x 3 = 243).
  • If you were okay with a "thin screen", then even increasing resolution is possible, although it is tedious. But anything for a good game idea... The fill capability remains the same (so for example in theory it is possible to get for example 5 cycles per pixel 160 pixels width with the same sprite capabilities.
  • If you wanted a vertical scroller (or no scrolling at all), it would be possible to drop horizontal scrolling capability for further sprites (tedious, but for a good space shooter, why not?).
So if you have any particular idea with this mode or a variant of it, feel free to ask!

(Currently I am building an RPG engine based on it focusing on SD sourced game material)