/vr/ - Retro Games

>>3078258
>What do you want, convolution using the letter shapes as kernels?
You speak my language. I like you.

>>3078338
All of these posts aren't contributing at all. The thread is about neat tricks on old hardware and how it was done. I don't see examples of tricks in games, nor how they were done, besides the initial post in this reply chain.

Anyway, the title screen effect posted by >>3077721 is cool because frankly I can't think off the top of my head a similar effect in any other game. Technically the rays of light are probably just a palette rotation on static graphics, but the idea and execution are unique, non-trivial (try it yourself and see how well you do), and memorable.

Btw guys, if anyone posts any demo scene stuff, that shit's about as insane as you can get.

To contribute with something else that has stumped me, in SD3, how the hell did they draw the overlays for the spell Rainbow? The ring consists of a high number n-gon (n~20) whos vertexes seem to be transformed and drawn in real time. It just seems like they'd be pushing close to the limit of what could be calculated in a single frame. Granted SD3 pauses gameplay when a spell is firing off, freeing up a substantial amount of cycles for special effects, but either the programmers wrote some slick code, or they just saved a shit ton of data to ROM.

Similarly, Super Metroid's power bomb has an expanding ellipsoid effect. If you watch it in slow mo, you can see the ellipsoid is drawn at different "granularities". I still wonder what they did to draw it, cause it seems like they didn't just draw an ellipsoid, but also had some scaling going on too, which means the ellipse was probably saved to ROM.

>>2902474
>So, yeah, chip on cart draws into RAM on cart. The SNES just takes whatever is in there, and throws it at the screen. Its own graphics hardware is practically bypassed. Of course the SNES itself handles the game logic, ...

Sorry, but no. Nearly all game logic is run on the SuperFX. YI's ROM was connected to both the CPU bus and SuperFX. When the SuperFX is running off the ROM, the CPU can't access it. In fact the CPU has to load a program into RAM and execute from there while the SuperFX is doing it's thing, which is completely unheard of on the SNES unless you are working with such hardware setup. (aside: it's was possible to have seperate ROMs for the SuperFX and CPU, but due to cost, no commercial game ever used this setup)

Also the graphics hardware isn't bypassed in any way, shape, or form. It's actually just the slowness of the stock CPU that is bypassed. Yes, the SuperFX draws character data into on-cart RAM which is transfered to VRAM, but this isn't much different than how a typical game transfers character data from ROM to VRAM. The only difference between the two is the source of the data, not how the graphics hardware is used. The SuperFX is just used to generate data to feed the PPU, not bypass it. In fact the graphics hardware is a state machine. You sick it on some memory, flip a few switches, and it renders a scene. It never actually produces any data on its own.

Actually there is only one way to bypass the graphics hardware on the SNES as indicated by the Engrish riddled dev manual, and that is using Mode 7 with the EXTBG flag set in $2133 SETINI. However this only seems to give you the ability to set a priority flag on Mode 7 tiles, not enable "input from external VLSI" as is said in the manaul, and I know of no game that ever used this feature, whatever it was.