It is currently Tue Aug 21, 2018 8:29 am

All times are UTC - 7 hours



Forum rules


Related:



Post new topic Reply to topic  [ 31 posts ]  Go to page Previous  1, 2, 3  Next
Author Message
PostPosted: Mon Feb 05, 2018 4:21 am 
Offline

Joined: Mon Mar 30, 2015 10:14 am
Posts: 275
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 .


Top
 Profile  
 
PostPosted: Mon Feb 05, 2018 8:59 am 
Offline

Joined: Sat Apr 25, 2015 1:47 pm
Posts: 408
Location: FL
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.


Top
 Profile  
 
PostPosted: Mon Feb 05, 2018 4:31 pm 
Offline

Joined: Fri Jul 04, 2014 9:31 pm
Posts: 960
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...


Top
 Profile  
 
PostPosted: Mon Feb 05, 2018 4:54 pm 
Offline
User avatar

Joined: Thu Mar 31, 2016 11:15 am
Posts: 337
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.


Top
 Profile  
 
PostPosted: Mon Feb 05, 2018 5:37 pm 
Offline

Joined: Fri Jul 04, 2014 9:31 pm
Posts: 960
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 1127 times ]

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

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

Quote:
Don't quote me on it.

Oops...


Top
 Profile  
 
PostPosted: Mon Feb 05, 2018 5:58 pm 
Offline

Joined: Wed May 19, 2010 6:12 pm
Posts: 2733
Is the SNES demo just drawing front facing polygons, like the NES demo does?


Top
 Profile  
 
PostPosted: Mon Feb 05, 2018 7:13 pm 
Offline

Joined: Sat Apr 25, 2015 1:47 pm
Posts: 408
Location: FL
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).


Top
 Profile  
 
PostPosted: Tue Feb 06, 2018 1:43 am 
Offline

Joined: Thu Feb 07, 2013 1:15 am
Posts: 115
Location: Sweden
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.


Top
 Profile  
 
PostPosted: Tue Feb 06, 2018 3:56 am 
Offline
User avatar

Joined: Thu Sep 15, 2016 6:29 am
Posts: 706
Location: Denmark (PAL)
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.


Top
 Profile  
 
PostPosted: Tue Feb 06, 2018 4:36 am 
Offline

Joined: Fri Jul 04, 2014 9:31 pm
Posts: 960
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...


Top
 Profile  
 
PostPosted: Tue Feb 06, 2018 5:05 am 
Offline
User avatar

Joined: Thu Sep 15, 2016 6:29 am
Posts: 706
Location: Denmark (PAL)
What do you mean by "per update"?


Top
 Profile  
 
PostPosted: Tue Feb 06, 2018 5:48 am 
Offline

Joined: Fri Jul 04, 2014 9:31 pm
Posts: 960
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?


Top
 Profile  
 
PostPosted: Tue Feb 06, 2018 8:46 am 
Offline
User avatar

Joined: Mon Jan 23, 2006 7:47 am
Posts: 125
BizHawk has a frame advance function, and you can switch it to use a bsnes core.


Top
 Profile  
 
PostPosted: Wed Feb 07, 2018 8:42 am 
Offline

Joined: Sat Apr 25, 2015 1:47 pm
Posts: 408
Location: FL
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.


Top
 Profile  
 
PostPosted: Wed Feb 07, 2018 7:38 pm 
Offline

Joined: Wed May 19, 2010 6:12 pm
Posts: 2733
The most interesting part is the bottom of the "vector plot" doc. That's what does the polygon filling.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 31 posts ]  Go to page Previous  1, 2, 3  Next

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 4 guests


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

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group