It is currently Thu Aug 22, 2019 6:09 am

All times are UTC - 7 hours



Forum rules





Post new topic Reply to topic  [ 23 posts ]  Go to page Previous  1, 2
Author Message
PostPosted: Mon Jul 08, 2019 6:29 pm 
Offline
Formerly Espozo
User avatar

Joined: Mon Sep 15, 2014 4:35 pm
Posts: 3501
Location: Richmond, Virginia
Wow... What framerate is the collision detection happening at? Even after slowing down BSNES, I never saw any instances where the boxes where in the wrong state.


Top
 Profile  
 
PostPosted: Mon Jul 08, 2019 11:05 pm 
Offline
User avatar

Joined: Mon Jan 23, 2006 7:47 am
Posts: 201
Location: Germany
Add some techno music and release it on pouet.net ;)

_________________
My current setup:
Super Famicom ("2/1/3" SNS-CPU-GPM-02) → SCART → OSSC → StarTech USB3HDCAP → AmaRecTV 3.10


Top
 Profile  
 
PostPosted: Tue Jul 09, 2019 10:18 am 
Offline

Joined: Sat Oct 06, 2018 10:15 am
Posts: 23
creaothceann wrote:
Add some techno music and release it on pouet.net ;)


And...
1. Graph a bar representing the number of collisions
2. Some kind of audio representing the number of collisions (volume?/pitch?)
3. Colour each sprite based on speed and cycle through shades of each colour incrementing on collision
4. Add a scrolling message.
And if you still have enough time left...
5. Do it all in mode 7 with an image moving around in the background. (Maybe not possible with the scroller unless split screen?)


Top
 Profile  
 
PostPosted: Tue Jul 09, 2019 5:57 pm 
Offline

Joined: Fri Jul 04, 2014 9:31 pm
Posts: 1076
Drew Sebastino wrote:
Wow... What framerate is the collision detection happening at? Even after slowing down BSNES, I never saw any instances where the boxes where in the wrong state.

The whole thing is 60 frames per second. Compute time varies between frames, of course, but I've never seen it with fewer than about 23 scanlines free between wai and NMI. The method should be fairly resistant to load spikes caused by uneven clustering, and it doesn't care how fast the objects are moving.

creaothceann wrote:
Add some techno music and release it on pouet.net ;)

Do you think this method could serve as a component of a serious demo? I haven't forgotten Titan's challenge...

noyen1973 wrote:
And...

I don't know about some of those. I've only got maybe 9% of the frame left. Scrollers and Mode 7 are one thing; adding operations to the inner collision loop is another... I suppose it might work, but it's hard to say without coding the logic and checking...

I do have a few ideas of my own on how to enhance the presentation - let's just say HDMA is cheap - but I'm pretty busy in real life so none of this is likely to happen soon.


Top
 Profile  
 
PostPosted: Tue Jul 09, 2019 10:58 pm 
Offline
User avatar

Joined: Mon Jan 23, 2006 7:47 am
Posts: 201
Location: Germany
93143 wrote:
creaothceann wrote:
Add some techno music and release it on pouet.net ;)

Do you think this method could serve as a component of a serious demo? I haven't forgotten Titan's challenge...

Sure. Many demos, especially older ones, have screens like this shown with some music for a minute or more.

93143 wrote:
I don't know about some of those. I've only got maybe 9% of the frame left.

You also have the APU, assuming the audio doesn't take all of its processing power.

_________________
My current setup:
Super Famicom ("2/1/3" SNS-CPU-GPM-02) → SCART → OSSC → StarTech USB3HDCAP → AmaRecTV 3.10


Top
 Profile  
 
PostPosted: Wed Jul 10, 2019 5:09 pm 
Offline

Joined: Fri Jul 04, 2014 9:31 pm
Posts: 1076
I should probably post the source code at some point.

There are a number of other ideas I've dreamed up that could be fun to put in a demo. If I had all the free time, I'd love to cooperate on one. Unfortunately I do not, at the moment...

Quote:
You also have the APU, assuming the audio doesn't take all of its processing power.

Unfortunately the APU is so isolated and so hard to talk to that it's not useful for many types of tasks. It can't access ROM, it can't manipulate the PPU, and it can't rapidly share data or do fine-grained multiprocessing with the CPU.

I suppose one could send and receive data with HDMA. My proposed method (assuming it works) should be adaptable to permit APU->CPU transfers, and gives you a practical maximum rate of around 800 bytes per frame at the cost of no more than several scanlines on the CPU side. But of course that would take most of the SMP's compute time just working the I/O ports, leaving very little for music. And it's entirely possible that you'd want to use a fair chunk of that bandwidth to feed the DSP, so you could still end up with a heavy I/O load even if whatever processing task you're offloading doesn't require that much data throughput.

So I guess it depends on what exactly is going on.

(I'm starting to want to try something with the APU...)


Top
 Profile  
 
PostPosted: Thu Jul 11, 2019 6:03 am 
Offline

Joined: Wed May 19, 2010 6:12 pm
Posts: 2885
What kind of algorithm did you use?


Top
 Profile  
 
PostPosted: Thu Jul 11, 2019 3:57 pm 
Offline

Joined: Fri Jul 04, 2014 9:31 pm
Posts: 1076
It's based on the grid idea, using an 8x7 grid of 32x32-pixel cells. It assigns each sprite to one grid cell based on its position. Then it goes through the sprite list again, removing each sprite from its assigned cell and then doing box-point collision against any remaining sprites in cells where they could possibly collide with the current sprite. If a collision is detected, both sprites are lit.

The anti-clustering mechanism takes advantage of the Boolean nature of the collision response. If a sprite is already lit when the main loop reaches it, the whole procedure is skipped for that sprite, because it doesn't care if it collides with any more sprites, but it is not removed from its assigned cell because other non-lit sprites do care if they collide with it. The result is that if all 128 sprites are on top of one another, the number of collision checks is best-case instead of worst-case.

This procedure got me within about 15% of a solid 60 fps. What put me over the line was unrolling all fixed-length loops. (This necessitated a bump to HiROM and very nearly another bank - the ROM as posted has 159 bytes free). Fortuitously, the unrolling caused the inner collision loop to no longer run out of index registers, which sped it up dramatically and left me with a credible margin of free compute time.


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

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 0 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