|
i love demos (c64 mostly) because its like the computer equivalent of urbex in abandoned buildings/sewers filled with graffiti. there is always something a little unnerving about them. pretty amazing what they can achieve too nothing like that technicolor chrome effect from the color palette on the c64 also SID chip
|
#
?
May 30, 2015 00:44
|
|
|
|
| # ? May 3, 2024 15:38 |
|
|
Snapchat A Titty posted:i remember there were some short ones that basically just switched between pre-rendered images very quickly to simulate greyscale, but that was all on like TI-82/3s. the TI-99/4A ain't a calculator it appears in one of the cozpops, so i guess that would make it an ideal platform for doing a yospos demo
|
|
#
?
May 30, 2015 00:47
|
|
|
What was the thread this came from again? Edit: was it the yospos bitch thread with people finding new and unique ways to say yospos with code and poo poo? thehustler fucked around with this message at 02:27 on May 30, 2015 |
|
#
?
May 30, 2015 00:57
|
|
|
good thread
|
|
#
?
May 30, 2015 00:58
|
|
|
http://keygenjukebox.com/ for all your beep boop needs
|
|
#
?
May 30, 2015 01:05
|
|
|
This is the best cracktro music http://youtu.be/7K5wrFI_iJI
|
|
#
?
May 30, 2015 02:15
|
|
|
minato posted:It was for a number of reasons. You could reduce memory usage by selecting fewer bitplanes, at the expense of fewer colors. And because you could move odd/even bitplanes separately, it made it easier to do foreground/background movement independently. this one does something kindof in the ballpark of texturemapping, i think, but: no real turns, its p much all "zoom and strafe" for lack of better words. from like 0:10 to 0:40 https://www.youtube.com/watch?v=_5HacABiXUE then later there are some rotating zooms that are pretty cool. intel outside 
|
|
#
?
May 30, 2015 02:43
|
|
|
Snapchat A Titty posted:this one does something kindof in the ballpark of texturemapping, i think, but: no real turns, its p much all "zoom and strafe" for lack of better words. from like 0:10 to 0:40 Conventional image rotation/zoom algorithms "walk" over the destination buffer at a constant speed and copy pixels from the source image at a variable speed / direction. On the Amiga this approach doesn't work well because a there are 8 pixels to a single byte, and multiple bytes-per-pixel for each bitplane. It's straightforward to create an efficient pixel writer that works on consecutive pixels, but not so easy to make a pixel reader that can move in arbitrary speeds/directions across the source image. Without optimizations, reading from source image (X,Y) means: byte offset = y * (imagewidth / 8) + x / 8 pixel mask = 1 << (7 - x % 8) read (image base address + byte offset) AND with pixel mask now a non-zero value means the pixel bit was 1, otherwise 0, so write that to the destination buffer x = (x + x_speed) % image width y = (y + y_speed) % image height [loop around for the next dest image pixel] This algorithm is way too slow, even for a 128x128 destination image. But, you can optimize the above heavily by modifying the source image (at the cost of multiplying its size by 8 times). Instead of storing it 1 bit per pixel, make the pixels 1 byte per pixel. (0x00/0xff if original pixel value was 0/1 respectively). This simple transformation means you can avoid the 3 divides in the above loop, and doesn't require a pixel mask at all for the read. And if you set the image width/height to a power of 2, then the " % image [width|height]" becomes a simple AND operation. So the optimized version of the loop becomes: byte_offset = y << (ln2 imagewidth) + x read (image base address + byte offset) AND with destination pixel mask x = (x + x_speed) & (ln2 imageheight)-1 y = (y + y_speed) & (ln2 imagewidth)-1 ... which is 1 shift and a couple of adds per source read. Much more efficient.
|
|
#
?
May 30, 2015 04:20
|
|
|
thx for the detailed post i just gotta say real quick re:minato posted:I think it must have been run on an A4000 though no, this is exactly as it runs on a vanilla amiga 500 (w 1 mb ram, i forgot if that was an expansion or not). i had one and played that demo for months when i got it. it did not run on a later cdtv which was basically the same hw except +AGA, and with a different ram layout (chip/fast/slow) and workbench 2.0 (boo) instead of 1.3 (yay)
|
|
#
?
May 30, 2015 04:40
|
|
|
almost natlie portmans birthday... Snapchat A Titty posted:(w 1 mb ram, i forgot if that was an expansion or not). it was
|
|
#
?
May 30, 2015 04:56
|
|
|
minato posted:That's a really nice demo, there's a lot going on there under the hood. I think it must have been run on an A4000 though, that 3D stuff at the end was well beyond what a stock Amiga could do at 7.14Mhz. this owns
|
|
#
?
May 30, 2015 04:57
|
|
|
And no one even MENTIONS the joy of MOD files for music? And Scream Tracker? Disappointing, lads, disappointing.
|
|
#
?
May 30, 2015 05:11
|
|
|
Samizdata posted:And no one even MENTIONS the joy of MOD files for music? And Scream Tracker? Disappointing, lads, disappointing. nobody mentions it because it's loving self evident
|
|
#
?
May 30, 2015 05:16
|
|
|
wait til the lads in yospos hear about these Module Files
|
|
#
?
May 30, 2015 05:16
|
|
|
A lot of MOD file authors went on to some success, mostly in the game industry. Some had more success than others, notably DJ Eric Prydz packed out Madison Square Garden recently.
|
|
#
?
May 30, 2015 06:02
|
|
|
the guy who did the Tyrian music when he was 19 later went on to do basically every unreal engine game and is also a voice actor now
|
|
#
?
May 30, 2015 06:31
|
|
|
atari VCS?
|
|
#
?
May 30, 2015 07:38
|
|
|
the old successful finnish game development companies (remedy and housemarque) had a background in the demo scene
|
|
#
?
May 30, 2015 08:26
|
|
|
i rly like the music in this one https://www.youtube.com/watch?v=IFXIGHOElrE
|
|
#
?
May 30, 2015 09:48
|
|
|
minato posted:That's a really nice demo, there's a lot going on there under the hood. I think it must have been run on an A4000 though, that 3D stuff at the end was well beyond what a stock Amiga could do at 7.14Mhz. Filled polygon 3d was perfectly fine for an old 7mhz Amiga as the blitter was able to render filled polygons and I'm p sure I remember Arte to work just fine on on a500. The CPU only had to transform the vertices and clip the polygons. In most case there was no lighting although some did Lambert shading (which is just a dot product per polygon but the annoying part is you needed to have gradients in your color palette) There were quite a few games in those days that managed to do 3d w/ solid polygons on Amiga 500. I remember starglider ii that was even doing it running at a solid 60 fps (it was made by argonaut software who went on to design the superfx chip and make starfox for Nintendo) As you said it was texturing that was hard because of the video memory format that wasn't suited to the CPU changing individual pixels easily which required a "chunky to planar" conversion routine, which cost a lot of CPU even if well optimized The earliest amiga demo I remember doing textured stuff and gouraud shading was origin: http://www.pouet.net/prod.php?which=3741 It also ran on non aga amiga and it blew my mind at the time ("wow they're computing stuff for each pixel") Zlodo fucked around with this message at 12:13 on May 30, 2015 |
|
#
?
May 30, 2015 12:10
|
|
|
per-pixel rendering got a lot easier when GPUs and shaders went ubiquitous this is a 4k PC demo, shorter than a Tom Collins post https://www.youtube.com/watch?v=auagm5UBTwY Edit: and here's how it works http://iquilezles.org/www/material/function2009/function2009.htm Cocoa Crispies fucked around with this message at 14:18 on May 30, 2015 |
|
#
?
May 30, 2015 14:12
|
|
|
here's a 64k one that's really good https://www.youtube.com/watch?v=gfk5Mqy3gpA
|
|
#
?
May 30, 2015 14:22
|
|
|
also this is a pretty neat documentary about ~teh scene~ it focuses a bit too much on Finnish and Hungarian groups but it's a good doc nonetheless make sure to turn on subs https://www.youtube.com/watch?v=iRkZcTg1JWU
|
|
#
?
May 30, 2015 14:28
|
|
|
this is a good thread
|
|
#
?
May 30, 2015 14:31
|
|
|
demoscene combined with touhou, in 170 kbytes https://www.youtube.com/watch?v=fu7rRYkWsyk
|
|
#
?
May 30, 2015 14:34
|
|
|
to make up for that, have the (arguably) best c64 demo ever https://www.youtube.com/watch?v=Zp3oEJemnz0
|
|
#
?
May 30, 2015 14:38
|
|
|
Snapchat A Titty posted:with a different ram layout (chip/fast/slow) anyway i like this demo a lot because its the only one for the system its on: https://www.youtube.com/watch?v=1q-4Ie5wjus
|
|
#
?
May 30, 2015 14:55
|
|
|
Zlodo posted:The CPU only had to transform the vertices and clip the polygons. The traditional way to do 3D is to combine all your rotation/scaling/translation operations into a 4x4 matrix and use it to transform 4x1 3D vectors, followed by a multiply by 1/w at the end to normalize them to a (screenx,screeny,z) tuple. But obviously a stock Amiga 500 had no floating point and terrible MUL/DIV performance (~70/~160 cycles respectively - we should at least be thankful we had multiply and divide, I don't think the C64 does), so vertex transform require a lot of tricks to do it at speed in volume: - use sine/cosine lookup tables instead of calculating them on the fly - loop unrolling (doesn't matter how long your unrolled loops are, you don't have to worry about instruction-cache-thrash because there is no cache!) - perform "ghetto" SIMD. Instead of multiplying A*X then A*Y separately with a MUL (2*70=140 cycles), calculate result=A*(X << 16 | Y), then A*Y = result & 0xffff, and A*X = (result >> 16). This is 1 MUL + some shifting/masking, which is < 100 cycles. But you have to choose your data carefully to avoid overflows. - hard-coded matrix elements (e.g. you're probably not scaling so that part of the matrix is 0/1, so those operations can be skipped) - Avoid screen x/y transformation by having your base screen address be the middle of the screen (more MULs/ADDs to skip) - MUL each vector element by 1/W, not DIV each item by W since DIV was twice as slow as MUL - Choose camera angles so that the model doesn't go off the edge of the screen (so you can avoid having to clip lines), or simply make the screen memory larger than the visible screen area. Once the verts are transformed, then each polygon is processed, starting with a cross-product of 2 adjacent vectors to see if the polygon is actually visible. That's 3 MULs, 2 ADDs and a comparison. This is expensive to do for each polygon. Careful choice of model data helps here; for example, with those tie-fighters at the end of the Arte demo, they can use symmetry and co-planarity to reduce the number of visibility checks: - determine polygon visibility for just 1 poly on the flat side of the "wing". Since other polys on the wing are coplanar, they share the same visibility. - exploit data symmetry. The visibility of a poly on a wing is the opposite to its corresponding poly on the other wing. - share data. If two tie fighters are facing in the same direction at all times, then they have the same poly visibility data. ... so with 1 cross-product calculation, you've determined the visibility of a poo poo-ton of polys. Then you've got Z sorting. There is no Z buffer, so you've got to draw back-to-front with the painter's algorithm. The traditional (and slow) way is to make a list of all the polys to draw, sort the list (an O(n log n) operation if you're smart), and draw furthest to nearest. A smarter way is to use Z-slots. This is a linked list of linked lists. The list starts out with each sub-linked list pointing to the head of the next sub-linked list, and each head is a NOP operation: [0 NOP ]-> [1 NOP] -> [2 NOP] -> ... [N STOP] Then to add a polygon to draw at distance Z, you normalize Z to between [0->N), and insert it into the sub-linked list at that point. (The insertion happens in O(1) time because it's just an array lookup to find the head of the target sub-linked list). Then to render all the polys, you just walk the whole linked list, drawing polygons as you go. (FWIW, this is how the PlayStation 1 GPU did Z-sorting because it didn't have a Z-buffer either). The real tricky problem with Amiga rendering is that it was necessary to clip polygons with respect to other polygons. The blitter could draw the outlines of polygons and fill them in, but it was too dumb to handle the case if lines from 2 different polygons intersected. Performing poly-to-poly clipping is expensive and painful, so tricks were used to avoid it. For example, its known that for a convex object, none of its polys will intersect. So draw two convex objects on different bitplanes, and then sort the bitplanes. This is like drawing the two objects on separate pieces of cellophane, and then sorting the cellophane. quote:In most case there was no lighting although some did Lambert shading (which is just a dot product per polygon but the annoying part is you needed to have gradients in your color palette) Well, the Blitter had a little-used "mask" mode where it could pull data from multiple sources and combine it together before writing. Some demos configured the blitter to either fill polygons with all 1s (mask-mode = off), or enable mask-mode and fill with all 1s AND'd with a mask of alternating 1s and 0s in a checkerboard pattern. The checkerboard pattern looked half as bright as the same poly filled with all 1s, so you get an "extra" color with fewer bits. Put another way: Old way: 8 actual colors, rendered across 3 bitplanes. Color 4 is filled with as [all 1s][all 0s][all 0s] and 5 with [all 1s][all 0s][all 1s] Cheaper way: 4 actual colors (but looks like 8), rendered across 2 bitplanes. Color 4 is filled with [all 1s][all 0s] and 5 as [all 1s][checkered 1s/0s] I was only about 14 when I was doing all this stuff, and although I figured out 3D, I had no concept of matrix math or image processing techniques. A lot of the demo tricks that blew my mind at the time seem really obvious with the 20/20 hindsight and a college degree.
|
|
#
?
May 30, 2015 17:27
|
|
|
thehustler posted:What was the thread this came from again? i don't remember the original thread but that isn't even the original video. this is: https://vimeo.com/11241456
|
|
#
?
May 30, 2015 17:35
|
|
|
minato posted:The real tricky problem with Amiga rendering is that it was necessary to clip polygons with respect to other polygons. The blitter could draw the outlines of polygons and fill them in, but it was too dumb to handle the case if lines from 2 different polygons intersected. Performing poly-to-poly clipping is expensive and painful, so tricks were used to avoid it. For example, its known that for a convex object, none of its polys will intersect. So draw two convex objects on different bitplanes, and then sort the bitplanes. This is like drawing the two objects on separate pieces of cellophane, and then sorting the cellophane. I remember at least one demo where clipping polygons against each other in real time was actually done as a standalone "look what we managed to do" effect though: https://www.youtube.com/watch?v=MyfxuIjdjfE at 1:37 (  because boobs near the end of the demo)quote:There was a trick here too. If you want shading with (say) 8 colors, then once you've calculated the polygons color, you have to render the same poly to potentially 3 bit planes. This is going to be expensive. Can we get the same number of colors with less writes? I had never really investigated the dithering tricks at the time but I figured that there had to be blitter tricks behind them. one I liked was the true color trick that TBL came up with using ham mode: https://www.youtube.com/watch?v=C2CTSY6JbVY ( because boobs too)I had figured that one out and re-implemented that one. It was basically using aga's ham8 (http://en.wikipedia.org/wiki/Hold-And-Modify) at super-hires (1280 pix wide resolution) where 4 native pixels would be used to represent one "logical" pixel, with the first pixel setting the red value of the pixel, the second one would set the green, third one the blue and last one would just be set to "repeat previous pixel color as is". The 6 lower bit were filled using a special chunky to planar conversion that basically took true color, 18-bit per pixel data and shoving in into the 6 lsb of each pixel (and doubling the blue channel accross two successive pixels) I had managed to cod ea few effects like blur and a gouraud software renderer with that but like everything I did back then I never finished anything with it just watched tint again and I didn't remember how garrish it was, then again the whole point was to show off their fancy "look at them colors" technique quote:I was only about 14 when I was doing all this stuff, and although I figured out 3D, I had no concept of matrix math or image processing techniques. A lot of the demo tricks that blew my mind at the time seem really obvious with the 20/20 hindsight and a college degree. same
|
|
#
?
May 30, 2015 18:25
|
|
|
The HAM stuff is pretty cool, I guess it was really underused because it was so difficult to write tools for. It was fine for scanned images, but artists must have hated modifying a pixel and sometimes seeing distortion to the pixels to the right. I recall there was some HAM demo that used both the copper and the CPU to furiously rewrite the color palette every scanline to achieve even more colors on the screen, but it meant the CPU was so busy that it couldn't have any other effects. The demo scene seemed to segment around '94. At that point, you had ECS/AGA Amigas filtering in so people with older hardware couldn't see the demos, and those AGA demos seemed like they were for a different platform - it wasn't ever clear to me how much heavy-lifting the ECS/AGA was doing. Combine that with PCs starting to take off as gaming devices, and DOS4GW making it really easy to write 32-bit PC programs, and that signaled the era of demos with a minimum hardware requirement (as opposed to an exact one). There was, for a while, a resurgence of the demo scene on game console hardware, but the closed nature of the systems prohibited development. ymgve posted:to make up for that, have the (arguably) best c64 demo ever
|
|
#
?
May 30, 2015 19:17
|
|
|
Farmer Crack-rear end posted:atari VCS? yeah it's just adding 1 to the color index each scanline for player graphics and the background which everything did
|
|
#
?
May 30, 2015 19:26
|
|
Luigi Thirty posted:the guy who did the Tyrian music when he was 19 later went on to do basically every unreal engine game and is also a voice actor now Alex Brandon owns and his non-game albums own too. I have a physical copy of Just Fun and I really wish I could get one of Violet Eclectic Speaking of people who worked on Tyrian, the artist Daniel Cook is now a game designer along with being an artist, he heads up Spry Fox and he did the art and game design for Triple Town. He also has a blog where he discusses game design and art, and he has a bunch of his old pixel art and new art he offers for free to budding game developers
|
|
|
#
?
May 30, 2015 20:04
|
|
|
i was gonna try and do a lovely demo on the gba but i decided i cant be bothered today maybe you'll get a flashing neon YOSPOS BITHC tomorrow
|
|
#
?
May 30, 2015 23:47
|
|
|
the french friend that I mentioned which originally started the whole demo discussion in the security thread stopped by to check out this thread, said he was happy to see groups like melon get posted  hi buddy 
|
|
#
?
May 31, 2015 04:14
|
|
|
i still like the second song in this a whole lot https://www.youtube.com/watch?v=oUSypR004Wo and this part of another demo: https://youtu.be/jX0UgvgBuQc?t=691 EMILY BLUNTS fucked around with this message at 04:43 on May 31, 2015 |
|
#
?
May 31, 2015 04:41
|
|
|
EMILY BLUNTS posted:and this part of another demo: there's a high note right at the top edge of my hearing on that one, it's physically painful to listen to 
|
|
#
?
May 31, 2015 04:55
|
|
|
Cocoa Crispies posted:there's a high note right at the top edge of my hearing on that one, it's physically painful to listen to yes everything using this trick seems to have an artifact like this at the the sample rate
|
|
#
?
May 31, 2015 05:06
|
|
|
Cocoa Crispies posted:https://www.youtube.com/watch?v=iQqJm14sHRY that is cool as gently caress. im the robot doing barbell curls
|
|
#
?
May 31, 2015 07:45
|
|
|
|
| # ? May 3, 2024 15:38 |
|
|
Here's a tech demo for the Sega 32x, made in 1995 to show off what the device could do https://www.youtube.com/watch?v=pOWZbydnlZE zyrinx was a game development studio made up of amiga demoscene people, including Jesper Kyd who is imo the best Yamaha FM composer ever One of their games is Red Zone which is pretty much a playable demoscene demo https://www.youtube.com/watch?v=NQxU2CIVb3c some of the assets in the Sega 32x demo show up in AMOK, an action game for the Saturn which is also a playable demoscene demo https://www.youtube.com/watch?v=HGGpEnV_0SM
|
|
|
#
?
May 31, 2015 08:35
|
|