TapamN

Well, it's "256 bytes of x86" (plus X KB of VESA bios) (plus Y KB of FM synth patches) (plus Z KB of microcode) (plus...)

Oof. The gamma on that screenshot.

If you want to see what it's supposed to look like, copy the screenshot into GIMP, go into "Color, Levels" and in the "Input Levels" section, there should be a textbox+spinner with a "1.00". Set that to 0.45.

Ad blockers typically have an option to select something to disable, like a single image URL.

The Sega Dreamcast online RPG "Phantasy Star Online" displayed the current time in beats.

The Galaksija computer used it's Z80 to help generate the video signal. I'm not sure how its implementation compares to your link.

https://en.wikipedia.org/wiki/Galaksija_(computer)

https://media.ccc.de/v/29c3-5178-en-the_ultimate_galaksija_t...

What I use for my phone (Planet Computer Astro Slide) has a Psion 5-style physical keyboard built in.

As a kid, I remember the Windows version from being included on the disk that came with the book, "Windows Magic Tricks," published by Sybex.

Years later, I was surprised to see the exact same cat on a "port" to the Sega Dreamcast VMU (a memory card that can function as a stand-alone device, with a 48x32 pixel screen,) where pressing a button would play one of the animations. It makes a little more sense now, finding out that the cat images were released into the public domain.

Wow, you're not kidding saying that it's cursed. I thought it would adapt a socket to the BGA pads, but it looks like the pins of the replacement CPU just sit naked on the interposer.

https://www.vogons.org/viewtopic.php?t=95704

Weird coincidence, but I had to look through some old files backed up from the computer I was using 15+ years ago, and noticed it had C:\DeusEx sitting right there, with the SDK files in it. I found the function that handles damage in it.

https://pastebin.com/bwjaiDj7

It looks like I misremembered/misinterpreted some stuff. It looks like the top of the head behaves like the sides of the head, extending upward, forming a + shape.

Judging by how the arm/leg damage works, it the collision hit zones rotate with the enemy. Offset appears to be were the collision point is releative to the character's rotation, since it's also used to determine front/back and left/right collision. So for a hit to count as a headshot, it has to hit a cardinal octant of the collision cylinder.

Edit:

Updated diagram: https://imgur.com/a/Mec7HGm

The headshot collision code in DX is broken as well. This is from memory from looking at the DX SDK years ago (+15 at least), but...

The collision shape used for a character in DX is a single cylinder. The game looks at where on the cylinder the collision point of the shot is, and tries to figure out if it's a head, body, or leg shot. It does this by checking how high the collision point is, with the lower X% being legs, top Y% being the head, and the middle being the body.

If a shot hits the head section, it runs some additional checks, and can sometimes still count as a body hit. There was some weird code that, after you stared at it long enough, looks like it ended up splitting the head area into compass aligned 1/8ths (so north, north-east, east, etc) and hits to the N-E-S-W octants would count as a head shot, and a hit to the NE-NW-SE-SW octants would count as body shots. (I couldn't tell if the angles rotate with the character, or are absolute relative to the world.) I think there was also a check for hits on the top cap of the cylinder, so that the hit would have to be close to the center of the cylinder to count as head hit, and near the outer rim would count as a body hit.

Hm, I should just make a diagram. Here: https://imgur.com/a/KG6MF1k

I guess what they were trying to do was make the actual head hitbox a smaller section of the head level, so that a shot that should go over the shoulder and miss would just count as a body shot and not a true headshot. And if you made a test map, with the player and a static test enemy placed in a line, this could work reliably from a fixed position. But when you actually play DX, and approach enemies from various angles, headshots inexplicably fail.

I created a (currently not publicly released) driver for the 1998 Sega Dreamcast's video hardware from scratch. It supports additional features over the driver in the open source homebrew OS, KallistiOS (KOS), like better render-to-texture support (the KOS driver only supports rendering to framebuffer sized textures), tile multipass (which allows for accumulation buffer style effects or soft shadows), and dynamically toggling anti-aliasing on the fly (with KOS it's fixed after init). Some screenshots of my driver can do are here: https://imgur.com/a/DyaqzZD

I used publicly available documentation (like https://www.ludd.ltu.se/~jlo/dc/ and the now defunct dcdev Yahoo Group), looked at the existing open source KOS driver, and looked at the source for Dreamcast emulators to figure out how things worked.

The GPU in the Dreamcast is a bit more complicated than PSX/PS2/GC since it doesn't accept polygons and draw them directly to the framebuffer. It's a tile-based deferred renderer, like many mobile GPUs, so it instead writes the polygons to a buffer in video RAM, then later walks through the polygons and renders the scene in tiles to an on-chip 32x32 pixel buffer, which finally gets written to RAM once.

This allows the Dreamcast to have a depth-only fillrate close to the 360 and PS3 (DC is 3.2 GPix/s vs 360/PS3 4.0 GPix/s), and it basically preforms a depth-only prepass to avoid doing texture reads for obscured texels. It can also preform per-pixel transparency sorting (order-independent transparency) with effectively no limit to the number of overlapping pixels (but the sorter is O(n^2), so a lot of overlap can become very expensive).

To get a working driver for the Dreamcast, you have to set up some structures in video RAM so that the hardware knows what polygons are in what tile. Another thing the driver needs to do is coordinate the part of the hardware that takes polygon commands and writes them to video RAM, and the part that actually does rendering. You typically double buffer the polygons, so that while the hardware is rendering one frame, user code can submit polygons in parallel for the next frame to another buffer.

My driver started as just code in "int main()" to get stuff on the screen, then I gradually separated stuff out from that into a real driver.

Oh, yeah, I am. I forgot about that setting. Switching Standard allows the videos to work for me, while Privacy Badger and uBlock Origin are enabled.

I'm using Firefox 139.0.4 canonical-002 Snap on Xubuntu, and the videos don't play for me. Even when not using private browsing, even when I disable uBlock Origin, even when I disable Privacy Badger (and, of course, I've set NoScript to enable JS for the tab.)

Just a week? I have a USB smartwatch with a 1 year battery life, the Timex Data Link USB.

It not necessarily physical RAM. If you memmap large files, like maybe a large file from RAID or network share, you could still need that much virtual address space.

My favorite trick with <marquee> was to nest them, with different, alternating directions. You could make the contents alternate between scrolling and stopping by setting the inner marquee to travel in the opposite direction at the same speed as the outer marquee. Or do more levels with alternating speeds to make it zip around randomly. I think you had to set a max width for the inner marquees for this to work?

IIRC, Gödel, Escher, Bach discusses comparing chromosome/protein generation and computation.

Some of it, but I'd rather use real hardware.

Shenmue is one of my favorite games. I did a bunch of Ghidra reversing on the Dreamcast version last year, since I wanted to add improvements to it. Like adding bilinear filtering on the sky background, making time run a bit (faster so you can see time specific events like Christmas/New Year more easily,) getting the game to run without disc swapping on an ODE, and adding antialiasing (which would require mipmaps to improve rendering performance, which would require higher texture compression levels to get them to fit, which would require a different texture format that supports that...) I never got around to actually implementing any of that, outside of doing some experiments, like forcing bilinear on all 2D elements.

I don't think I found the sun/moon code (or more likely I did, but didn't realize what exactly it was doing, Ghidra SH4 has serious problems with floating point instructions making following anything that uses them almost impossible) but I did find most of the other time related code for updating the clock/calendar.

One weird thing I found while doing that is about the in-game watch. You always have a watch in your inventory, so you'd think it would be hard coded in, but it's treated like any other item. The game also has code to check if the watch is missing and add it back in anyways. But the code that draws the on-screen clock also checks if you don't have the watch, and won't draw the clock if you don't have it (or at least part of the UI clock logic is disabled, I haven't actually tried seeing what happens if you don't have a watch to verify if my interpretation is correct).

On the PAL version, the code that checks for a missing watch is at 0x0c180dc6 (that's where the code is loaded into memory, subtract 0xc010000 to get the address in 1ST_READ.BIN), and I think the code for drawing the clock (or at maybe it was just updating the hands of the clock?) is at 0x0c18290a.

Dreamcast Shenmue has code to support other video modes, like alternate resolutions (320x240p!), antialiasing, and 24/32 bit color. They're a bit bugged, like when using antialiasing, the 2D elements being squashed into the left half of the screen, and some strange issue with the screen position for the RAMDAC being setting incorrectly, causing the screen to vibrate left/right by a pixel or two, but the 3D models were drawn correctly.

24-bit color worked surprisingly well (even if the flag intended to enable it didn't seem to work, and I had to force it elsewhere.) I would have thought that having less video RAM free would have caused serious problems, but the game just loaded fewer NPCs. It was strange playing without dithering.

It seems like it should be possible to do the X async method without tearing.

When updating the cursor position, check if line being output overlaps with the cursor. If it isn't, it's safe to update the hardware cursor immediately, without tearing. Otherwise, defer updating the cursor until later (vblank would work) to avoid tearing.

Of course, this assumes it's possible to read what row of the frame buffer is being displayed. I think most hardware would support it, but I could see driver support being poorly tested, or possibly even missing entirely from Linux's video APIs.

Does Ken Shirriff have time to look at a 68030?

In 1992, you more options. Your friends could tell you for free, you could stumble on them yourself, or you could get them with a magazine or book (which you didn't necessarily have to buy, you could just flip through it at the store and memorize the cheats.)

I figured out how to fix Hydro Thunder's compatibility issues last year (it would very briefly change the pixel clock). You can either use a Codebreaker code to fix the game if you're running from a real disc, or if you use an ODE, you can patch the disc image.

https://www.dreamcast-talk.com/forum/viewtopic.php?f=5&t=165...

I was hoping, but not expecting, for it to be about the Capcom arcade board.

Also on the Sega Genesis/MegaDrive as F1 World Championship, and a sequel, Kawasaki Superbike Challenge.

True correct behavior would have that if a > b, then a + c > b + c also holds true for all integers, but that isn't guaranteed for wrapping (or clamping.) (e.g. if 250 > 1, then 250 + 10 > 1 + 10 should be true, but with 8-bit wrapping you would get 4 > 11, which is false.)

Usually, speedruns aren't actually faster than the TAS, unless the speedrun used some new technique was developed after the TAS was made. Normally the biggest different is that TASes and regular speedruns use different methods of timing.

TASes are pretty much always measured from power on to last button input required to trigger the credits. With normal speedrun, timing various from game to game, but a common method is timing from selecting new game to the last hit on the final boss. So games with long openings or with interactive post-final boss sequences that have to be played before the credits start would have inflated times on the TAS.

The TAS counts about an extra 15 seconds before the game starts. The TAS reaches the point the speed run stops counting at 18:52, and continues to play out the ending. So the TAS would be measured as about 18:37 using speed run timing, so the speed run is still genuinely faster than the TAS, but less than the official numbers indicate.

It seems like the speed run uses a glitch that the TAS deliberately avoided. From the TAS description:

At the same time, a major new glitch allowing Ecco to go through nearly any wall was not used because the frequency of its use would make the run very repetitive.

Possibly the earliest shipping game with stencil shadows is Severance: Blade of Darkness from 2001 whose shadows look great.

Revolte, for the PowerVR PCX1, had stencil shadows in 1996.

https://www.youtube.com/watch?v=7BvtML5dIuI

The PowerVR PCX1 had hardware support for shadow volumes, which were implemented more efficiently than standard stencil shadows. Rather than drawing the scene multiple times, it basically did a depth-only pre-pass (in hardware, to an on-chip depth/stencil buffer) to determine visible pixels and test the shadow volumes to determine what pixels are in shadow, then it preformed texture sampling and shading afterwards, with lighting brightness adjusted by shadow volume results. It would only shade visible pixels, overdraw would not waste bandwidth on unnecessary texture fetches.

The Dreamcast, based on the successor to the PCX1, also had many games with shadow volumes. The Dreamcast's implementation was more flexible, and its volumes could adjust more than lighting, such as what texture is used, UV mapping, or even what blending equation is used for transparent polygons.

I've managed to get soft shadows on the DC (https://imgur.com/a/DyaqzZD at the end), although it's pretty fill rate heavy, since it falls back to a more standard stencil method and redraws the shadow multiple times.

An LLM does have a model of reality. An LLM's reality is built on the experiences (words) it's been feed.

Humans are similar. A human's reality is built on the experiences (senses) it's been feed. There definitely are several major differences, the obvious one being that we have a different sensory input than an LLM, but there are others, like human's having a instinctual base model of reality, shaped by the effects of natural selection over our ancestors.

Just like an LLM can't tell if the reality it's been fed actually corresponds to the "truer" outside reality (you could feed an LLM lies like the sky is plaid in such a way that it would report that it's true), a human can't tell if the reality it's been fed actually corresponds to a "truer" outside reality (humans could be feed lies like we are in true reality, when we're actually all NPCs in a video game for a higher level).

The LLM can't tell if it's internal reality matches an outside reality, and humans can't tell if their internal reality matches an outside reality, because both only have the input they've received to go on, and can't tell if it's problematic or it's incomplete.

It's not really the addressing modes, but the instruction format. Immediate values on RISC-V are not stored contiguously on certain RISC-V instructions.

On all MIPS instructions, the bits for a immediate add, load constant, branch, etc value are always stored in order.

On RISC-V, the bits are (sometimes) jumbled around. For example, on a unconditional branch, the bits for the destination offset are stored in the order of bit 19, bits 9-0, bit 10, bits 18-11. In hardware, reordering that is free, you just run your wires the right way to decode it. In software, you have to do a ton of bit manipulation to fix it up.

The reason RISC-V does that is to simplify the hardware design.