Can someone enlighten me about /vr/ graphical glitches? Why did this happen? I'd just be sitting there and sometime stuff like this would happen. Getting older, I can come to some conclusions like "Maybe it was due to a poor connection in the pins" and other similar things, but can anyone go more in depth for me?
How does that differ from the graphical glitches of today? Say, anything modern 3D from Bethesda when corpses do things "Corspes head stayed in place, the neck melted like pulling the first pizza slice away from the pie, while the rest of the corpse fell under the world"?
"Poor connection in the pins" is actually the right answer a lot of the time, the reason it has this result is because NES games stored their graphics as a set of 8x8 tiles (often on a separate ROM chip from the game's main program ROM) and a poor pin connection would cause it to send the wrong index when it requests a tile and end up with a different one
Here's the full guide on how the NES renders graphics if you want to go in extreme depth: http://wiki.nesdev.com/w/index.php/PPU
Everything else I've found so far is either equally in-depth or way too terse to be useful for someone looking for a rundown on how it works, I'll have to cave in and link an eceleb's explanation: https://youtu.be/Tfh0ytz8S0k
>>3415976
I have an old malfunctioning megadrive/genesis that shows every game just like that, even though they can be "played", all sprites, backgrounds look all garbled.Yeah, tried the games in another system and they do work fine.
I've been wondering for a while if I can fix that somehow, guess I'll do a proper research and try to find help.
>>3415976
That is exactly the kind of thing I'm looking for. Thanks man!
>>3416068
>all sprites, backgrounds look all garbled.
Not a hardware wizard, but sounds like it'd be something work ram being fine(actual game running correctly) but video ram is shot since the graphics are shot.
>>3415976
That's really interesting. Thanks for that.
>>3415957
>How does that differ from the graphical glitches of today?
the "modern" glitches you described are the results of a canned animation going out of sync, and collision detection dealing with floating point errors. The differences between old and new are effectively that the new stuff is entirely in software, while the old glitches had a hardware aspect, as >>3415976 described
>>3415957
sometimes is an hradware problem, like >>3415976
said, but sometime it might be caused by a corruption in software.
Basically the piece of data that keeps track of where to go read the tiles that makes up the graphic get corrupted somehow and now it says a new location. That's what happens with most of the bugs in pokemon red, since those are reproducible. One important difference is that hardware based bugs are a one shot occurence usually.
>>3416068
It seems that the CPU+RAM (and the bus arbiter) is fine, so it might be a problem on one of the two graphic chips. Or the VRAM is busted or the graphic filling chip. If it's the first, you might be able to salvage it by changing it with a modern chip wich support the clock speed of the Genesis. If I remember correctly the genesis VRAM is just a SRAM chip.
If it is the VPU you might be fucked because it should be one of the 2 chips that were sega proprietary, so the only way is to rip it from another genesis.
Anyay if you go on SegaRetro wiki they should have a lot of info on this chips
If you're interested in reading about game glitches on old hardware, I HIGHLY recommend reading Metroixer's old "Let's horribly break Pokemon blue":
http://lparchive.org/Pokemon-Blue/
>>3421156
That's a good one. I recall there are a few on youtube that try a similar route but they update at the speed of a snail. I'd really enjoy something more up-to-date in terms of breaking pokemon apart by exploiting glitches and injecting code and shit like that, but few people has the technical knowledge for it.
>>3421894
there's also one of those for FF6 http://lparchive.org/Breaking-Final-Fantasy-VI/
How come the graphics could get so horrifically corrupted, but the games could still run fine? Shouldn't the binary code be just as corrupt as the binary data?
>>3422565
On the Gameboy, graphics and music were just embedded directly into the assembly as binary data.
>>3422549
the reason older games still keep on chugging even as everything falls apart is cause there's no error checking or memory protection to shut it down and crash it like a newer game
i corrupt the rom and memory for fun sometimes and it's amazing how far gone a game can go on the nes/snes before it finally stops working altogether
>>3415957
This is a interesting topic