http://www.youtube.com/watch?v=rnKlTN8aFJU
kp64.my3gb.com/aimForTheTop.zip
kp64.my3gb.com/aimForTheTop.zip
Feel like sharing any details about what exactly I'm looking at and how it was done? It seems interesting.
Khaz wrote:
Feel like sharing any details about what exactly I'm looking at and how it was done? It seems interesting.
The results are pretty cool but the program is simple and uninteresting.
I will try to explain it the better I can, but writing explanations in english
is not my speciality, so excuse me if I write something that does not make any sense.
The program transfers a 160x144 4bpp image to the VRAM using DMA each VBLANK period .... and thats it.
I wrote a BMP to SNES batch converter and also a script to auto generate the includes of all the pictures in the code.
With ffmpeg (I should start using avconv) and Imagemagick, I can extract frames from videos , resize , indexing , crop , etc...
I have scripts that do the mayority of the process.
We do have people here who speak fluent Spanish, so if you want to provide an explanation in native Spanish, please do so! :-)
Is there any compression involved ? Still looks nice, the 4bpp conversion is really well done (we can hardly tell there is only 15 used colors in the video).
Stef wrote:
Is there any compression involved ?
No , there is not compression.
Stef wrote:
Still looks nice, the 4bpp conversion is really well done (we can hardly tell there is only 15 used colors in the video)
Imagemagick applies Riemersma's dithering to the images by default.
Each frame has his own 16 colors palette.
Also, the video itself looks pretty good at 16 colors.
I made this before, using just one shared palette for all the frames:
http://www.mediafire.com/download/vk1jp ... 282%29.sfc
As you can see , the results are uglier
Well the ImageMagick result is quite impressive, i used to use it a long time ago...
I don't remember if it support both color space reduction and color reduction *at same time*.
For instance from a 24 RGB image, can you convert easily to 16 colors in RGB555 ? and also control the dithering (checkboard or diffusion) ?
I don't remember if it support both color space reduction and color reduction *at same time*.
For instance from a 24 RGB image, can you convert easily to 16 colors in RGB555 ? and also control the dithering (checkboard or diffusion) ?
Quote:
For instance from a 24 RGB image, can you convert easily to 16 colors in RGB555 ? and also control the dithering (checkboard or diffusion) ?
ImageMagick let you control the dithering and reduce colors at the same time.
http://www.imagemagick.org/Usage/quantize/
My program converts images that are already indexed (16 or 256 colors).
SDL converts the images to 8 RGB , then my program converts the 8 RGB palette to 5 BGR.
I wrote the conversion program like 2 or 3 years ago.
This is a part of the function that converts the palette( pls dont bully):
Code:
#define SDL_FULLCOLOR 255 //<- MAX COLOR VALUE
#define SNES_FULLCOLOR 31 //<- MAX COLOR VALUE
float color_average = (float)SNES_FULLCOLOR/(float)SDL_FULLCOLOR ;
for(i= 0; i < img->format->palette->ncolors ; i++)
{
#ifdef DEBUG
printf("Translating color number %d \n",i);
#endif
SNES_color_buffer= 0;
SNES_color_component= 0;
//get red
SNES_color_component= ((double)(img->format->palette->colors+i)->r*color_average);
SNES_color_buffer= SNES_color_buffer | SNES_color_component;
//get green
SNES_color_component= ((double)(img->format->palette->colors+i)->g*color_average);
SNES_color_buffer= SNES_color_buffer | (SNES_color_component << 5);
//get blue
SNES_color_component= ((double)(img->format->palette->colors+i)->b*color_average);
SNES_color_buffer= SNES_color_buffer | (SNES_color_component << 10);
#ifdef DEBUG
printf("SNES BGR color: %x \n",SNES_color_buffer);
#endif
/*MORE STUFF HERE*/
}
#define SNES_FULLCOLOR 31 //<- MAX COLOR VALUE
float color_average = (float)SNES_FULLCOLOR/(float)SDL_FULLCOLOR ;
for(i= 0; i < img->format->palette->ncolors ; i++)
{
#ifdef DEBUG
printf("Translating color number %d \n",i);
#endif
SNES_color_buffer= 0;
SNES_color_component= 0;
//get red
SNES_color_component= ((double)(img->format->palette->colors+i)->r*color_average);
SNES_color_buffer= SNES_color_buffer | SNES_color_component;
//get green
SNES_color_component= ((double)(img->format->palette->colors+i)->g*color_average);
SNES_color_buffer= SNES_color_buffer | (SNES_color_component << 5);
//get blue
SNES_color_component= ((double)(img->format->palette->colors+i)->b*color_average);
SNES_color_buffer= SNES_color_buffer | (SNES_color_component << 10);
#ifdef DEBUG
printf("SNES BGR color: %x \n",SNES_color_buffer);
#endif
/*MORE STUFF HERE*/
}
The program uses SDL and SDL_Surfaces.
With SDL, you don't need to write code to support diferent image formats, because SDL itself does all the work for you.
Also, SDL_Surface structures are pretty simple and easy to work with.
If you're sharing your own version, that's cool. Always nice to see others' code.
But if you're demonstrating the technique, we've already done this before. We've done it at 2bpp, 4bpp, 8bpp at 15fps, 20fps, 30fps; in lores/progressive and in hires/interlace.
The problem is that it eats ROM like crazy. 160x144x4bpp@15fps will eat 168.5KB/s, giving you 24 seconds of video for a full ROM. And said ROM won't have a game to go with it. So the technique is nearly worthless for stock hardware.
You can double this by using the S-DD1 or SPC7110 for real-time decompression (and also expand your ROM to 8MB/hardware, or 256MB/theoretical). smkdan was able to run the 2-minute Lunar: SSS opening video in a 64MB S-DD1 ROM. But even that's not really practical.
Hence why MSU1 was made: to give you tons of ROM storage space for video.
> Is there any compression involved ?
Even with the SuperFX or SA-1, the SNES doesn't have the horsepower for real-time decompression of video. Not even simple RLE stuff.
But if you're demonstrating the technique, we've already done this before. We've done it at 2bpp, 4bpp, 8bpp at 15fps, 20fps, 30fps; in lores/progressive and in hires/interlace.
The problem is that it eats ROM like crazy. 160x144x4bpp@15fps will eat 168.5KB/s, giving you 24 seconds of video for a full ROM. And said ROM won't have a game to go with it. So the technique is nearly worthless for stock hardware.
You can double this by using the S-DD1 or SPC7110 for real-time decompression (and also expand your ROM to 8MB/hardware, or 256MB/theoretical). smkdan was able to run the 2-minute Lunar: SSS opening video in a 64MB S-DD1 ROM. But even that's not really practical.
Hence why MSU1 was made: to give you tons of ROM storage space for video.
> Is there any compression involved ?
Even with the SuperFX or SA-1, the SNES doesn't have the horsepower for real-time decompression of video. Not even simple RLE stuff.
byuu wrote:
Hence why MSU1 was made: to give you tons of ROM storage space for video.
Hey byuu, I thought you might appreciate this.
This looks really good, would there be a chance of overlapping BG layers to get 31 colors, or is that too much data to DMA each frame?
byuu wrote:
Even with the SuperFX or SA-1, the SNES doesn't have the horsepower for real-time decompression of video. Not even simple RLE stuff.
I guess it depends from resolution and codec, the Mega CD which use a 12 Mhz 68000 is able to decode cinepak video with almost fullscreen and decent frame rate (15 FPS). The Megadrive even had the Sonic 3D blast intro video which is also compressed.
Maybe with a very simple and adapted codec (and resolution) you can get something working on a stock SNES.
mikejmoffitt wrote:
This looks really good, would there be a chance of overlapping BG layers to get 31 colors, or is that too much data to DMA each frame?
Why not just use 8bpp graphics at that point?
You know, one thing I thought would be really cool is if you had a 4bpp layer, and a transparent 2bpp layer on top of it so you are only using 6bpp. I'm really not sure how you'd write a code to translate a video to use that, and I'm sure it would take years on end to process...
If 4bpp and 8bpp are feasible, 6bpp should too, provided you have existing code to adapt. The biggest problem would be to adapt the code that comes up with an optimized palette then (since I assume you'd use this with blending or something?).
Wouldn't it be more feasible to just use all the palettes and assign the best one for each tile?
Wouldn't it be more feasible to just use all the palettes and assign the best one for each tile?
Sik wrote:
Wouldn't it be more feasible to just use all the palettes and assign the best one for each tile?
You mean like what is already being done, where there are 8 palettes? When I meant 6bpp, I mean you would do that exact same thing, except you would save 1 or 2 palettes for a transparent 2bpp layer over the 4bpp layer for a greater number of colors. (It would probably take a year to process one frame, but yeah...)
> I guess it depends from resolution and codec, the Mega CD which use a 12 Mhz 68000 is able to decode cinepak video with almost fullscreen and decent frame rate (15 FPS)
The SNES is a 2.68MHz CPU. But the clock frequency is misleading: every instruction consumes 2-8 of these cycles, and you often need multiple opcodes to do things you could do in one on the 68K. So your throughput is really more like ~400,000 instructions per second. Even if you could pull off the world's fastest codec that only needs four SNES instructions per byte of output, that's 100KB of data you could push through per second. But you're not done yet. You also have to throw in DMA when you do send a frame, and there's also DRAM refresh. So probably more like 80KB/s. Which would net you 2-4fps with your impossibly fast codec. With a realistic trivial codec (RLE, LZ), you're looking at seconds per frame, not frames per second. And for all of this, you're going to be really disappointed with the compression ratio on anything that's not Bad Apple.
The SFX and SA1 are certainly faster, but they have their own limitations. The biggest win is that you won't have the chips paused while sending data to VRAM. I'm not 100% sure on the SFX, but I'd say with the SA-1 and this imaginary codec, you could get maybe 4-10fps, depending on bit depth.
> Why not just use 8bpp graphics at that point?
Indeed. 16x the color for only 2x the storage requirements. Since the idea's useless without super bulk storage (S-DD1/SPC7110 emulator-only 256MB ROMs, or MSU1), you might as well go for 8bpp.
The SNES is a 2.68MHz CPU. But the clock frequency is misleading: every instruction consumes 2-8 of these cycles, and you often need multiple opcodes to do things you could do in one on the 68K. So your throughput is really more like ~400,000 instructions per second. Even if you could pull off the world's fastest codec that only needs four SNES instructions per byte of output, that's 100KB of data you could push through per second. But you're not done yet. You also have to throw in DMA when you do send a frame, and there's also DRAM refresh. So probably more like 80KB/s. Which would net you 2-4fps with your impossibly fast codec. With a realistic trivial codec (RLE, LZ), you're looking at seconds per frame, not frames per second. And for all of this, you're going to be really disappointed with the compression ratio on anything that's not Bad Apple.
The SFX and SA1 are certainly faster, but they have their own limitations. The biggest win is that you won't have the chips paused while sending data to VRAM. I'm not 100% sure on the SFX, but I'd say with the SA-1 and this imaginary codec, you could get maybe 4-10fps, depending on bit depth.
> Why not just use 8bpp graphics at that point?
Indeed. 16x the color for only 2x the storage requirements. Since the idea's useless without super bulk storage (S-DD1/SPC7110 emulator-only 256MB ROMs, or MSU1), you might as well go for 8bpp.
The SNES's CPU with the SA-1 is definitely going to be stronger than just the plain 68000 in the Genesis though, and Stef said that Sonic 3D blast's intro used some sort of compression and it is only using the Genesis's 68000.
About the SNES's CPU running at 2.68MHz, doesn't it actually run at 3.58MHz with fastrom? Why in the world would you ever use slowrom then? I think I heard it has something to do with the cartridges? Anyway, at 3.58MHz, if you only used the fastest instructions, you should get 1.79 million instructions per second, and with the slowest instructions, you should get 0.4475 million instructions per second. Since most useful instructions seem to use around 4-6 cycles, you could get 3.58 and divide it by 5 and you'd get 0.716 million instructions per second.
About the SNES's CPU running at 2.68MHz, doesn't it actually run at 3.58MHz with fastrom? Why in the world would you ever use slowrom then? I think I heard it has something to do with the cartridges? Anyway, at 3.58MHz, if you only used the fastest instructions, you should get 1.79 million instructions per second, and with the slowest instructions, you should get 0.4475 million instructions per second. Since most useful instructions seem to use around 4-6 cycles, you could get 3.58 and divide it by 5 and you'd get 0.716 million instructions per second.
Cycles that access I/O ports* always run at 3.6 MHz, and cycles that access RAM ($0000-$1FFF and $7E0000-$7FFFFF) always run at 2.7 MHz. Slow ROM was common early on because of replication cost.
* The gamepad ports $4016 and $4017 take two 3.6 MHz cycles.
* The gamepad ports $4016 and $4017 take two 3.6 MHz cycles.
Well, even for 2.68MHz, 0.4 million instructions still seems a little low. Unless you're only using 7 cycle instructions with a little bit of 6 cycle instructions, the amount of instructions per second is going to be higher. 5-6 cycle instructions seem more reasonable, and in that case, you'd get about a half a million instructions.
There is no possible way an SA-1 chip can struggle with running a 15fps 160x144 4bpp video, especially when your decompressing it as groups of 8 pixels. With the stock hardware, it's kind of in that grey area where it just might make it, or just might not.
byuu wrote:
If you're sharing your own version, that's cool. Always nice to see others' code.
But if you're demonstrating the technique, we've already done this before.
But if you're demonstrating the technique, we've already done this before.
I just wanted to have a tool for playing animations on SNES.
Now I can see short animations of my favorite shows on my fav system.
I dont own a SD2SNES , soo I cant use MSU1 on real hardware.
Quote:
We've done it at 2bpp, 4bpp, 8bpp at 15fps, 20fps, 30fps; in lores/progressive and in hires/interlace.
I really want to see this.Almost all the links here are dead:
viewtopic.php?f=12&t=5767
Can someone post the demos?
Quote:
The problem is that it eats ROM like crazy. 160x144x4bpp@15fps will eat 168.5KB/s, giving you 24 seconds of video for a full ROM. And said ROM won't have a game to go with it.
The 29.49% of all the banks are free so you can put a bit more seconds of animation in the ROM.
But yeah , you are right.
Quote:
So the technique is nearly worthless for stock hardware.
I disagree
.It looks cool!For me , That was the whole point of doing it.
Thank you for taking the time to reply to my post , It means a lot to me.
I appreciate very much all your work.
> There is no possible way an SA-1 chip can struggle with running a 15fps 160x144 4bpp video. With the stock hardware, it's kind of in that grey area where it just might make it, or just might not.
Well, since you guys know more than the guy who emulated the SNES and SA-1, I wish you the best of luck when you go to implement this.
> I really want to see this.Almost all the links here are dead: viewtopic.php?f=12&t=5767 Can someone post the demos?
Wish I had 'em. I'd especially like to show you smkdan's Lunar: SSS opening demo. That one was amazing, and didn't require the MSU1/21fx at all.
> I disagree. It looks cool! For me , That was the whole point of doing it.
Sure, as long as you have fun doing it, that's all that matters :D
Well, since you guys know more than the guy who emulated the SNES and SA-1, I wish you the best of luck when you go to implement this.
> I really want to see this.Almost all the links here are dead: viewtopic.php?f=12&t=5767 Can someone post the demos?
Wish I had 'em. I'd especially like to show you smkdan's Lunar: SSS opening demo. That one was amazing, and didn't require the MSU1/21fx at all.
> I disagree. It looks cool! For me , That was the whole point of doing it.
Sure, as long as you have fun doing it, that's all that matters :D
byuu wrote:
> I really want to see this.Almost all the links here are dead: viewtopic.php?f=12&t=5767 Can someone post the demos?
Wish I had 'em. I'd especially like to show you smkdan's Lunar: SSS opening demo. That one was amazing, and didn't require the MSU1/21fx at all.
Wish I had 'em. I'd especially like to show you smkdan's Lunar: SSS opening demo. That one was amazing, and didn't require the MSU1/21fx at all.
Here you go.
http://manuloewe.de/snestuff/temp/fzeroxvid.zip
http://manuloewe.de/snestuff/temp/lunar.7z
http://manuloewe.de/snestuff/temp/novideo.zip
http://manuloewe.de/snestuff/temp/vid7.7z
http://manuloewe.de/snestuff/temp/vid10.7z
http://manuloewe.de/snestuff/temp/vid15_2.7z
http://manuloewe.de/snestuff/temp/vid32khzstereo.zip
http://manuloewe.de/snestuff/temp/vidtmnt.zip
These won't stay on my webspace forever, so please grab 'em while you can.
I used to play them with bsnes v0.058 (I think), but I've only tested the Lunar one on higan just now. It kind of works, but not without major graphical glitches ... 
byuu wrote:
> There is no possible way an SA-1 chip can struggle with running a 15fps 160x144 4bpp video. With the stock hardware, it's kind of in that grey area where it just might make it, or just might not.
Well, since you guys know more than the guy who emulated the SNES and SA-1, I wish you the best of luck when you go to implement this.
Well, since you guys know more than the guy who emulated the SNES and SA-1, I wish you the best of luck when you go to implement this.
With the SA-1 you'd have 248 cycles per every group of 8 pixels. You could just use a library of the 256 most commonly used 8x1 slivers. The stock CPU would have 60-80 cycles per 8x1 sliver, and my Bad Apple demo uses about 60 cycles to per 8x1 sliver.
Espozo wrote:
The SNES's CPU with the SA-1 is definitely going to be stronger than just the plain 68000 in the Genesis though, and Stef said that Sonic 3D blast's intro used some sort of compression and it is only using the Genesis's 68000.
It's also running at an extremely low resolution which makes it way less impressive. (and if you wonder about the compression, they literally just passed RNC through every frame - they already used RNC for everything else so I guess it was easy)
Ah, wonderful!
kp64, please be sure to try http://manuloewe.de/snestuff/temp/lunar.7z in higan v094-balanced.
I'm sure you will be very impressed by smkdan's work =)
Ah, you had me worried there for a second, but it seems to work fine for me? :/
The video has lots of artifacts because it was sourced from a Youtube rip of a PSX CD rip >_<
The biggest problem with lossless videos in MSU1 is that nobody distributes lossless video in the first place.
kp64, please be sure to try http://manuloewe.de/snestuff/temp/lunar.7z in higan v094-balanced.
I'm sure you will be very impressed by smkdan's work =)
Ramsis wrote:
I've only tested the Lunar one on higan just now. It kind of works, but not without major graphical glitches ... :|
Ah, you had me worried there for a second, but it seems to work fine for me? :/
The video has lots of artifacts because it was sourced from a Youtube rip of a PSX CD rip >_<
The biggest problem with lossless videos in MSU1 is that nobody distributes lossless video in the first place.
byuu wrote:
kp64, please be sure to try http://manuloewe.de/snestuff/temp/lunar.7z in higan v094-balanced.
(...)
Ah, you had me worried there for a second, but it seems to work fine for me? :/
(...)
Ah, you had me worried there for a second, but it seems to work fine for me? :/
As you mentioned the balanced build, I just tried it on all three of them (vs. yesterday, where I only tested the performance one).
Here's the results ...higan-accuracy:
higan-balanced:
higan-performance:
Hmmm ... Why does it work on higan-balanced, but not on either one of the other builds as well ...?
byuu wrote:
kp64, please be sure to try http://manuloewe.de/snestuff/temp/lunar.7z in higan v094-balanced.
I already did , is really impressive!
I'm getting the same results that Ramsis. It works ok with the balanced profile.
kp64 wrote:
byuu wrote:
kp64, please be sure to try http://manuloewe.de/snestuff/temp/lunar.7z in higan v094-balanced.
I already did , is really impressive!
I want say (to quote Thomson and Thompson): It's no less than awesome.
> Hmmm ... Why does it work on higan-balanced, but not on either one of the other builds as well ...?
Well, higan-performance is utter shit, so I'm not concerned there.
It's not working in higan-accuracy because the game isn't initializing memory and registers properly.
You can verify this by using the power cycle option. The corruption pattern changes every time.
The only thing that varies between power cycling in higan-accuracy is the randomization of memory.
higan-balanced does not randomize memory, as you might have guessed.
So unfortunately, bug in lunar.sfc. That's a shame =(
Well, higan-performance is utter shit, so I'm not concerned there.
It's not working in higan-accuracy because the game isn't initializing memory and registers properly.
You can verify this by using the power cycle option. The corruption pattern changes every time.
The only thing that varies between power cycling in higan-accuracy is the randomization of memory.
higan-balanced does not randomize memory, as you might have guessed.
So unfortunately, bug in lunar.sfc. That's a shame =(
I think the question is "how can it fail in the most and least accurate builds but still work in the halfway point one?". That certainly doesn't make much sense (although anybody who has worked in software knows how volatile things can get)
It seems like the middle-of-the-road emulators are the easiest to get something working, because everything is fully functional, but the "hardware glitches" are not implemented.
kp64 wrote:
https://www.youtube.com/watch?v=P_wV724qQAI
kp64.my3gb.com/aimForTheTop.zip
kp64.my3gb.com/aimForTheTop.zip
This is interesting. I remember years ago, before I really knew what I was doing, displaying frames of video in mode 3 using much shorter animations and less tiles. Then when I switched to mode 1 I recall getting glitchy frames. Did you have any issues along the way or did everything always display smoothly for you?
I'll have to see if I can find my original source or rom to see where things went wrong. It worked fine for short loops but if I had 64 frames 4 or 5 of them might be glitchy. Sometimes removing those specific frames would eliminate the problem, but not always.
Augustus Blackheart wrote:
This is interesting. I remember years ago, before I really knew what I was doing, displaying frames of video in mode 3 using much shorter animations and less tiles. Then when I switched to mode 1 I recall getting glitchy frames. Did you have any issues along the way or did everything always display smoothly for you?
I used mode 1 since I started coding the animation player and I didnt have any problem.
Maybe I'm not understanding well what are you saying but, mode 3 uses 8bpp tiles and mode 1 uses 4bpp.
If you are gonna switch the mode and use the same tileset/bitmap , you are gonna get glitches for sure.
kp64 wrote:
I used mode 1 since I started coding the animation player and I didnt have any problem.
Maybe I'm not understanding well what are you saying but, mode 3 uses 8bpp tiles and mode 1 uses 4bpp.
If you are gonna switch the mode and use the same tileset/bitmap , you are gonna get glitches for sure.
Maybe I'm not understanding well what are you saying but, mode 3 uses 8bpp tiles and mode 1 uses 4bpp.
If you are gonna switch the mode and use the same tileset/bitmap , you are gonna get glitches for sure.
I used the mode 1 option in my conversion script which provided the necessary 4bpp tiles. I don't have the original code or video I used, however I just wrote an animation routine and it worked fine. Perhaps previous glitches were caused due to too many unique tiles. Possibly I didn't use the best modulate and contrast commands.
Sik wrote:
I think the question is "how can it fail in the most and least accurate builds but still work in the halfway point one?". That certainly doesn't make much sense (although anybody who has worked in software knows how volatile things can get)
The balanced core in bsnes has PPU code from 2005. It's a mess in there, and I don't like to touch it unless forced to. The accuracy and performance PPUs are newer, and so I added randomization there.
I didn't think I did so with the performance core though, maybe some other issue is going on there. Again, not much concern for the performance core. Its PPU was kind of a dead end attempt at speeding things up, which didn't work out in the end.
All of my primary focus is on the accuracy core.
Sik wrote:
It's also running at an extremely low resolution which makes it way less impressive. (and if you wonder about the compression, they literally just passed RNC through every frame - they already used RNC for everything else so I guess it was easy)
Is it that low ? I though blocky parts comes from the compression loss itself but not because of low resolution but i admit it's quite hard to tell from the video itself which is definitely heavily compressed. Also RNC is really CPU intensive (bit stream) for something which needed live unpacking, are you sure they used that for the sonic 3D intro ?
I got to that part of the code when I disassembled the game =P And yes, it's horribly low resolution. RNC is a loseless compression format, by the way. And yeah, it isn't decompressing much so it's feasible (it's not like the framerate is that high either).
When I mentioned that I forgot about the other two FMVs though, the Sega logo and the Game Over screen. Both are indeed full resolution and 30FPS, but only 2 colors. Actually this isn't the truth: they're 4bpp, but use palette trickery to cram four frames into one. This also means their true framerate is 7.5FPS, which is something easier to do. Clever guys =P
When I mentioned that I forgot about the other two FMVs though, the Sega logo and the Game Over screen. Both are indeed full resolution and 30FPS, but only 2 colors. Actually this isn't the truth: they're 4bpp, but use palette trickery to cram four frames into one. This also means their true framerate is 7.5FPS, which is something easier to do. Clever guys =P
Sik wrote:
I got to that part of the code when I disassembled the game =P And yes, it's horribly low resolution. RNC is a loseless compression format, by the way. And yeah, it isn't decompressing much so it's feasible (it's not like the framerate is that high either).
Lossless really ? i don't know the format but looking at the video i though it was really lossy... Taking the video frame by frame it looks like vertical resolution is divided by 2.5, not sure about the horizontal one (very tricky to guess because of the weird line scrolling trick they used to fake higher resolution) but i would say maybe / 2 factor (with patterned nibbles)... so the real resolution is probably something as 128x80. But the frame rate is definitely not bad (at least 15 FPS) ! And they have to do a bit of process to upscale it to fullscreen (not that much using some tricks with both plans).
Quote:
When I mentioned that I forgot about the other two FMVs though, the Sega logo and the Game Over screen. Both are indeed full resolution and 30FPS, but only 2 colors. Actually this isn't the truth: they're 4bpp, but use palette trickery to cram four frames into one. This also means their true framerate is 7.5FPS, which is something easier to do. Clever guys =P
Yep, i use the same trick in the bad apple demo (4bpp frame to encode 2 frames in 2bpp), very simple to fake 2bpp and 1bpp mode with palette trick. But still unpacking full resolution frame at 7.5 FPS with RNC compression is definitely impressive for me (the intro sega logo is full resolution).
Stef wrote:
Lossless really ? i don't know the format but looking at the video i though it was really lossy...
If the video looks lousy and it's encoded in a lossless format then it must have been compressed in some other way first before it was RNC-encoded, probably just to make it fit and be playable on the system...
OK looking at it again and odd, I thought it was lower =/ (vertical scaling is done with raster effects though, do note) I did framestep and the framerate seems rather unstable (often around 5 frames per update (12FPS), but sometimes 4 and sometimes 6), so there's that.
EDIT: also is there any horizontal scaling? They need to store both nibbles anyway to do the dithering, so I guess it's just stored as-is.
EDIT: also is there any horizontal scaling? They need to store both nibbles anyway to do the dithering, so I guess it's just stored as-is.
For the horizontal resolution, i believe they encoded byte (8 bits) pixels to fake more colors with the 2 nibbles (which explain why they used the 1 pixel offset scrolling at each odd scanline) and then they doubled the 8 bits pixel by copying low byte in high byte and storing the word result. Honestly i think the result is still quite impressive considering they used RNC compression which is definitely not the fastest one. Also for the other video (as the sega intro logo), they really required to do full resolution 4bpp at 7.5 FPS (or 1bpp at 30 FPS), really not bad at all...