May be you can use mode 7 for that,for dealing with chunky rather than planar, and use sprites to avoid a black background .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.
"TwistIT", a small demo/intro
Moderator: Moderators
Re: "TwistIT", a small demo/intro
I like it, a little bit short but cool,and show some interesting effects .
Re: "TwistIT", a small demo/intro
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 ownSumez wrote:Of course, running a game at that speed is an entirely different challenge altogether.
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:Optiroc wrote:Aha, neat trick with the bitplane conversion!
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.
Re: "TwistIT", a small demo/intro
...no?Sumez wrote:15 FPS is still twice as good as Starfox
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...
Re: "TwistIT", a small demo/intro
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.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...
At least that's what I remember. Don't quote me on it.
Re: "TwistIT", a small demo/intro
This doesn't look orthographic to me:pubby wrote:It's also orthographic and not true perspective, which removes the need for the expensive z divide.
For reference, this is the ROM I'm talking about:
Oops...Don't quote me on it.
-
- Posts: 3140
- Joined: Wed May 19, 2010 6:12 pm
Re: "TwistIT", a small demo/intro
Is the SNES demo just drawing front facing polygons, like the NES demo does?
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).
Re: "TwistIT", a small demo/intro
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.Revenant wrote: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:Optiroc wrote:Aha, neat trick with the bitplane conversion!
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.
Re: "TwistIT", a small demo/intro
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 wrote:...no?Sumez wrote:15 FPS is still twice as good as Starfox
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.
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...
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...
Re: "TwistIT", a small demo/intro
What do you mean by "per update"?
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?
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?
-
- Posts: 611
- Joined: Mon Jan 23, 2006 7:47 am
- Location: Germany
- Contact:
Re: "TwistIT", a small demo/intro
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
Super Famicom ("2/1/3" SNS-CPU-GPM-02) → SCART → OSSC → StarTech USB3HDCAP → AmaRecTV 3.10
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.
Here is the (messy) source to this thing. I didn't comment it as thoroughly as I probably should have, but oh well.
-
- Posts: 3140
- Joined: Wed May 19, 2010 6:12 pm
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.