It is currently Mon Dec 10, 2018 6:57 pm

All times are UTC - 7 hours



Forum rules





Post new topic Reply to topic  [ 59 posts ]  Go to page Previous  1, 2, 3, 4  Next
Author Message
PostPosted: Sat Jul 21, 2018 3:47 am 
Offline
User avatar

Joined: Mon Jan 23, 2006 7:47 am
Posts: 145
93143 wrote:
The graphics seem to be smaller than they need to be, the screen is letterboxed, and the animations are missing frames. [...] The game also has some slowdown, and I don't really see why it should.

AI?


Top
 Profile  
 
PostPosted: Sat Jul 21, 2018 2:19 pm 
Offline
User avatar

Joined: Sat Aug 20, 2016 3:58 am
Posts: 77
93143 wrote:
Markfrizb wrote:
So the game has issues already.... humph, wasn't aware of that.

It's a port of a CPS2 game, so it was never going to be perfect.

It's just that I and others feel that it was probably possible to do better. Maybe it would have been unreasonable to expect better under reasonable time and budget constraints, or for an affordable price. Maybe it was a corporate afterthought or a contractual obligation and didn't get a reasonable schedule or budget. Maybe the RAM-limited nature of the next-gen consoles made devs wary of pushing the SNES too hard for fear of making the PlayStation look bad. Maybe the programmers were just lazy or incompetent. Or maybe it really is as good as it can get on the hardware - but I doubt it.

The graphics seem to be smaller than they need to be, the screen is letterboxed, and the animations are missing frames. Preliminary calculations suggest that it may be possible to remedy all of these things with a sufficiently advanced animation engine and more ROM.

The vocals are muddy, the music is terrible, and the game has loading pauses where everything freezes. These things are intimately related, and I think it's possible to fix all of them at once with a high-bandwidth HDMA streaming scheme. Even if I'm wrong, there are multiple examples of games that handle on-the-fly ARAM loading better than this one.

The game also has some slowdown, and I don't really see why it should.


May be one day it can be fixed, just how today is going on with the final fight.

Take a look on this, its author has much merit:
http://www.baddesthacks.net/forums/view ... &start=260


I'm sorry for the intromission, magno ^^u


Top
 Profile  
 
PostPosted: Sat Jul 21, 2018 11:10 pm 
Offline

Joined: Fri Jul 04, 2014 9:31 pm
Posts: 991
creaothceann wrote:
AI?

Is that typically a large chunk of the frame in a Super NES fighting game? I imagine it uses a bytecode scripting system, and it may be possible to substantially optimize it (maybe even hardcode it if all else fails), but I'm not an expert...

Markfrizb wrote:
But wouldn't that require a few options --- either A, someone would need to buy the FPGA SDD1 pcb (presumably a dev board), or B, wouldn't this lead to more cart destruction because some potential future game/hacks that needs the SDD1.

You can get what looks like an original copy of Star Ocean for less than $20, although it varies a fair bit. SFA2 seems to be in the $40 range. (Weird, considering it's nowhere near as highly regarded and was sold outside Japan. I'm guessing it's because Star Ocean has been extracted and can be cloned without an S-DD1, while SFA2 hasn't.)

Can an FPGA beat those prices?

Quote:
Can the SD2Snes can run the SDD1 games?

They're still on the incompatibility list. The Super FX games aren't, which means the list was updated very recently. But if this project works properly on real hardware, it should be possible to implement it, right? That should reduce demand for repros.


Top
 Profile  
 
PostPosted: Wed Jul 25, 2018 1:07 am 
Offline
User avatar

Joined: Sat Jul 04, 2015 9:58 am
Posts: 841
Location: -29.794229 -55.795374
A thing that I've found interesting is that there's an early prototype that didn't use the SDD1.
Seems to be an early version, but maybe the chip can be just left out by using a larger ROM.


Top
 Profile  
 
PostPosted: Mon Jul 30, 2018 2:40 am 
Offline

Joined: Tue Aug 15, 2006 5:23 am
Posts: 193
Location: Spain
Fisher wrote:
A thing that I've found interesting is that there's an early prototype that didn't use the SDD1.
Seems to be an early version, but maybe the chip can be just left out by using a larger ROM.


Yes, that can be done; Nevitski did for Star Ocean and I myself did it for Star Ocean too, resulting in a 65.5 Megabit ROM. My way of doing it was dumping all and any S-DD1 compressed chunk and then, re-inserting each one as decompressed data. That is tedious, but you get the minimum ROM size.


Top
 Profile  
 
PostPosted: Mon Jul 30, 2018 3:18 am 
Offline

Joined: Fri Jul 04, 2014 9:31 pm
Posts: 991
magno wrote:
I myself did it for Star Ocean too, resulting in a 65.5 Megabit ROM.

...wait, what?

That substantially alters my estimate of the potential compression ratio available. Both SFA2 and Metal Slug should still fit without cuts, but it's a lot closer than it was. On the other hand, Star Ocean isn't really very much like either of those games...

What kind of average compression ratio do you see with graphics?


Top
 Profile  
 
PostPosted: Mon Jul 30, 2018 3:52 am 
Offline

Joined: Fri Feb 16, 2018 5:52 am
Posts: 29
Location: Ukraine
magno wrote:
I myself did it for Star Ocean too

Star Ocean has 8bpp modes data?


Top
 Profile  
 
PostPosted: Mon Jul 30, 2018 6:52 am 
Offline

Joined: Tue Aug 15, 2006 5:23 am
Posts: 193
Location: Spain
93143 wrote:
magno wrote:
I myself did it for Star Ocean too, resulting in a 65.5 Megabit ROM.

...wait, what?


Is 65.5 Megabit bigger or smaller than you expected?


93143 wrote:
What kind of average compression ratio do you see with graphics?


I could make calculations about it if you are interested.

Most of the SDD-1 chunks are 8x16 4BPP sprite tiles, ie, 64 bytes per chunk, which are compressed down to 40~50 bytes per chunk.

srg320 wrote:
Star Ocean has 8bpp modes data?


I can't remember any 8BPP modes.

Please, let my check when I have some free time and I will be able to provide reliable information about it.


Top
 Profile  
 
PostPosted: Mon Jul 30, 2018 8:42 am 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 20851
Location: NE Indiana, USA (NTSC)
magno wrote:
93143 wrote:
magno wrote:
I myself did it for Star Ocean too, resulting in a 65.5 Megabit ROM.

...wait, what?

Is 65.5 Megabit bigger or smaller than you expected?

To me, the most unexpected part was that it's so close to a power of 2 bits: 67.1 megabits, which is 64 mebibits or 64 of what the game industry called "megabits" in the mask ROM era. 65.5 megabits sounds close to 64*1000*1024 bits, which has the same mixed-up logic as the old "1.44 MB" floppy disk, which held 1.44*1000*1024 bytes using the most common MFM sector format (80 tracks, 18 sectors per track, 512 bytes per sector).

And I too am curious about typical compression rates over the S-DD1 corpus. If you have time, it'd be interesting to read what causes a particular kind of graphic to be compressed more or less than average, or comparison with the rate performance of the SPC7110 (another context-adaptive arithmetic decoder). At least this might help inform design of pure-software tile codecs for Game Boy and Super NES.


Top
 Profile  
 
PostPosted: Mon Jul 30, 2018 10:44 am 
Offline

Joined: Tue Aug 15, 2006 5:23 am
Posts: 193
Location: Spain
tepples wrote:
65.5 megabits sounds close to 64*1000*1024 bits


In fact, my Star Ocean version is 65.5 * 1024 * 1024 bits. It spans 132 LoROM banks (32768 bytes each) and 64 HiROM banks (65536 bytes each).


tepples wrote:
And I too am curious about typical compression rates over the S-DD1 corpus. If you have time, it'd be interesting to read what causes a particular kind of graphic to be compressed more or less than average, or comparison with the rate performance of the SPC7110 (another context-adaptive arithmetic decoder). At least this might help inform design of pure-software tile codecs for Game Boy and Super NES.


That sounds interesting, although I still don't know SPC7110 inners :(

93143 wrote:
magno wrote:
I myself did it for Star Ocean too, resulting in a 65.5 Megabit ROM.

...wait, what?

That substantially alters my estimate of the potential compression ratio available. Both SFA2 and Metal Slug should still fit without cuts, but it's a lot closer than it was. On the other hand, Star Ocean isn't really very much like either of those games...

What kind of average compression ratio do you see with graphics?


I checked; Star Ocean japanese version has 4395668 uncompressed bytes and they are compressed down to 2180646 bytes, pretty near to 50%. That includes all graphic chunks.


Top
 Profile  
 
PostPosted: Mon Jul 30, 2018 2:52 pm 
Offline

Joined: Fri Jul 04, 2014 9:31 pm
Posts: 991
magno wrote:
Is 65.5 Megabit bigger or smaller than you expected?

Smaller. The neviksti hack is 12 MB, so I assumed that was the uncompressed size of the game.

magno wrote:
I checked; Star Ocean japanese version has 4395668 uncompressed bytes and they are compressed down to 2180646 bytes, pretty near to 50%. That includes all graphic chunks.

Okay, that sounds better. Scared me for a moment.

Metal Slug seems to have 16 MB of C-ROM, based on the MAME manifest (though the MAME ROMs add up to more than 193 Mbit, so some of them are probably partly empty). Could be 14-15 MB rescaled to SNES resolution, since the graphics probably won't reduce by the full 256/304 ratio because of tiling. If that compresses down to about 7-8 MB, and audio can be squeezed down quite a bit because the SNES can re-pitch samples, it may be possible to do the game in about 9-10 MB, maybe with 8 MB behind the S-DD1 and 2 MB in parallel. At worst I imagine 12 MB would be more than adequate, and by the time the S-DD1 came out the N64 was on the cusp of hosting games that big.

SFA2 has 20 MB of graphics and 4 MB of audio data. The former could easily be well below 16 MB when rescaled to SNES resolution, and since a lot of it is cartoony with a bunch of flat colour it might compress better than Star Ocean or Metal Slug. Even if it doesn't, 7-8 MB is still a plausible estimate. The audio should compress to about 2 MB with BRR, and we're left with a very similar scenario as with Metal Slug.

So they should both work about as well as I had thought. Thanks for the estimate.


Top
 Profile  
 
PostPosted: Mon Jul 30, 2018 10:23 pm 
Offline

Joined: Tue Aug 15, 2006 5:23 am
Posts: 193
Location: Spain
93143 wrote:
Smaller. The neviksti hack is 12 MB, so I assumed that was the uncompressed size of the game.


Neviksti's version is 12MByte but must of the ROM space is not filled with data. He left untouched the first 48Mbit (the original ROM) then used 3 bank to make a big lookup table for pairing each compressed address with new uncompressed location in expanded ROM. Then added all of Dejap's GFX packs in the rest of the ROM.
The fact is the original 48Mbit can be exploited because part of it is S-DD1 compressed data (about 18 MBit aprox), and hundreds of Dejap's GFX chunks are not valid, so they shouldn't be included in the expanded ROM.
If you make the calculations, the original game has about 35 megabits of uncompressed data; 18 Megabits of that uncompressed data can be allocated in the original ROM, and the rest of if, in the expanded space: 48Mbit (original) + 17 (expanded) = 65 Mbit.
You can check this in the ROM layout document I uploaded to RHDN.


93143 wrote:
Metal Slug seems to have 16 MB of C-ROM, based on the MAME manifest (though the MAME ROMs add up to more than 193 Mbit, so some of them are probably partly empty). Could be 14-15 MB rescaled to SNES resolution, since the graphics probably won't reduce by the full 256/304 ratio because of tiling. If that compresses down to about 7-8 MB, and audio can be squeezed down quite a bit because the SNES can re-pitch samples, it may be possible to do the game in about 9-10 MB, maybe with 8 MB behind the S-DD1 and 2 MB in parallel. At worst I imagine 12 MB would be more than adequate, and by the time the S-DD1 came out the N64 was on the cusp of hosting games that big.

SFA2 has 20 MB of graphics and 4 MB of audio data. The former could easily be well below 16 MB when rescaled to SNES resolution, and since a lot of it is cartoony with a bunch of flat colour it might compress better than Star Ocean or Metal Slug. Even if it doesn't, 7-8 MB is still a plausible estimate. The audio should compress to about 2 MB with BRR, and we're left with a very similar scenario as with Metal Slug.

So they should both work about as well as I had thought. Thanks for the estimate.


That MEtal Slug sounds exciting!!


Top
 Profile  
 
PostPosted: Tue Jul 31, 2018 10:27 pm 
Offline

Joined: Fri Jul 04, 2014 9:31 pm
Posts: 991
magno wrote:
That MEtal Slug sounds exciting!!

It would be more exciting if there was any realistic prospect of it happening any time soon. Everybody who might contribute, including me, is busy doing other stuff.

But it's certainly fun to think about and talk about. And there is one member here who arrived harbouring the intention to port Metal Slug to the SNES, and has given it a lot of thought, even if he now feels it would be too big a task for him alone. A few other members are known to have been working on stuff that could be applicable to such a port, such as predictive animation, dynamic sprite VRAM allocation, and HDMA audio data streaming. Not to mention an FPGA implementation of the S-DD1... I can't rule out the possibility that this project may get off the ground someday.


Top
 Profile  
 
PostPosted: Tue Jul 31, 2018 11:39 pm 
Offline

Joined: Fri Feb 16, 2018 5:52 am
Posts: 29
Location: Ukraine
So, with magno’s help I finally launched SDD1 on FPGA SNES. Not sure what will work on real hardware. Also not tested in 8BPP modes. So far I have achieved 3 master cycles for ROM access. Also I don't know how SDD1 should work if more than one DMA channel is selected for it (header is common or different).

sorry for the quality
https://youtu.be/FWvs6r8bg44
https://youtu.be/muA43DjAKS4


Attachments:
SDD1.rar [6.86 KiB]
Downloaded 88 times
Top
 Profile  
 
PostPosted: Wed Aug 01, 2018 12:19 am 
Offline

Joined: Tue Aug 15, 2006 5:23 am
Posts: 193
Location: Spain
srg320 wrote:
So, with magno’s help I finally launched SDD1 on FPGA SNES. Not sure what will work on real hardware. Also not tested in 8BPP modes. So far I have achieved 3 master cycles for ROM access. Also I don't know how SDD1 should work if more than one DMA channel is selected for it (header is common or different).

sorry for the quality
https://youtu.be/FWvs6r8bg44
https://youtu.be/muA43DjAKS4


How did you record those videos? You say you don't know if your implementation will work on hardware, so... which hardware did you run SFA2 and SO?
As for ROM access, 3 master cycles is the miminum for FastROM, since that means 139ns time access. FastROM is slower than 120ns, so 3 master cycles is the proper time access for SDD1 core.

EDIT:
Ok, taking a look to the source code you provided, that implementation CAN'T work neither in real hardware nor in any other platform. The design lacks of 3 signals needed to manage the ROM output, and what's more, there is no SRAM_CS at all, so Star Ocean wouldn't work: if there is no SRAM present in the cartridge, audio engine stalls and the game freezes.
Still wondering how those videos were recorded...


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

All times are UTC - 7 hours


Who is online

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