Blur Busters Forums

Who you gonna call? The Blur Busters! For Everything Better Than 60Hz™ Skip to content

Raster "Interrupts" / Beam Racing on GeForces/Radeons!

Talk to software developers and aspiring geeks. Programming tips. Improve motion fluidity. Reduce input lag. Come Present() yourself!

Raster "Interrupts" / Beam Racing on GeForces/Radeons!

Postby Chief Blur Buster » 09 Jun 2018, 23:09

Hello Blur Busters Forums readers!

Some of you may have noticed talks of "scanline based" and "raster based" or "lagless VSYNC" or "beam racing" recently in modern graphics programming -- as a method of reducing input lag for things like emulators, virtual reality, and other lag-critical applications. This is all raster-based stuff!
- Virtual reality beam racing programming (Android)
- Lagless VSYNC ON Mode in emulators -- WinUAE/GroovyMAME
- New RTSS frame capping via Scan Line
- Etc.

Before you read further, make sure you have at least a faint idea of the complex "raster programming" involved in the classic programming days -- Atari 2600 TIA, Commodore 64 raster interrupts, Amiga Copper, or any raster technique or "Racing The Beam".

Image
This book is on Amazon.

For those who have never heard of beam racing -- There is a great WIRED Magazine Article about this book.

One of its image is also peripherally useful useful to understand the crazy numbers stuff you see in Custom Resolution Utilities too:

Image
(For Custom Resolution Utility / ToastyX CRU users -- Porches/Sync is hidden offscreen signal data not too dissimilar to this. In reality, bottom overscan = "Vertical Front Porch" in Custom Resolution Utility, and "Horizontal Blank" is actually both the Horizontal Porches/Sync.)

So, now on the topic of beam racing....
VSYNC OFF tearlines are just rasters!
Every tear line created in humankind, are essentially rasters. It was not until roughly 10 years ago that modern computers became fast enough with precise clocks (e.g. RTDSC, QueryPerformanceCounter, etc) -- and this technique is still very little used until latency-critical applications came along. Today, look at what we all have accomplished!

So, with encouraging from me to several emulator authors (and the author of RTSS frame rate capper, too) -- emulator authors included, are now beginning to do modern-era beam racing as methods of reducing input lag (emulators, RTSS, etc). WinUAE now have frameslice based beamracing (synchronization of real raster with emulator raster), and there's also an experimental (unofficial) GroovyMAME patch available.

The Tearline Jedi Demo
(Written by me!)

Now, I'd like to introduce one Blur Busters projects that are currently in progress.
It's a cross-platform raster demo (Tearline Jedi Demo) -- World's first platform-independent rasterdemo -- that works on GeForces / Radeons / Intel / Android GPUs!

The software below compiles on PC and Mac (no #ifdefs in the main module!)

phpBB [video]


While raster-exactness is not needed for emulators due to jittermargin technique (hide tearlines in repeat-frameslicing), Tearline Jedi does require it, so I go above and beyond.

A few of you already saw my earlier "Use the mouse to drag tearline demo". That requires pretty demanding raster-exact precision, so I've wasted a lot of time researching how to pull that off. I needed this code for another project I am doing, so Tearline Jedi is a good raster-learning sandbox!

phpBB [video]


Recruiting Co-Credit

I haven't released the Tearline Jedi demo yet because I'm still debating whether to make it a submission to a demoscene party (e.g. Assembly 2018). Regardless, it will be open source afterwards. (Demoscene submissions allow opensource after demoscene submission).

If any volunteer programmer wants to help me improve Tearline Jedi Demo (the "VSYNC OFF Tearlines Are Just Rasters" concept) to more proper demoscene standards, contact me -- mark@blurbusters.com -- I'd put it up initially on a private git -- and obviously you'd get full credit as a co-programmer with all the creds.

phpBB [video]


The challenge is it is a hybrid between retro era (of raster interrupt era of 8-bit/16-bit platforms) and modern era (powerful GPUs), so if submitting for Assembly 2018 (Thursday August 2nd) as a remote outsider submission. According to rules, one doesn't have to attend. It would have to be a Realtime Demo entry (not Oldskool since it'd run on their modern high-end NVIDIA platform). https://www.assembly.org/summer18/demoscene/participate

And guess what... I think I am the first person to create a cross-platform raster-dependent Kefrens Bars demo that works on Radeons & NVIDIA on both PC and Mac!

Cross Platform Rasters Now Possible

Thanks to a technique that distilled rasters to three minimum requirements:
(1) Existence of precision counters (e.g. RTDSC instruction)
(2) Existence of VSYNC timestamps
(3) Existence of tearlines (aka VSYNC OFF)

With (1)+(2)+(3) it becomes unnecessary to poll a raster register. The position of a tearline is a precision time-based offset from a VSYNC timestamp. Thusly, with some creativity, rasters now becomes cross-platform (works on D3D, OpenGL, Mantle, Metal, Direct2D, etc) as long as the minimum requirements are successfully met. Then it becomes possible to guess the raster-exact scanline position of a tearline to a very accurate margin. (...Any refresh rate. We even found a way to make it work during variable refresh rates too, in the Emulator thread... The raster accuracy is within 1-2% without knowing the signal horizontal scanrate, and within 0.1% accuracy if knowing the signal horizontal scanrate -- minimally on any platform, all one needs is to listen to the VSYNC timestamps / VSYNC events -- the heartbeat of the blanking intervals is all you need to know -- and then using a precision counter to guess the current raster relatively accurately without needing a raster register -- all modern systems have microsecond precision counters available.)

So, here's a little surprise:
The world's first cross-platform raster-generated Kefrens Bars demo!
If you don't know what a Kefrens Bars is, it's a famous demo made back in the Amiga Copper days.. The effect is successfully replicated using raster beam raced VSYNC OFF.

Some of you already know this from private email, but I have decided to post this in this thread, to try and recruit a demoscene submission helper:

phpBB [video]


Yes, it's written in cross platform C# (open source MonoGame engine -- coding is similiar to older Microsoft XBox programming). I intentionally "glitch" the demo at the end by trying to launch software in the background (That messes up the timings, creating genuine rastery glitches), and it crashes near the end due to a bug. But it's really nice to see how the raster glitches with computer loading. 7000 frameslices per second generating Kefrens Bars in real time!

Over 100 frame slices per refresh cycle -- each frameslice is a "pixel row" generated raster-realtime in Kefrens Bars.

This demo is completely impossible to screenshot, given each "pixel row" (roughly ~14 pixel rows at 1080p 120Hz and roughly ~7 pixel rows at 1080p 60Hz -- the Kefrens Bars become higher resolution at lower refresh rates due to more frameslices per refresh cycles) of the Kefrens Bars is a completely separate VSYNC OFF frameslice that is currently being beamraced in realtime with a new custom Kefrens Bars position every frameslice.

The Kefrens Bars algorithm done pixel-row-at-a-time just like Amiga and Copper days, except timings are much more forgiving (timing errors simply manifest itself as pixel-row-height errors, as seen when pausing during the glitched section) -- but other than that, it's a true, bona-fide, fully-raster-generated Kefrens Bar demo. It's simply by sheer GPU brute force that we can now do this crossplatform, on PC and Mac, NVIDIA GeForce and AMD Radeon. (Intel GPUs also work, albiet at much lower frameslice rate).

Thinking: Submit To Demoscene Event?

If any one of you programmers want to help me refine/fancy/improve this "idea" & submit this to one of the demoscene events? (Email or PM me).

And then we'd make this open source right after. This is too simple graphics now, but these can be fancied up / polished more to something that is more appealing to modern audiences while still wowing 8-bit and 16-bit audiences.

I'll just open source eventually -- but I'm holding off to see if I can submit this to one of the demoscene events.

Comments welcome from raster-experienced programmers -- on this hobby side project.

Thank you!
Head of Blur Busters - BlurBusters.com | TestUFO.com | Follow @BlurBusters on Twitter!
To support Blur Busters: Official List of Best Gaming Monitors | G-SYNC | FreeSync | Ultrawide
User avatar
Chief Blur Buster
Site Admin
 
Posts: 4801
Joined: 05 Dec 2013, 15:44

Re: Raster "Interrupts" / Beam Racing on GeForces/Radeons!

Postby Chief Blur Buster » 10 Jun 2018, 14:43

My tweet on this has 25 Likes and over 10,000 views.
The author of the "Racing The Beam" book has retweeted.
Also have posted on the pouet.net forums too.

Even if you're not able to help out, I'm happy to hear suggestions/referrals to others -- email mark@blurbusters.com
Head of Blur Busters - BlurBusters.com | TestUFO.com | Follow @BlurBusters on Twitter!
To support Blur Busters: Official List of Best Gaming Monitors | G-SYNC | FreeSync | Ultrawide
User avatar
Chief Blur Buster
Site Admin
 
Posts: 4801
Joined: 05 Dec 2013, 15:44

Re: Raster "Interrupts" / Beam Racing on GeForces/Radeons!

Postby Chief Blur Buster » 12 Jun 2018, 14:57

OK, new video:

phpBB [video]


Higher frame slice rate than the earlier video, so better looking Kefrens Bars. And extra Kefrens Bars. I glitch it at the end by dragging around a window.
  • An audacious abuse of plain old standard VSYNC OFF
  • Standard GPUs. Standard Direct3D and OpenGL. Standard VSYNC OFF. Crossplatform. Radeon/GeForce. PC/Mac.
  • ~8000 frameslices per second
  • ~8000 tearlines per second
  • Over 100 tearlines per refresh cycle.
  • 1 pixel row per framebuffer
  • Each pixel row is separated by a tearline.
Those are real-time generated raster graphics of Atari TIA lore, with pixels hitting the graphics output in 1/8000sec after Present() or glutSwapBuffers() ;)

Obviously, a crude rasterdemo, but real-raster Kefrens Bars used to require assembly language. This is nerfy-scripty C#. I don't think a true real-raster Kefrens Bars have ever been done in a managed (garbage collected) programming language (C#) until I did this.
Head of Blur Busters - BlurBusters.com | TestUFO.com | Follow @BlurBusters on Twitter!
To support Blur Busters: Official List of Best Gaming Monitors | G-SYNC | FreeSync | Ultrawide
User avatar
Chief Blur Buster
Site Admin
 
Posts: 4801
Joined: 05 Dec 2013, 15:44


Return to Software Developers / Low-Lag Code / Game Programming

Who is online

Users browsing this forum: No registered users and 1 guest