"TwistIT", a small demo/intro

A place where you can keep others updated about your SNES-related projects through screenshots, videos or information in general.

Moderator: Moderators

User avatar
TOUKO
Posts: 306
Joined: Mon Mar 30, 2015 10:14 am
Location: FRANCE

Re: "TwistIT", a small demo/intro

Post by TOUKO »

I like it, a little bit short but cool,and show some interesting effects .
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.
May be you can use mode 7 for that,for dealing with chunky rather than planar, and use sprites to avoid a black background .
Revenant
Posts: 462
Joined: Sat Apr 25, 2015 1:47 pm
Location: FL

Re: "TwistIT", a small demo/intro

Post by Revenant »

Sumez wrote:Of course, running a game at that speed is an entirely different challenge altogether.
It definitely is, and I'm certainly not trying to suggest I could do anything even remotely close to Star Fox without some kind of hardware assistance - when you have to deal with potentially complicated game logic and rendering multiple moving 3D objects as part of a scene, it becomes a totally different ball game. But being able to get reasonable performance from any 3D at all on the stock hardware is an interesting challenge of its own :)
Optiroc wrote:Aha, neat trick with the bitplane conversion!
I honestly wonder if that sort of thing isn't specifically what Nintendo intended the address translation bits in $2115 to be used for. In particular, part of what led me to experiment with it was the way it's described in nocash's docs:

Code: Select all

2115h - VMAIN - VRAM Address Increment Mode (W)
  7     Increment VRAM Address after accessing High/Low byte (0=Low, 1=High)
  6-4   Not used
  3-2   Address Translation    (0..3 = 0bit/None, 8bit, 9bit, 10bit)
  1-0   Address Increment Step (0..3 = Increment Word-Address by 1,32,128,128)
The address translation is intended for bitmap graphics (where one would have filled the BG Map by increasing Tile numbers), technically it does thrice left-rotate the lower 8, 9, or 10 bits of the Word-address:
  Translation  Bitmap Type              Port [2116h/17h]    VRAM Word-Address
  8bit rotate  4-color; 1 word/plane    aaaaaaaaYYYxxxxx --> aaaaaaaaxxxxxYYY
  9bit rotate  16-color; 2 words/plane  aaaaaaaYYYxxxxxP --> aaaaaaaxxxxxPYYY
  10bit rotate 256-color; 4 words/plane aaaaaaYYYxxxxxPP --> aaaaaaxxxxxPPYYY
Where "aaaaa" would be the normal address MSBs, "YYY" is the Y-index (within a 8x8 tile), "xxxxx" selects one of the 32 tiles per line, "PP" is the bit-plane index (for BGs with more than one Word per plane). For the intended result (writing rows of 256 pixels) the Translation should be combined with Increment Step=1.
93143
Posts: 1717
Joined: Fri Jul 04, 2014 9:31 pm

Re: "TwistIT", a small demo/intro

Post by 93143 »

Sumez wrote:15 FPS is still twice as good as Starfox
...no?

IIRC Star Fox is capped at 20 fps (the Arwing at the title screen is a good example), and 15 isn't unusual. Wolfenstein 3D is capped at 15.

I'm wondering how polynes3 was achieved. It seems (can't find a frame advance control in Nestopia) to be pulling off 30 fps with a cube - a big one - in actual perspective. It then proceeds to higher-order polyhedrons at lower frame rates, but still solid-filled. Apparently it uses a bunch of illegal opcodes and is optimized to the rafters, so I can't guarantee that it isn't using precomputed vertex positions or some such...

...

Nice demo, BTW. Good to see more of this sort of thing starting up. Maybe we'll have an answer to Overdrive 2 someday...
User avatar
pubby
Posts: 583
Joined: Thu Mar 31, 2016 11:15 am

Re: "TwistIT", a small demo/intro

Post by pubby »

93143 wrote:I'm wondering how polynes3 was achieved. It seems (can't find a frame advance control in Nestopia) to be pulling off 30 fps with a cube - a big one - in actual perspective. It then proceeds to higher-order polyhedrons at lower frame rates, but still solid-filled. Apparently it uses a bunch of illegal opcodes and is optimized to the rafters, so I can't guarantee that it isn't using precomputed vertex positions or some such...
All vertexes are distance 1 from the origin and that simplifies the math a lot. There's no clipping whatsoever, which obviously means it doesn't have to perform costly clipping operations, but it also means that it can use a fast xor filling algorithm for rasterization. It's also orthographic and not true perspective, which removes the need for the expensive z divide.

At least that's what I remember. Don't quote me on it.
93143
Posts: 1717
Joined: Fri Jul 04, 2014 9:31 pm

Re: "TwistIT", a small demo/intro

Post by 93143 »

pubby wrote:It's also orthographic and not true perspective, which removes the need for the expensive z divide.
This doesn't look orthographic to me:
polynescube.png
For reference, this is the ROM I'm talking about:
polynes3.nes
(128.02 KiB) Downloaded 190 times
Don't quote me on it.
Oops...
psycopathicteen
Posts: 3140
Joined: Wed May 19, 2010 6:12 pm

Re: "TwistIT", a small demo/intro

Post by psycopathicteen »

Is the SNES demo just drawing front facing polygons, like the NES demo does?
Revenant
Posts: 462
Joined: Sat Apr 25, 2015 1:47 pm
Location: FL

Re: "TwistIT", a small demo/intro

Post by Revenant »

Assuming you mean mine, the cube is front faces only, the other shape has front and back faces on opposite bitplanes (using the 3 palette colors to "blend" them).
Optiroc
Posts: 129
Joined: Thu Feb 07, 2013 1:15 am
Location: Sweden

Re: "TwistIT", a small demo/intro

Post by Optiroc »

Revenant wrote:
Optiroc wrote:Aha, neat trick with the bitplane conversion!
I honestly wonder if that sort of thing isn't specifically what Nintendo intended the address translation bits in $2115 to be used for. In particular, part of what led me to experiment with it was the way it's described in nocash's docs:
Yeah, maybe. They must certainly have had bit depth conversion in mind, like using 1bpp font data in ROM and translate it to 2bpp data as it is sent over to VRAM. Who knows if they saw this use case as well.

I've never looked into how the polygonal triforce splash screen in Zelda 3 is rendered. Being an early game with the developers surely in close contact with the hardware team, it sort of serves as Nintendo's canonical example of how to render polygons on stock hardware.
User avatar
Sumez
Posts: 919
Joined: Thu Sep 15, 2016 6:29 am
Location: Denmark (PAL)

Re: "TwistIT", a small demo/intro

Post by Sumez »

93143 wrote:
Sumez wrote:15 FPS is still twice as good as Starfox
...no?

IIRC Star Fox is capped at 20 fps (the Arwing at the title screen is a good example), and 15 isn't unusual. Wolfenstein 3D is capped at 15.
I don't have any hard numbers, but I find it hard to imagine Starfox is running at 20FPS during gameplay. Is there any video out there that measures it? It's surprisingly hard to get details on.
93143
Posts: 1717
Joined: Fri Jul 04, 2014 9:31 pm

Re: "TwistIT", a small demo/intro

Post by 93143 »

I'm getting 4-6 frames per update on Corneria in Snes9X, and the gameplay feels about right to me (I don't think bsnes has frame advance). I did say "capped" and not "locked"...

The beginning of the training level runs at 3 frames per update, or 3-4 once some buildings show up in the distance. This is with maneuver but no weapons fire. There's not much on screen, but it is technically gameplay...
User avatar
Sumez
Posts: 919
Joined: Thu Sep 15, 2016 6:29 am
Location: Denmark (PAL)

Re: "TwistIT", a small demo/intro

Post by Sumez »

What do you mean by "per update"?
93143
Posts: 1717
Joined: Fri Jul 04, 2014 9:31 pm

Re: "TwistIT", a small demo/intro

Post by 93143 »

I'm using "frame" to mean a video frame, and "update" to mean a graphics update - what you'd call a "frame" if you were talking about fps. So 3 frames per update is 20 fps, and 6 frames per update is 10 fps.

I figured it would be evident, but I'm not good at judging how well other people can read my mind (sometimes it feels like they can't do it at all, which is weird because I can read my mind just fine...). I used "frames per update" rather than fps because fps is usually considered an average, and I was just taking a few consecutive point measurements without really trying to average them. I should probably have changed it to "VBlanks per frame" or something, but since I wasn't specifically detecting VBlank it felt pretentious and inaccurate... "frames per frame" perhaps?
creaothceann
Posts: 611
Joined: Mon Jan 23, 2006 7:47 am
Location: Germany
Contact:

Re: "TwistIT", a small demo/intro

Post by creaothceann »

BizHawk has a frame advance function, and you can switch it to use a bsnes core.
My current setup:
Super Famicom ("2/1/3" SNS-CPU-GPM-02) → SCART → OSSC → StarTech USB3HDCAP → AmaRecTV 3.10
Revenant
Posts: 462
Joined: Sat Apr 25, 2015 1:47 pm
Location: FL

Re: "TwistIT", a small demo/intro

Post by Revenant »

https://github.com/ResistanceVault/demo-twistit

Here is the (messy) source to this thing. I didn't comment it as thoroughly as I probably should have, but oh well.
psycopathicteen
Posts: 3140
Joined: Wed May 19, 2010 6:12 pm

Re: "TwistIT", a small demo/intro

Post by psycopathicteen »

The most interesting part is the bottom of the "vector plot" doc. That's what does the polygon filling.
Post Reply