FMV via Inlined Video Mode

[D3thAdd3r]

Full Motion Video used tastefully can add a lot to the story of a game in my opinion. From memory there has never been an Uzebox game that had complex cutscenes let alone animated video, because that type of video mode is worthless for actual gameplay(unless you are a fan of quick time events...or some Sega CD "games"). The kernel is gracefully setup for using any video mode, but by the same methods using more than 1 video mode would require a lot of restructuring and not be nearly as clean I fear. Obviously it would also require more flash space for the actual code.

This idea is not fancy at all, but I think it would work and allow any game in any video mode to insert video content that can be skipped. If nothing else you could have some cool well animated Uzebox logo at the intro. My idea is to simply create a loop using current video player code that continues until the video is done, and it does not let user code run at all until, but is rather inlined and totally separate from kernel code. It's nice to skip videos, so each frame this looping video function could check the padstate versus a bitfield specified as a function parameter. It could also end with a fade out or other effect as specified by another argument. I think this will be way cleaner and easier.

The mode 3/13 ram tiles method does provide better possible resolution, but the limitations require a lot of modifications on some items to limit unique tiles. I think the video method most likely has better temporal resolution, or frames per second, than the ram tiles method. It doesn't even seem to need much modification from the current mode 7 besides basic pad checking and returning the padstate that cancelled it(so you could implement FMV games with branches, maybe even ShadowGate). From my understanding this is entirely possible, thoughts?

[uze6666]

So you mean some sort of standalone executable blob with code and data the kernel delegates to and relinquish full control including sound and vsync? It's probably feasible. But I'm wondering about all the duplicate code that would go in there: duplicate sound, sync, SD, etc. I kinda like the idea thought of having an "add-on" mode for such use. I'll think a bit more about it, but there's nothing preventing two video modes side-by-side if they don't share the same RAM area/variables. A video player don't require much ram at all so it would be a good candidate. A compile switch could include the code and switch between mode dynamically with a SetVidemoMode(x) or something.

[D3thAdd3r]

So you mean some sort of standalone executable blob with code and data the kernel delegates to and relinquish full control including sound and vsync?

Precisely, though I didn't phrase it too elegantly now that I reread it. Basically run the scanline/HSYNC/VSYNC items, by pass make file settings and always use full screen, check standard pad, then take advantage of always known cycles to enter a precise wait loop.

I'll think a bit more about it, but there's nothing preventing two video modes side-by-side if they don't share the same RAM area/variables.

I don't know how much it takes on it's own, but you seem more confident than I anticipated that juggling 2 modes is not overly complicating the kernel. If that's better then it's simply better, however I don't think the blob idea would necessarily have to be as bad as it appears at first glance. I think, there should be a way that it takes 0 extra ram, in that you can pass the address of a suitably large buffer(like vram, or ram_tiles) to do the work in. Should be able to pass the functions to it in the C code, like ReadButtons(), and other items to help with duplicate code waste. It seems like the user program would only require 1 ugly line of code to run it.

The method you describe might be less wasteful of ram than my initial thought. Since it is trivial to let temporarily unused kernel bytes be variables for the gameplay and just be careful about it. Since every mode has some sort of vram, and running a movie is mutually exclusive to displaying anything but the movie, maybe those make files things you guys think up could to multiplex the big buffers.