Wikipedia - Software Demo
Within the computer subculture known as the demoscene, a non-interactive multimedia presentation is called a demo (or demonstration). Demogroups create demos to demonstrate their abilities in programming, music, drawing, and 3D modeling. The key difference between a classical animation and a demo is that the display of a demo is computed in real time, making computing power considerations the biggest challenge. Demos are mostly composed of 3D animations mixed with 2D effects and full screen effects.
The boot block demos of the 1980s, demos that were created to fit within the small (generally 512 to 4096 bytes) first block of the floppy disk that was to be loaded into RAM, were typically created so that software crackers could boast of their accomplishment prior to the loading of the game. What began as a type of electronic graffiti on cracked software became an art form unto itself. The demoscene both produced and inspired many techniques used by video games and 3D rendering applications today - for instance, light bloom, among others.
Wired News has frequently described demos as "digital graffiti", emphasizing the underground nature of the demoscene as well as the way demos are used to proclaim the authoring "gang's" superiority.
Digitalcraft has described demos as "digital origami", referring to the creation of aesthetically pleasing works by overcoming strict technical restrictions.
There are demos available for a great variety of computing platforms. Currently, most new demos are native-code programs designed to run on PCs under the Microsoft Windows operating system, but demos are still actively being made for many other machines including old and new computers, consoles and mobile devices such as PDAs, mobile phones and pocket calculators.
The main historical platforms include Commodore 64, ZX Spectrum, Atari ST and Commodore Amiga, and demo competitions for these platforms are still relatively common at today's demo parties. There are even demos running on such diverse platforms as VIC-20, Commodore Plus/4, Atari 8-bit, Atari 2600, Amstrad CPC, Macintosh, Game Boy, GP32, PlayStation and MSX.
Unlike mainstream retrocomputing, the activity of creating demos for old computers is more commonly associated with technical challenge than nostalgic feelings. The accomplishment of new and groundbreaking things is a major driving force on the demoscene, and the limits of various pieces of "obsolete" hardware are still being pushed forward by several groups. Even many PC-oriented democoders do some programming on more restricted platforms in order to get in touch with ways of democoding that are no longer available on modern PCs.
In the 1990s, it was still quite common for different platforms to have more or less separate demoscenes. When users of different platforms participated in a single event, it was considered obvious to split the competition categories for each supported platform (e.g. having separate demo and intro competitions for the PC and the Amiga). Nowadays, the availability of decent emulators and video captures have brought the different scenes closer together.
In the 1980s, a lot of personal computer games were released for early equipment like the Commodore 64, ZX Spectrum, Atari ST and Commodore Amiga, including Copy protection to prevent unauthorised copies. Some cracker groups started to release those games with the protection removed. Simple noninteractive demos were also released as type in programs in books and magazines, often with an invitation to the reader/programmer to expand the listing into a full-fledged game.
Initially, small demos were shown before the actual game, including music, animations and marquees with shoutout-style greetings to represent the releasing group. The quality of these demos was quickly considered as a figurehead of the group. Intros increased in quality, often touching the limits of the computer's abilities. The cracker groups started a severe competition for being the first in releasing cracked copies of games.
At that moment, levering out copy protection decreased in importance for some artists inside the scene. They felt that programming ambitious Intros was more challenging. While publishers improved their copy protections, the quality of Intros increased as well. Often, the fame of well-known groups was based on their spectacular Intros.
The introduction of 16-bit and 32-bit computer systems like the Amiga and the Atari ST resulted in a new distribution of work inside the groups, since the hardware allowed new possibilities. The creation of Intros was divided in programming, music and graphics. Intros were often spread on Disk magazines.
At the end of the 1980s, pirate copies increasingly became an issue for the software industry. The development of games for certain platforms was stopped entirely due to insuffient profit, some[who?] claimed that the cracker scene being responsible for the doom of the Amiga platform. Some Amiga games were released by crackers before they were released commercially. Authorities started to apply pressure on individuals and whole groups in the scene.
This led to the release of stand-alone demos computer art without the illegal distribution of computer games. With the increasing use of the Internet, the separation was complete. Cracked copies of computer games were available online for the masses with the crack attached. Often, greetings were only attached in a text file, while the demoscene separately distributed their work.
Small file sizes have been an integral feature of certain types of demos from the very beginning, when software crackers needed to squeeze a crack intro into a very small leftover area of a floppy disk or RAM. It was also important for BBS advertisement intros to be relatively small, since they were typically included in every file downloaded from the BBS.
Sometimes even the platform itself dictated some size restrictions: the size of the boot sector of a floppy disk (generally 512 to 4096 bytes) was also the maximum size of a boot block demo. The common 64-kilobyte size limit for intros, on the other hand, was the segment size in the 16-bit x86 architecture and also the maximum size of an MS-DOS-based .COM executable.
In later times, the practical need for very small demos had diminished, but the willingness to compete in squeezing much into little space had not disappeared. It was therefore necessary to introduce artificial size restrictions in order to challenge the authors. In modern demoscene events, there are demo competitions with relatively loose size restrictions, and intro competitions with quite strict limits of 64 kilobytes or less.
Because of the strict size limits, intros show off the programmer's ability to squeeze much into little space, often by generating graphic and sound data rather than just reading it from a datafile. Because of the extremely low size limit, 4K intros used to lack sound, or had extremely low quality music. As technology progresses, however, 4K sound synthesis has become a new frontier in the demoscene. 4K still isn't the lowest border for demosceners: some demoparties organize 1K, 256 byte, 64 byte or even 32 byte intro competitions. While creating a 4K might not require low-level programming knowledge anymore, sub-1K competitions require the demo coder to be skilled in both assembly programming and algorithmic optimization. (For comparison: The size of this section of article is over 2 kilobytes.)
Procedural generation techniques developed for small intros have worked their way into mainstream gaming such as Will Wright's game, Spore.
There are several categories into which demos are informally classified. The most common way to classify demos is by platform or size class, but the purpose, content or style of a demo can also matter.
See also: Crack intro An intro originally referred to an endless demo where all the action happened on a single graphical screen, often to promote a BBS or a game crack. Nowadays it can refer to any demo written within a strict size limit, such as 4 kB or 64 kB. Also, any demos written for announcement purposes (such as demo party invitation) are typically called intros regardless of the actual size.
Many demosceners reserve the term "demo" exclusively for "non-intros", that is, full-length demos that compete in demo competitions rather than intro competitions. However, the current trend of squeezing a "whole demo" within a strict intro-like size limit has decreased this kind of division.
Most demo parties have at least one intro competition, where the rules are nearly the same as in the main demo competition, with the exception of the size limit of the executable file. The most common intro types are the 64K intro and the 4K intro, where the size of the executable file is limited to 65536 and 4096 bytes, respectively.
Some intro types defined by their content rather than size may also have their own names. Crack intros or cracktros, attached to a cracked game, are perhaps the oldest category of intros. Invtros (or invitros) are demos or intros which serve as invitations to demo parties. A birthtro (or borntro) can announce a new demo group, while a memtro can announce a new group member, and a jointro can recruit others. For "real life" events, there have been wedtros to announce weddings and even babytros (also called birthtros) to announce the birth of a child of a demo scener.
The term dentro, much less common than demo and intro, can either mean a demo in between an intro and a full-length demo in size, or a short preview of an upcoming demo.
A megademo is a demo that consists of >1MB data. An 880K Amiga standard disk plus the packing advantage has a size of 1MB, which qualifies as a megademo. The first trackloaded demos (short: Trackmos) and megademos were released in 1987 on the Amiga. Megademos are quite uncommon on today's demoscene.
The term megademo was often used on 8-bit computers, where 1MB of data would be unusual or impossible, to describe a multi-load demo in several parts, larger than a typical demo. For example, Shock Megademo on the ZX Spectrum was closer to 100 kilobytes in size. Or on Commodore Plus/4 classic 'press space' Oldschool megademo and Oldschool megademo 2.
As the demoscene grew and demogroups became more competitive in terms of what they could accomplish, so megademos developed and became more elaborate. Megademos soon became collections of demoscreens that were brought together under one compilation, usually written by the same demogroup, but often featuring one or more guest demos by a member or members of other demo groups. These demos were accessible from a 'main menu', the style of which varied from the user selecting a demo from a simple list of names, to a more interactive method of choosing a demo, such as using the keyboard or mouse to navigate an avatar (such as a stick man, race car or spaceship) around the display until a demoscreen was found and activated.
These megademos usually followed the same format, whereby one or two intros were first displayed, and then the main menu was presented so that the user could select which demos he or she wished to view. There were often one or more 'hidden' demoscreens available in megademos, where the access point was hidden, or a certain key combination had to be entered by the user to reveal the hidden demo. Hints to the existence and method of access to any hidden demos could usually be found by reading the scrolling texts of one of the other demos within the megademo.
As megademos became more and more popular, the number of demoscreens available would increase in size and often span two or more disks, requiring the user to swap disks between the main menu and whichever demos resided on the second disk.
Since the early 1990s, the predominant demo format has been the trackmo, in which visual effects follow a set timeline, synchronized to a continuous soundtrack, much like a music video. The word "track" also refers to the data tracks of a floppy disk, and therefore, to be called a trackmo in the original sense, the demo should run from a diskette and use a custom-made trackloader to read data from it. The first trackmos included "Enigma" (1991) by Phenomena and "Mental Hangover" (1990) by Scoopex, both on the Amiga.
Demos consist of program code, graphics and music, which are traditionally considered the three main elements of a demo and associated with the coder, graphician and musician, respectively. The overall design is also considered very important, although most groups lack specialized designers.
Demos are executable programs, and the program code created by the coder is still considered a very important element of a demo. Although there are programs known as demomakers or demotools that allow the creation of technically decent demos without coder involvement, demo groups not using any code of their own are still widely frowned upon. It is not customary to release the source code for a demo for various reasons although a handful of notable demos have had their source code released.
Earliest demos were typically made in machine code monitors, the same programs that were used by the crackers to crack copy protections. The next step was the transition from monitors to assemblers.
Higher-level programming languages, such as C and C++, started to gradually take over assembly programming in the demos of the 1990s, when cycle-level timing was no longer considered as important as before and compilers were beginning to be able to produce code comparable to hand-coded assembly. The transition to higher-level languages originated in the PC scene.
Nowadays, demos programmed in pure assembly are rare on the PC (except for the extreme size-restricted categories), but assembly is still widely considered the only relevant choice for democoding on eight-bit platforms such as the Commodore 64.
Snippets of program code performing visual tricks, collectively called effects, have always been an integral part of demos. Effects are often used to show off the programmer's skills, although they're seldom used as stand-alone content elements any more. See demo effect.
Executable compression has been used in demos since the very beginning: pirated software needed to be packed into a compact and easily spreadable format, which often required some kind of compression for both the software itself and the attached intro. Early demos often had multiple parts which were separately decompressed into memory during the short pauses between parts.
The demos and intros for modern platforms are compressed either by general-purpose executable compressors (such as UPX) or programs specifically designed for the compression of small intros. The decompressor stubs integrated in 4K intros are often well under 200 bytes in size. Some Windows-based 4K intros may even wrap themselves inside DOS-based .COM executables in order to eliminate the header bytes. Decompression facilities provided by the operating system may also be used.
Many size-restricted intros use procedural techniques to generate content such as textures, 3D objects and music. Some of the ideas were pioneered by The Black Lotus in their PC intros such as Jizz and Stash. Nowadays, the achievements of the Farbrausch group are well-known.
Procedural generation is often disguised as compression in order to increase the amusement value. See, for example, the end scrollers of The Product by Farbrausch and Zoom3 by AND.
Recently, competitions have been held for procedural rendered graphics that have to fit into an executable file of 4 kilobytes. These pictures often consist of landscapes and the size of the executable file is the challenge.
Demos written for older platforms often use hand-tailored video modes rather than standard ones. Some examples:
FLI (Flexible Line Interpretation) makes more colorful pictures possible on the C-64 by diminishing the size of the "character chunk". IFLI (Interlaced FLI) swaps between two FLI pictures between screen refreshes, enhancing both resolution and color palette. The display areas in most home computers were surrounded by borders, which could often be removed with special undocumented tricks. The removal of borders made it possible to implement full-screen graphics images and demo effects. Mode X was commonly used in VGA-based MS-DOS demos, allowing resolutions up to 360x480 in 256 colors along with decent double-buffering. Pseudo-truecolor was an 18-bit color mode based on separate red, green and blue scanlines in Mode X. APAC mode is a mode special to the Atari 8-bit family by alternating the GTIA graphics modes for 16 hues and 16 shades each line to produce an blending effect on Television sets with 256 colors in 80x96 pixels resolution. Quickly changing the color attributes on the ZX Spectrum each line, to overcome the 2-color limit every 8x8 pixel cell is often called "Multicolor", probably from the C-64-specific term describing the 160x200 mode with 4 colors at least. Technically it's closer related with the C-64 FLI technique. "Multicolor" is also used for software-driven low-resolution graphics modes like 64x96/64x48 in almost 15 colors for very colorful but less blocky effects in contrast to 8x8 pixel blocks. However, these modes are so critical with timing, that they often don't work different Spectrum models and are usually only work on one specific model. (Spectrum 48/128, 128+2, Pentagon...) Split-rasters are often a compromise between high-resolution modes, that offer not many color per rasterline and blocky modes with many onscreen colors. They are often found on older systems, where no character-cell-based color attributes exist such those of the Spectrum and C-64. Most common on the Atari 2600, Atari 8-bit computers and the Amstrad CPC where usually 4 colors or less are found in the highest resolution modes. With this technique, the CPU follows the raster-beam of the screen and changes one of the colors in mid-line. This has to be done by carefully synchronizing the program code with Interrupts and knowledge of how many cycles opcodes need. This also incorporates displaying 2 or more different video-modes in a row rather than on top of each other, more Sprites than usually possible or even enhancing the playfield on the Atari 2600. Drawing 2D art for newly invented graphics modes often require sceners to first write graphics editors of their own. Recently, this has become less difficult because of crossplatform tools like Graph 2 Font for the Atari 8-bit computers or Grafx 2 for the Amstrad CPC.
Music is generally an integral part of a demo and the lack of a soundtrack is tolerated only in size-restricted intro categories.
Before the advent of general-purpose music editing software, the music in the earliest cracktros and demos was often ripped from games. However, as music programming developed in the 1980s groups began creating music specifically for their demos. Certain early groups even specialized in music, such as Vibrants and Maniacs of Noise. Early soundtracks were typically chiptunes, a synthetic style which originated with the video game music of the 1980s. The "Oldskool" chiptune style was continued in later Amiga, Atari and PC intros due to its efficient use of memory, even though these systems often allowed the playback of full digital sound samples. The development of sample-based trackers in the 1980s and 1990s greatly affected the styles of demo music, making it possible to program many genres of music, although variants of electronica and techno music were most widespread. Today, most demo music remains electronic, even though streaming formats allow the use of any type of soundtrack. With less limitations on sound playback, demo musicians may use professional music sequencers and other audio tools to create more complex soundtracks than was possible with earlier tracker software.
Many demo groups have created music editors of their own, some of which have been released as general-purpose music editors in their own right. Well-known examples include the classical PC trackers Scream Tracker and FastTracker by Future Crew and Triton respectively, and the modular synthesizer Buzz by Jeskola. On the Amiga platform, the Protracker format was almost universally used as it allowed playback with very little CPU overhead.
In most demos, the music is played back by a stock player routine such as a module player, MP3/Vorbis player or a routine specific to a music editor. Specialized players are also common, particularly in size-restricted intros. Modern 4K and 64K intros often contain a software synthesizer which may even have been written with a specific song in mind.
In demoscene parlance, graphics or GFX typically only includes the work of the graphician - that is, still images, textures, charsets (short for character sets such as monospaced fonts), 3D scenes, 3D objects and color schemes. Effects and other code-related visualization is usually not regarded as graphics.
The traditional form of graphics art in demos is pixel art, which has been made with dedicated editors or commercial graphics software such as Deluxe Paint. The still images in modern PC demos are usually made with industry-standard software such as Adobe Photoshop.
The technical skills of an artist were often stressed far more than originality or imagination, which gave birth to many graphics-related clichés in the demoscene art of the 1990s. Sci-fi and fantasy themes with dragons, swords and spaceships were very common, as were images of women, both clothed and naked.
The earliest 3D objects and scenes in demos were often very simplistic and were constructed by the coder, often without any modeler-like software whatsoever. Nowadays, many demos have several complex 3D scenes but lack still art entirely.
In the mid-1990s, many groups had advanced 3D routines capable of dealing with complex objects but lacked members skilled or interested in 3D modeling. This lead many demos to only have simple procedural objects such as dones or example file objects such as ducks and teapots. The use of these stock objects is the origin of a lot of insider humor within the demoscene.
Design, in its broadest sense, refers to everything that combines the separate elements of a demo into a consistent whole, down from the low-level synchronization of soundtrack and visuals to the overall choices in concept, structure and narrative.
Melon Dezign, active on the Amiga in the early 1990s, is known as one of the first groups that paid a considerable attention to design aspects.
Traditional recurring elements
While the demoscene itself is already a long-running phenomenon, to this day, a lot of demos have common elements which are reiterated in most modern demos as well.
"Fuckings" to a member of the Andromeda demogroup It is traditionally standard in demos for the creators to send greetings (or greetz) and well-wishes to other demoscene groups, typically of the same platform. While these were often used in scrollers in the early days, in current, graphically more complex demos, greets are usually presented through a demo effect, such as mapping the group names onto objects or using particle systems to fill the letters of the groupname. Being greeted in a demo is usually considered an honor, especially when the demo is high-quality. While there is no rule on whom one should greet, tradition dictates that groups send greetings to other groups whom they consider their friends. Other groups, usually newcomers to the demo scene who don't have sufficient contacts, prefer to greet groups whose works they consider influential or high-quality. Some groups occasionally send greetings to individual people.
Greetings sometimes include "fuckings", in which the creators can explain their dismay about another group's productions or behavior. Fuckings were more common in the early days of the demoscene, but are quite rare nowadays, and mostly used for comedic effect only. One "fucking" in a demo appeared in "Nexus 7" by Andromeda, in which a voxel scroller said "The infinite Andromeda sends fuckings to -Lord Helmet- of Spaceballs for being a pathetic figure and a pityful [sic] liar!"
It is very important in a demo to display a list of names of people who made the demo. These are also usually presented through a graphical effect, but some groups prefer a cinematic approach and present the credits during the opening scene as movie-like overlays, or have them as an end scroller. Credits in demos, however, rarely feature the creators' real names, opting to use for their handles instead.
There are a few recurring elements in demos, which - sometimes due to the technicalities of demomaking, but sometimes because of a certain trend in the scene - tend to reappear over the years.
When 3D was first introduced to the demoscene, good 3D artists were so few and far between that people were somewhat forced to use existing stock 3D models found bundled to 3D software. This caused a recurring phenomenon of ducks, teapots and faces (3D Studio), or dolphins (Lightwave) in demos. While nowadays graphics artists are using 3D on a very common basis, these objects sometimes still appear as an amusing retro-reference in demos. With the introduction of the Internet, demoscene forums (most prominently Pouët) have spawned a considerable number of injokes and insider humor, which eventually appear in demos. The bouncing ball
Historically, the bouncing ball has been a popular theme in computer demo effects since the 1950s, when a bouncing ball demo was released for Whirlwind computers. It later became the primary theme for the early Atari games Pong and Breakout. Commodore released a bouncing ball demo at the 1978 Consumer Electronics Show, to illustrate the capabilities of the VIC chip. A similar theme was used by Amiga Corporation to demonstrate the capabilities of the Amiga computer at the 1984 Winter Consumer Electronics Show in January 1984. It was a real-time animation showing a red-and-white spinning ball bouncing and casting a shadow, this bouncing ball became the official logo of the Amiga company. Within the context of this tradition of bouncing ball demos at the Consumer Electronics Show, CBS Electronics also showed a Bouncing Ball demo for the Atari VCS/2600, with a spinning and bouncing ball, at the same event. Following these semi-official demonstrations the bouncing ball theme has reappeared in various demoscene productions.
Wikipedia Link To The Article
How To Demo
How to Demo Your Software Product – Lessons from 200 Demos
Show Us Your Deck
nate west How to Demo Your Software Product Lessons from 200 Demos Don of the Demo
This is a post from Nate Westheimer that originally appeared on his blog.
After running the NY Tech Meetup for nearly two and a half years, and personally curating and coaching over 200 demos, I’ve learned a thing or two about what makes a successful software demo.
First, let’s define a a “successful software demo.” A successful demo is comprised to two important outcomes, no matter the audience:
As a whole, the audience comes away with some level of consensus that you’re a smart, self-aware person doing worthwhile things. At least 1 person in the audience has an “ah-ha” moment and comes away with a mission to help your product succeed, either by providing a critical feature idea, a hire candidate, potential partnership, or — in the case of a demo to investors — the desire to fight to invest. So, how can you deliver the best demo possible, no matter what time you’re given? Follow these rules:
The Core: Software is Magic. A Demo is a Magic Show.
All software have this in common:
There are inputs. Those inputs get processed by all of our hard work and labor that goes into our software. And there are outputs which are nothing short of magical. For a product like Aviary, the magic is quick, visual, and has a lot to do with the complexity of the software. Drag an image over a filter (that’s the input) and a totally new image pops out the other end (that’s the output).
For Meetup.com, it’s the same, but different. You have inputs, which comprise the creation of a group and scheduling a time to “meetup,” but the output (the magic) is — in the case of the NY Tech Meetup — 860 passionate people in a room all at once.
Aviary and Meetup — both have inputs, both have magical outputs. That’s software at work.
So, it’s pains me when people come to demo and, instead of putting on a magic show — showing off how humans (themselves) and software interact — they try to inspire the audience through their words and by speaking about their ideas; or, just as bad, they flip through a bunch of preloaded tabs in an effort to “show” the product, as if pre-loaded tabs are any better than PowerPoint slides.
Flipping from tab to tab is like showing a tiger in a cage at a magic show, but having never shown the audience that the tiger wasn’t in the cage in the first place! Yes, that will save some time — 5 seconds of page-loads here and there certainly add up — but what people don’t understand is that those 5 seconds of page-loads are the magic we’re looking to see. A magic trick is about experiencing a process, not looking at a before and after picture.
You put in an input (a click? a swipe?) and the output was magic (a new page? interesting restaurant recommendations? a room chock full of people?).
(Want to see one of the NYTM’s best demos ever? Check out John Britton’s famous Twilio demo here.)
The Preamble: Demo the Problem. Don’t Talk to it.
There are many people for whom demoing their software comes very naturally. Still, there is one major mistake they make leading up to the part of the program where they show their software: they talk about why they built it.
Talking is always a mistake during a demo. If you’re talking, you’re not showing, and while anyone can talk a good game, not everyone can show one.
More practically speaking, telling the audience about why you’re in business is not nearly as powerful as showing them why you’re in business.
Instead of spending the first 10% – 20% of your demo telling your audience why what you built matters, take the time to demo the current state of affairs: the “why” your software matters.
A great example of this recently at NYTM was the Matchbook demo. When Jason showed up at the May NY Tech Meetup, he asked to spend a few seconds talking about “why” they made Matchbook. When we dug into the issue, it seemed that most people were keeping lists of places they needed to checkout on the iPhone’s native Notes app.
When I heard that, I thought like it sounded like the perfect problem to demo. Jason then loaded his iPhone’s Notes app with a lot of tips, opened his demo by showing them, and stole the show.
At the end of the day, it’s okay to demo someone else’s application if it helps illustrate why your app is so great. Most great products are alternatives to existing hacks, so show the existing hack — get the audience on your side by relating to a pain they already experience — and dive right into the meat of the demo: the way you change everyone’s life for the better.
Two small but still important points: Keep it Simple and Stay Cool
Keep it Simple
Some services are barebones and elegant, and others are feature rich. For the barebones, it’s easy to focus on the big main idea behind the process when demoing. However, for the feature rich, people always seem to get bogged down by the nitty-gritty. “And we have the ability to share this new ‘doodad’ on Twitter.”
Even if your app has a lot of features, leave many of them out of your demo. Leave something for the users to discover on their own while browsing. Anyway, sharing on Twitter is useful to some people, but it’s magic to no people — so just leave that kind of stuff out.
Lastly, when it comes to demos there are so many points of failure. The Internet connection of the venue you’re demoing in, the Internet connection of your webhost, the browser’s configuration you’re demoing in, Flash’s overall shittyness, and even your own stumbling trying to type and talk at the same time.
Believe it or not, if something goes wrong while you’re demoing, the audience won’t pass judgement on you at all. However, the audience will pass judgement on how you react in times of stress.
When something goes wrong, do you freak out? Go completely silent?
People are drawn to those who handle stress like nothing ever happened. If you can keep your cool, keep talking, get a few jokes out, and find a creative way to let the show go on, you’ll win more hearts and minds than if all the technology even worked. Remember, generally speaking the point of a demo is to get people to think that you’re a smart person doing worthwhile things.
Someone who can handle a bump in the road looks like a smart person.
Smaller and bigger
This will display smallish (normal size).
This will display huge.
This is a weird look too.