It is currently Sun Oct 21, 2018 9:30 pm

All times are UTC - 7 hours





Post new topic Reply to topic  [ 114 posts ]  Go to page Previous  1, 2, 3, 4, 5, 6, 7, 8  Next
Author Message
PostPosted: Fri Jun 08, 2018 3:24 pm 
Offline

Joined: Fri Jul 04, 2014 9:31 pm
Posts: 966
Espozo wrote:
Background updates should still mostly be free though, correct?

Yeah, BG changes should be fairly cheap because you can just schedule them like tile updates. As long as the sprite repalettizer knows about them and can work around them.

I'm just wondering if these extra palettes really are always vertically segregated, or if there are enough situations where they'd inevitably collide that it'd look better to just harmonize them. Palette streaking would probably be more noticeable than slightly inauthentic colours...

Those cars in the example you used last time might be doable with a BG layer.

psycopathicteen wrote:
- Update 4kB of sprite patterns in one frame

I'm wondering if it's feasible to get this up to 5 KB, at least conditionally. With a standard 38-line VBlank, you've got a little over 6 KB of time. Subtracting OAM and 5 KB of sprite data still leaves well over half a KB. Updating one row or column of two BG maps, along with the requisite tile data (assuming 100% new) can be done in four frames at 544 bytes per frame, leaving about half a scanline for overhead.

Probably too tight for the general case (especially if Metal Slug ever scrolls faster than four layer-pixels per frame). But it might be helpful to be able to detect situations where extra sprite data (or BG data, for BG-based pseudosprites) will fit into VBlank.

On the other hand, if large areas of CGRAM need updating too, that might get in the way too much... I don't like the idea of having to trim the screen vertically, though perhaps a couple of lines could go mostly unnoticed... Or maybe BG update stuffing could leave some frames clear for extra OBJ data. Metal Slug isn't the sort of game where leaving DMA bandwidth on the table is a good idea if you can avoid it.


Top
 Profile  
 
PostPosted: Fri Jun 08, 2018 5:24 pm 
Offline

Joined: Wed May 19, 2010 6:12 pm
Posts: 2760
I have thought about putting SRAM in the Fast ROM region so you can have a fast self modifying code for vblank. If I do 2 16x16 at a time so that every DMA transfer is $80 bytes long, I can write the same value to both $420b and $4375.


Top
 Profile  
 
PostPosted: Sat Jun 09, 2018 7:35 pm 
Offline
User avatar

Joined: Wed Dec 06, 2006 8:18 pm
Posts: 2827
93143 wrote:
TOUKO wrote:
Quote:
It seems that the only possible bottleneck is system RAM

Of course it is,and as you can see, even with 24Mb of RAM(main+VRAM) the loadings are frequent(we can conclude there is a lot of VRAM transferts),so if you can have the benefit of a cartridge speed, you are inevitably limited by the amount of VRAM and the DMA bandwidth

No, that doesn't follow. Consider logically:

The problem isn't DMA. A Metal Slug screen uses memory roughly on the order of the amount of VRAM the SNES has, generally less. The main RAM bus on the PlayStation is 133 MB/s, and VRAM is twice that. So it doesn't matter if you can't fit all the animations in VRAM because you can easily swap them out from main RAM in virtually no time at all. Completely replacing all the graphics necessary to draw a frame 60 times a second would barely make a dent in your overall compute time, and the actual DMA load would be even less because you don't need to do that.

The problem isn't VRAM. Triple-buffering the framebuffer in 32-bit colour would still leave way more than enough space for the data necessary to display a Metal Slug screen, and there's no reason to go to either of those extremes; I'd guess almost 3/4 of VRAM is probably available for data. And from the previous paragraph we see that loading lots of data into VRAM is not necessary for animation purposes because DMA is so fast - all you actually need is the data for one frame.

...

None of this handwaving has anything to do with the PSX version having choppy animation. I think it's reasonably evident that the bottleneck in that case doesn't apply to the SNES or MD. And since the anticipated bottlenecks on 16-bit consoles aren't even close to being a problem on the PSX, the PSX version tells us nothing about the feasibility of a 16-bit port.


With PS1 you start out with 1 Megabyte of VRAM and then subtract your frame buffers from that. For a 320x240 game you lose around 307,200 bytes. So you'd lose more than a quarter of the available VRAM. I'm not sure what you are talking about with triple buffering or 32-bit color. If that was in relation to PS1, I'm fairly sure there is no 32bit color and not aware of any game that would use 3 frame buffers. What games typically do is load background tiles in VRAM and maybe some objects/enemies that don't take a ton of frames. The player (or players) which usually have lots of animation typically have their graphics loaded into the main work RAM and are DMAed to VRAM as needed. This sort of setup can be seen in SNES games too.

The problem with Metal Slug (and Metal Slug X) on PS1 is obviously a lack of RAM. You cited the Sega Saturn which benefits from a RAM expansion cartridge and has a very solid port of Metal Slug. If the PS1 had an additional 1 megabyte or more of RAM it could have had a similarly good port. But Sony never created one. Maybe the Parallel I/O slot on the back wasn't capable of adding additional memory. Or maybe it was and they didn't feel it was worth it to create one. Plenty of other 2D games from this era demonstrate the PS1's lack of RAM.

And none of this is relevant to the SNES. But a more important question is are you thinking you'll just make your own clone of the game with modified assets? Or are you actually looking to reverse engineer the game?

On the subject of optimization, check out Metal Slug 2. It's way worse with slowdowns. Metal Slug X and Metal Slug 3 improve on performance over the first two games. The bottom line though is Metal Slug was given NeoGeo Pocket versions. So anything is possible if you cut it down enough. And no matter what any SNES version of Metal Slug would pale in comparison to the original.


Top
 Profile  
 
PostPosted: Sun Jun 10, 2018 1:34 am 
Offline

Joined: Fri Jul 04, 2014 9:31 pm
Posts: 966
MottZilla wrote:
With PS1 you start out with 1 Megabyte of VRAM and then subtract your frame buffers from that. For a 320x240 game you lose around 307,200 bytes. So you'd lose more than a quarter of the available VRAM.

I was not trying to suggest that there was enough VRAM for all the animations. My point was that regardless of any framebuffer considerations, there was certainly enough VRAM for one frame, and that since DMA was fast enough to replace all the graphics data needed to draw one frame in much less than a frame, VRAM as such was therefore not a bottleneck.

I was attempting to demonstrate by process of elimination that the bottleneck had to be the CD interface, which then caused the game to be RAM-limited. And the PSX has nowhere near as much RAM as a SNES+S-DD1 has ROM, meaning the reason the PSX port came out choppy doesn't apply to the SNES, meaning you'd have to actually examine the problem to conclude anything about a hypothetical SNES port rather than just assuming the PSX version to be indicative.

Also, it seems my estimate of the actual likely framebuffer size ("almost 3/4 of VRAM is probably available for data") matches yours pretty closely. In fact most of your post sounds like you're agreeing with me. Was that your intention?

Quote:
I'm not sure what you are talking about with triple buffering or 32-bit color. If that was in relation to PS1, I'm fairly sure there is no 32bit color and not aware of any game that would use 3 frame buffers.

What I was getting at is that even if you were to max out the amount of VRAM used by the framebuffering (triple-buffering is a thing, though I'm not sure how helpful it'd be here), there'd still be plenty left for the graphics data used to draw the frame. I was not suggesting that this was a likely approach (particularly since the Neo Geo uses 15-bit colour).

As for 32-bit, I've been reading up on the N64 lately, and I guess I just assumed that the PlayStation's true-colour mode was 32-bit. The N64 stores alpha in the framebuffer for a couple of reasons, but I guess the PSX just uses 24-bit...

Quote:
The player (or players) which usually have lots of animation typically have their graphics loaded into the main work RAM and are DMAed to VRAM as needed. This sort of setup can be seen in SNES games too.

Generally that's done when software decompression is used. With uncompressed graphics, or a decompression chip like the S-DD1 that's capable of feeding DMA, there'd be no need to use WRAM for graphics.

Quote:
The problem with Metal Slug (and Metal Slug X) on PS1 is obviously a lack of RAM.

Exactly. And the only reason that matters is that the CD drive is too slow and high-latency to act as proper ROM. Therefore
Quote:
none of this is relevant to the SNES.

Which was my point, in opposition to TOUKO who seemed to be maintaining that the choppy animation in the PSX version somehow indicated that the game would be even worse on SNES. It very well might be, of course, but if so it would be for unrelated reasons.

Quote:
But a more important question is are you thinking you'll just make your own clone of the game with modified assets? Or are you actually looking to reverse engineer the game?

The idea here would be to port the actual game as faithfully as possible; hence the talk of switching out sprite palettes with HDMA so as to be able to use more than 8.

I'm pretty sure it's a hypothetical at this point - maybe a team will come together around it someday, but I at least am certainly too busy right now. In any case I imagine Espozo would want to be involved; he started learning SNES dev with the idea of making this port himself.

There are a number of ports that could be interesting to try. This is one of them. The danmaku game I'm porting (which I won't name at this stage) is another. TIE Fighter, Thunder Force IV... psycopathicteen was poking at Gunstar Heroes at one point, but seems to be working on an original IP now... Games like Street Fighter Alpha 2 and Doom that appear to have been ported suboptimally could be interesting targets too. But these are all fairly big projects, and together with copyright issues this suggests that few would be willing to bother.

Super Road Blaster exists. It's possible it was simpler to port due to its nature as a laserdisc game with minimal interactivity, but it's at least a completed example, pulled off by one person no less...

A clone of Metal Slug with modified assets (as in real new art, not just rescaled Metal Slug art) would be massively more time-consuming than a straight port even if the art was bad.

Quote:
And no matter what any SNES version of Metal Slug would pale in comparison to the original.

I'm not sure I can agree with this given the current state of the question, though I suppose it depends what you mean by "pale". Certainly it wouldn't be a perfect port. There would be far more sprite dropout as well as a lower horizontal resolution. But it's not clear to me how much worse it would need to get beyond that, because no one's tried it. With an S-DD1 there'd certainly be enough ROM...


Last edited by 93143 on Sun Jun 10, 2018 3:14 am, edited 1 time in total.

Top
 Profile  
 
PostPosted: Sun Jun 10, 2018 2:34 am 
Offline

Joined: Mon Mar 30, 2015 10:14 am
Posts: 275
Quote:
Which was my point, in opposition to TOUKO who seemed to be maintaining that the choppy animation in the PSX version somehow indicated that the game would be even worse on SNES.

Yes because when i read all the comments here, you all seem to think that DMA bandwidth is the only problem to solve to do a good MS port .
DMA bandwidth is only one of the problems,you have to deal with the tons of BGs animations, collisions, the huge and many sprites .
The NG's CPU is only taxed by the game logic and collisions detection,he don't care of VRAM transferts and is not impacted by them and it slow down,really i don't see how the snes's CPU (or MD one) can do better, even if you can juge the NG version as a lazy programming, it still a 10Mhz CPU .

Quote:
The idea here would be to port the actual game as faithfully as possible

i agree else this topic is a nonsense,the goal is to do a conversion as close as possible.


Top
 Profile  
 
PostPosted: Sun Jun 10, 2018 4:25 pm 
Offline

Joined: Fri Jul 04, 2014 9:31 pm
Posts: 966
TOUKO wrote:
you all seem to think that DMA bandwidth is the only problem to solve to do a good MS port .

I don't think I've ever implied this. It's certainly one possible source of trouble, and it's much easier to quantify and have discussions about than CPU load, for instance.

What I've been arguing is specifically that the PlayStation version having choppy animation is not evidence of what you are contending. It's purely a memory issue, which doesn't exist on SNES. And none of the possible problems with a SNES version (CPU, DMA, VRAM, OAM) are even close to being problems on PSX. So the comparison is pointless. It doesn't imply anything.


Top
 Profile  
 
PostPosted: Mon Jun 11, 2018 2:07 am 
Offline

Joined: Mon Mar 30, 2015 10:14 am
Posts: 275
Quote:
It's purely a memory issue,

Not only, there is less sprites on screen and it slow down a lot too and seems less fluid overall.
You can have all the ROM space you want, if you are not able to transfer all the datas and manage all the sprites/collisions needed, it's a pure waste,that's my point :wink:
And even with a SDD-1, i'am really curious if somebody can do something better or impressive only with the stock CPU, because for me there is really too much on screen .


Top
 Profile  
 
PostPosted: Mon Jun 11, 2018 9:56 am 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 7677
Location: Seattle
... They literally said:
93143 wrote:
the PlayStation version having choppy animation
Quote:
purely a memory issue, which doesn't exist on SNES


That's it. Nothing more.

Their entire point is:
  1. PSX version has problems
  2. Those problems imply NOTHING about the feasibility of a good SNES port.


Top
 Profile  
 
PostPosted: Mon Jun 11, 2018 9:59 am 
Offline

Joined: Fri Jul 04, 2014 9:31 pm
Posts: 966
TOUKO wrote:
there is less sprites on screen

Isn't that mostly just debris and stuff? That could pretty easily be explained by the memory issue - maybe they didn't want to waste space on details irrelevant to gameplay.

Quote:
and it slow down a lot too

I'm not seeing it.

In any case, if it did have slowdown, it would have to be either deliberate or incredibly lazy, because a 33 MHz R3000 destroys a 12 MHz 68000, and even 33 Mpix/s is enough to draw over the whole screen roughly 15 times in 1/30 of a second. There's no way this game is legitimately overtaxing either the CPU or the GPU.

It's hard to figure this stuff out with quick web searches, but Metal Slug X at least is said to have no slowdown on PlayStation.

Quote:
and seems less fluid overall.

Yeah, choppy sprite animation (and loading pauses) will do that. Maybe this is why it looks like slowdown? Possibly combined with YouTube conversion issues making the whole thing even choppier?

...

There should have been a Nintendo 64 version. Even the slowest cartridge speed of about 5 MB/s would have been more than enough, and with the monster CPU for decompression, the whole game probably could have fit in a 12 MB cartridge. The N64 isn't known for 2D games, but it has a surprising amount of support for various types of limited drawing that never really got used, and its theoretical performance when drawing untransformed alpha-keyed graphics is 250 Mpix/s. Taking TMEM loading into account and assuming no tile reuse, that drops to a bit under 200 Mpix/s, or eight Neo Geos... you'd have to use big enough chunks to get a substantial fraction of that, of course, but it'd be simple to rearrange the backgrounds and large bosses in horizontal strips, and most other objects, even the 80x80 explosion, would fit in TMEM with room to spare...

...

Also, I was reading sega-16 and found this comment:

TheSonicRetard wrote:
Joe Redifer wrote:
I often wonder if the Neo Geo could even do a game like Space Harrier with it's constantly changing floor.

If nothing else, the Neo Geo could brute force the floor from space harrier through FMV.

It's funny because it's true...


Top
 Profile  
 
PostPosted: Mon Jun 11, 2018 4:30 pm 
Offline

Joined: Wed May 19, 2010 6:12 pm
Posts: 2760
Quote:
Subtracting OAM and 5 KB of sprite data still leaves well over half a KB. Updating one row or column of two BG maps, along with the requisite tile data (assuming 100% new) can be done in four frames at 544 bytes per frame, leaving about half a scanline for overhead.


If you figure out how many palettes or tiles you need before you do the dynamic animation routine, the dynamic animation routine can work around whatever DMA time is left.


Top
 Profile  
 
PostPosted: Mon Jun 11, 2018 11:34 pm 
Offline

Joined: Mon Mar 30, 2015 10:14 am
Posts: 275
Quote:
I'm not seeing it.

A quick example .
https://www.youtube.com/watch?v=34sU5DVIGMM&t=137s

Quote:
Yeah, choppy sprite animation

No it's not really a question of choppy animations, all seem slower, maybe it's the video,or it's because the psx is emulated here i don't know .
But i agree MSx seems a way better game technicaly,it has way less flaws .

TheSonicRetard wrote:
Joe Redifer wrote:
I often wonder if the Neo Geo could even do a game like Space Harrier with it's constantly changing floor.

If nothing else, the Neo Geo could brute force the floor from space harrier through FMV.

The space harrier floor effect is nothing else than a raster effect which can be donne even with sprites,sega did it like that for the Md version (the raster effect ,but with BG not sprites) .


Last edited by TOUKO on Tue Jun 12, 2018 12:35 am, edited 2 times in total.

Top
 Profile  
 
PostPosted: Tue Jun 12, 2018 12:23 am 
Offline

Joined: Fri Jul 04, 2014 9:31 pm
Posts: 966
TOUKO wrote:
Quote:
I'm not seeing it.
A quick example .
https://www.youtube.com/watch?v=34sU5DVIGMM&t=137s

Nope, still not seeing it. I really think it's a combination of choppy sprite animation and poor video sync. Look at the Slug's machine gun; it doesn't change its fire rate at all.

Quote:
The space harrier floor effect is nothing else than a raster effect

I know; I posted that because I thought it was humorous. I almost wouldn't put it past a Neo Geo developer to do that...


Top
 Profile  
 
PostPosted: Tue Jun 12, 2018 12:33 am 
Offline

Joined: Mon Mar 30, 2015 10:14 am
Posts: 275
Quote:
Nope, still not seeing it. I really think it's a combination of choppy sprite animation and poor video sync. Look at the Slug's machine gun; it doesn't change its fire rate at all.

The example was for the boss part, few seconds later !! :D

The saturn version seems to slow down even more, but i don't know if it's related to emulation, or it's the same on real thing .
https://youtu.be/waIxNfAMUBY?t=58s

EDIT: i think this is because emulation .


Top
 Profile  
 
PostPosted: Tue Jun 12, 2018 1:06 am 
Offline

Joined: Fri Jul 04, 2014 9:31 pm
Posts: 966
I still don't see any unambiguous slowdown. If it's there, it's minor, and could be due to a number of factors other than system overload. Emulation is one possibility. Also, the frame rate of the video is low and doesn't seem to be well synchronized with the game's frame rate, which results in strange effects, most obviously with the water. If the game is emulated, frame rate inconsistencies could stack and result in funky timing in the final video. Again, the machine gun's rate of fire seems to be pretty consistent.

As for the Saturn version, a) the Saturn was far harder to program, and b) they may simply have been attempting to emulate the slowdown in the arcade - apparently it's very similar if you use the right RAM cartridge (reportedly, using anything other than the original 1 MB cart slows it down more, which also suggests something weird in the programming).


Top
 Profile  
 
PostPosted: Tue Jun 12, 2018 11:14 am 
Offline

Joined: Wed May 19, 2010 6:12 pm
Posts: 2760
I almost forgot, you can block move 5kB of data together to speed up DMA. Although block moving could be kind've slow, unless you time DMA around HDMA.


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

All times are UTC - 7 hours


Who is online

Users browsing this forum: Google Adsense [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