111–120 of 123 posts
Since these are so small I don't see why we couldn't have a "demoscene launcher" with a "mailto:" style protocol handler and just let people click on base64 encoded links to start the demo.
(author here) Well there is http://twt86.co/ You can try samples, write your own code, or create clickable links =)
Earlier quoted context omitted.
Unreasonably impossible as of yet, yes. For handy reference: 8^8: 16,777,216 8^16: 281,474,976,710,656 8^32: 79,228,162,514,264,337,593,543,950,336 8^64: 6,277,101,735,386,680,763,835,789,423,207,666,416,102,355,444,464,034,512,896 8^128: ... 8^256: ? 8^512: hello from the other side of the quantum dimension 8^8 sounds interesting. 16 million reboots of a real {PC,C64,ST,Amiga,Mac,Z80,...} sounds like a collectively…
Thats weird "reference". Why 8 as the base number? Nobody works with 3bit bytes. 8^8 == 2^24 == 2^(8 * 3) == 256^3, i.e. the combination space of three bytes . The smallest category in pouet for reference is 32b (or 256 bits), so 2^256 combinations to brute force. For comparison usually 128bit encryption is considered "safe" and infeasible to brute force. You might be able to constrain the search space to only valid…
My original comment ran the numbers against the OP's "wouldn't that be 256^256?", but I got tripped up by the reply refuting that and saying it was 8^256 instead.
For as-yet unknown reasons my brain has always had a hard time mapping between the real world and the mathematical vacuum, so it was honestly less stressful to risk trusting that comment than try and [figure out how to] figure it out on my own. So I just substituted calculations for 8^n.
Here are the original numbers I supplied:
8^8: 167,77,216
16^16: 18,446,744,073,709,551,616
32^32: 1,461,501,637,330,902,918,203,684,832,716,283,019,655,932,542,976
Thanks.
Hopefully I can figure out those mapping problems one day. I think neurological damage may be involved, or something - I had to resort to button-mashing on my calculator while trying to figure out how many vegetables I could buy for $X given that they were $Y/kg one day at the supermarket. I'm 29.
> In 320x200 mode, instead of constructing X and Y from the screen pointer DI with DIV, you can get a decent estimation with multiplying the screen pointer with 0xCCCD and read X and Y from the 8bit registers DH (+DL as 16bit value) and DL (+AH as 16bit value). The idea is to interpret DI as a kind of 16 bit float in the range [0,1], from start to end. Multiplying this number in [0,1] with 65536 / 320 = 204,8 results…
Earlier quoted context omitted.
It's wonderful. More impressed with this being 64k than the originally posted 256 bytes.
PC64k is the main size constrained demo format, where people do seriously impressive things. 256b is the masochists category, where doing anything at all is hard. 4k intros are in between. It's interesting that the demo scene is very Windows/DOS focused, unlike other hacker scenes. Linux or Mac demos are basically not a thing. You're far more likely to see C64 or Amiga demos.
Earlier quoted context omitted.
PC64k is the main size constrained demo format, where people do seriously impressive things. 256b is the masochists category, where doing anything at all is hard. 4k intros are in between. It's interesting that the demo scene is very Windows/DOS focused, unlike other hacker scenes. Linux or Mac demos are basically not a thing. You're far more likely to see C64 or Amiga demos.
Well I guess it makes sense after all, because in DOS you kinda have an "API", for instance using the default interrupts you can select video modes, and the video memory is mapped at a fixed offset and so forth. In Linux due to API fragmentation it would be hard to agree on something that works in the future, and even know likely more setup boilerplate setup code is needed.
> In 320x200 mode, instead of constructing X and Y from the screen pointer DI with DIV, you can get a decent estimation with multiplying the screen pointer with 0xCCCD and read X and Y from the 8bit registers DH (+DL as 16bit value) and DL (+AH as 16bit value). The idea is to interpret DI as a kind of 16 bit float in the range [0,1], from start to end. Multiplying this number in [0,1] with 65536 / 320 = 204,8 results…
This explanation was so confusing that I had to write a program to get it clear in my head. https://gistpreview.github.io/?9b252f267cd1fdf9754059bb73a18... More clearly: DI = (y * 320) + x Multiply by 0xCCCD => (y * 0x1000040) + (x * 0xcccd) Take top byte is equivalent to divide by 0x1000000. So that gives you Y. The next lower (third) byte is then (x * 0xcccd / 0x10000) == (x * 52429 / 65536) =~ (x * 256/320). And t…
Earlier quoted context omitted.
I’ve pondered before the idea of a video codec that works like RAR, where the video embeds an arbitrary user-specified virtual machine that can be used to decode the video frames. (How is this not just a program binary? Because it still would have the semantics of a video stream , with no random access to frame data, only tape-head-like access.) Seems like this would be perfect for videos that are just e.g. gameplay…
I think Super Smash Bros records replays as a random seed and user input, then generates the video on the fly from that.
An application state-data format can only be decoded by the original application, because necessary context—in this case, the game engine that translates user input to game-state and then to displayed frames, and also the library of visual assets the game uses to render those frames—is in the application, rather than in the video.
A video format is self-contained, and usually not domain-specific. Many encoders and many decoders can be written to target a video format, and the decoders should not have to ship with an asset library (let alone a game engine) in order to properly render specific videos.
A format like I'm talking about—one that doesn't know anything about application state, but does understand that it's compositing and placing a set of embedded assets each frame, rather than only knowing about pixels/gradels—seems like something generically useful to me. (Heck, we're close to support for such a format already, since many video players already understand the idea of compositing arbitrary stuff with placement instructions on the screen each frame, care of support for the https://en.wikipedia.org/wiki/SubStation_Alpha subtitle format. That format is exactly the kind of "vector video" I'm talking about, except the only primitives it can position and style are text elements. Add RGBA-textured rectangles as another primitive type to it, and you'd get a video format!)
And yes, I'm basically talking about the visual equivalent of a https://en.wikipedia.org/wiki/Module_file (embedded samples/synth patches + sequencing information); or, if you prefer another analogy, "what Flash movies are if you exclude the ability to execute ActionScript."
Earlier quoted context omitted.
It's wonderful. More impressed with this being 64k than the originally posted 256 bytes.
PC64k is the main size constrained demo format, where people do seriously impressive things. 256b is the masochists category, where doing anything at all is hard. 4k intros are in between. It's interesting that the demo scene is very Windows/DOS focused, unlike other hacker scenes. Linux or Mac demos are basically not a thing. You're far more likely to see C64 or Amiga demos.
Back in the day we wanted to have the cool demos at the parties to show off how we managed to do something that others deemed impossible.
Part of the challenge is to match what others did and out win them, without having access to how they achieved it in first place.
Older Macs were never a thing in Europe given how expensive their were, Comodore, Atari and Sinclair machines ruled Europe.
While UNIX and demos never were a thing, those were more the domain of cracking competitions. Trying to gain access to some random university server.
There is a JavaScript implementation of this parallax checkerboards effect with just 140 characters of code, including 3D animated perspective: https://www.dwitter.net/top/all In this page you can also find an implementation of Pouet's tunnel effect.
I am always very impressed when I see these demos and how much can be done with so little. If you are like me you just jumped to Youtube[1] to see it in action. When trying to make my significant other to understand what was happening I wanted to run it myself. I was amazed how simple that was! - Install the assembler[2] - Install dosbox[3] - Get the source[4] and put it into c:\temp\demo\memories.asm - Start nasm an…