Fraps is hideous. They should call it Craps. Camtasia Studio is where cool kids play.
Fraps is for games, and does a great job for what it's supposed to do.
Camtasia is for the desktop, but CamStudio does the same, has a good codec that can be used elsewhere, and is free.
I'm sure it would be much easier to write a QBasic emulator than a complete PC emulator. You just have to add some restrictions, e.g. no CALL ABSOLUTE and no file access.
There's also Opera, SRWare Iron, ...
ventuz wrote:
Video isn't big, 332 mb and 5 min 30 sec long.
That's... 8241 kbits/s. Are you sure you need that much?
ventuz wrote:
I'd like to upload to different video website, but I'm needing Youtube's Annotation, I have no idea how to attach text into video without replacing "clip" or add blank background with text in middle of video.
You can create a subtitles file via Aegisub and combine it with the video by using "VSFilter_TextSub(FileName)" in AviSynth (needs the VSFilter plugin). Example
I just want to add that yes, FM synthesis can sound great - my favorite game on the GB is Link's Awakening, and it has incredible music (e.g. Face Shrine). And there are lots of memorable songs on the C64 etc.
But FM just can't reproduce "real-world" sounds as well as PCM samples. Just compare Rock'n'Roll Racing on the Genesis and the SNES. I think the latter can also mix channels better; with FM something like Undersea Palace would no be as clear, imo.
SNES has better graphics (see Seiken Densetsu 3 aka Secret of Mana 2 for a good example)
There is no Gens version of SoM2 so how can you compare the two platforms by mentioning SoM2?
SoM2 is a game that uses the hardware quite well, so it's a real-world example (instead of a tech demo) that shows what difference a larger palette can make.
video
Texture warping at 00:04 and 00:10. Moving vertices = the polygon points are "wobbling" when the view is changed; see the floor at the end when the camera stabilizes.
My point was that some technical aspects don't mean a thing in the big picture.
Maybe for you, but then you should say "I like the effects that are possible with a faster processor" instead of "The Genesis has better graphics than the SNES". Because then you're comparing specifically the graphic chips of both consoles.
That was my point. :)
mz wrote:
It's like saying "The N64 looked much better than the PSX because it could do trilinear filtering, show 500000 polygons per second, had high resolution, a 64-bit CPU, etc etc.", but then most games looked like this:
<img>http://i39.tinypic.com/vru15l.png</img>
While the PSX had things like this:
Yeah, but PSX graphics had their problems too - warping textures, and vertices jumping all over the place.
Conker's Bad Fur Day is a good example how programmers are able to work around the limitations of a console, but then you're comparing the programmers instead of the consoles. And since you're mostly looking at the games, saying "machine x is better than machine y" is not correct, imo.
mz wrote:
I know most people prefer DKC graphics over Gunstar Heroes, just because they have thousands of colors.)
Actually it's just 256 most of the time. :)
DKC uses just Mode1 graphics (2 BGs of 16 colors per tile and 1 BG of 4 colors per tile), and of course 16-color sprites. If there are more than 256 colors on screen it's either because of changing the palette after each line, or because of transparencies.
title screenlevel 1 bg 1
Most publications on the site these days use a rate factor of 20, if you want a basis for comparison.
I see. :)
EEssentia wrote:
In my experience, bitrate 2-pass compresses way better than constant rate factor. Hit the right bitrate and it will be way smaller than the same quality as constant rate factor.
Yeah, but trying out many 2-pass settings for a 5-hour video might be something for a Zen master. :) Maybe with a short representative selection...
EEssentia wrote:
That's like saying that Twilight looks better than Citizen Kane because it has color and was recorded with better cameras.
And that would be true. We're comparing technical aspects after all, not content.
mz wrote:
In my opinion, Genesis has better graphics thanks to a much faster processor.
But when you're comparing "graphics" you can do so objectively only by comparing the specs, and the SNES is just better here. If you're comparing processors you're no longer comparing graphical capabilities, imo.
"Effects" can be created either by hardware (for example SNES' transparencies) or by software, i.e. the programmer. And programmers differ in creativity and ability. Look at Rendering Ranger R2 for what is possible with the SNES when it's programmed properly.
mz wrote:
Also, that 1-minute track sounds great, but it's just as useful as an static image of a scanned photo. The real fact is that the SNES could never have something as good as this in a real game: http://www.youtube.com/watch?v=jLvG-Al6tOg :P
Drag the video into AvsP (an AviSynth script editor) and add a new line with the text "info.Crop(0, 0, 400, 300)" in it. Press F5; it should display the topleft corner of the video with some info on it. Check if the audio length differs greatly from the video length, or if the video has an unusual FPS.
To see audio issues the AviSynth plugin AudioGraph may be useful; use "ConvertToYUY2.AudioGraph(1)", scroll to the end of the video and see if the waveforms match the actions in the video.
To fix issues use the "TimeStretch" function. Use the "rate" parameter slightly above or below 100. Testing in realtime might be difficult though if your system can't handle playback...
N64 games should be fine at 640x480. Record to a lossless format for editing. For lossless RGB use the CamStudio codec (fast) or the ZMBV codec (small files, doesn't like 24-bit sources). For lossless YV12 use FFDShow's HuffYUV ("HFYU", "YV12", "Median", "adaptive tables" checked) or the original Huffyuv codec. (Emulators output in RGB.)
For downsizing try the GaussResize function (upscaling should be fine with BilinearResize). Test a few values for p.
For the final encode I'd use x264 with a constant ratefactor (not constant quantizer). A value of 16 should look almost like the original; larger values compress more. For audio you can use the lame codec in VirtualDubMod, or extract the audio into a WAV file + encode it on the command line + merge video and audio with MKVMerge GUI.
Lot of games released for both console but Megadrive has better graphics and sound
Wait, what?
SNES has better graphics (see Seiken Densetsu 3 aka Secret of Mana 2 for a good example) and better audio (Star Ocean, Tales of Phantasia, or this).
Personally, I don't care if a file its 5 or 20% bigger than an "usual" encode. I think the quality (sound and picture) should be top notch
Same here. For Youtube I usually encode audio (even NES & GB) at 256 kbps and video at 640x480 and the highest x264 settings, or lower until it's not more than ca. 200 MB for the 11 minutes limit.
AngerFist wrote:
To divide a file into 1 or more playable pieces. example youtube time limit
Note that YT checks only the "minutes" part in the video length, i.e. as long as you stay below 11 minutes it should be fine.
At 30 fps this means a maximum of 19799 frames, resulting in a time of 10:59.9666.
As for software, I use AviSynth+AvsP for timing-related stuff.
Warp:
Just use mkvmerge / mkvmerge GUI.
bsnes v0.051 released
Starting with this release, I wish to take bsnes in a new direction. It has always excelled in accuracy, as the only SNES emulator to offer a full 100% compatibility rate with all known commercial software. But over the years, it has also gained an impressive array of features and enhancements not found anywhere else. It is also the only actively developed SNES emulator with rapid, periodic releases. Its only achilles heel is the steep system requirements, which is quickly being overcome by aggressive new optimizations and steadily-increasing hardware speeds.
In an effort to make bsnes even more accessible to everyone, starting with this release, bsnes is now fully open source software, licensed under the terms of the GNU General Public License. I would like to work toward positioning bsnes as a truly general use emulator, and would welcome any help with this.
Specifically, I am looking for an interested Debian maintainer to package bsnes for Linux users; as well as for anyone interested in helping to optimize and improve bsnes as a whole. It also seems that many still do not know about bsnes, I'd appreciate advice and help on spreading the word. Please leave a message on my forum if you are interested.
I would also welcome and support any forks that target specific areas: a speed-oriented version, a tool-assisted speedrun version, netplay bindings, and so on. As part of this targeting, I've also released a custom debugger-enabled version, which trades a bit of speed in turn for best-in-class debugging capabilities.
Please check back here over the following few days, I'll be writing up documentation explaining all of the various unique features of bsnes, as well as detailed compilation instructions for programmers.
Changelog:
* corrected a small bug in HDMA processing; fixes College Football '97 flickering
* corrected ROMBR and PBR SuperFX register masking; fixes Voxel demo [MooglyGuy]
* DSP-4 driver AI bug fixed [Jonas Quinn]
* added save state support to the S-DD1, S-RTC, DSP-1, DSP-2 and ST-0010 co-processors
* fixed a freeze issue when the S-SMP encounters STOP and SLEEP opcodes
* Cx4 save states no longer need floating-point values, and are thus fully portable now
* added new custom file loading dialog; allows non-modal usage, screenshot previews and ROM info summary, among many other benefits
* added support for IPS soft-patching
* added blargg's File_Extractor library
* added support for archives compressed using 7-zip, RAR and BZip2; which is in addition to existing support for Gzip, ZIP and JMA
* state manager now properly updates the timestamp column on saves [FitzRoy]
* added OpenGL renderer to OS X port
* fixed system beep issue with keyboard input on OS X port
* fixed menubar visibility issue on OS X port
* fixed a Display handle leak on Linux port [snzzbk]
* X-video driver now releases SHM memory properly upon exit [emon]
* fixed Direct3D rendering issue that was blurring video on some cards [Fes]
* enhanced window positioning code for all platforms
* debugger is now GUI-driven instead of via command-line
* memory hex editor is now fully usable
* added PPU video RAM viewer to debugger
* added S-CPU and S-SMP tracing capabilities to debugger
* Qt version upgraded to 4.5.2, and compiled with optimizations enabled; runs faster but makes the binary slightly larger
* too many code cleanups to list
EDIT: the user manual is now up. Please have a look, perhaps there are features there which you weren't aware of ;)
[ Discuss ]
Wouldn't it be possible to use SNES9x 1.51? It seems to have less graphical errors, especially in the 4th level.
Snes9x 1.51 has a lot of lag. More than the regular console. This movie shows the game lagging quite a lot, in a regular corridor, even though not a single egg is shot or juggled:
http://dehacked.2y.net/microstorage.php/info/1714283091/SMW2YIwithlag.smv (play this with snes9x 1.51)
I think none of the extra juggling or eggshots are possible when using 1.51
