A little something I worked on over the last month or so for the oldschool intro compo at Demobit this weekend, where it ranked first (out of... two...) Contains some HDMA abuse and attempts at semi-fast realtime 3D without a coprocessor. Totals a bit smaller than 64kb.

Most of the code was written as experimental stuff at a few points throughout late 2017, and then around the new year we decided to put it together into an actual production. I used Optiroc's libSFX tools/library (which I also helped out with a bit during development) and snesmod for music.

Excellent, I really like the music, and the polygon graphics / blending are great!

Kudos for finishing it, and I'm eager to see your next release!

One silly question from a newbie SNESdev: How are you doing the "title blinking". Do you use an identical graphical data with a dynamically modified palette, or did you simply make a small "blinking" animation using different sprites / tiles data?

Thank God somebody made this demo. Now I have stuff to show if anybody says that the SNES can't do polygons without a Super FX chip.

There actually is another demo out there that pushes about the same number of polygons at the same size and framerate. Of course, for a person's first demo though, this is excellent.

We all know the main problem with producing 3D on the SNES though, is having to convert the framebuffer to the SNES graphics format once the frame is done, unless you can find a way to render unshaded polygons on a framebuffer using the SNES graphics format at a faster speed.

Even at its smallest size/number of faces, this is never running at more than 20 fps, whereas my large cube is a constant 30fps (and would probably get a little higher at a size that small). The other (24-face) shape runs between 15-20 fps depending on how much else is happening (unfortunately all the stuff happening in the NMI keeps it ultimately locked at 15).

(If you're talking about a different demo that I've somehow forgotten about, then never mind )

There's also not really any "conversion" needed on the software side if you make good use of $2115. I can demonstrate better once I get around to releasing the source, but basically I render into two separate 1bpp buffers and DMA them individually such that they're basically "converted" to 2bpp on-the-fly.

drludos: The flashing logo just uses some alternate palettes which are generated from the normal one by bitwise-ORing the colors with a few increasing shades of grey. (I could have also just used multiple pre-made palettes, but doing it programmatically on the SNES seemed easier somehow)

Even at its smallest size/number of faces, this is never running at more than 20 fps, whereas my large cube is a constant 30fps, and the other (24-face) shape runs between 15-20 fps depending on how much else is happening (unfortunately all the stuff happening in the NMI keeps it ultimately locked at 15).

Okay then; nevermind.

Revenant wrote:

but basically I render into two separate 1bpp buffers and DMA them individually such that they're basically "converted" to 2bpp on-the-fly.

What would you have to do to get 4bpp? 2bpp is pretty much irrelevant for an actual game.

4bpp is probably doable the same way (the "address translation" and "increment after high/low" bits in $2115 are the key). At that point you'd have to be more careful about DMA bandwidth, though; ultimately I'm DMAing 128x128x2bpp of pixel buffer which takes nearly the entire vblank period.

Basically, the value of "f(t)" (where f(x) is some relatively simple sinusoidal function and t is a frame/tick counter) is added to the current scanline number and then used as the parameter to two other similar functions which determine each scanline's horizontal position (with an appropriate phase difference between the two twisters) and the actual twist position (which you can probably guess is just vertical scrolling, and each of the two layers uses a different function for this part).

f(t) is also used for the translucent twister to determine per-scanline color math settings for the "in front/behind" pseudo-3D thing.

So basically the horizontal movement as well as the actual twisting are just functions of the frame and scanline numbers (something like "sin(y + sin(t))"; that's not literally the equation since there's some additional frequency/amplitude/phase twiddling going on but you probably get the idea).

It's calculated the same way for the top and bottom as it is for every individual scanline (or rather, every two scanlines) in between, using a combination of elapsed frames and the scanline number (and two or three lookup tables for some fairly basic sine-based curves).

It's not really as sophisticated as it might look, I just generated some sinusoid tables and experimented with ways to combine them and factor in frame/scanline counts until it looked sort of cool. I couldn't really tell you any exact equations or anything without trying to "un-work" a bunch of loops and lookup tables

Even at its smallest size/number of faces, this is never running at more than 20 fps, whereas my large cube is a constant 30fps (and would probably get a little higher at a size that small). The other (24-face) shape runs between 15-20 fps depending on how much else is happening (unfortunately all the stuff happening in the NMI keeps it ultimately locked at 15).

15 FPS is still twice as good as Starfox, and without a coprocessor, I'd say that's a feat. Of course, running a game at that speed is an entirely different challenge altogether. But I'm looking forward to seeing where SNES demos will go from here. I feel like the hardware should allow programmers to get way more creative than what the MegaDrive allows.

Who is online

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot post attachments in this forum