Video mode experiments

Topics related to the API, programming discussions & questions, coding tips, bugs, etc. should go here.
Post Reply
CunningFellow
Posts: 1445
Joined: Mon Feb 11, 2013 8:08 am
Location: Brisbane, Australia

Video mode experiments

Post by CunningFellow »

Probably mostly a question aimed at Jubatian, but anyone else working on something or with ideas can chime in.

I am wondering what video mode ideas are being worked on or thought about by people.

From me there is the

RLE mode that is 5 clock per pixel and has a demo already.
4 Bpp 9 clock per pixel (160 pixel wide) with a weird fixed palette.
Higher resolution FMV player to replace Mode7. I'd like to hit 288x224 if possible - even if flash usage is extreme.

Also what ideas never got completed in the past ?

I know there was a doom/wolfenstien mode that never flew as well as one that was intended for a 1st person car racing game.
User avatar
Jubatian
Posts: 1560
Joined: Thu Oct 01, 2015 9:44 pm
Location: Hungary
Contact:

Re: Video mode experiments

Post by Jubatian »

Could be interesting indeed to collect some of these ideas!
CunningFellow wrote: Sat Jan 26, 2019 11:43 pmRLE mode that is 5 clock per pixel and has a demo already.
Isn't the video mode itself mostly complete at this point, by the way? I see you are pushing towards vector graphics and 3D, the demos look pretty solid, but I could imagine those aspects more or less involving further layers over the video mode itself.
CunningFellow wrote: Sat Jan 26, 2019 11:43 pm4 Bpp 9 clock per pixel (160 pixel wide) with a weird fixed palette.
I have a never finished mode which could be somewhat similar to the idea. It is based on Mode 72, but double-scanned to get big fat square pixels, the two HBlanks for one practical output line used to add sprites. If completed, it would be something not unlike some of the fantasy consoles around (Pico-8 or Neko8), and like with Mode 72, a great advantage would be relatively lots of free RAM (No RAM tiles).

The Wolfenstien mode by Jhhoward is actually quite simple in its core, maybe there is even some source up there in the thread, the scanline core is definitely posted somewhere. It wouldn't be difficult to reproduce it, it just demands someone with a creative mind and interest to realize a game on it.

Mode 72 also has a hidden potential: An Outrun-like racing game is possible with it. You can control each scanline in this mode, the background (unlike RAM tile modes, even mine including parallax scrolling) is completely independent of the sprites, so you can realize the twisting 3D road effect. So there is also that for a genre not yet explored.

My new square kernel has potential beyond the video mode it currently has: it could be a useful framework for building up Mode 2 alikes with its audio solution, using only 202 bytes compared to the current kernel's hefty RAM consumption in VSync mixer mode. It wouldn't be very difficult either to add more audio channels for such a mode where the added RAM and processing cost of them is affordable (the current 3 channel audio engine is devised especially to accompany the current video mode which is a RAM tiled mode, but one which takes all the Hsync time, so inline mixing is impossible).

In the future I might release some more modes built on this base, but first I would like to finish with the current task at hand as I would like to have something for my RPG ideas.

FMV player... 5 cycles per pixel (288x224)... Unless 2bpp was OK, I feel like this was pretty much impossible due to the lack of SPI bandwidth.

Ideas from Mode 52 could possibly be used, though, most notably to create a multicolor mode (2bpp with each 8x8 tile block having its own palette). Such a video player was actually pulled off on a C64 + REU (action begins around 7:30), using the VIC's Multicolor mode, the principle here would be about the same. On VBlank, you stream in the attributes (palette for each 8x8 block) for the entire screen, then during display, you stream the 2bpp image.

So for now I have about these for the Uzebox.

I cooked up a quite neat NES-like video mode for an ARM STM32G0, but for the Uzebox, at least at an acceptable horizontal resolution, this seems impossible. The core concept would be having a 2bpp background with 4bpp RAM tiles, the 2bpp background being a multicolor mode (so for sprites only 12 colours would be available as the bottom 4 would vary depending on which background tile the RAM tile copies, that's also something seemingly impossible on the Uzebox, to combine palettes in this manner during display). Maybe an ordinary 2bpp tiled background combined with 4bpp RAM tiles for a flexibility on sprites could be possible.
CunningFellow
Posts: 1445
Joined: Mon Feb 11, 2013 8:08 am
Location: Brisbane, Australia

Re: Video mode experiments

Post by CunningFellow »

Jubatian wrote: Sun Jan 27, 2019 9:55 am Could be interesting indeed to collect some of these ideas!
CunningFellow wrote: Sat Jan 26, 2019 11:43 pmRLE mode that is 5 clock per pixel and has a demo already.
Isn't the video mode itself mostly complete at this point, by the way? I see you are pushing towards vector graphics and 3D, the demos look pretty solid, but I could imagine those aspects more or less involving further layers over the video mode itself.
The video mode is functional. I want to convert to ASM and optimize the routines that add lines to the off screen linked list. It's not too difficult a task, I just want to know I will have a clear block of time I can think without something causing me to crash.
Jubatian wrote: Sun Jan 27, 2019 9:55 am
CunningFellow wrote: Sat Jan 26, 2019 11:43 pm4 Bpp 9 clock per pixel (160 pixel wide) with a weird fixed palette.
I have a never finished mode which could be somewhat similar to the idea. It is based on Mode 72, but double-scanned to get big fat square pixels, the two HBlanks for one practical output line used to add sprites. If completed, it would be something not unlike some of the fantasy consoles around (Pico-8 or Neko8), and like with Mode 72, a great advantage would be relatively lots of free RAM (No RAM tiles).
What I was looking at was something that could look like Amstrad CPC mode 0. 160x200x4Bpp. I'll look at that WIP a bit closer to see if it will work.
Jubatian wrote: Sun Jan 27, 2019 9:55 am FMV player... 5 cycles per pixel (288x224)... Unless 2bpp was OK, I feel like this was pretty much impossible due to the lack of SPI bandwidth.
The idea is to do some form of lossy video compression. If you can get >= 4:1 compression then the SD card bandwidth is OK.

I started doing something with this idea and something like JPG but for that idea I ran out of flash space. Just recently I saw a project and then spoke to the author that was using something like LZ77

https://rv6502.ca/post/2018/01/22/bad-d ... n-arduino/

Adding an LZ like dictionary to my previous efforts could rescue that video mode. I'm going to play with it some time soon.

Maybe the other thing that might be a nice idea is to try compile all the ideas used in video modes so far. What do people think of that idea?
rv6502
Posts: 80
Joined: Mon Feb 11, 2019 4:27 am

Re: Video mode experiments

Post by rv6502 »

There's a few issues.

Streaming LZ77 requires 256 bytes for the circular buffer + 1 byte index into that buffer.

In my Bad Apple video player I use 2x separate LZ77 streams (514 bytes) as compressing the motion command stream and the video content stream separately gave much better compression.

And the whole player is almost 50KB of code.
Not very practical for Uzebox.

A color codec would require a different approach and possibly even more ROM used by code.

To be usable in a game the video player code for cut-scenes would need to be swapped with the game in and out unless the game is just a simple quick reaction game.
CunningFellow
Posts: 1445
Joined: Mon Feb 11, 2013 8:08 am
Location: Brisbane, Australia

Re: Video mode experiments

Post by CunningFellow »

Welcome to the forum RV6502
rv6502 wrote: Tue Apr 02, 2019 3:48 am Streaming LZ77 requires 256 bytes for the circular buffer + 1 byte index into that buffer.

In my Bad Apple video player I use 2x separate LZ77 streams (514 bytes) as compressing the motion command stream and the video content stream separately gave much better compression.

And the whole player is almost 50KB of code.
Not very practical for Uzebox.

A color codec would require a different approach and possibly even more ROM used by code.
Most Uzebox games dedicate >2K to video modes. For something that is primarily a video player using 90% of the flash space for the video decoder would be OK as well.
rv6502 wrote: Tue Apr 02, 2019 3:48 am To be usable in a game the video player code for cut-scenes would need to be swapped with the game in and out unless the game is just a simple quick reaction game.
All I can say is "Lead on, adventurer."
User avatar
Jubatian
Posts: 1560
Joined: Thu Oct 01, 2015 9:44 pm
Location: Hungary
Contact:

Re: Video mode experiments

Post by Jubatian »

rv6502 wrote: Tue Apr 02, 2019 3:48 amIn my Bad Apple video player I use 2x separate LZ77 streams (514 bytes) as compressing the motion command stream and the video content stream separately gave much better compression.
That's quite a nifty player there on that Mega! :) Glad to welcome you on the forum!

Regarding me things are a bit at hiatus at the moment partially due to life stuff (still not entirely settled after my relocation), other part a little bit due to that I am primarily a graphics artist, and the Uzebox is just too tight for all the pixels I want to cram into it! Occasionally I am even toying with an idea for a pixel art comic which could run on real device, but it just doesn't work if I had to fix most of my assets up front for the ROM.

Reflashing ROM during the game is just not a very great idea, this popped up several times already. Used with extreme consideration it could do, but the lifetime of the device is limited (maybe even more due to the overclocking if the Flash is actually the primary bottleneck why the AVRs can not officially be clocked higher). The current bootloader actually has support for reflashing (the game can call it requesting loading a different game, which it does after 5sec safety timeout).
Post Reply