It is currently Mon Dec 18, 2017 9:50 am

All times are UTC - 7 hours



Forum rules


Related:



Post new topic This topic is locked, you cannot edit posts or make further replies.  [ 127 posts ]  Go to page Previous  1 ... 5, 6, 7, 8, 9  Next
Author Message
PostPosted: Mon Aug 01, 2016 9:49 am 
Offline
User avatar

Joined: Mon Sep 15, 2014 4:35 pm
Posts: 3166
Location: Nacogdoches, Texas
tepples wrote:
The GSM Full Rate compressed audio decoder used in Luminesweeper takes 60%.

I honestly have no clue what that means, but if 18KHz is 15%, then I imagine you could just have a sampler at CD quality (44,1Khz) which I imagine is about a well as a human can even hear, (I don't know why else it would be a ridiculous number like that) so 15 / 12 = 1.2 x 44.1 = 52.92% of CPU time for audio, which leaves you with 47.08%, which for any game not doing 3D software rendering (maybe aside for the 500+ bullet hell demo) that is way more than enough.

tepples wrote:
There's only one cart I know of that uses a mapper to address more: Shrek and Shark Tale.

I imagine all the flash carts can address more, and they're what you're going to be playing any homebrew games on.


Top
 Profile  
 
PostPosted: Mon Aug 01, 2016 10:40 am 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19356
Location: NE Indiana, USA (NTSC)
Espozo wrote:
tepples wrote:
The GSM Full Rate compressed audio decoder used in Luminesweeper takes 60%.

I honestly have no clue what that means

GSM Full Rate, aka GSM 06.10, is a lossy audio codec based on linear prediction. When run at 18 kHz mono, it encodes audio at 30 kbps.

Espozo wrote:
tepples wrote:
There's only one cart I know of that uses a mapper to address more: Shrek and Shark Tale.

I imagine all the flash carts can address more

Only if you can figure out the sequence of writes to switch banks (if it's NOR based) or access the inserted memory card (if it's CF or SD based). This differs from one make and model of flash cart to another, which is why "DLDI" was invented for DS homebrew. It's as if the PowerPak supported only one mapper and the EverDrive another, and you had to mapper-hack games bigger than a certain size to run on a different brand of flash cart. And even then, a CF or SD card will be a lot slower than ROM, making it useful for streaming but not for random access to, say, a large set of frames. Besides, which flash cart's bank switching registers do VBA and NO$GBA emulate?


Top
 Profile  
 
PostPosted: Mon Aug 01, 2016 11:04 am 
Offline

Joined: Thu Aug 12, 2010 3:43 am
Posts: 1589
tepples wrote:
GBA ROM is limited to 32 MiB for the first player and 256 KiB for players 2-4. There's only one cart I know of that uses a mapper to address more: Shrek and Shark Tale.

That's not how it works, at all.

There are two different methods to implement multiplayer. One involves requiring each player have their own cartridges, in this case there isn't any limit besides what you can fit in ROM as usual. The other one involves having only one player own a cartridge, in this case the game needs to fit entirely in RAM for all the other players (which is probably what you're referring to). I suppose it could be possible to stream in data from the player that has the cartridge but I assume that's horribly slow.

Note that this also applies to games downloaded using the Game Boy Player (like the chao garden minigame or the Nights minigame in some of Sega's Gamecube games), they have to fit entirely in RAM.


Top
 Profile  
 
PostPosted: Mon Aug 01, 2016 11:07 am 
Offline
User avatar

Joined: Sun May 27, 2012 8:43 pm
Posts: 1312
Tepples was certainly referring to the multiboot scheme for 2-4 players.

Espozo wrote:
I imagine I imagine I imagine

I imagine


Top
 Profile  
 
PostPosted: Mon Aug 01, 2016 11:56 am 
Offline
User avatar

Joined: Mon Sep 15, 2014 4:35 pm
Posts: 3166
Location: Nacogdoches, Texas
tepples wrote:
which flash cart's bank switching registers do VBA and NO$GBA emulate?

Well, how about this, does anything (flash cart or emulator) emulate the Shrek and Shark Tale mapper? I'm saying that it's possible to have more memory, just not easily possible, kind of like having character ram on a Neo Geo cart.

mikejmoffitt wrote:
Espozo wrote:
I imagine I imagine I imagine

I imagine

I should start to proofread my messages... :lol:


Top
 Profile  
 
PostPosted: Mon Aug 01, 2016 2:54 pm 
Offline

Joined: Sat May 04, 2013 6:44 am
Posts: 22
Stef wrote:
The Saturn is very complex, convoluted but at least it doesn't have real weakness as the SNES can have.
This is from an old part of the conversation, but I really can't let it slide. The Saturn has multiple weaknesses that stem from atrocious design decisions. The SNES, on the other hand, has only one true weakness - the inexcusably slow CPU.

Let's start with the Saturn's two main Hitachi SH-2 CPUs, clocked at 28.6 MHz. Not dual-core, it's two separate chips, and they couldn't both access the memory bus at the same time. As individual chips that were not intended for multiprocessor systems, they had no bus snooping or cache-coherency. Without cache coherency, changes made to memory on one CPU are not guaranteed to be visible on the other CPU until the software running on the writing CPU flushes its relevant cache line and the software running on the reading CPU invalidates its relevant cache line. That's a weakness that practical dual-CPU systems don't have, including systems that predate the Saturn.

Compared to the Playstation's single MIPS R3000A at 33.9 MHz, the Saturn's CPUs are individually both slower and more obscure. MIPS is and was a popular and well-understood CPU architecture, in the same way that the 6502, Z80, and 68000 were popular architectures when designed into the NES, Game Boy, and Megadrive, respectively. The SuperH architecture used in the Hitachi SH-2 really only saw use in microcontrollers and some mobile phones, aside from the Saturn and Dreamcast.

Being hard to program for is not "complexity", it's a weakness. If you can't turn theoretical performance into real performance, it might as well not be there.

Now, let's talk about the Saturn's two Video Display Processors (VDPs). The VDP1 is really just an nVidia NV1 chip. You might have warm, fuzzy feelings about nVidia nowadays, but the NV1 was frankly bizarre. It couldn't do translucent polygons. It used quadrilaterals instead of triangles to build 3-D scenes, contrary to pretty much every 3-D accelerator before or since. The Playstation, on the other hand, only needed 1 chip to be competitive. (Of course, both Saturn and Playstation pale in comparison graphically to the N64, but that system came out almost two years later, so that comparison is unfair.)

Finally, let's talk about FMV. FMV was much better on the Playstation, which had a dedicated video decoder chip. You'd think that Sega would have learned from the Sega CD debacle, but FMV had to be decoded in software on the Saturn, unless the add-on Video CD Card was installed. And how many gamers bought that?

So yeah, the Saturn deserved to lose to the Playstation.


Top
 Profile  
 
PostPosted: Mon Aug 01, 2016 4:07 pm 
Offline

Joined: Wed May 19, 2010 6:12 pm
Posts: 2433
Quote:
The SNES, on the other hand, has only one true weakness - the inexcusably slow CPU.


A lot of people on this forum disagree with this statement.


Top
 Profile  
 
PostPosted: Mon Aug 01, 2016 4:48 pm 
Offline

Joined: Mon Mar 27, 2006 5:23 pm
Posts: 1339
Quote:
The VDP1 is really just an nVidia NV1 chip.


The VDP1 predates the NV1. It is similar in design and features, and that's why a lot of Saturn PC game ports used it.

The similarity is interesting, but I know of no documentation that clearly indicates nVidia designed the VDP1, let alone that it's actually just the NV1's GPU in disguise.

Quote:
A lot of people on this forum disagree with this statement.


Eeeeeh, kind of.

It was definitely atrocious for the generation of variable-width fonts. You could do it with dialogue text, but it was really inadequate for entire inventory screens full of 8x8 text. I had to resort to pre-rendering all possible item names into ROM data, which would never fly back in the days of super expensive mask ROM.

Instructions to left/right shift A by X would have saved it for that and a lot of other use cases.


Last edited by byuu on Mon Aug 01, 2016 4:56 pm, edited 1 time in total.

Top
 Profile  
 
PostPosted: Mon Aug 01, 2016 4:56 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19356
Location: NE Indiana, USA (NTSC)
psycopathicteen wrote:
Quote:
The SNES, on the other hand, has only one true weakness - the inexcusably slow CPU.

A lot of people on this forum disagree with this statement.

And I'm among them. The S-CPU is plenty fast for 2D games, so long as you have time and skill to write inner loops in assembly language rather than relying on a C compiler.

byuu wrote:
Eeeeeh, kind of.

It was definitely atrocious for the generation of variable-width fonts. You could do it with dialogue text, but it was really inadequate for entire inventory screens full of 8x8 text.

The NES can render a whole page of VWF text in a few frames. And that's with a 40% slower CPU, no 5A22 multiplier to shift the glyph slivers, and no DMA to copy rendered tiles to the PPU. See the help screens in Action 53, RHDE, and the 240p test suite. Once I finish my present paid project, should I port my VWF engine to the Super NES and make an e-book reader app?


Top
 Profile  
 
PostPosted: Mon Aug 01, 2016 5:01 pm 
Offline

Joined: Mon Mar 27, 2006 5:23 pm
Posts: 1339
It takes about 3-4 scanlines worth of CPU time to render one 2bpp 72x8 pixel item name. I used every possible trick in the book to optimize my VWF routine to that point. I am confident you couldn't beat my routines.

Unless you have a giant pool of RAM to buffer lots of items, you have to render and blit them one at a time. Including the setup and transfer to VRAM, you're eating 5 scanlines. Vblank is ~37 scanlines long, and you have to do other stuff during it. So, at best, you can get seven item names rendered and uploaded per frame. But more realistically, I could get in only 3-4 due to busy NMI routines.

Bahamut Lagoon had screens with 36 text names and 4 menu options on them. Having the entire game lock for 150ms every time you scroll one row in a giant list was completely unacceptable. Dejap's non-ZSNES patch was far worse than mine, and would take a full second, while you watched the entire screen fill with gibberish since they did the updates to the tiledata while the tilemap was still pointing at the old data. But that was kind of shitty programming on their part.

There were also many screens that used 4bpp fonts.


Top
 Profile  
 
PostPosted: Mon Aug 01, 2016 5:19 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19356
Location: NE Indiana, USA (NTSC)
In a situation like that, my NES VWF engine would be rendering two 72x8 lines per frame. It doesn't cause the menu to "lock", as it's rendered in the background. Here it is in 240p test suite rendering to a 128x176 window (Action 53 is similar):

Attachment:
vwf_rendering_speed.gif
vwf_rendering_speed.gif [ 8.07 KiB | Viewed 1239 times ]


If you scroll one row at a time, you can just render 2 lines into the pattern table and update the nametable to reflect different tile numbers.

But I'd be interested (in a separate topic) to see your routines.


Top
 Profile  
 
PostPosted: Mon Aug 01, 2016 5:38 pm 
Offline

Joined: Wed May 19, 2010 6:12 pm
Posts: 2433
Isn't that more of a RAM problem than a CPU problem if you have to rely on doing everything during vblank?


Top
 Profile  
 
PostPosted: Mon Aug 01, 2016 7:44 pm 
Offline

Joined: Thu Aug 12, 2010 3:43 am
Posts: 1589
LightStruk wrote:
It couldn't do translucent polygons.

Huh, it could... just wasn't very useful. Only 50%, and only within the framebuffer which was a problem because Saturn games often used the tilemaps for the backgrounds and floors. Also it was glitchy because the way it rendered quads meant it would render some pixels twice (making them more opaque than usual). So yeah, it could do translucent polygons but it was better to do checkerboard in practice =P

Surprised you didn't mention the fact the Saturn had to do all 3D calculations in software in your rant - I presume this is the reason why there's a second SH2 on the system, especially since their devkit seemed to default to using it to do all the sorting and 3D math. The PS1 had dedicated hardware to do all the 3D math instead (albeit separate from the GPU which still only saw 2D triangles).

LightStruk wrote:
So yeah, the Saturn deserved to lose to the Playstation.

It was going to lose miserably even if it had the best platform ever because Sega of Japan and Sega of America were actively trying to sabotage each other at the time (and this is something that they were already starting to do by the end of the previous generation). Nothing can save a company that's trying to destroy itself =P


Top
 Profile  
 
PostPosted: Mon Aug 01, 2016 7:55 pm 
Offline
User avatar

Joined: Mon Sep 15, 2014 4:35 pm
Posts: 3166
Location: Nacogdoches, Texas
LightStruk wrote:
the inexcusably slow CPU.

Even if 3.58Mhz isn't fast enough, the ram still doesn't even go that fast.

Yeah though, if the two CPUs in the Saturn have to interrupt each other to pull data from ram, then you might as well only have one. :lol:

The N64 was terribly programed for. Conker's Bad Fur Day is one of the few games I believe really show of the N64's capability. Perfect Dark also looks good, but the framerate rivals a Super FX game. :lol: I don't get what the whole "small texture cache" thing was, I mean, it's not like you can just swap it out. I guess the main problem is that if you had a 128x128 texture that you wanted to sprawl out forever, you'd need to have each 64x64 section be its own quad. Even if you decided to draw all the sections that used that 64x64 texture, and then swapped out the texture in the texture cache, it would still be slower than if you just drew one 64x64 texture that wraps around.


Top
 Profile  
 
PostPosted: Tue Aug 02, 2016 12:45 am 
Offline
User avatar

Joined: Fri Nov 12, 2004 2:49 pm
Posts: 7320
Location: Chexbres, VD, Switzerland
Quote:
I don't know why else it would be a ridiculous number like that

44100 Hz was taken because it is an integer multiple of both 50 Hz and 60 Hz. (Agruably, any multiple of 300 Hz fits that criteria so I don't know why they picked this instead of any other multiple of 300 above 40000 Hz).

Quote:
The SNES, on the other hand, has only one true weakness - the inexcusably slow CPU.

Once again, this statement complete and utter bullshit.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic This topic is locked, you cannot edit posts or make further replies.  [ 127 posts ]  Go to page Previous  1 ... 5, 6, 7, 8, 9  Next

All times are UTC - 7 hours


Who is online

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