nesdev.com
http://forums.nesdev.com/

"TwistIT", a small demo/intro
http://forums.nesdev.com/viewtopic.php?f=12&t=17023
Page 2 of 3

Author:  TOUKO [ Mon Feb 05, 2018 4:21 am ]
Post subject:  Re: "TwistIT", a small demo/intro

I like it, a little bit short but cool,and show some interesting effects .

Quote:
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 .

Author:  Revenant [ Mon Feb 05, 2018 8:59 am ]
Post subject:  Re: "TwistIT", a small demo/intro

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:
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.

Author:  93143 [ Mon Feb 05, 2018 4:31 pm ]
Post subject:  Re: "TwistIT", a small demo/intro

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...

Author:  pubby [ Mon Feb 05, 2018 4:54 pm ]
Post subject:  Re: "TwistIT", a small demo/intro

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.

Author:  93143 [ Mon Feb 05, 2018 5:37 pm ]
Post subject:  Re: "TwistIT", a small demo/intro

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:

Attachment:
polynescube.png
polynescube.png [ 25.91 KiB | Viewed 1292 times ]

For reference, this is the ROM I'm talking about:

Attachment:
polynes3.nes [128.02 KiB]
Downloaded 44 times

Quote:
Don't quote me on it.

Oops...

Author:  psycopathicteen [ Mon Feb 05, 2018 5:58 pm ]
Post subject:  Re: "TwistIT", a small demo/intro

Is the SNES demo just drawing front facing polygons, like the NES demo does?

Author:  Revenant [ Mon Feb 05, 2018 7:13 pm ]
Post subject:  Re: "TwistIT", a small demo/intro

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).

Author:  Optiroc [ Tue Feb 06, 2018 1:43 am ]
Post subject:  Re: "TwistIT", a small demo/intro

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.

Author:  Sumez [ Tue Feb 06, 2018 3:56 am ]
Post subject:  Re: "TwistIT", a small demo/intro

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.

Author:  93143 [ Tue Feb 06, 2018 4:36 am ]
Post subject:  Re: "TwistIT", a small demo/intro

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...

Author:  Sumez [ Tue Feb 06, 2018 5:05 am ]
Post subject:  Re: "TwistIT", a small demo/intro

What do you mean by "per update"?

Author:  93143 [ Tue Feb 06, 2018 5:48 am ]
Post subject:  Re: "TwistIT", a small demo/intro

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?

Author:  creaothceann [ Tue Feb 06, 2018 8:46 am ]
Post subject:  Re: "TwistIT", a small demo/intro

BizHawk has a frame advance function, and you can switch it to use a bsnes core.

Author:  Revenant [ Wed Feb 07, 2018 8:42 am ]
Post subject:  Re: "TwistIT", a small demo/intro

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.

Author:  psycopathicteen [ Wed Feb 07, 2018 7:38 pm ]
Post subject:  Re: "TwistIT", a small demo/intro

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

Page 2 of 3 All times are UTC - 7 hours
Powered by phpBB® Forum Software © phpBB Group
http://www.phpbb.com/