SNES vs Genesis
Moderator: Moderators
- TmEE
- Posts: 789
- Joined: Wed Feb 13, 2008 9:10 am
- Location: Estonia, Rapla city (50 and 60Hz compatible :P)
- Contact:
Re: SNES vs Genesis
You need to make the parts of the explosions have random trajectories and speeds. It is lot easier than it seems.
-
tomaitheous
- Posts: 592
- Joined: Thu Aug 28, 2008 1:17 am
- Contact:
Re: SNES vs Genesis
Locks up randomly in zsnes. Controls don't work in higan. I think your demo is gimp'd.psycopathicteen wrote:I was able to get the SNES to software rotate a sprite, while running an unfinished version of Gunstar Heroes on stock hardware. The rotating sprite is placed at the end of the "level" using the dynamic-loading-corridor trick shown as described here. http://tvtropes.org/pmwiki/pmwiki.php/M ... micLoading
Re: SNES vs Genesis
I'm just seeing a white background with some grass at the bottom and a guy running in place, controls do nothing... what's supposed to happen?
Re: SNES vs Genesis
Controls works fine for me. Pehaps you're using an old/outdated/inaccurate emulator ? Or pehaps psycopathicteen could rewrite his joypad reading routine so that it is more tolerant ?
Re: SNES vs Genesis
Controls don't work in the latest version of higan, which AFAIK is the super duper most ultra accurate emulator of all time. Anyway, I just tried ZNES too, and, as reported, it crashes randomly, but I can see what it's supposed to do now.
Re: SNES vs Genesis
Since BSNES changed to higan I never bothered to update ever again. Honnestly Higan is completely unusable and is a piece of... okay I'll say nothing since byuu is arround, but you see the point.
Looks like I'm not missing much using the last version of BSNES and SNES9x.
Looks like I'm not missing much using the last version of BSNES and SNES9x.
Re: SNES vs Genesis
I was pretty disappointed with the direction it was heading too, but the "import" feature in higan makes it quite usable. I really miss the NTSC filter though.Bregalad wrote:Since BSNES changed to higan I never bothered to update ever again. Honnestly Higan is completely unusable and is a piece of... okay I'll say nothing since byuu is arround, but you see the point.
From a gamer's point of view, probably not... but you know people say that about outdated NES emulators too, right?Looks like I'm not missing much using the last version of BSNES and SNES9x.
- TmEE
- Posts: 789
- Joined: Wed Feb 13, 2008 9:10 am
- Location: Estonia, Rapla city (50 and 60Hz compatible :P)
- Contact:
Re: SNES vs Genesis
I could run it in some version of BSNES tha I had around. Input did not work in Higan on which I tried first.
-
psycopathicteen
- Posts: 3001
- Joined: Wed May 19, 2010 6:12 pm
Re: SNES vs Genesis
The people at nintendoage.com told me that it works on real hardware, but that was before I added the rotating ball at the end.
Re: SNES vs Genesis
I can try it on my SD2SNES the next time I unbox my SNES (I have no idea when that's gonna be!), if no one else has done it by then.
Still, in my experience with the NES, even if a program appears to work well on hardware, the fact that it fails on emulators could mean that there's something wrong with it, maybe it's relying on some edge case that could still result in bugs on hardware under certain conditions. IMO, you should try to find why it's not working on some emulators, to make sure the error is theirs and not yours. I mean, input is the most basic thing a game does, unless you're doing it in a very unconventional way there's no reason for it not to work, you must have goofed somewhere.
Still, in my experience with the NES, even if a program appears to work well on hardware, the fact that it fails on emulators could mean that there's something wrong with it, maybe it's relying on some edge case that could still result in bugs on hardware under certain conditions. IMO, you should try to find why it's not working on some emulators, to make sure the error is theirs and not yours. I mean, input is the most basic thing a game does, unless you're doing it in a very unconventional way there's no reason for it not to work, you must have goofed somewhere.
-
psycopathicteen
- Posts: 3001
- Joined: Wed May 19, 2010 6:12 pm
Re: SNES vs Genesis
http://wiki.superfamicom.org/snes/show/Timing
This is the problem. Joypad reading has to be enabled before dot 32.5 on the first scanline.When enabled, the SNES will read 16 bits from each of the 4 controller port data lines into registers $4218-f. This begins between dots 32.5 and 95.5 of the first V-Blank scanline, and ends 4224 master cycles later. Register $4212 bit 0 is set during this time. Specifically, it begins at dot 74.5 on the first frame, and thereafter some multiple of 256 cycles after the start of the previous read that falls within the observed range.
- Attachments
-
- gunstar heroes.zip
- (25.17 KiB) Downloaded 131 times
Re: SNES vs Genesis
No worries, I'd rather not have nonconstructive critics on my forum anyway.Looks like I'm not missing much using the last version of BSNES and SNES9x.
Me too. I tried, but was unable to port blargg's filter to support the color depth of my monitor, same deal for the SaI algorithms.I was pretty disappointed with the direction it was heading too, but the "import" feature in higan makes it quite usable. I really miss the NTSC filter though.
Next version is going to support multi-pass shaders, and I'm pretty sure there are GLSL implementations of it (but I don't know how good they are), so it should return soon in some form.
-
psycopathicteen
- Posts: 3001
- Joined: Wed May 19, 2010 6:12 pm
Re: SNES vs Genesis
I also finally accomplished my goal of making an efficient dynamic animation engine, and I even know how to take it one step forward.
The trick is to compress all metasprites into a block that is 2 tiles tall and power-of-2 tiles wide, using a combination of 16x16 sprites and 8x8 sprites, and have the system strategically place the metasprites to fit within the rectangular grid of VRAM, to avoid fragmenting. I still use the double-buffered 30fps load scheme, but now I could fit more metasprites into 8kB of vram (the other 8kB is being used for non-dynamic sprites), and I have more vblank time left over.
Taking this one step forward, instead of using the 30fps double-buffered scheme, I can make newly spawned objects search for an open vram slot, update the vram slot when there is a new frame of animation for the object, and automatically de-fragmentize vram when an object is killed. Obviously, there should only be a DMA update requested if there is either a new frame of animation or a vram slot relocation (due to auto de-fragmenting), but only if there is enough "DMA bandwidth" left.
The trick is to compress all metasprites into a block that is 2 tiles tall and power-of-2 tiles wide, using a combination of 16x16 sprites and 8x8 sprites, and have the system strategically place the metasprites to fit within the rectangular grid of VRAM, to avoid fragmenting. I still use the double-buffered 30fps load scheme, but now I could fit more metasprites into 8kB of vram (the other 8kB is being used for non-dynamic sprites), and I have more vblank time left over.
Taking this one step forward, instead of using the 30fps double-buffered scheme, I can make newly spawned objects search for an open vram slot, update the vram slot when there is a new frame of animation for the object, and automatically de-fragmentize vram when an object is killed. Obviously, there should only be a DMA update requested if there is either a new frame of animation or a vram slot relocation (due to auto de-fragmenting), but only if there is enough "DMA bandwidth" left.