It is currently Sun Oct 22, 2017 1:11 am

All times are UTC - 7 hours



Forum rules


Related:



Post new topic Reply to topic  [ 147 posts ]  Go to page Previous  1 ... 5, 6, 7, 8, 9, 10  Next
Author Message
PostPosted: Sat May 14, 2016 7:33 pm 
Offline

Joined: Fri Jul 04, 2014 9:31 pm
Posts: 788
psycopathicteen wrote:
Are you planning on uploading instruments as needed?

My original goal was real-time multi-channel streaming at high sample rates, without restricting music timing to VBlank. But obviously if you can do that, it should also be possible to change out samples in RAM during playback. And it would be nice to have a reasonably fast bulk data loader that didn't freeze the game à la SFA2...

I suspect it'll be a while before I'm ready to actually try out this method in the field. By then I may have a better idea, or I may have realized that this one has a fatal flaw or something...

rainwarrior wrote:
Revenant wrote:
The "Nintendo crippled the CPU in order to make cartridges more expensive" is definitely "[citation needed]" material.

"Citation needed" is for stuff you think is true, but doesn't have a source. I'd say that's just "delete on sight" material, author inserting their own opinion instead of objectively reporting.

Technically what it said (following on from the part about the CPU being weak) was:
Quote:
This was intentional on the part of Nintendo because it wanted to lower the cost of the system, and it provided connections for cartridges to have their own coprocessors when high performance processing is needed. This naturally drove up the cost of games that required such coprocessors.

Which could be considered technically true, but gives the wrong impression. I deleted it, and gave the following reason (visible only in page history):
Quote:
This seems to be an unsupported extrapolation. The NES, Genesis and even N64 could and did use special hardware in cartridges; I am unaware of any indication that this feature was related to the choice of CPU in the case of the SNES.

But now I'm worried that I may have started an urban legend about coprocessors in N64 cartridges, which is not what I meant. If some dude on some forum starts claiming WDC or Conker or Naboo had an enhancement chip, you know who to blame...

Next up is to try to finesse some of the CPU stuff...


Top
 Profile  
 
PostPosted: Sat May 14, 2016 9:30 pm 
Offline

Joined: Thu Aug 12, 2010 3:43 am
Posts: 1589
Even the Atari 2600 did, really (and at some point the Odyssey was going to - that's a console that didn't even have a CPU for starters). I don't recall of any extra hardware in N64 cartridges outside save RAM though, but I may be missing something obvious.

And yeah, people apparently were convinced Donkey Kong 64 really made some proper use of the Expansion Pak until one of the devs came out and admitted it was just to prevent a crash somewhere in the game, so I can see why some people may start thinking some games would need a coprocessor >_>


Top
 Profile  
 
PostPosted: Sun May 15, 2016 3:12 am 
Offline

Joined: Fri Jul 04, 2014 9:31 pm
Posts: 788
Doubutsu no Mori's real-time clock, Mario no Photopi's flash card readers, and Morita Shougi 64's built-in modem. At least, that's what a quick Google turned up.

I didn't know that about DK64. Knowing Rare, it must have been one hell of a bug...


Top
 Profile  
 
PostPosted: Sun May 15, 2016 5:44 am 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19115
Location: NE Indiana, USA (NTSC)
93143 wrote:
Mario no Photopi's flash card readers

I wonder whether that game can be exploited to take full control, as Super Mario World and Pokémon Yellow and many Wii games were. Then it would become a flash cart. True, little else uses SmartMedia, but I think a few multi-format card writers that handle xD-Picture cards can still handle SM.


Top
 Profile  
 
PostPosted: Sun May 15, 2016 5:47 am 
Offline

Joined: Thu Aug 12, 2010 3:43 am
Posts: 1589
93143 wrote:
Doubutsu no Mori's real-time clock, Mario no Photopi's flash card readers, and Morita Shougi 64's built-in modem. At least, that's what a quick Google turned up.

Touché.

And to Rare's credit, DK64 started as a 64DD game (and hence was made with the extra memory in mind). When they decided to turn it into a cartridge game they tried to cram it into less memory, and they did manage to pull it off... except for that one annoying crash, and it happened to stop if the extra memory was present. So they just made the game require the Expansion Pak and they claimed the game made use of the extra memory =P (also probably gave a good excuse to sell the Expansion Pak as it'd later be needed for Ocarina of Time, which was another 64DD to cartridge port)


Top
 Profile  
 
PostPosted: Sun May 15, 2016 6:41 am 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19115
Location: NE Indiana, USA (NTSC)
You mean Majora's Mask? Ocarina was a 64DD to cart port, but it came out a year before DK64.


Top
 Profile  
 
PostPosted: Sun May 15, 2016 11:56 pm 
Offline

Joined: Thu Aug 12, 2010 3:43 am
Posts: 1589
Right, my timeframes keep being all messed up =P (and yeah now that I remember, OOT was always cartridge, Majora's Mask was the disk one that latched onto OOT)


Top
 Profile  
 
PostPosted: Sun May 22, 2016 11:47 am 
Offline

Joined: Mon Mar 30, 2015 10:14 am
Posts: 177
I checked the SOR 3's sprites, and i am surprised by the number of sprites used for the foes(and may be for players too).
Up to 10 sprites are used for each meta sprites, it sounds like a wastle to me ..
i don't know how many cpu cycles are used to modify a single sprite entry on Md,but with this system i think a lot .


Top
 Profile  
 
PostPosted: Sun May 22, 2016 2:28 pm 
Offline

Joined: Thu Aug 12, 2010 3:43 am
Posts: 1589
Yeah, but remember the MD has the ability of displaying rectangular-shaped sprites. In a beat'em-up the amount of tiles to be uploaded is a bigger issue (both for bandwidth and memory usage), so you're better off using more sprites in order to reduce waste from blank areas.


Top
 Profile  
 
PostPosted: Sun May 22, 2016 7:19 pm 
Offline

Joined: Wed May 19, 2010 6:12 pm
Posts: 2295
Because audio streaming has been brought up, I wonder how a 1-bit adpcm format would sound like.

Such as something with a formula similar to this:

y(t) = x(t) + 5/2*y(t-1) - 5/2*y(t-2) + 15/16*y(t-3)

where y(t) is the signed 8-bit output, and x(t) is either +8 or -8.


Top
 Profile  
 
PostPosted: Sun May 22, 2016 8:48 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19115
Location: NE Indiana, USA (NTSC)
CVSD, a form of 1-bit ADPCM, is in Sinistar.


Top
 Profile  
 
PostPosted: Mon May 23, 2016 1:08 am 
Offline

Joined: Mon Mar 30, 2015 10:14 am
Posts: 177
Quote:
Yeah, but remember the MD has the ability of displaying rectangular-shaped sprites. In a beat'em-up the amount of tiles to be uploaded is a bigger issue (both for bandwidth and memory usage), so you're better off using more sprites in order to reduce waste from blank areas.

Of course i thought it was for maximising the sprites bandwidth, but i think (may be i am wrong) it's not really optimal on the number of sprites used, you can use bigger sprites here with the same result (for bandwidth).

For exemple the baseball bat use 5 sprites (8x8) .. :shock: ,good for bandwidth, but a little bit overkill no ??

Even with this , i think the SOR series have a very good sprites engine.


Top
 Profile  
 
PostPosted: Mon May 23, 2016 5:26 am 
Offline

Joined: Mon Jul 01, 2013 11:25 am
Posts: 228
Aside bandwidth i believe it has be made that way to optimize the sprite per scanline rendering and avoid sprite flickering as much as possible. That is for me the big advantage of having rectangular sprite (8x32 for vertical object) and sometime you have to use many smalls hardware sprites when you have thin diagonal object (pipe or sword)...

Quote:
Even with this , i think the SOR series have a very good sprites engine.


Of course they have ;) I observed a bit the SOR2 engine and we can see they cut sprites (i mean just rendering half of it) when they are going out of screen, an optimization to limit the scanline flickering but which require more computation.
Actually having a good sprite engine is definitely something not easy to deal with. I'm certain that many game spent a big part of CPU budget with the sprite engine (not even considering collisions, just about displaying (meta) sprites in a somehow optimized way considering hardware resource limitation).


Top
 Profile  
 
PostPosted: Wed May 25, 2016 12:05 pm 
Offline

Joined: Wed May 19, 2010 6:12 pm
Posts: 2295
I found an audacity plugin that allows me to convert PCM to 1-bit dpcm quality, believe it or not. So far, setting it the output to 4-bit has more white noise, whereas 8-bit is more muffled. I haven't tried 6-bit yet.


Top
 Profile  
 
PostPosted: Wed May 25, 2016 5:36 pm 
Offline

Joined: Thu Oct 10, 2013 3:30 pm
Posts: 2
tepples wrote:
The fastest you could scroll on a GS was about 10 to 15 fps using the obscure "PEA field" technique that overlays the stack on the hardware frame buffer, and the back buffer is stored backwards as a block of self-modifying code.


Another guy used the same kind of technique to get what looks like 30+fps scrolling.
http://iigs.dreamhosters.com/gte/gte.html
https://www.youtube.com/watch?v=IsXPn6OCMF8
8-)


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 147 posts ]  Go to page Previous  1 ... 5, 6, 7, 8, 9, 10  Next

All times are UTC - 7 hours


Who is online

Users browsing this forum: Bing [Bot] 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