It is currently Fri Oct 20, 2017 10:08 pm

All times are UTC - 7 hours



Forum rules


Related:



Post new topic Reply to topic  [ 77 posts ]  Go to page 1, 2, 3, 4, 5, 6  Next
Author Message
PostPosted: Mon Mar 16, 2015 8:50 pm 
Offline
User avatar

Joined: Mon Sep 15, 2014 4:35 pm
Posts: 3074
Location: Nacogdoches, Texas
This is mostly going to be sprite related things, just so you know. This first thing I want to say isn't very amazing, I figured that if DMAing sprites is such a big issue, you could take 16 pixels of the top and 16 off the bottom, and you would get a bit more DMA bandwidth (I don't remember the formula, so I can't tell you how much) and if your TV is able to vertically stretch the display, you can view the game at 4:3 without cropping out any of the picture. Second and more importantly, I know sprites only being able to access 16KB of ram is a bit of a problem so now that it has been discovered, you could have 3 sprite banks with the 2nd one being shared by 1 and 3. 224 - 32 = 192, and 192 / 64 = 3, and there are 3 sprite banks, so you could have it divide the display nicely. You would have the first half of the screen use banks 1 and 2, and the second half of the screen use 2 and 3. Here's a picture to show what I mean.

Attachment:
Example.png
Example.png [ 567 Bytes | Viewed 2481 times ]


The only problem is that I'm not exactly sure how to change the position for what tiles a sprite is using. (If it were located in hi oam, this would be a heck of a lot easier...) You would have to find to see if there are spots in both sprite banks (1 and 2 or 2 and 3) that are open that correspond to each other, so there is a seamless transition between the top and bottom parts of the screen. If you are going to animate a sprite at the top third of the screen, you look for a spot in the 1st sprite bank and if it is empty, the second and if it is in the middle, you look in the 2nd sprite bank and then the 1st or the 3rd depending on if you are near the top or the bottom, and on the third, you look at the 3rd bank, and then the second. I hope what I said even makes the slightest bit of sense.


Top
 Profile  
 
PostPosted: Mon Mar 16, 2015 10:25 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 6289
Location: Seattle
Espozo wrote:
if your TV is able to vertically stretch the display
I assume you mean "the input is letterboxed, remove the letterboxing" with a proportional scaling. Tepples has pointed out in the past that the SNES/NES could have an active area of ≈256x164 to be 16:9 friendly.

That said, 160 pixels is kinda painfully low.


Top
 Profile  
 
PostPosted: Mon Mar 16, 2015 10:26 pm 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 5728
Location: Canada
Is this a game that you are working on? What's the idea for?


Top
 Profile  
 
PostPosted: Tue Mar 17, 2015 12:47 am 
Online

Joined: Fri Jul 04, 2014 9:31 pm
Posts: 787
Espozo wrote:
you could take 16 pixels of the top and 16 off the bottom, and you would get a bit more DMA bandwidth (I don't remember the formula, so I can't tell you how much)

You'd almost double it, at least on an NTSC deck. The approximate formula is (262-N)*165.5, where N is the number of scanlines in active display. The exact value depends on when your interrupt fires and what else is going on during VBlank.

The formula comes from the fact that a frame on an NTSC SNES is 262 scanlines, most scanlines are 341 dots, each dot is four master cycles, and DMA goes at eight master cycles per byte except during the 40-cycle DRAM refresh in the middle of each scanline. So you get ([341*4]-40)/8 bytes per scanline.

PAL is 312 scanlines per frame, but everything else is the same. DMA bandwidth is usually not an issue with PAL...


Top
 Profile  
 
PostPosted: Tue Mar 17, 2015 2:53 am 
Offline
User avatar

Joined: Mon Mar 02, 2015 1:11 am
Posts: 75
Location: Australia (PAL)
Espozo wrote:
you could have 3 sprite banks with the 2nd one being shared by 1 and 3. 224 - 32 = 192, and 192 / 64 = 3, and there are 3 sprite banks, so you could have it divide the display nicely. You would have the first half of the screen use banks 1 and 2, and the second half of the screen use 2 and 3. Here's a picture to show what I mean.

[...]

The only problem is that I'm not exactly sure how to change the position for what tiles a sprite is using


I don't think what your attempting is possible. According to Anomie's document OBSEL can only be written during V-Blank or Force-Blank. I remember reading somewhere that it might be possible to modify the OAM Base Address mid frame on an 1-Chip SNES. I do remember it is not possible on my old first gen PAL SNES (or maybe I was doing it wrong, I don't have it anymore).


Espozo wrote:
I figured that if DMAing sprites is such a big issue, you could take 16 pixels of the top and 16 off the bottom, and you would get a bit more DMA bandwidth.


Most games cope with the limited DMA bandwidth by either:
  • Only DMAing the Player Character
  • Delaying a frame change if the DMA buffer is full (Secret of Mana)
  • Alternate which sprites have their frames updated in a circular buffer (RARE Games).

Donkey Kong Country uses a circular buffer to allocate 16 CGRAM colours and 2 VRAM rows (32 8x8 tiles) for each entity on the screen. The animation routine processes 2 entities per frame[1], requiring only 2048 bytes[2] to be transferred to the OAM tiles per frame.

If you need bigger characters, Killer Instinct (NTSC) uses a similar method but allocates 6 VRAM rows per entity, and only processes 1 character animation per frame. However the metasprite-animation-frames rarely requires more than 4 VRAM rows for its characters.


We kinda need to know how big the characters are and how many you expect to see on the screen before I can help anymore.

---

[1] With a limit of 7 characters on the screen at any given time (1 palette is reserved for the bananas and GUI) we get a maximum of 15 FPS (60 / 4) for sprite animation.

[2] Each animation frame consists of a MetaSprite Table, 2 DMA transfers (address and size) for the two VRAM rows and an index to the next frame.


Top
 Profile  
 
PostPosted: Tue Mar 17, 2015 3:22 am 
Offline

Joined: Thu Aug 12, 2010 3:43 am
Posts: 1589
Transferring sprite graphics should not be much of an issue actually, because it's not that common to have all or even most of them updating simultaneously (remember, the same graphic will be shown for several consecutive frames), and this is without even factoring in sharing (e.g. several beat'em-ups just have a single kind of enemy at any given moment, which lets them just store every frame for those enemies).

The real problem will be memory usage. How many tiles do you think you'll need? Account in both players and the maximum amount of enemies that could possibly show up on screen at the same time, and remember you'll need some room for items and scenery as well.

As for chopping 16 pixels off the top and bottom: it's not as bad as it sounds, especially since part of that is already off-screen in the first place - it's more like losing a tile row than two. The resolution you end up with is 256×192, and your vblank bandwidth in NTSC is nearly doubled. I'd avoid it if possible, but if you run out of bandwidth and can't work around it, that may be an option. If your HUD is opaque, you could even pass some of the clipping as part of the HUD background.


Top
 Profile  
 
PostPosted: Tue Mar 17, 2015 3:27 am 
Online

Joined: Fri Jul 04, 2014 9:31 pm
Posts: 787
UnDisbeliever wrote:
Espozo wrote:
you could have 3 sprite banks with the 2nd one being shared by 1 and 3. 224 - 32 = 192, and 192 / 64 = 3, and there are 3 sprite banks, so you could have it divide the display nicely. You would have the first half of the screen use banks 1 and 2, and the second half of the screen use 2 and 3.

I don't think what your attempting is possible. According to Anomie's document OBSEL can only be written during V-Blank or Force-Blank. I remember reading somewhere that it might be possible to modify the OAM Base Address mid frame on an 1-Chip SNES. I do remember it is not possible on my old first gen PAL SNES (or maybe I was doing it wrong, I don't have it anymore).

It works on my NTSC SNES, and on every emulator I tried from ZSNES to bsnes (except the accuracy cores; bsnes v072 accuracy reverses the colours on the top scanline, and higan v094 accuracy reverses them everywhere else):

viewtopic.php?f=12&t=12305&start=30#p141770

Anomie doesn't list something as possible when he's not sure. And to be fair it isn't obvious what should happen if the size setting changes during a frame - I only tried changing the name base.

Does this work on anyone else's machine? Mine's a replacement, and I haven't checked the version; I assumed all the large-form-factor units worked pretty much the same.

EDIT: higan v094 any core reverses the colours. WTH?


Last edited by 93143 on Wed Mar 18, 2015 4:29 pm, edited 1 time in total.

Top
 Profile  
 
PostPosted: Tue Mar 17, 2015 6:34 am 
Offline
User avatar

Joined: Mon Sep 15, 2014 4:35 pm
Posts: 3074
Location: Nacogdoches, Texas
UnDisbeliever wrote:
We kinda need to know how big the characters are and how many you expect to see on the screen before I can help anymore.
Sik wrote:
The real problem will be memory usage. How many tiles do you think you'll need? Account in both players and the maximum amount of enemies that could possibly show up on screen at the same time, and remember you'll need some room for items and scenery as well.


I'm think the average size for characters would be about 48x80, give or take a bit.

Attachment:
Untitled.png
Untitled.png [ 572 Bytes | Viewed 2383 times ]

I think 2 players with 4 enemies would be all right. (and maybe an oil drum or something, but I'll really risking problems with overdraw.) The heads for the characters should be thinner, so if all the characters are on a line together, there will be some of what I like to call "the cheese grater" (don't ask) but if they are at positions slightly different from each other, it should be all right. I really wanted to have it to where halfway down the screen, I would change a sprites character bank to where 2 is changed to 1 so sprites in the middle of the screen wouldn't need to have character data in 2 different positions, which would cut DMA bandwidth in half. I'm not sure how worth this would be, because you cannot change a sprites last character bit during h blank. (I would have much preferred it if the character bit was in hi oam and the x bit wasn't.)


Top
 Profile  
 
PostPosted: Tue Mar 17, 2015 8:33 am 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19113
Location: NE Indiana, USA (NTSC)
lidnariq wrote:
the SNES/NES could have an active area of ≈256x164 to be 16:9 friendly.

That said, 160 pixels is kinda painfully low.

It wasn't painful on the Game Boy Advance, which had 240x160 square pixels. And even if you find it painful, might this be one of the cases where interlaced mode would help? That'd give 256x320 pixels for sprites, though they would be really wide (16:7) pixels.


Top
 Profile  
 
PostPosted: Tue Mar 17, 2015 3:56 pm 
Offline

Joined: Thu Aug 12, 2010 3:43 am
Posts: 1589
The GBA also had a small screen.


Top
 Profile  
 
PostPosted: Tue Mar 17, 2015 4:58 pm 
Offline

Joined: Wed May 19, 2010 6:12 pm
Posts: 2293
I thought DKC had up to 14 objects on-screen, and 4 objects animated per frame. Maybe they improved it for DKC2.


Top
 Profile  
 
PostPosted: Tue Mar 17, 2015 5:11 pm 
Offline
User avatar

Joined: Mon Sep 15, 2014 4:35 pm
Posts: 3074
Location: Nacogdoches, Texas
psycopathicteen wrote:
I thought DKC had up to 14 objects on-screen, and 4 objects animated per frame. Maybe they improved it for DKC2.

Agreed. 7 seems awfully low... Do things like smoke clouds and debris from barrels breaking count toward the limit? If so, I definitely know 7 is not right.


Top
 Profile  
 
PostPosted: Tue Mar 17, 2015 5:23 pm 
Offline
User avatar

Joined: Mon Sep 15, 2014 4:35 pm
Posts: 3074
Location: Nacogdoches, Texas
The case has been solved. DKC does indeed support more than 7 objects. (but doesn't run very fast... I wonder what the main thing is that's causing it to go so slow.) I edited the rom with the Donkey Kong Country Resource Editor by Simion 32.

Attachment:
Donkey Kong Country Object Number Test.rar [2.34 MiB]
Downloaded 205 times


Top
 Profile  
 
PostPosted: Wed Mar 18, 2015 1:28 am 
Offline
User avatar

Joined: Fri Nov 12, 2004 2:49 pm
Posts: 7232
Location: Chexbres, VD, Switzerland
Espozo wrote:
Agreed. 7 seems awfully low... Do things like smoke clouds and debris from barrels breaking count toward the limit? If so, I definitely know 7 is not right.

I'm sure there is rooms with dozens of bananas on screen simultaneously. They don't move, but are animated and collides with the player.


Top
 Profile  
 
PostPosted: Wed Mar 18, 2015 7:37 am 
Offline
User avatar

Joined: Mon Sep 15, 2014 4:35 pm
Posts: 3074
Location: Nacogdoches, Texas
Bregalad wrote:
Espozo wrote:
Agreed. 7 seems awfully low... Do things like smoke clouds and debris from barrels breaking count toward the limit? If so, I definitely know 7 is not right.

I'm sure there is rooms with dozens of bananas on screen simultaneously. They don't move, but are animated and collides with the player.

In DKC, bananas don't count as objects. They count as their own separate thing, except for banana bunches, which do count as objects. It's neat, because there is a place in the game where you can make a pattern of bananas on a grid, and you can just place the pattern of bananas in the level instead of making a bunch 1 by 1. I think a whole banana grid only counts as 1 banana toward the banana memory limit for the level.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 77 posts ]  Go to page 1, 2, 3, 4, 5, 6  Next

All times are UTC - 7 hours


Who is online

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