I've spent some time not wandering around doing random projects and just studying existing ones (mostly byuu's). And I feel like I've learned a lot, so much that I want to stop learning and start some doing again.
For now I have my sights set on a SNES fighting game. Mostly inspired by a quote from
this post:tepples wrote:
The workaround is for the leagues to collaborate on developing a quality fighting game whose program is free software and whose assets are free cultural works.
That quote made me wonder what a legitimate open-source fighting game would be like. It would be painfully ambitious on my part trying to code it, but as for graphics and all, I'll probably just rip some MK3 sprites and call it that for a while. Yes, I'm aware that that makes the assets non-free until original graphics are make, and they might make me unable to put demos on here because of copyright. We'll see. With how long my attention span is for one project, I wouldn't exactly make my money back paying an artist right now.
What I want to knock out first is what people would actually want to play. The big two SNES-era fighting games that I'm aware of (that are a series) are Mortal Kombat and Street Fighter (we'll say MK and SF). I grew up on old MK games, but don't know much about SF. The former seems to lean much more on violence while the latter is simply an arcade-style fun beat-'em-up.
With me being a big MK junkie who grew up looking up fatalities and having nobody as player two so I can perform them flawlessly, of course I'm gonna say I'd like to go with something more MK styled, with the more loose physics and all. So you could say "well, that's what you want so just make it!" but I know there are people around here who might be less into that and more into SF stuff, and since I do intend for this game to eventually be enjoyable by a legitimate audience and not just by people browsing old demos, I'd like for it to be appealing.
There's two big things I want peoples' preference on. Controls, and physics. Controls in MK seem more free than in SF which seems to just allow a bunch of different punches and kicks. Physics seem faster-paced in MK, but sometimes they don't seem to promote a lot of variety in the action (same with the controls, SF has more combos and stuff).
This post probably hasn't given a whole lot of food for thought (it's mostly here to say "I'm alive",) but regardless uh...thoughts?
Controlswise I'm all for MK approach.
nicklausw wrote:
I grew up on old MK games, but don't know much about SF.
I'm mostly the opposite. I didn't exactly grow up playing
any fighting games, but I got a bit into Street Fighter games later on. I've never played Mortal Kombat at all.
Quote:
The former seems to lean much more on violence while the latter is simply an arcade-style fun beat-'em-up.
Somewhat similarly, the impression I get is that Street Fighter is known more for its technical end, whereas Mortal Kombat depends more heavily on thematic appeal. Though you could argue that a differentiator was necessary to counter the first-mover advantage, after which the game would naturally become known for said differentiator...
If I had to vote, I'd vote Street Fighter, but it's an uninformed opinion so don't take it too seriously.
...
If all you know is MK, it might be a good idea to familiarize yourself with Street Fighter games before making this decision. I think the best-playing classic SF games are probably Alpha/Zero 3 and III 3rd Strike, though the more famous II games do have a distinct flavour and you should probably try one of those first. The original Street Fighter is, shall we say, of mainly historical interest...
SNK fighters tend to have significantly different gamefeel, but I think they mostly follow the Street Fighter style - King of Fighters has multiple
Shotoclones, for instance. It might still be useful to play one for perspective... or if I've overestimated just how different MK really is...
On the other hand, if you're a Mortal Kombat fan, maybe you're better off doing a MK-style game, since it might be easier to put your heart into it (darn it, I
know there's a joke around here somewhere)...
I recommend one thing from MK: its more lenient special move recognizer that uses only key down, not individual positions of the whole Control Pad. This way, instead of requiring that the Control Pad be pressed Down, Down+Forward, Forward then Punch to do a fireball, do Down pressed, Forward pressed, A. This makes things like a rising uppercut (Forward Down Forward A), large fireball (Back Down Forward A), and the like easier to hit.
Or simplify the controls even further and just have one button for normal attacks (B), one for special attacks (Y), and one for block (L or R). Then choose weak, strong, low, or high attacks based on the Control Pad being neutral, forward, down, or up. This frees up A for an alternate jump.
I made a post in a similar topic:
viewtopic.php?p=181240#p181240I actually really like the pace of Street Fighter, but don't like its lack of input leniency. (SFV tries hard to change this, but has other issues).
nicklausw wrote:
what a legitimate open-source fighting game would be like.
Sometime ago, a company made a fighting game engine called
Mugen, wich is the basis of many fan-made fighting games.
Don't forget the
Beats of Rage engine, wich is designed towards one vs a million instead of a one-on-one fighting as Mugen.
I think this is kind of a open source project would look like.
About what I expect from a fighting game, well... I mostly want to see nice graphics, a good combo system, fast pacing combats and a cool history.
Looks like both SF and MK have these aspects, as with the many SNK fighting games and others like Rushing Beat, Final Fight and Double Dragon series, just to say some of them...
From my very limited exposure to fighting games (which I suck at)...
- Please no more than three attack buttons. You have fighters where you have separate buttons for your left and right limbs. Don't do that. You also have fighters where you have five or six buttons of varying attack strengths, when three could probably do the job just fine, and make more complex attacks more discoverable.
- Dedicated button for guard/block (and maybe throw?). Defensive options in fighting games make things a lot more interesting, and it's easier to learn if you have a big button that says "press this to block" instead of some random seemingly unrelated button input.
- I suggest the following triangle: attack beats throw, throw beats block/counter, block/counter beats attack.
- No more than one special guage! Don't confuse the player with a myriad of HUD elements.
- Don't punish the player for playing badly (getting dizzy in SF2 because your opponent combo'd you... allowing them to combo you yet again)
- Help the player figure out where and how they're making mistakes. As far as I can tell this is still an unsolved problem in the fighting game genre... good luck!
HihiDanni wrote:
- Dedicated button for guard/block (and maybe throw?)
Or, if you have to fit it on a 3-button system like the Genesis, do it like
Smash Bros. where throw is block+normal attack.
HihiDanni wrote:
Don't punish the player for playing badly (getting dizzy in SF2 because your opponent combo'd you... allowing them to combo you yet again)
Again,
Smash Bros. does it well: dizzy is reserved for overusing block.
HihiDanni: Seems like you want him to make a Friending game and not a Fighting game.
Why can't it be both? Notice that after each bout in
mixed martial arts or
Olympic martial arts, the combatants do what amounts to a Friendship on each other.
Something that doesn't have black bars, and has large well animated characters.
psycopathicteen wrote:
Something that doesn't have black bars
In which of the following six environments do you want no black bars?
- 4:3 TV, 60 Hz (NTSC or PAL-M)
Possible. Use 224 active lines per field. Importers in 50 Hz will see letterbox. - 4:3 TV, 50 Hz (PAL or SCART)
Not possible. The height of the action safe area is roughly 268 lines, and the S-PPU produces only 239 at most. Players will see letterbox. - 16:9 TV, 60 Hz, zoomed out
Not possible. Zoomed out produces pillarbox, or vertical black bars at both sides. - 16:9 TV, 50 Hz, zoomed out
Not possible. Zoomed out produces windowbox, or black bars on all four sides. - 16:9 TV, 60 Hz, zoomed in
Possible. Use 176 active lines per field. - 16:9 TV, 50 Hz, zoomed in
Possible. Use 208 active lines per field.
Lately, it's become common on modern platforms to optimize screen layout for 16:9 TVs.
New Super Mario Bros. Wii, for example, is letterboxed when the display settings are 4:3. I'm aware that this loses vertical resolution, but using interlace can compensate somewhat, especially for slowly moving sprites. It's possible to use interlace only for still or slow cels, such as idle, guard, and knocked down, by using separate sets of sprite tiles for the low and high fields of these cels.
psycopathicteen wrote:
and has large well animated characters.
How large? And are we allowed to trade off background complexity to present one player's character as background instead of sprites?
psycopathicteen wrote:
Something that doesn't have black bars
Not sure what this means. Is that a hardware issue?
I've been looking at everyone else's input too, by the way, just need to take the time to take everything into consideration.
Capcom's fighers on SNES all have mismatched letterboxing, and some people are of the opinion that this is an unnecessary artifact of the original Final Fight engine.
Double buffering sprite data is possible, and tepples has come up with a method of predictive loading that usually results in glitch-free animation on NES. Based on some preliminary calculations, it is suspected by some that even Street Fighter Alpha 2 could have been done at full size without letterboxing on SNES if the engine had been optimized properly.
One question that occurs to me is: is it better to accept the occasional animation frame delay, or to incorporate an across-the-board single-frame input delay?
nicklausw wrote:
psycopathicteen wrote:
Something that doesn't have black bars
Not sure what this means. Is that a hardware issue?
There are three issues all under the banner of "black bars".
- Some games set forced blanking on the top and bottom 8-24 scanlines to buy additional time for DMA to VRAM. Battletoads did this on NES, as do Capcom fighters for Super NES.
- The Super NES was designed for 4:3 TVs. Third- and fourth-generation game consoles put 256x224 pixels in the center of a 280x240 (NTSC) pixel plane that corresponds to the 4:3 frame. Modern TVs are 16:9; a 4:3 picture will either have black bars on the sides or have a bunch chopped off the top and bottom.
- Consoles for 50 Hz markets with (PAL or SCART output) have more scanlines per field than NTSC. Most consoles aren't capable of reaching all these pixels, resulting in substantial letterboxing that becomes windowboxing on 16:9 sets.
tepples wrote:
nicklausw wrote:
psycopathicteen wrote:
Something that doesn't have black bars
Not sure what this means. Is that a hardware issue?
There are three issues all under the banner of "black bars".
- Some games set forced blanking on the top and bottom 8-24 scanlines to buy additional time for DMA to VRAM. Battletoads did this on NES, as do Capcom fighters for Super NES.
This is what I assumed he was talking about, given the other times he's mentioned it in other threads.
93143 wrote:
Based on some preliminary calculations, it is suspected by some that even Street Fighter Alpha 2 could have been done at full size without letterboxing on SNES if the engine had been optimized properly.
Street fighter alpha 2 in snes has a brutal bandwidth that could let all the animations of the arcade game, with the original size of the characters.
Seriously, even two zangiefs are within the requeriments... the only thing is the limit of sprites per scanline if both of them fall to the ground at the same time, maybe could be possible to collapse all the drawing thing during that frames xD
I think a lot of fighting games waste a lot of time re-uploading the entire HUD every frame instead of just stuff that needs to be changed. You just need to change the health bars when a player gets hit, and change the timer once a second.
psycopathicteen wrote:
I think a lot of fighting games waste a lot of time re-uploading the entire HUD every frame instead of just stuff that needs to be changed. You just need to change the health bars when a player gets hit, and change once a second.
Depending of the complexity, maybe you can keep all the necessary tiles in VRAM, saving bandwidth.
After all, a yellow/red bar is the succession of one tile repeated a determined number of times.
But, well seen, i never thought about that.
So I thought about this for a bit. You can have some pretty big characters with full screen height, but you'll only have the bandwidth to upload graphics for one at a time. However, you also want to be fair to both players by not preferring early updates for one over the other. So here is my idea for a simple algorithm that won't introduce any input lag (though occasionally the sprite change will be delayed by one frame for both players). It involves looking one frame in advance into the animation data:
- Each player sprite is 4 KiB max.
- If only one of the two players is changing their sprite on this frame, go ahead and change it this frame.
- If both players are changing their sprite either on this frame, or the next frame, buffer player 1's sprite this frame (but don't display it). Next frame upload player 2's sprite as if it were on the same frame as player 1's and display both at once.
There will be a one frame sprite change delay if both players perform an input on the same frame. Outside of input changes, there should be no delay, assuming a max animation rate of 30 FPS.
Yeah, something like:
-Character 1 upload the tiles ot it animation during odd frames. Character 1 starts its animation during odd frames.
-Character 2 upload the tiles of it animation during pair frames. Character 2 starts its animation during pair frames.
-In the third frame is mixed all the computing to evaluate all the thing about prioritys, so nobody really punchs first. Character 1 made effective it animation during frame 1, and character 2 made effective it animation during frame 2 (one frame later), but only counts during third frame, where the character 2 already have too the same animation before deciding the result.
With animations at even 3 ticks, there could not have conflicts... except that sometimes seems that one player punchs first, and sometimes the other, but being always a double punch.
It has its coherence in the fact that at that level is impossible to appreciate differences except recording at high speed (but, please...), and after all there isn't any cheating, and this even counting with the fact that is truly hard to do the same move just in the same frame.
Both the sprites in this photo are about 4KB (warning: i say in this photo shrinked at 256x224, not in the original at 384x224)... so, doubling its size we go over 8KB for sure, BUT, uploading tiles by turns, you can do it without change resolution or refresh, all at 256x224 and 60fps.
And stretching the image more or less at the size of a crt:
The thing is, in the photo every one of the two characters are about 2,5KB, but doing it during succesive frames every character could upload until 5,5KB without risks of artifacts... so, Could be possible hugo vs hugo doing one of them with a plane to don't overdraw?.
I said something interesting?.
Every time fighting games get brought up, it makes me think about compression algorithms and how there is no guaranteed way of knowing which algorithm is best because luck is involved. You can even take a sprite, rotate it by 90 degrees and get completely different results with algorithms that don't accommodate for both horizontal and vertical detail.
I'm throwing ideas out. Maybe we can make an algorithm that separates a sprite into 3 layers. A horizontal RLE layer, a vertical RLE layer, and a fine detail layer, that has both runs of uncompressible pixels and sporadic single pixels.
How computationally intensive is your average fighting game, excluding graphics decompression?
I don't think fighting games are that CPU intense.
I think it should decompress roughly 4kB per frame.
Something just occurred to me. I can save sprites as PNG and ZIP files and use that as a benchmark.
It seems like that might require an extra frame of lookahead, or at least more frequent lag frames. 4 KB per frame isn't enough to fill VBlank, and you'd want to be able to rely on the data being there in the maximal load case.
This is why I like the S-DD1 - you don't have to worry about that. The SA-1 would be good at decompression too, though it might be overkill if your only problem is that you have too much graphics data.
But I know you tend to be more hardcore than me when it comes to pushing the unassisted S-CPU. It seems like every time I come up with an idea for something that could be done with a special chip, you come up with an idea about how to do the same thing without one...
...
Do you know if anyone ever tried Stef's LZ4W on the SNES?
I have an idea for a huffman-RLE format.
Each color would have a list of the most to least frequent adjacent color (excluding itself) with a hardcoded huffman tree.
1: 00
2: 01
3: 100
4: 1010
5: 1011
6: 1100
7: 1101
8: 11100
9: 111010
10: 111011
11: 111100
12: 111101
13: 111110
14: 1111110
15: 1111111
...and the length is encoded like this
1: 0
2+x: 1xxxx
If the length is 17 or more, there would be an additional 4 bits, etc
EDIT: Dang it I forgot 12.
Quote:
I don't think fighting games are that CPU intense.
You're right, if you don't need compression it's how much data you can transfer in VRAM who's counting .
Quote:
Do you know if anyone ever tried Stef's LZ4W on the SNES?
if you want a well suited on the fly depacker for the 65816 you can look at this :
https://www.brutaldeluxe.fr/products/cr ... index.htmlthe decompression part is in 65816 asm,and all the tools are supplied and the stef's lz4w is based on this algo .
Code:
Here is the LZ4 unpacker source code, ready to be assembled into Merlin 16+ or Orca M :
Before calling the unpack code function, you have to allocate 2 memory banks of 64 KB, one containing the LZ4 file (Source Bank) and one ready to receive the Uncompressed Data (Destination Bank). Because we are only processing file with a size < 64 KB, we don't need more space and we don't have to deal with bank boundary. The LZ4 file will be loaded at the beginning of Source bank and the uncompressed data will be written at the beginning of the Destination bank. We also need to provide the Header size (16 bytes) and the LZ4 file size (used to stop the unpacking process) :
MX %00
*-------------------------------------------------------------------------------
LZ4_Unpack STA LZ4_Literal_3+1 ; Uncompress a LZ4 Packed Data buffer (64 KB max)
SEP #$20 ; A = Bank Src,Bank Dst
STA LZ4_Match_5+1 ; X = Header Size = 1st Packed Byte offset
STA LZ4_Match_5+2 ; Y = Pack Data Size
XBA ; => Return in A the length of unpacked Data
STA LZ4_ReadToken+3
STA LZ4_Match_1+3
STA LZ4_GetLength_1+3
REP #$30
STY LZ4_Limit+1
*--
LDY #$0000 ; Init Target unpacked Data offset
LZ4_ReadToken LDAL $AA0000,X ; Read Token Byte
INX
STA LZ4_Match_2+1
*----------------
LZ4_Literal AND #$00F0 ; >>> Process Literal Bytes <<<
BEQ LZ4_Limit ; No Literal
CMP #$00F0
BNE LZ4_Literal_1
JSR LZ4_GetLengthLit ; Compute Literal Length with next bytes
BRA LZ4_Literal_2
LZ4_Literal_1 LSR ; Literal Length use the 4 bit
LSR
LSR
LSR
*--
LZ4_Literal_2 DEC ; Copy A+1 Bytes
LZ4_Literal_3 MVN $AA,$BB ; Copy Literal Bytes from packed data buffer
PHK ; X and Y are auto incremented
PLB
*----------------
LZ4_Limit CPX #$AAAA ; End Of Packed Data buffer ?
BEQ LZ4_End
*----------------
LZ4_Match TYA ; >>> Process Match Bytes <<<
SEC
LZ4_Match_1 SBCL $AA0000,X ; Match Offset
INX
INX
STA LZ4_Match_4+1
*--
LZ4_Match_2 LDA #$0000 ; Current Token Value
AND #$000F
CMP #$000F
BNE LZ4_Match_3
JSR LZ4_GetLengthMat ; Compute Match Length with next bytes
LZ4_Match_3 CLC
ADC #$0003 ; Minimum Match Length is 4 (-1 for the MVN)
*--
PHX
LZ4_Match_4 LDX #$AAAA ; Match Byte Offset
LZ4_Match_5 MVN $BB,$BB ; Copy Match Bytes from unpacked data buffer
PHK ; X and Y are auto incremented
PLB
PLX
*----------------
BRA LZ4_ReadToken
*----------------
LZ4_GetLengthLit LDA #$000F ; Compute Variable Length (Literal or Match)
LZ4_GetLengthMat STA LZ4_GetLength_2+1
LZ4_GetLength_1 LDAL $AA0000,X ; Read Length Byte
INX
AND #$00FF
CMP #$00FF
BNE LZ4_GetLength_3
CLC
LZ4_GetLength_2 ADC #$000F
STA LZ4_GetLength_2+1
BRA LZ4_GetLength_1
LZ4_GetLength_3 ADC LZ4_GetLength_2+1
RTS
*----------------
LZ4_End TYA ; A = Length of Unpack Data
RTS
psycopathicteen wrote:
Each color would have a list of the most to least frequent adjacent color (excluding itself) with a hardcoded huffman tree.
Huffman based on adjacent color... Are you a
codemaster by any chance?
But seriously: I'd be interested to see what ratio you get for real images using this technique.
I thought a little bit more about this. I think the run lengths should be done like this, as opposed to the above, to avoid runs of 2 pixels causing bloat.
Code:
1: 0
2: 10
3+x: 11xxxx
I also thought that perhaps I should make the color huffman tree slightly less risky, by making sure colors never exceed 5 bits.
Code:
1: 00
2: 01
3: 1000
4: 1001
5: 1010
6: 10110
7: 10111
8: 11000
9: 11001
10: 11010
11: 11011
12: 11100
13: 11101
14: 11110
15: 11111
I've thought about using 3 different 8x8 tile types, with type 4 being an end marker.
-horizontally compressed tiles
-vertically compressed tiles
-uncompressed tiles
EDIT:
I was wrong with thinking that this tree is "safer" because "safeness" can be calculated by averaging the code size for each color. It should have the worst case scenario only slightly worst than uncompressed code.
EDIT:
Nevermind, I forgot 12 in the previous post. The new tree is indeed safer.
psycopathicteen wrote:
I thought a little bit more about this. I think the run lengths should be done like this, as opposed to the above, to avoid runs of 2 pixels causing bloat.
Code:
1: 0
2: 10
3+x: 11xxxx
I also thought that perhaps I should make the color huffman tree slightly less risky, by making sure colors never exceed 5 bits.
Code:
1: 00
2: 01
3: 1000
4: 1001
5: 1010
6: 10110
7: 10111
8: 11000
9: 11001
10: 11010
11: 11011
12: 11100
13: 11101
14: 11110
15: 11111
I've thought about using 3 different 8x8 tile types, with type 4 being an end marker.
-horizontally compressed tiles
-vertically compressed tiles
-uncompressed tiles
EDIT:
I was wrong with thinking that this tree is "safer" because "safeness" can be calculated by averaging the code size for each color. It should have the worst case scenario only slightly worst than uncompressed code.
EDIT:
Nevermind, I forgot 12 in the previous post. The new tree is indeed safer.
If you provide some example data (in any format supported by
Farbfeld Utilities), then I can try to implement this, and see if it is working. (Some name to call such format also should be needed.) (With this new Huffman table, a forty byte header (5 times 16 times 4 bits) to specify which colours are most common next to another one, should be sufficient.)
Attachment:
darkstalkers felisha.png [ 3.06 KiB | Viewed 3236 times ]
You can break this up into 8x8 tiles for compression. I'll also post a "VRAM pattern table" version for a better idea of how it would fit in a ROM uncompressed.
Attachment:
darkstalkers VRAM.png [ 4.12 KiB | Viewed 3224 times ]
Here is the VRAM table version.
I wrote the encoder, and am now starting writing the decoder too. My initial experiment shows that it seems to be about as good as PNG (but there is something wrong with the comparison, because PNG is a whole picture format rather than a tile set format; I did compare only the IDAT chunk though; I also expect that with a larger picture and better compression settings, PNG might work better anyways, but I am not sure and it might not), although I will need to write the decoder too in order to test if it is correct, and then I will release the files (including source-codes) as public domain, and then further tests can be made and/or the program can be altered in order to make improvement.
Note: I did not use your "VRAM table version". Before you posted the VRAM table version, I wrote my own program to remove duplicate tiles instead, which I have already released (it is called "ff-uniq").
How many bytes is that? The sprite would take up 3kB VRAM.
psycopathicteen wrote:
How many bytes is that? The sprite would take up 3kB VRAM.
I got it to 1674 bytes, but that includes a 42 byte header (2 bytes give the tile size (8x8 in this case), and then there are two and a half bytes for each of 16 colours, giving the information about the five most common adjacent colours (storing additional adjacency data is worthless due to the Huffman tree used)). My calculation of storing uncompressed is 3040 bytes (1 byte for 2 pixels). These are the results with PNG format to compare:
Code:
$ pngff < felisha.png | ff-strip 8 8 1 | ff-uniq 8 | ff-strip 8 8 19 | ffpng w32768 n258 | pnglist
IHDR 13
PLTE 48
IDAT 1701
IEND 0
I have started writing the decoder and will post it soon if it is working, so that we can then make more discussion of improvement and other details.
Here are the programs:
This may be used to make more experiments with it, and see if any improvement might be made, etc.
Wow, you're fast. I wish I can be that fast at programming.
Allowing both horizontal compression and vertical compression does in fact help. I have also added a report mode, to display the encodings in case that helps anyone; and now ffbit/bitff can support (uncompressed) Super Nintendo format graphics too. However, I do have some other ideas too (none of which I have implemented yet, and I also don't know what will help and what doesn't help):
- Order the palette so that colours 1 to 15 are the most to least frequently adjacent to colour 0, in order to save 20 bits (two and a half bytes) in the header; but, depending on details that I do not know about both the game and the Super Nintendo, this might not be suitable.
- The type codes themself could be huffed to save a few bits, since horizontal and vertical compression seem to be much more common than uncompressed tiles (with the example data given, no tiles are uncompressed), and of course the end marker can only occur once. But it also care, the decoder intended to be used, how much it would complicate it, I suppose.
- I don't know what ratios are achieved using your old Huffman tables, although they would require a larger file header to support them.
You are speaking of compression, but what you want exactly ??
On the fly decompression, or the best compression possible ??
Because i don't think that huffman is particularly well suited for on the fly decompression or graphic datas, and so why using compression today when big roms are cheap ??
TOUKO wrote:
why using compression today when big roms are cheap ??
Because big ROMs are serial, and serial ROMs are slow to access unless you run them on the 21.5 MHz master clock and have some circuit on the cart act as a shift register. Bit-banging an SPI flash would feel like "loading" on a CD system.
Ah ok, it's a good reason then
What on earth are you talking about? There are already two SNES-specific interfaces defined for outsize ROMs. One (the MSU1) allows 4 GB of data, and the other (S-DD1) is legit official period hardware and has onboard decompression circuitry. Both can feed DMA.
You're not going to outperform the S-DD1 with a software codec, not once the bankswitching capability is accounted for. I can only think of a few reasons why one would try to do heavy-duty manual decompression on the S-CPU in the current year:
- to prove it's possible
- to avoid accusations of "cheating"
- to avoid having to source a rare, poorly understood (?) chip
- to allow the use of a different special chip that's incompatible with the S-DD1, without relying on the blatantly unhistorical MSU1
- uh... how much current does an S-DD1 draw? Can you use it with a multitap?
Am I missing anything?
93143 wrote:
I can only think of a few reasons why one would try to do heavy-duty manual decompression on the S-CPU in the current year:
[...]
- to avoid having to source a rare, poorly understood (?) chip
There's the big one. Remaking S-DD1 or MSU1 for a production single-game cartridge might be cost prohibitive.
Quote:
to avoid accusations of "cheating"
The teams who's developing for the MD, don't care about this assumption .
For exemple:
Pier solar 64 MB
Paprium 64/80 MB
Overdrive 2 64 MB
it seems that all SF2 versions (exept alpha) were uncompressed,so you can easily make a good fighting game with 40/64 MB without any compression .
however:
Quote:
to prove it's possible
this is a good and valid argument .
Sometimes I forget that not every game needs to be 100% stock hardware.
And sometimes I forget that the special chips aren't just there by default, especially if you plan to actually manufacture the game.
TOUKO wrote:
Quote:
to prove it's possible
this is a good and valid argument .
It's the only reason I'm in SNESdev in the first place. Mind you, it did turn out to be a really fun hobby...
The game I'm porting is advanced enough that I feel no shame at using the Super FX with extra CPU ROM. (And since it
is a port of somebody else's IP, mass production isn't high on my priority list.) If I were to attempt a port of Thunder Force IV, I'd try to do it with stock hardware only. Ideally SlowROM (Rendering Ranger was SlowROM), but that might be pushing it...
I might even go with pre-rendered sprite rotation in my game if I can't get it fast enough for large sprites. If I mix it with software rendering for smaller sprites, people might think I'm doing the same with larger sprites too.
Quote:
If I were to attempt a port of Thunder Force IV, I'd try to do it with stock hardware only
i agree, but can we consider for exemple the use of a SA-1(only the 65816 core) as cheating ??
If somebody can patch TF3 and delete/minimise his slowdowns like psycopathicteen did with SGnG
In fact the big problem is not the low snes's CPU frequency, if the hardware was staightforward the frequency would not have been a problem, but adds with the complexity of the system an unnecessary overhead,like for exemple this stupid 16k sprites limit.
Quote:
The game I'm porting is advanced enough that I feel no shame at using the Super FX with extra CPU ROM
Interesting, have you a rom or video of it ??
Why would using the SA-1 be cheating? If it's necessary to port TF4 faithfully (i.e. without having to cut features / gameplay elements) then that's just what it takes.
Putting a different chip (e.g. x64 + DDR4 RAM + clock multiplier) would be another issue.
Quote:
Why would using the SA-1 be cheating
Because it's not a part of the stock machine and help a lot for doing better games, that normaly the standard hardware cannot without slowdowns .
And using a SA-1 to do a simple TF4 port would be boring, because i think a snes+SA-1 can do something largely better than this game, in every way(RR² is already as impressive technicaly) .
For exemple this SMW style demo,with 1 classic layer+1 mode 7 layer:
https://www.youtube.com/watch?v=spVwBD6NOVIreal time sprite rotation:
https://youtu.be/tNSaMX4cuHQ?t=19sOr 3D:
https://www.youtube.com/watch?v=42GeYsPGSjM
The Mode 7 level can be done without an SA-1 if Vitor Vilena didn't treat every BG sprite cell as separate objects.
I've managed to do software rotation of a 64x64 sprite on stock hardware, but at least it's cleaner rotation than my algorithm.
psycopathicteen wrote:
The Mode 7 level can be done without an SA-1 if Vitor Vilena didn't treat every BG sprite cell as separate objects.
technicaly you're right, but there is some slowdowns even with SA-1,imagine with the stock CPU !!
Quote:
I've managed to do software rotation of a 64x64 sprite on stock hardware, but at least it's cleaner rotation than my algorithm.
Yes i know that
, and i find it impressive, but is it all in real time,or some phases are precalc ??
The guy who's make those demos describe himself as a non 65816 guru, imagine what you can do with all this power !!
creaothceann wrote:
Why would using the SA-1 be cheating?
Why port TF4 at all in this day and age?
The only reason I can see is to prove the console can handle it. And if you're using the SA-1, it kinda says the opposite. More than that, it's overkill. It's like porting F-Zero to the 32X - kinda removes the point of the exercise. As TOUKO said, it's boring.
(There's one other reason to do the port. I kinda like the soundtrack, and I want to see what it would sound like in a more realistic style with the SNES APU stretched to its limits, using obscure features like pitchmod and recent ideas like sample ID switching and high-bandwidth HDMA streaming. But you wouldn't need to port the whole game just for this.)
TOUKO wrote:
For exemple this SMW style demo
Pretty sure that's literally a SMW ROM hack. I don't think you should be expecting much in terms of efficiency.
Quote:
The only reason I can see is to prove the console can handle it.
I suppose the other reason is a mundane one: to simply play it on your snes.
Okay, fair enough, but does that motive by itself justify all that effort? If you've got the resources to port it, surely you've got the resources to play it. And the market for such a port could hardly be very large nowadays, especially since most people would be satisfied with Kega Fusion and an Xbox pad.
We do know that "to prove it's possible" is a working motivation. The Mega Drive Star Fox demo proves it. Hu-Zero proves it. Heck, the entire demoscene proves it. But I'm not aware of any retro console port done solely for the reason you cite; everything I can think of is some sort of technical marvel, and most of them are just proof-of-concept demos that are only fun to play because they impress you with the fact that they run at all.
If these motivations were combined, they might result in a working port. I guess what I'm saying is that using the SA-1 seems to send the message that it's not possible on a stock SNES, vindicating all the Sega fanboys who have claimed this throughout the ages, and that would seem to remove a lot of the motivation from the sort of person who might try it in the first place.
Aha. I didn't think of it that way, but now it makes perfect sense to me. Thanks for elaborating.
I think tschack's
Wizard of Wor port might fall a bit in both categories, and then there's retroUSB:s
quadralords. But they might be in the minority.
Likewise, i've been toying with the idea of a
Moon Patrol port or clone, simply for being able to have something that plays like moon patrol on the NES (it's just in the very far end of my projects list). But that's not even a thing yet, so...
For a Sega to SNES port, it's hard to get all the resources available from the original game. Plus you would probably need to clean up dithering, and deal with aspect ratio incompatibilities.
...right, you've dealt with this before. You were trying to port Gunstar Heroes.
Why'd you stop? Or did you just answer that?
FrankenGraphics wrote:
I think tschack's
Wizard of Wor port might fall a bit in both categories, and then there's retroUSB:s
quadralords.
I guess you might see some of that on NES. The psychology seems to be different, maybe because there was no real console war in the NES era... Also, those games are a lot simpler, so they don't require as much motivation to finish.
TOUKO wrote:
Quote:
The game I'm porting is advanced enough that I feel no shame at using the Super FX with extra CPU ROM
Interesting, have you a rom or video of it ??
It's not very far along (I've been rather busy), and I'm trying to keep quiet about exactly what game it is, partly because I've overpromised and underdelivered often enough in the past that I don't want any specific expectations attached to this project. All I'll say is that it's a vertical bullet hell shmup, and that it's from a significantly more powerful platform than the SNES (being stubborn about the graphical presentation has cost me about 2/3 of my CPU time in raster effects).
But I have posted a
Super FX coding exercise with a pseudorandom bullet pattern that reaches 640 shots onscreen at 60 fps. This doesn't prove much by itself about the feasibility of the game, but it does put me in the ballpark.
Quote:
I suppose the other reason is a mundane one: to simply play it on your snes.
yeah, but no need a SA-1, you can do a pretty accurate port on a stock machine .
Quote:
We do know that "to prove it's possible" is a working motivation. The Mega Drive Star Fox demo proves it. Hu-Zero proves it. Heck, the entire demoscene proves it. But I'm not aware of any retro console port done solely for the reason you cite
i agree .
Quote:
For a Sega to SNES port, it's hard to get all the resources available from the original game. Plus you would probably need to clean up dithering, and deal with aspect ratio incompatibilities.
if you want to prove it's possible on a stock machine no need to code the entire game, i think only a level is sufficient .
@93143: ah it's a 2D game, cool because in my mind (sorry) SFX sound 3D,and i forget often the beautiful yoshi island
TOUKO wrote:
psycopathicteen wrote:
The Mode 7 level can be done without an SA-1 if Vitor Vilena didn't treat every BG sprite cell as separate objects.
technicaly you're right, but there is some slowdowns even with SA-1,imagine with the stock CPU !!
Quote:
I've managed to do software rotation of a 64x64 sprite on stock hardware, but at least it's cleaner rotation than my algorithm.
Yes i know that
, and i find it impressive, but is it all in real time,or some phases are precalc ??
The guy who's make those demos describe himself as a non 65816 guru, imagine what you can do with all this power !!
I decided not to use real time rotation, because it gets really choppy when I have it running during a boss fight and I've been working on it for far too long and I've already managed on making more RAM room for rotating sprites.
Hey, time for bumps.
I've finally come back to this project after not having time to think about it (high school isn't calming down near the end of my time there, sadly). So far, the only progress made is that the project is
using HiROM now, a feat I didn't expect to get done without having to come here and post for help.
I do have to ask how people manage things in HiROM though. My PPU copying routine (actually I
stole it) is becoming pretty awful because it's always getting called when the data bank is set to something crazy like $C1, meaning my code has to use long addresses.
Code:
function copy {
php
axy16()
sta ^DMAMODE
txa; sta ^DMAADDR
tya; sta ^DMALEN
a8()
phb
pla
sta ^DMAADDRBANK
lda #%00000001
sta ^COPYSTART
plp
rtl
}
The assembler I use offers ^ as an alternative to ".l". I'd like to just have the copying function change the data bank to $00 itself, but I'd want to preserve its original value, which could get weird as the function utilizes all three registers.
Code:
php; pha; phb; a8(); lda #$00; pha; plb; a16(); pla // start of function (this wouldn't even work)
plb; plp // end
Is there any good way to avoid stack nightmares like that while having easy access to bank 0 registers without long addresses everywhere? It would be easier if phb set the bank to 0, but it doesn't.
It doesn't seem to me that there's any way to do it that wouldn't take longer than just using long addresses.
Note that long addresses only add one cycle over a 16-bit address, so they're not as costly as you might expect. You would need to set the bank to $00 and restore it in less than 5 cycles 9 cycles to make your copy routine faster than what you've already got.
EDIT: Just noticed that you're doing txa; sta ^DMAMODE because stx and sty don't have a long addressing mode, so it's 9 cycles rather than 5 cycles. I'm not sure if it can be done even in 9 cycles though.
I've seen it recommended to just keep the data bank in the LoROM areas ($00-$3F, $80-$BF), and put any small data tables you need direct code access to in those areas (for 4 MB or less, I guess that means putting such stuff in the top halves of banks). The program bank can be in a HiROM region so you get 64 kB of uninterrupted code, and bulk data can be put anywhere because specifying a bank for DMA is not very onerous.
You might also want to move the direct page to point to a set of registers if you need to do a bunch of accesses (since direct page is always in bank 0), but make sure it's a net win cycle-wise first.
When direct page is pointed at PPU ports ($2100) or memory controller ports ($4200), you can't easily use it for (dd),Y addressing. This means you need to fall back to (dd,S),Y, which has a 1-cycle penalty like [dd],Y.