nesdev.org

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.

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.

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.

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=spVwBD6NOVI

real time sprite rotation:
https://youtu.be/tNSaMX4cuHQ?t=19s

Or 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 !!

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.

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:

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.

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 .

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 .

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 !!

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. 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. 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.