yupferris

NTSC-J

Model	Serial	Board	CPU	PPU	SMP	DSP
SHVC-001	SM10938872	SNS-CPU-RGB-02	S-CPU B (5A22-02)	S-PPU1 (5C77-01) / S-PPU2 C (5C78-03)	S-SMP	S-DSP A
SHVC-001	S18362950	SNS-CPU-GPM-01	S-CPU A (5A22-02)	S-PPU1 (5C77-01) / S-PPU2 B (5C78-03)	S-SMP	S-DSP A

PAL

| Model | Serial | Board | CPU | PPU | SMP | DSP |

yupferris

// video generation
// ~12,288,000 hz pixel clock
//
// we want our video mode of 320x240 @ 60hz, this results in 204800 clocks per frame
// we need to add hblank and vblank times to this, so there will be a nondisplay area. 
// it can be thought of as a border around the visible area.
// to make numbers simple, we can have 400 total clocks per line, and 320 visible.
// dividing 204800 by 400 results in 512 total lines per frame, and 240 visible.
// this pixel clock is fairly high for the relatively low resolution, but that's fine.
// PLL output has a minimum output frequency anyway.

yupferris

In 2006, a (then-14-year-old) me wrote Overhead, a 256-byte intro (which was, ehm, "hEavilY InspiREd" by lander, among other intros). It was, for me, an early and highly rewarding experiment in x86 assembly, and huge thanks are owed to Baze/3SC (author of lander) not just for inspiration, but also including source with their intros (a common practice at the time, less common now unfortunately) and helpful responses to my emails asking how some basic things worked (eg. VGA setup and FPU stack).

In the pouët comments, many people reported that it ran quite a bit slower than intended. It was never blazingly fast (I recall 20-30FPS on my box at the time), but some people were reporting eg. 1-2FPS, which was pretty awful.

In a 2007 comment by Pirx, it was mentioned that writing memory at the beginning of the program segment was likely what was causing it to be so slo

yupferris

The last few months have really been a grind, to the point where I'm feeling pretty demotivated/exhausted and I keep getting this idea that I didn't accomplish as much this year as I would have liked... however, this is pretty ridiculous considering the amount of things I objectively did accomplish this year, so I thought I'd write a (non-exhaustive) list to better align my thoughts with reality and give myself more room to take it easy lately without guilt.

In (mostly) no particular order...

• Had a baby! first one too, man, what a ride!
• Moved
• Turned 30
• Norwegian driver's license
• Norwegian citizenship
• Changed jobs

yupferris

Goals

• Input vertex attrib stream(s), output transformed vertex data stream(s)
  • Which stream(s) depend on required capabilities - eg. we don't always want/need lighting
• Vertex transformation/deformation
  • Transform position vector into correct space, write out
  • Should support "spikeballs" somehow - eg. scale object space coords by sinusoid whose phase depends on vertex/thread index
• Vertex lighting
  • Transform normal vector into correct space, dot product with light vector, scale rgba, write out
• Relatively easy to program, probably via assembly (or similar)

yupferris

note: j is used instead of i in these notes as it's much easier to differentiate from 1 in my editor's font :)

So, let's consider a 4-point (N=4) DFT of the following signal:

x = [0, 1, 0, 1]

for regular DFT, we have 4 basis vectors:

 - k=0: [ 1,  1,  1,  1] (exp(-j(2pi/N)kn) for k=0 yields exp(0) or 1 for all n)
 - k=1: [ 1, -j, -1,  j] (exp(-j(2pi/N)kn) for k=1 yields exp(-j(pi/2)n))

yupferris

@ECHO OFF

set OLDPATH=%PATH%

call "C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Auxiliary\Build\vcvarsall.bat" x64 > NUL:

echo #!/bin/bash

echo export INCLUDE='%INCLUDE%'
echo export LIB='%LIB%'

yupferris

diff --git a/rtl/src/color_thrust.rs b/rtl/src/color_thrust.rs
index 58b94d5..5fa8482 100644
--- a/rtl/src/color_thrust.rs
+++ b/rtl/src/color_thrust.rs
@@ -19,15 +19,25 @@ pub const REG_W1_DY_ADDR: u32 = 6;
 pub const REG_W2_MIN_ADDR: u32 = 7;
 pub const REG_W2_DX_ADDR: u32 = 8;
 pub const REG_W2_DY_ADDR: u32 = 9;
-
-pub const REG_COLOR_ADDR: u32 = 10;

yupferris

How would you define livecoding in the demoscene? A sport? An art? Something else?

Definitely a mix of the two. There's a definitively competitive aspect that isn't necessarily present in other livecoding scenarios (eg. algorave) which makes it at least e-sports like, while still being an inherently artistic medium.

What are the reasons a shader wins over another one in a livecoding session and why, in your opinion?

It depends on the audience of course. It's the same with demos - people like what they like. For the demoscene, a cool 3D scene with lots of shiny things will often win. However, sometimes a very stylistic 2D shader will also win if it captures the audience (which is particularly common if it appeals to an "oldschool" palate, eg. by using a classic C64 color scheme/dithering style).

When did you first hear of livecoding in the demoscene?

yupferris

/// **UNSTABLE:** Provides a convenient way to write conditional combinational logic.
///
/// # Panics
///
/// Since this macro rewrites the referenced variable assignments using [`mux`], any panic conditions from that method apply to the generated code as well.
///
/// # Examples
///
/// ```
/// use kaze::*;