I still don't understand what the point is. Such an arbitrary resolution that goes well beyond what any monitor supports. Why not make it 42400×24000 while you are at it? Bigger is better, so why not make it really big?
I use large resolutions for the videos, because my input material is multi-resolution. When your input material is of a single resolution, it only makes sense to scale it by 2.0 in both directions in order to inhibit chroma supersampling, and possibly an additional 2.0 or 4.0 in order to get YouTube to activate the 720p and 1080p quality levels which provide more bitrate and give less artifacts.
But when the material is of multiple resolutions ― in my editor I switch resolutions constantly ― the optimal resolution would be the least common multiple of the input resolutions.
If I only used e.g. 640×480 (VGA graphics mode) and 720×400 (VGA text mode), the least common multiple would be 5760×2400; for it is the smallest resolution where both input resolutions fit with integer ratios. If non-integer ratios are used, the pixels will not be preserved as sharp rectangles, but will either be blurred at their edges or be irregularly sized, or commonly, both. And to inhibit chroma supersampling, it should be 2× that both vertically and horizontally, due to the non-even 9× and 5× scaling factors respectively: 11520×4800. Obviously this kind of resolution is impractical already.
But the source material uploaded to YouTube should be as close to lossless as possible. Otherwise each further reprocessing step (as done by YouTube) only multiplies the loss already done before uploading the video.
But I do not even use as few resolutions as two. In my NES emulator coding video, all of the following resolutions were used: 640×480 656×420 656×480 672×420 672×480 672×480 688×480 720×400 720×408 720×408 720×475 720×494 752×288 752×296 752×344 752×352 752×400 752×400 752×400 752×408 752×416 752×420 752×424 752×462 752×464 752×480 752×480 752×490 752×536 752×552 768×400 768×400 768×480 784×400 784×448 784×456 784×464 784×472 784×480 784×560 800×400 800×400 800×448 800×480 800×480 816×400 816×448 816×480 816×560 832×448 832×480 832×480 848×400 848×408 848×408 848×416 848×416 848×424 848×456 848×464 848×472 848×480 848×480 848×480 848×480 848×480 848×480 848×480 848×480 848×480 848×488 848×496 848×496 848×496 848×496 848×496 848×496 848×496 848×496 848×496 848×504 848×504 848×504 848×504 848×504 848×528 848×536 848×536 848×536 848×544 848×544 848×544 848×544 848×544 848×544 848×552 848×552 848×552 848×560 848×560 848×560 848×560 848×560 880×400 880×416 880×424 880×424 880×432 880×440 880×448 880×456 880×464 880×464 880×480 880×480 880×480 896×480 896×480 912×448 912×480 912×480 928×480 944×400 944×408 944×420 944×448 944×480 944×480 944×480 944×512 944×528 944×536 944×600 976×480 992×488 992×504 992×560 1008×560 1024×560 1026×475 1040×608 1044×475 1056×608 1062×400 1072×608 1088×568 1088×608
Of course some of those resolutions were padded horizontally to preserve aspect ratio, so the list becomes slightly smaller: 852×288 852×296 852×344 852×352 852×400 852×408 852×416 852×420 852×424 852×432 852×440 852×448 852×456 852×462 852×464 852×472 852×475 852×480 866×488 870×490 880×496 896×504 910×512 938×528 952×536 960×400 960×408 960×475 960×494 966×544 980×552 994×560 1008×568 1066×600 1080×608
It is still quite a large list, and the least common multiple does not really work here (it would produce 115945931878090554240×23348390524866115315211404800). So I simply picked the resolution that I want to optimize for ― this was 848×400 ― and upscaled it with an integer of choice ― this was 5 and 6 ― producing 4240×2400.
Also, I don't think such a large sounding resolution like 4000×3000 is going to be that excessive in future. Images of that size are every day to the people dealing with print and image editing. It is possible to make good print-quality snapshots from my videos (provided that YouTube does not damage them).
Why I did not use larger size? Most people today use a desktop resolution of 1024×768. or 1280×800 [1]. According to that source, approximately 1 % of Steam gamers use a desktop as large as 2560×1440 (WQHD). In order to avoid chroma supersampling artifacts, my video should be at least double that (5120×2440). But YouTube only goes up to 4K, so that's where I try to set my cap at, approximately.
Think I am overestimating the impact of chroma supersampling artifacts? Try watching this video on 480p or smaller: http://youtu.be/8x9Ya4izFaE The green text on blue background will have artifacts in it that vary from tolerable to horrible depending on your display gamma.
For the tl/dr people, the reason is: In order to avoid minimize supersampling artifacts, in order to preserve sharp uniform-size rectangular pixels, and in order to enable the better-bitrate options in YouTube.
Finally, I should make a set of simulated comparison images some day…
EDIT: I posted part 2, the demonstration video. http://youtu.be/XZWw745wPXY ― It is still uploading, but it should be watchable at some quality level by December 8th 0:00 UTC.
...
Where do you even learn how to program this well? Why is every TASer so much more competent than literally every other programmer I've ever met? I want to learn how to do stuff like this...or just understand it.
<scrimpy> fairly safe to say the dude likes coding things
This pretty much sums it.
Doesn't help me being professionally successful, though. I'm just a low paid web developer. And I don't even consider myself particularly talented. I look far up to folks like Ken Silverman, who created the Build engine upon which the game Duke Nukem 3D is based (while he was like 18), and Fabrice Bellard who created QEMU among a dozen other accomplishments. While I have been pursuing similar goals now and then, I have never managed to create anything that can even be spoken about in the same sentence with their accomplishments. I am always walking in the footsteps of giants.
The way I explain it is that TAS is something that could only be invented by mega-nerds.
Nerdom is, after all, almost obsessive interest towards a topic. The curiosity and the non-discouraging will. The type of personality, that sets down to bisect a problem as deep as needed, to grasp the roots of it and to understand how it grows.
I look far up to folks like Ken Silverman, who created the Build engine upon which the game Duke Nukem 3D is based (while he was like 18), and Fabrice Bellard who created QEMU among a dozen other accomplishments.
On that subject, I must mention John Carmack, who is one of the best-known programmers in the gaming industry. Co-founder and lead programmer of id Software, and main designer of all of their game engines. (Also a big fan of open source software. All of their older game engines have been released as OSS.)
Time for some criticism? Why not!
You call these tool-assisted education videos and certainly they are educating, but as they are now they still seem to be more like tool-assisted coding demonstration videos to me. Over the raw source code, which you provide in the video description, the educational contents exclusive to the videos are voice dubs/annotations and coding sequence. What I am missing are verbalizations of your thought processes behind coding stuff the way you did and explanations of why and how the "little tricks" you use work. It's not really necessary and maybe it'd be even annoying to do to you, but I can imagine it'd make those videos more appealing as educational videos. Certainly, you would never be able to cram a whole NES emulator into 15 minutes that way though, I know. Your videos are art, they are beautiful and I love them as they are, and surely explaining every little thing would take something away from that. This criticism is just due to the name you chose to label those videos yourself. Maybe keep the art/demonstration videos seperate from additional videos that attempt to explain things more in detail? Maybe just leave it like this, I'd be happy with that too. ;)
Thanks Kuwaga.
You are right in that if I stopped at any point to explain something in detail, perhaps with illustrations, I would not be able to fit this code in 15 minutes.
As a compromise, I tried to cover that aspect with very verbose comments; such as the one before PPU::tick() that explains the timings and what happens in each part of the rendering process.
I script the code and the video very carefully beforehand, down to smallest details; because I'm well aware (from watching videos by others) that stopping to hesitate will not make for an entertaining video. In television/movie/theatre, actors often speak lines that are too long and too prone for enunciation errors to be ever used in real communication. Nevertheless, it is done, and it is entertaining to watch, and rarely the audience pays attention to the fact that nobody ever speaks like that. So I do the same with the code that I write. Nobody ever writes code as straightforwardly and fluently as I do in my videos, but it makes for an entertaining and educational show.
In other words, although my programming videos are all Hollywood to varying degrees, they are still scientifically accurate Hollywood.
Sometimes in my videos, I forget to type something and/or make typos. When it happens, I always pause the recording immediately to do the bug-tracking off-screen, and then quickly patch the bugs on-screen while the recording is resumed, in order to avoid spending two minutes of viewer's time trying to figure out what exactly is wrong with my code. I have gotten better with this by every video I have published, so today fewer mistakes end up in my videos. But there still was one in my NES emulator, that I had to go and fix in part 2.
Kuwaga wrote:
It's not really necessary and maybe it'd be even annoying to do to you, but I can imagine it'd make those videos more appealing as educational videos.
I think my priorities go in order of entertainment and teaching. If people are distracted by the video's pace slowing too much, and they stop following the video, it does not matter what I teach. I need views. Without views, people who would be genuinely interested of the lesson won't ever find my video. Often, interesting stuff is simply stumbled upon. Sure, people do search too, but at least for me the majority of stuff that I find interesting in the Internet is not something that I was intentionally searching for. This is why I don't stop to explain things even in the shorter programs. Usually I try to provide information without stopping, such as with voiceovers in Doukutsu Monogatari music player or with comments in MicroBlaze emulator.
Ahh, yes, the "if you're not an author/musician/athlete/chef/etc. then you can't criticize books/music/sports/food/etc." attitude.
He could have been less insulting but he did have a point -- compact, "elegant" code is typically much harder to understand than straightforward, simple code. Code golf has artistic value but I wouldn't want it anywhere near a serious project.
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
compact, "elegant" code is typically much harder to understand than straightforward, simple code. Code golf has artistic value but I wouldn't want it anywhere near a serious project.
Don't generalize. That just sounds a bit similar to the attitude of those deluded individuals who deliberately use slow algorithms because they have misunderstood what "premature optimization" means.
Ahh, yes, the "if you're not an author/musician/athlete/chef/etc. then you can't criticize books/music/sports/food/etc." attitude.
Yeah, except I never wrote or implied anything of the sort. I wasn't saying SXL needs to make an emulator himself, only that he's being a rude asshole to one of the biggest contributors to this site...while contributing virtually nothing to this place himself.
There are always people who think blunt opinions are not subject to anyone's status.
To address the topic of "code golf", I intentionally reduced the code length as much as I could, because the other alternative would have been to speed up the typing even more, to the point of being impossible to follow without constant abuse of the pause button. It was already much faster than I would have liked it to be. I was aiming for 800 lines. I got 940.
If it had been over 1000, I would have probably sacrified the APU (sound support).
I'm actually very interested in the subject. I'd really want to make my own (SMS) emulator. I tried to read the code but failed, because it lacks everything a shared programming project has : specifications, build instructions, KISS and reusability. Also, I loath C/C++ and low level programming, maybe because I do Java for a living.
For those reasons I feel entitled to proclaim that this project failed its educational purpose. If anyone managed to do his/her own emulator thanks to this, please enlighten me, I'm lost.
All in all, it's a raw demonstration of skill, that I truly admire, and wish I could reproduce, but to me the best developer still is the one whose code can be understood by the most people.
If the topic had presented the project as art instead of education, things'd have been very different. Narcissism would become personal creative touch.
Also, I'm sorry if it sounded harsh. I'd really like to hear more of the process that turned the console's specs into code ; yet I disregard any "only doers may criticize" as I'm too old for this shit, Riggs.
I never sleep, 'cause sleep is the cousin of death - NAS
yet I disregard any "only doers may criticize" as I'm too old for this shit, Riggs.
I don't think the sentiment is "only doers may criticize", but more like "don't criticize a subject you don't understand" (because else you'll just look like a fool who's complaining about something without good reason). This doesn't mean you don't understand the subject (and hence should not present any critique), just pointing out.
Moderator, Senior Ambassador, Experienced player
(908)
Joined: 9/14/2008
Posts: 1014
Bisqwit, I trust that if this had not met your goals you would not have posted it. I watched the video (and read the commentary here) and I have to say that this *was* educational and entertaining. I am not a programmer (the best I have to show is the Python virtual machine rerecording framework I built for ais523 for abusing NetHack). I do not know C++11, let alone straight C. About all I can do is write scripts. With that context of my viewpoint I found the video to be very educational on how to take advantage of some very interesting techniques and I saw several sections where thought and care had been taken beforehand to ensure the Hollywood show looked dazzling while still producing code that could be puzzled over and debated.
Discussions here and elsewhere about how some aspects of this code is written have been educational and entertaining in and of themselves. I feel the video description does an adequate job of explaining the intent in creating something interesting using Tool Assisted Speed Programming techniques and methods and I personally see this as an art form on par with a TAS of a game. If anything, I believe this is just the beginning of a new artform that may catch on.
Thanks for the video, Bisqwit! Keep up the great work.
A.C.
******
I'm not very comfortable in doing this, but I just can't help but to somewhat agree with the sentiment that a video that shows nothing else than program code appearing on screen isn't very educative, nor is it very entertaining (especially since it's 15 minutes of basically nothing but code appearing on screen).
If you wanted to explain your code eg. for educational purposes, a much more fluent medium for this would be a simple web page, rather than a video. (The exception would be if the video would be in the form of a spoken lecture. But then it would probably require a rather different kind of presentation and editing to explain the relevant parts properly. As well as speech, of course.)
A web page would allow the viewer to go through the contents at their own pace, trying to understand difficult parts of the code, reading the explanations, going back, etc.
