Anybody on here have a powerpack or neo myth cart, and would like to test this out on real hardware?
I don't have either of those, but I have somethng that will load roms and play them on real hardware. I can take a look for you if you'd like and record a video/stream it for you if you'd like.
I'm doing a lot of work upgrading my metasprite/animation routine, to handle all the animated sprites, so it may take awhile before I have a demo with explosions.
I currently have it optimized to select between dynamic (sprite patterns being updated on the fly, such as player and enemies) and non-dynamic (sprite patterns that remain in vram, such as explosions and bullets) and to upload 8x8 dynamic sprites in a seperate region from 16x16 dynamic sprites.
What still needs to be done is change the metasprite format, so that the ROM address of the dynamic sprite patterns are defined per metasprite, instead of per sprite, because it will be more CPU efficient.
Some of the bosses look like they will be challenging to program.
Eventhough my animation routines are already working efficiently enough, there is still one more optimization I want to make. The DMA routine is an unrolled loop with each sprite pattern being updated individually. Since I already have the sprite patterns organized into metasprite groups, it would make sense for the DMA routine to also update the sprite patterns in metasprites groups.
Many of you are forgetting that this is fucking Gunstar Heroes. The fact that it might be able to expand to another console is just plane badass.
Here's hoping someone will eventually fix the port of Thunder Force III and then port TFIV.
Funny you mention that. I was wondering myself if a given game (such as TF3 or Gradius 3) could be hacked to use the SA-1 chip. While the SNES is more efficient than the Genesis, it's still slower in the long run, but that's where the SA-1 could be potentially useful, which will nearly triple the SNES' power. Thunder Spirits is a gorgeous game for the SNES, but they didn't program it as well as it could have been.
Also, BioMetal is one interesting SNES shmup. In addition to using 2 Unlimited's music, it's also one of the few SNES shooters that has TONS of bullets and ships onscreen and suffer little to no slowdown. Was this an SA-1 game? Cause if not, then they must've had some talented programmers for that.
Many of you are forgetting that this is fucking Gunstar Heroes. The fact that it might be able to expand to another console is just plane badass.
Here's hoping someone will eventually fix the port of Thunder Force III and then port TFIV.
Funny you mention that. I was wondering myself if a given game (such as TF3 or Gradius 3) could be hacked to use the SA-1 chip. While the SNES is more efficient than the Genesis, it's still slower in the long run, but that's where the SA-1 could be potentially useful, which will nearly triple the SNES' power. Thunder Spirits is a gorgeous game for the SNES, but they didn't program it as well as it could have been.
Also, BioMetal is one interesting SNES shmup. In addition to using 2 Unlimited's music, it's also one of the few SNES shooters that has TONS of bullets and ships onscreen and suffer little to no slowdown. Was this an SA-1 game? Cause if not, then they must've had some talented programmers for that.
BioMetal does not use an SA-1 chip.
The funny part is that I know how BioMetal pulled off a ton of sprites without slowdown. What I don't know is how everyone else fucked it up.
The funny part is that I know how BioMetal pulled off a ton of sprites without slowdown. What I don't know is how everyone else fucked it up.
Is that so? Then damn, color me impressed. Other notable SNES shooters that have a fair bit of action with notable slowdown would be all three Parodius titles. Hell, in the second one (Gokujou Parodius), one of the bunny girls will LITERALLY slow down the entire game when she's fully equipped and starts firing. As for why, I guess it's because they decided that it wouldn't be worth the effort. This is the same reason why the SNES has a comically large selection of RPGs.
The funny part is that I know how BioMetal pulled off a ton of sprites without slowdown. What I don't know is how everyone else fucked it up.
Is that so? Then damn, color me impressed. Other notable SNES shooters that have a fair bit of action with notable slowdown would be all three Parodius titles. Hell, in the second one (Gokujou Parodius), one of the bunny girls will LITERALLY slow down the entire game when she's fully equipped and starts firing. As for why, I guess it's because they decided that it wouldn't be worth the effort. This is the same reason why the SNES has a comically large selection of RPGs.
I wonder why Konami thought that 16-bit arithmetic wasn't worth the effort, but 32-bit arithmetic was, despite the fact that 32-bit arithmetic takes longer to write. If you have a CPU with a single 16-bit accumulator, what's the point of bogging yourself down, juggling 2 words with 1 accumulator?
I wonder why Konami thought that 16-bit arithmetic wasn't worth the effort, but 32-bit arithmetic was, despite the fact that 32-bit arithmetic takes longer to write. If you have a CPU with a single 16-bit accumulator, what's the point of bogging yourself down, juggling 2 words with 1 accumulator?
I dunno, I wish I was a programmer. It's probably for the same reason that Contra Force slows down all the time. Unless the "AI Routines" hogged up that much resources, previous Contra games were capable of far more action onscreen with very brief slowdown, should it occur. They probably programmed the game first, and then decided to skimp out on the optimization, since they figured "who cares? It's not like they can do anything about it".
It actually takes more effort to program a game the way Capcom and Konami did, than to program a game the efficient way the creators of BioMetal did, not the other way around like most people would expect.
It actually takes more effort to program a game the way Capcom and Konami did, than to program a game the efficient way the creators of BioMetal did, not the other way around like most people would expect.
You're saying that it takes more effort to get a game to run sub-par than it is to do it right?
I'm amazed and intrigued. Could you share a bit more of your knowledge on these things?
It actually takes more effort to program a game the way Capcom and Konami did, than to program a game the efficient way the creators of BioMetal did, not the other way around like most people would expect.
You're saying that it takes more effort to get a game to run sub-par than it is to do it right?
I'm amazed and intrigued. Could you share a bit more of your knowledge on these things?
I think most people didn't use the program bank register and the data bank register in the 65c816 CPU, which would slow things down.
And as Aaendi already said, Konami used 32-bit arithmetic with 16 bit registers, when 16 bit would have been just fine in most, if not all cases.
Also, if you do things in a slow way, it will be harder to get a lot of moving stuff on screen, in some cases impossible.
Here is the collision detection routine I use. Sweet, simple and to the point. Direct Page points to one sprite slot, Index X points to the other. First it checks if the objects overlap on the x-axis, then it checks if they overlap on the y-axis. If they overlap eachother on both axis, then collsion has occured.
If you look at the collision detection routine found in your average SNES game, it is much longer, and more complicated.
I'll take your word on that, since I'm not programming inclined. I seriously wonder what Gradius 3 did in order to have such tremendous slowdown. Sure, it's one of the first SNES games ever programmed, but it's still pretty bad.
Hmm, in BSNES, the character just keeps going to the left, and in SNES9X you never know if you will shoot or not when pushing the shoot button(if you don't shoot the gun will be visible, when shots actually come the gun is not visible)
"Oh, Gunstar Heroes. There's a ton of stuff in that game (or any MD game with decent -let alone heavy- optimization around the hardware's strengths) that couldn't be done as well on the SNES . . . or at all in some cases. (it definitely won't be able to pull off sprites in the same way without more flicker/tearing, and resolution will be lower) And on vanilla SNES hardware, there's even more than you'd probably have to compromise, and even more if you limited ROM size, and even more still if you limited ROM speed. (3.58 vs 2.68 MHz makes a real difference)"
God, do these people EVER look at a fricking programming manual? They keep complaining about a CPU they know absolutely nothing about.
Comments
Originally posted by: dra600n
Originally posted by: Aaendi
Anybody on here have a powerpack or neo myth cart, and would like to test this out on real hardware?
I don't have either of those, but I have somethng that will load roms and play them on real hardware. I can take a look for you if you'd like and record a video/stream it for you if you'd like.
Go right ahead.
-Controls are no longer delayed by a frame
-Enemies no longer "pop" onscreen when being spawned
-Enemies no longer jump 16 pixels for a single frame when being killed
-When hanging from a tree, player character now only snaps to the branch on the way down from jumping
BSNES v091 (with slowdown)
BSNES v070 (no slowdown)
I currently have it optimized to select between dynamic (sprite patterns being updated on the fly, such as player and enemies) and non-dynamic (sprite patterns that remain in vram, such as explosions and bullets) and to upload 8x8 dynamic sprites in a seperate region from 16x16 dynamic sprites.
What still needs to be done is change the metasprite format, so that the ROM address of the dynamic sprite patterns are defined per metasprite, instead of per sprite, because it will be more CPU efficient.
Eventhough my animation routines are already working efficiently enough, there is still one more optimization I want to make. The DMA routine is an unrolled loop with each sprite pattern being updated individually. Since I already have the sprite patterns organized into metasprite groups, it would make sense for the DMA routine to also update the sprite patterns in metasprites groups.
Keep up the good work, I look forward to following this project.
Originally posted by: Enig
Originally posted by: Thunderblaze16
Many of you are forgetting that this is fucking Gunstar Heroes. The fact that it might be able to expand to another console is just plane badass.
Here's hoping someone will eventually fix the port of Thunder Force III and then port TFIV.
Funny you mention that. I was wondering myself if a given game (such as TF3 or Gradius 3) could be hacked to use the SA-1 chip. While the SNES is more efficient than the Genesis, it's still slower in the long run, but that's where the SA-1 could be potentially useful, which will nearly triple the SNES' power. Thunder Spirits is a gorgeous game for the SNES, but they didn't program it as well as it could have been.
Also, BioMetal is one interesting SNES shmup. In addition to using 2 Unlimited's music, it's also one of the few SNES shooters that has TONS of bullets and ships onscreen and suffer little to no slowdown. Was this an SA-1 game? Cause if not, then they must've had some talented programmers for that.
Originally posted by: Luigi_Master
Originally posted by: Enig
Originally posted by: Thunderblaze16
Many of you are forgetting that this is fucking Gunstar Heroes. The fact that it might be able to expand to another console is just plane badass.
Here's hoping someone will eventually fix the port of Thunder Force III and then port TFIV.
Funny you mention that. I was wondering myself if a given game (such as TF3 or Gradius 3) could be hacked to use the SA-1 chip. While the SNES is more efficient than the Genesis, it's still slower in the long run, but that's where the SA-1 could be potentially useful, which will nearly triple the SNES' power. Thunder Spirits is a gorgeous game for the SNES, but they didn't program it as well as it could have been.
Also, BioMetal is one interesting SNES shmup. In addition to using 2 Unlimited's music, it's also one of the few SNES shooters that has TONS of bullets and ships onscreen and suffer little to no slowdown. Was this an SA-1 game? Cause if not, then they must've had some talented programmers for that.
BioMetal does not use an SA-1 chip.
The funny part is that I know how BioMetal pulled off a ton of sprites without slowdown. What I don't know is how everyone else fucked it up.
Originally posted by: Aaendi
BioMetal does not use an SA-1 chip.
The funny part is that I know how BioMetal pulled off a ton of sprites without slowdown. What I don't know is how everyone else fucked it up.
Is that so? Then damn, color me impressed. Other notable SNES shooters that have a fair bit of action with notable slowdown would be all three Parodius titles. Hell, in the second one (Gokujou Parodius), one of the bunny girls will LITERALLY slow down the entire game when she's fully equipped and starts firing. As for why, I guess it's because they decided that it wouldn't be worth the effort. This is the same reason why the SNES has a comically large selection of RPGs.
Originally posted by: Luigi_Master
Originally posted by: Aaendi
BioMetal does not use an SA-1 chip.
The funny part is that I know how BioMetal pulled off a ton of sprites without slowdown. What I don't know is how everyone else fucked it up.
Is that so? Then damn, color me impressed. Other notable SNES shooters that have a fair bit of action with notable slowdown would be all three Parodius titles. Hell, in the second one (Gokujou Parodius), one of the bunny girls will LITERALLY slow down the entire game when she's fully equipped and starts firing. As for why, I guess it's because they decided that it wouldn't be worth the effort. This is the same reason why the SNES has a comically large selection of RPGs.
I wonder why Konami thought that 16-bit arithmetic wasn't worth the effort, but 32-bit arithmetic was, despite the fact that 32-bit arithmetic takes longer to write. If you have a CPU with a single 16-bit accumulator, what's the point of bogging yourself down, juggling 2 words with 1 accumulator?
Originally posted by: Aaendi
I wonder why Konami thought that 16-bit arithmetic wasn't worth the effort, but 32-bit arithmetic was, despite the fact that 32-bit arithmetic takes longer to write. If you have a CPU with a single 16-bit accumulator, what's the point of bogging yourself down, juggling 2 words with 1 accumulator?
I dunno, I wish I was a programmer. It's probably for the same reason that Contra Force slows down all the time. Unless the "AI Routines" hogged up that much resources, previous Contra games were capable of far more action onscreen with very brief slowdown, should it occur. They probably programmed the game first, and then decided to skimp out on the optimization, since they figured "who cares? It's not like they can do anything about it".
Originally posted by: Aaendi
It actually takes more effort to program a game the way Capcom and Konami did, than to program a game the efficient way the creators of BioMetal did, not the other way around like most people would expect.
You're saying that it takes more effort to get a game to run sub-par than it is to do it right?
I'm amazed and intrigued. Could you share a bit more of your knowledge on these things?
Originally posted by: SegF4ult
Originally posted by: Aaendi
It actually takes more effort to program a game the way Capcom and Konami did, than to program a game the efficient way the creators of BioMetal did, not the other way around like most people would expect.
You're saying that it takes more effort to get a game to run sub-par than it is to do it right?
I'm amazed and intrigued. Could you share a bit more of your knowledge on these things?
I think most people didn't use the program bank register and the data bank register in the 65c816 CPU, which would slow things down.
And as Aaendi already said, Konami used 32-bit arithmetic with 16 bit registers, when 16 bit would have been just fine in most, if not all cases.
Also, if you do things in a slow way, it will be harder to get a lot of moving stuff on screen, in some cases impossible.
lda !x_position
sec
sbc !x_position+$0000,x
cmp !width+$0000,x
bcc check_y_collision
clc
adc !width
bcc no_object_collision
check_y_collision:
lda !y_position
sec
sbc !y_position+$0000,x
cmp !height+$0000,x
bcc object_collision_detected
clc
adc !height
bcc no_object_collision
object_collision_detected:
lda #$0001
rts
no_object_collision:
lda #$0000
rts
Here is the collision detection routine I use. Sweet, simple and to the point. Direct Page points to one sprite slot, Index X points to the other. First it checks if the objects overlap on the x-axis, then it checks if they overlap on the y-axis. If they overlap eachother on both axis, then collsion has occured.
If you look at the collision detection routine found in your average SNES game, it is much longer, and more complicated.
-no more black bars (full 256x224 screen)
-multidirectional shooting
-improved AI
"Oh, Gunstar Heroes. There's a ton of stuff in that game (or any MD game with decent -let alone heavy- optimization around the hardware's strengths) that couldn't be done as well on the SNES . . . or at all in some cases. (it definitely won't be able to pull off sprites in the same way without more flicker/tearing, and resolution will be lower) And on vanilla SNES hardware, there's even more than you'd probably have to compromise, and even more if you limited ROM size, and even more still if you limited ROM speed. (3.58 vs 2.68 MHz makes a real difference)"
God, do these people EVER look at a fricking programming manual? They keep complaining about a CPU they know absolutely nothing about.