Forums

Sega Master System / Mark III / Game Gear
SG-1000 / SC-3000 / SF-7000 / OMV
Home - Forums - Games - Scans - Maps - Cheats - Credits
Music - Videos - Development - Hacks - Translations - Homebrew

View topic - Fullscreen video playback on Sega Master System

Reply to topic Goto page 1, 2, 3  Next
Author Message
  • Joined: 14 Sep 2016
  • Posts: 71
  • Location: Lyon, France
Reply with quote
Fullscreen video playback on Sega Master System
Post Posted: Thu Sep 15, 2016 7:36 am
Hello, this is my first post here but I think I have something worth posting :)
I love the SMS and it's games, I had a SMS as a kid and even wrote a small private emulator for it few years ago.
Anyway, I recently thought about making a demo for it but since I'm not very good with graphics, I thought about trying to play video by encoding frames into tiles and tilemaps.

So, I started by writing a PC app to encode the video frames. Basically the encoder first tries to merge similar tiles between 2 keyframes, stopping when a quality level is reached.
Then it finds the optimal 16 color palette to encode all the tiles for a keyframe and finally it does the dithering and outputs a binary blob and an index to include in the ROM asm.
I have to say the encoding process is extremely memory and CPU heavy, a 20sec video takes 10GB of RAM and 2 hours to encode on my PC.

The Z80 decoder then unpacks the tiles and tilemaps as the video advances. Video is 12.5 fps by the way (no worse than many 50Hz PS1 videos eh :).
Since this process seems too slow to be done in a single VBlank, I use a form of double buffering to be able to use the 4 VSync of time to prepare the next video frame. Unfortunately it limits the quality to 207 tiles per video frame to fit 2 frames in the 16KB VRAM.

Here's the link: sfx.gligli.free.fr/smsdev/nggyu_v1.sms (made for 50Hz, should work in 60Hz but will play too fast) (also attached to this post).

The ROM seems to work on all emulators I tried, I have yet to try it on real hardware but it should be a matter of days.

Next, I will try to add PCM sound, but it seems like quite a hard task given I will have to interleave PCM playback code with video decoding.

PS: I wonder if any of you will recognise the video I chose ;)
nggyu_v1.zip (687.97 KB)

  View user's profile Send private message
  • Joined: 09 Apr 2013
  • Posts: 95
  • Location: Sydney Australia
Reply with quote
Post Posted: Thu Sep 15, 2016 11:50 am
Very nice! Happy to be subjected to that video when it's coming out of a master system ;-)
  View user's profile Send private message
  • Joined: 14 Sep 2016
  • Posts: 71
  • Location: Lyon, France
Reply with quote
Post Posted: Thu Sep 15, 2016 2:46 pm
Thanks!

I finally received the parts to build a 315-5235 based flash cart and I was able to try it on my own SMS2.
Unfortunately it seems like there's a problem with the VDP timings: I write to VRAM during VDP display phase and that doesn't seem to work on real hardware...
  View user's profile Send private message
  • Joined: 01 Jul 2015
  • Posts: 125
  • Location: Berlin
Reply with quote
Post Posted: Thu Sep 15, 2016 5:56 pm
A good way testing your program is Emulicious. It seems to be the most accurate emulator for the SMS right now.
Just be sure you turned on "Emulate VDP Constraints" at Options > Emulation > Master System.
  View user's profile Send private message
  • Joined: 05 Sep 2013
  • Posts: 1941
Reply with quote
Post Posted: Thu Sep 15, 2016 6:59 pm
gligli wrote
I write to VRAM during VDP display phase and that doesn't seem to work on real hardware...


You're probably doing it too fast. You can safely write to VRAM during display as long as there are at least 26 CPU cycles between each write.
  View user's profile Send private message Visit poster's website
  • Site Admin
  • Joined: 19 Oct 1999
  • Posts: 11875
  • Location: London
Reply with quote
Post Posted: Thu Sep 15, 2016 8:24 pm
It looks like you're running at 12.5fps in order to have time to fill your 207 tiles and a name table (using name table flipping to get your double-buffering). This seems like it's going to be very data intensive because you're uploading all the tiles you need every time - are they stored redundantly in the ROM or is that how the indexing works? I suspect some gains could be made in terms of quality or frame rate if you could instead make use of the tiles already in the VRAM for the next frame, to recycle their 32 bytes' data if it is useful. Presumably you can also trade off ROM size for quality by adding more tiles to the index for those frames where you have time left for more uploads.

For the VRAM speed thing, you probably need to have two functions to run in VBlank and out with the necessary delays added in, which will hurt your data upload rates. The PCM stuff will be tough too - interleaving the output will be hard work, but may sound acceptable provided you can avoid too much jitter, or even somehow optimise your data for the jittery playback (for example, sample your master wave at the exact time points you are hitting and encode the pre-anti-jittered data).
  View user's profile Send private message Visit poster's website
  • Joined: 14 Sep 2016
  • Posts: 71
  • Location: Lyon, France
Reply with quote
Post Posted: Thu Sep 15, 2016 9:00 pm
badsector> Yeah I was using Emulicious and tried this option when I saw the mess my rom displayed on my SMS2, and it did seem to reproduce the same glitches :)

sverx> Yep, I then made 2 different tile upload versions, one with 32 unrolled outi for VBlank and the other with a outi / djnz loop for display time.

Maxim> Yeah, I now struggle to even reach 12.5fps while acounting for VDP timing constraints but it's also a tradeoff between ROM size and motion quality.
Tiles are unique for all the frames between 2 keyframes in ROM. I think I have to let them be potentially duplicated in VRAM otherwise the double buffering wouldn't work anymore.
For sound, my main idea right now is to somehow use the scanline counter as an index into a per video frame sample buffer. That way I may skip samples depending on workload but jitter shouldn't be a problem.

Overall I'm having lots of fun coding and optimising for the Z80 with this project :)
  View user's profile Send private message
  • Site Admin
  • Joined: 19 Oct 1999
  • Posts: 11875
  • Location: London
Reply with quote
Post Posted: Thu Sep 15, 2016 10:31 pm
I think there is some scope to trade space for speed in the code, in particular using ix and iy is slow.

I'm a bit confused about the key frames, isn't the tile cache global? Or are you splitting at certain points (scene changes?) and then having data scoped to that sequence (and palette)? I'd have thought a global tile cache of 64K entries (2MB data) might do for the whole video, even with the palette changes.

What algorithm are you using to decide which tiles to discard? I always found it got a lot harder once it got to that sort of perceptual estimation problem.
  View user's profile Send private message Visit poster's website
  • Joined: 14 Sep 2016
  • Posts: 71
  • Location: Lyon, France
Reply with quote
Post Posted: Thu Sep 15, 2016 11:00 pm
Last edited by gligli on Thu Sep 15, 2016 11:44 pm; edited 1 time in total
Yay, it finally works on my SMS2 at full speed :D

Link: http://sfx.gligli.free.fr/smsdev/nggyu_v2.zip (also attached)

There's an additional (shorter) 4 mega version for those (like me) who have a 315-5235 based cart.
50Hz only for now, as there's not enough time to upload the tilemaps during VBlank in 60Hz...

Maxim> I was able to do some quite massive optimisations in v2 (loop unrolling, less ops, ...).
Yeah by keyframe I mean when the video has a major change, like a different camera angle. They last at most 20 to 30 frames and really are independent entities that contain tiles, a palette, and tilemaps for each frame.
Theoretically it would not be a bad idea to have a true global tile cache, but it would then take ages to encode and use an insane amount of RAM. This is because the encoding algorithm maintains something like a "similarity matrix" where all tiles combinations have a "similarity rating".
I compare the 64 pixels of two tiles using the sum of CIE94 color differences ( https://en.wikipedia.org/wiki/Color_difference ) and this is what the "similarity matrix" contains.
The encoder then just searches the best "similarity rating", blends the 2 corresponding tiles into one and repeats the process until a quality threshold is reached.

In any case, I'm not saying my approach is the best there is, I just thought about all that as I progressed.
nggyu_v2.zip (1021.18 KB)

  View user's profile Send private message
  • Joined: 01 Jan 2014
  • Posts: 294
Reply with quote
Post Posted: Thu Sep 15, 2016 11:16 pm
Awesome stuff!
  View user's profile Send private message
  • Site Admin
  • Joined: 19 Oct 1999
  • Posts: 11875
  • Location: London
Reply with quote
Post Posted: Fri Sep 16, 2016 2:06 pm
haroldoop made a graphics reduction demo ( http://www.smspower.org/forums/15214-RgbQuantSMSReduceTheTileCountOfYourImages ) using https://en.wikipedia.org/wiki/K-means_clustering to find similar tiles, but I suspect the algorithm to determine similarity is still flawed, and something like DCT transforms would help to group things more perceptually.
  View user's profile Send private message Visit poster's website
  • Joined: 14 Sep 2016
  • Posts: 71
  • Location: Lyon, France
Reply with quote
Post Posted: Fri Sep 16, 2016 3:51 pm
Nice, using kmeans to group tiles seems like a great idea!
I already heard about kmeans from my job and this could very well allow for a global tile cache while reducing encoding CPU and RAM use!
To compute CIE94 color differences, I have to convert color values from RGB to LAB color space. LAB seems to have the advantage that L, A and B seem to have the same importance regarding perception, so I think doing kmeans on LAB pixels will work great.

Off to code now :)
  View user's profile Send private message
  • Joined: 14 Sep 2016
  • Posts: 71
  • Location: Lyon, France
Reply with quote
Post Posted: Sat Sep 17, 2016 9:57 pm
So it turns out you were right about DCT being the best option!
I rewrote the tiling part of my encoder to use KMeans on weighted DCT coefficients and quality is much much better, especially in the backgrounds. It's a bit noisier tho but I'm really nitpicking given the media :)
Encoder RAM usage is back to something reasonable but encoding time more than doubled to about 5 hours to encode the rickroll video!

Anyway, I'm now releasing the player source code and the encoder, for those who would try to encode their own videos (attached to this post or http://sfx.gligli.free.fr/smsdev/sms_video_player_v3.zip ).
It also includes the rickroll ROM and data files too as an example and also to compare quality with v2.

By the way, as I now upload the tilemaps during VBlank, I think it might be possible to not double buffer those, just the tiles. This would theoretically up the "max tiles per frame" limit to 231 but I didn't try to code it yet.

  View user's profile Send private message
  • Joined: 11 Sep 2016
  • Posts: 24
Reply with quote
Post Posted: Sun Sep 18, 2016 1:19 pm
This is full-on amazing. It's a technical marvel how you've managed to make a god damn video compression program to make videos play on the Master System!!

Now all we need to do is add a PSG rendition of Never Gonna Give You Up and we've got the world's greatest way to get Rick Rolled!
  View user's profile Send private message
  • Site Admin
  • Joined: 19 Oct 1999
  • Posts: 11875
  • Location: London
Reply with quote
Post Posted: Sun Sep 18, 2016 1:36 pm
Let's see what it does for Bad Apple too... Anyone got a bunch of CPUs to throw at it? I have a few 24 core Sandy Bridge boxes to play with at work...

I might also see what I can do with pcmenc running interleaved.

It's worth mentioning that this is still running at quite a high data rate (although that can be traded for quality), so you're not going to get very long videos in here.
  View user's profile Send private message Visit poster's website
  • Joined: 14 Sep 2016
  • Posts: 71
  • Location: Lyon, France
Reply with quote
Post Posted: Sun Sep 18, 2016 3:36 pm
JomasterII> Hehe thank you! Probably not the most useful thing I ever coded but definitely a lot of fun to make :)

Maxim> I'm currently trying other implementations of KMeans as it is the bottleneck speed wise. Seems like the library I used is slow compared to others.
If I find a really fast implementation, getting rid of keyframes will greatly improve the ROM size to quality ratio.
  View user's profile Send private message
  • Joined: 16 May 2002
  • Posts: 1088
  • Location: italy
Reply with quote
Post Posted: Sun Sep 18, 2016 3:40 pm
I suspect a different approach would be better for Bad Apple, since it's basically a B/W video (with few gray exceptions which can be ignored for simplicity). The result at hand is impressive, but aiming for monochromaticity might lead to specific optimisations, it's a waste to use a good color "codec" for a B/W video.

(note: this post is a reply to Maxim, of course. gligli posted while I was typing)
  View user's profile Send private message Visit poster's website
  • Site Admin
  • Joined: 19 Oct 1999
  • Posts: 11875
  • Location: London
Reply with quote
Post Posted: Sun Sep 18, 2016 5:17 pm
Yes, I know it will go better (and at a higher frame rate) with some bespoke handling, but it's a recurring thing and maybe the lack of detail would go well here. If nothing else, going purely 1bpp would speed up the VRAM writes and save a bunch of ROM space.
  View user's profile Send private message Visit poster's website
  • Joined: 01 May 2011
  • Posts: 371
Reply with quote
Post Posted: Sun Sep 18, 2016 6:25 pm
This is really impressive. Would it be possible to go above 1MB for an SMS ROM with a custom mapper?
  View user's profile Send private message
  • Site Admin
  • Joined: 19 Oct 1999
  • Posts: 11875
  • Location: London
Reply with quote
Post Posted: Sun Sep 18, 2016 6:49 pm
Last edited by Maxim on Mon Sep 19, 2016 5:14 pm; edited 1 time in total
The standard mapper scheme tops out at 4MB (256×16KB) but with a custom mapper there would be no limit. Real hardware is more limited, the Everdrive has a 1MB limit and the available mapper chips don't go above 512KB I think.
  View user's profile Send private message Visit poster's website
  • Joined: 01 May 2011
  • Posts: 371
Reply with quote
Post Posted: Sun Sep 18, 2016 7:00 pm
Thanks for your reply. I believe that TecToy 1MB SMS games use the same mapper as 1MB GG games, so I guess that's the limit for available hardware.

Is the Everdrive 1MB limit due to software or hardware? An increase to 4MB would be quite useful for this.
  View user's profile Send private message
  • Joined: 14 Sep 2016
  • Posts: 71
  • Location: Lyon, France
Reply with quote
Post Posted: Sun Sep 18, 2016 7:07 pm
Before reverting to tricky hardware mods, there's still room for improvement in ROM size efficiency with my encoder I think.

By the way, I don't think bad apple will encode nicely with my encoder, as it merges similar tiles by blending them, the resulting tiles won't be 1bpp anymore.
  View user's profile Send private message
  • Site Admin
  • Joined: 19 Oct 1999
  • Posts: 11875
  • Location: London
Reply with quote
Post Posted: Sun Sep 18, 2016 8:30 pm
Everdrive works by copying data from the SD card to some random access memory, which is 1MB. So it's a hardware limit. In theory you can access the SD card from the game, and then you may be able to get a few GB, but the data rate would suffer.
  View user's profile Send private message Visit poster's website
  • Joined: 05 Sep 2013
  • Posts: 1941
Reply with quote
Post Posted: Sun Sep 18, 2016 8:35 pm
As for Bad Apple, it's totally doable in a 8Mb ROM.
I say that because approx one year ago haroldoop and I almost made a 1bpp (gray done with dithering) pixel-perfect (lossless!) GameGear version that would fit into a single megabyte.
Unfortunately we lost interest in the process, and we stopped when we were probably almost there.
There's a public GitHub repository of haroldoop's code. I might search in my old e-mail if someone needs more details (or we could ask haroldoop, who probably remembers much more than I can...)
  View user's profile Send private message Visit poster's website
  • Joined: 01 Jan 2014
  • Posts: 294
Reply with quote
Post Posted: Sun Sep 18, 2016 10:44 pm
@sverx

Sounds like fun. What was the frame rate?
  View user's profile Send private message
  • Joined: 01 May 2011
  • Posts: 371
Reply with quote
Post Posted: Sun Sep 18, 2016 10:53 pm
I tried to encode a simple video, but I get an access violation on "2b - Interframe tiling". The rest of the processes seem to work ok.
  View user's profile Send private message
  • Joined: 14 Sep 2016
  • Posts: 71
  • Location: Lyon, France
Reply with quote
Post Posted: Sun Sep 18, 2016 11:20 pm
Ah this is odd, this process works exclusively on memory, no file I/O or other stuff like that.
I have a feeling this is related to keyframes, maybe something I didn't think of like 2 consecutive keyframes or on the last frame...

In any case, if you want, you can send me the input pics and the settings you used so that I can try to reproduce the problem.
  View user's profile Send private message
  • Joined: 01 May 2011
  • Posts: 371
Reply with quote
Post Posted: Sun Sep 18, 2016 11:39 pm
Maybe I've done something wrong with the keyframe. I just created a file and named it test0000.kf, putting it next to the first picture.
tiler.jpg (185.26 KB)
tiler.jpg

  View user's profile Send private message
  • Joined: 05 Sep 2013
  • Posts: 1941
Reply with quote
Post Posted: Mon Sep 19, 2016 7:29 am
psidum wrote
Sounds like fun. What was the frame rate?


30 fps. "6570 frames at 30 fps" according to my records.
  View user's profile Send private message Visit poster's website
  • Joined: 14 Sep 2016
  • Posts: 71
  • Location: Lyon, France
Reply with quote
Post Posted: Mon Sep 19, 2016 9:05 am
BKK wrote
Maybe I've done something wrong with the keyframe. I just created a file and named it test0000.kf, putting it next to the first picture.

I could reproduce the problem with a simple 6 frame video. Actually, it has nothing to do with keyframes, and there's 2 problems in one.
First problem is that on pictures with little visual noise, the intraframe tiler algorithm just wrongly reduces everything to 1 tile per frame.
Second is the interframe algorithm crashes when there's such a small amount of remaining tiles.

I've since made major changes to those algorithms to improve speed and quality but I don't have the improved version with me atm, I'll try it when I'm back home.
  View user's profile Send private message
  • Joined: 14 Sep 2016
  • Posts: 71
  • Location: Lyon, France
Reply with quote
Post Posted: Mon Sep 19, 2016 6:55 pm
v4 is up! : http://sfx.gligli.free.fr/smsdev/sms_video_player_v4.zip (also attached).
What's new:
  • Improved video quality.
  • Greatly reduced encoding time by using an external K-Means processor (yakmo: http://www.tkl.iis.u-tokyo.ac.jp/~ynaga/yakmo/ ).
  • Fixed some bugs with plain colors noiseless videos. If you still get frames wrongly reduced to 1 tile, set "KMeans restarts" to 1.
  • No more need to create a .kf file for the first frame.
  • New longer demo video from Sonic CD :)

With the encoder being faster, I only added 1 keyframe every 100 frames for the demo video, which allowed me to drop the average tiles per frame to 20 while still maintaining acceptable quality.
Now the problem is that per-frame tile index and tilemap are taking a lot of space compared to tiles. APlib could help for that but then there won't be any resources left for sound once it's implemented I think.

  View user's profile Send private message
  • Joined: 01 May 2011
  • Posts: 371
Reply with quote
Post Posted: Mon Sep 19, 2016 7:52 pm
Excellent, all working for me now, and I even managed to compile it (thanks Maxim). Now to make a more complex video.
  View user's profile Send private message
  • Site Admin
  • Joined: 19 Oct 1999
  • Posts: 11875
  • Location: London
Reply with quote
Post Posted: Mon Sep 19, 2016 8:21 pm
APLib won't help much, it operates badly on this sort of data and needs bigger data to start getting some gains. Possibly Huffman coding might help, but that's still not quick.

Audio is quite resource intensive. My pcmenc 8kHz player leaves 387 cycles per sample unused, so that's 13% CPU, more for better quality.
  View user's profile Send private message Visit poster's website
  • Joined: 14 Sep 2016
  • Posts: 71
  • Location: Lyon, France
Reply with quote
Post Posted: Mon Sep 19, 2016 8:35 pm
Damn, that '76 Z80 is slow! :)
Not sure exactly how much CPU time I have left, but probably not more than 25%.
Maybe plain 4bit PCM may fit tho, or pcmenc-alike with only 2 PSG channels and no fancy compression.
Not an easy problem, that's for sure!

Edit: Is it 13% left or 13% used?
  View user's profile Send private message
  • Joined: 25 Feb 2006
  • Posts: 456
  • Location: Belo Horizonte, MG, Brazil
Reply with quote
Post Posted: Tue Sep 20, 2016 12:46 am
It's nice to see some nice video encoding scheme running on the good old SMS! :)

BTW, if anyone is curious about the experiments that sverx and me have made for encoding "Bad Apple", the repository is here:
https://github.com/haroldo-ok/bad-apple-sms

The branches of the repost also have some additional experiments with non-pixel-perfect encoding and bit packing schemes:
https://github.com/haroldo-ok/bad-apple-sms/branches

Please, keep in mind that at this point we were only experimenting with the encoding to see how tightly the video could be packed; the decoder simply hasn't been written, yet.
  View user's profile Send private message Visit poster's website
  • Site Admin
  • Joined: 19 Oct 1999
  • Posts: 11875
  • Location: London
Reply with quote
Post Posted: Tue Sep 20, 2016 6:29 am
13% used for 8kHz. It's pretty much just a 4 bit PCM player, but it round-robins the channels to get a better SNR overall. You really need a higher sampling rate for non speech though.
  View user's profile Send private message Visit poster's website
  • Site Admin
  • Joined: 19 Oct 1999
  • Posts: 11875
  • Location: London
Reply with quote
Post Posted: Tue Sep 20, 2016 9:22 am
The ROM headers are conflicting with the data, giving warnings at compile time. In the v4 demo it corrupts a tile near the start, which is used in a couple of places on the screen. The fix is probably to compile to a 16KB player stub and manually append data, or to make the data be generated as asm includes with labels, and let WLA DX do the layout. The latter would be best for getting the data packed more efficiently.
  View user's profile Send private message Visit poster's website
  • Joined: 14 Sep 2016
  • Posts: 71
  • Location: Lyon, France
Reply with quote
Post Posted: Tue Sep 20, 2016 11:49 am
Oh cool, 13% used sounds a lot better!

Ah yeah, saw that there was something wrong when I tried it on real hardware, I even had to add the sdsc tag at the end of the file for it to override video data as a hackfix but then forgot about it...

The video data tile indices depend on data.bin being at a fixed address so I guess I'll have to compile a 16KB ROM with only the code and index.bin and then append data.bin to it.

How would it pack it better? With more work the gap between code/index.bin and data.bin could be avoided but that's about it I think.
  View user's profile Send private message
  • Joined: 05 Sep 2013
  • Posts: 1941
Reply with quote
Post Posted: Tue Sep 20, 2016 12:19 pm
Since on a NTSC (60 Hz) SMS there are 262 lines and 60 fps, wouldn't be easier to have a (262x60=) 15720 Hz PCM simply using line IRQ?
(ok, line IRQ IIRC doesn't get fired during vblank...)
  View user's profile Send private message Visit poster's website
  • Site Admin
  • Joined: 19 Oct 1999
  • Posts: 11875
  • Location: London
Reply with quote
Post Posted: Tue Sep 20, 2016 3:16 pm
A line IRQ costs extra time for the call and return, and probably the need to push/pop (or switch) a bunch of registers. That can eat a large percentage of your CPU time before you even get any work done. The alternative isn't much better though.

WLA DX could in theory pack the data tile by tile from the start of ROM, around anything else you have there, and then generate the indexes automatically. It's probably quite hard work to do that though, and more efficient to improve page locality to reduce the page register writes to a minimum.
  View user's profile Send private message Visit poster's website
  • Joined: 01 May 2011
  • Posts: 371
Reply with quote
Post Posted: Tue Sep 20, 2016 3:42 pm
Intro of the 3D colour version of Bad Apple. Runs slightly fast as converted from 30fps to 12fps (same issue occurs with 24fps movies on PAL TV channels).

Keyframes: 4
Frame Count: 160
Average tiles per frame: 150
KMeans restarts: 8

  View user's profile Send private message
  • Site Admin
  • Joined: 19 Oct 1999
  • Posts: 11875
  • Location: London
Reply with quote
Post Posted: Tue Sep 20, 2016 5:43 pm
Last edited by Maxim on Wed Sep 21, 2016 7:26 am; edited 2 times in total
One thing that seems a bit distracting (?) is that static areas tend to flicker a lot with this algorithm, because there's no intra inter-frame optimisation - as it's actually precluded by the double-buffering that goes on. If there was a way to re-use tiles from the previous frame, it could save a lot of VDP bandwidth, but even without that having a preference to re-use the existing tile (and upload it to VRAM again) could reduce the noise.
  View user's profile Send private message Visit poster's website
  • Joined: 14 Sep 2016
  • Posts: 71
  • Location: Lyon, France
Reply with quote
Post Posted: Tue Sep 20, 2016 6:04 pm
There's both intra and inter passes but the thing that makes it noisy is that all the tile merging happens with no knowledge of where the tile will be on the screen, ie the algorithms just see a bunch of unsorted tiles and try to merge the similar ones.
I'm not sure it's really possible to take into account x/y/frameIndex coordinates as there's potentially a lot more than one per tile. Maybe an average on each coordinate could work, but it will certainely reduce the algorithm ability to merge similar tiles that are far from each other.
  View user's profile Send private message
  • Joined: 01 Jan 2014
  • Posts: 294
Reply with quote
Post Posted: Wed Sep 21, 2016 1:19 am
Last edited by psidum on Thu Sep 22, 2016 12:40 am; edited 1 time in total
Working on similar things. I have been using the following approach to remove need for framebuffer. I don’t think its viable with what you are doing due to noise but it might be of interest.

It’s a fill routine based around two fill methods;

A rectangular fill to fill areas of the same nametable updates (example filling white in the bad apple colour video).

A flood type fill that, from the initial address iterates down rows filling column entries based on a run length flag.

Below is code used to write frames and attached is an example of it in action. It is very work in progress for example you can get a speed improvement by limiting update to 255, using djnz on b to speed up loop and c to out directly from non a registers. I have been holding off as trying to think of a better overall approach, suggestions are welcome :)

Attached is example of code in action, ROM size is not proportionate to actual size of animation.

EDIT: slipped code example in to zip.
MIR Example.zip (16.35 KB)

  View user's profile Send private message
  • Joined: 05 Sep 2013
  • Posts: 1941
Reply with quote
Post Posted: Wed Sep 21, 2016 11:47 am
@psidum: didn't you use that for Be No Sqr demo?
  View user's profile Send private message Visit poster's website
  • Joined: 01 Jan 2014
  • Posts: 294
Reply with quote
Post Posted: Wed Sep 21, 2016 12:49 pm
Animation is the same but technique is different.

I was running out of time for demo so the tile and nametable streaming code was quite bad. I stored vram address / nametable value pairs for every update on nametable :S I needed to do this as it was not viable to update a full nametable at 50 fps.

Over last few months I have been working on some libraries and tools to help with next project. This particular problem turns out to be many problems, best way to store / update frames, best way to store tiles, best way to stream tiles, how to compress tiles on tool side (broad tile compression vs inter-frame). I have been lazily tackling each problem in isolation, I hacked together some of the stuff to get that rom going.

Honestly its been doing my head in so this thread has been nice.
  View user's profile Send private message
  • Joined: 14 Sep 2016
  • Posts: 71
  • Location: Lyon, France
Reply with quote
Post Posted: Wed Sep 21, 2016 6:42 pm
Cool, I like the way you use sp as a pointer to your data, must be really efficient!

I have an very raw idea for 1bit animation but I'm not sure it's even doable:
Basically, each tile would be a repeated pattern of 8 / N lines and then I would render the frame using N name tables switched sequentially every 8 / N scanlines by a line int.
Eg with N = 8 and some tile vertical mirroring trickery, you could only have 128 hardcoded tiles and encode any frame without max tiles contraints.

For my own case, I don't think i'll be able to improve quality and efficiency much if I don't do a good rework of my encoder to at least try to use tile mirroring, a global tile cache, and limit VRAM updates when the image doesn't change much.
  View user's profile Send private message
  • Joined: 01 Jan 2014
  • Posts: 294
Reply with quote
Post Posted: Thu Sep 22, 2016 12:34 am
That sounds intense, you would lose a lot of cpu grunt to the flipping. I don't know if you noticed but on hardware the nameable changes happen instantly mid scanline.

The legacy mode graphics II (i think its this one) allows a full screen of unique monochrome graphics in a chunky format on vram so its an easier path if you are looking for that type of thing but it also has its caveats.

I did extract and run the first 8 frames using the above technique (first version rick roll) and the total size came back 6194 byes which is 50% however i do not believe it could render the frames in time even in pal. For my type of animation 100 name tables are reduced from 76800 bytes to 9914 bytes which is pretty massive and turns out to be way faster.
  View user's profile Send private message
  • Joined: 01 May 2011
  • Posts: 371
Reply with quote
Post Posted: Fri Sep 23, 2016 7:37 pm
"Plug me into a Sega" commercial.

Keyframes: 5
Frame Count: 354
Average tiles per frame: 50
KMeans restarts: 4

  View user's profile Send private message
  • Joined: 01 May 2011
  • Posts: 371
Reply with quote
Post Posted: Sat Sep 24, 2016 9:49 am
Sega: The Challenge Will Always Be There commercial.

Keyframes: 15
Frame Count: 371
Average tiles per frame: 50
KMeans restarts: 8
Challenge Ad.rar (680.83 KB)

  View user's profile Send private message
Reply to topic Goto page 1, 2, 3  Next



Back to the top of this page

Back to SMS Power!