Home Page Forums MAME MAME The SNES WIP topic

#Act Raiser (U) - crashes now *randomly* and can't get an inp to reproduce it (i.e. tried 5 times, 3 with inp and 2 without, crashes ONLY when I didn't recorded it, shrug), sound doesn't work anyway due of the timing crap.
#Bishoujo Wrestler Retsuden (J)
MESS

vs. BSNES

#Final Fight 2
http://mamedev.emulab.it/kale/fast/files/final_fight_2.zip
Pretty obvious, timing issue
#Fushigi no Dungeon 2 - Furai no Shiren
http://mamedev.emulab.it/kale/fast/files/shiren.zip
(delete nvram)
The "ranking screen" is that "wood board" that I check as the first thing I do in the inp (yeah, it isn't supposed to fart ;D) ... then I play "randomly" for one floor
and commit suicide, the ranking screen then is clearly garbage (the same play nets something like ... hmm, 50 points in a working game?)

#Ikari No Yousai
http://mamedev.emulab.it/kale/fast/files/ikari.zip
Maybe you can fix the sprites there, the garbage is caused by timing issues ... this *doesn't* happen on the US version Operation Logic Bomb, mainly because the latter has many bugfixes than the original Japanese release.
#Super Mario World
(delete nvram)
http://mamedev.emulab.it/kale/fast/files/super_mario_world.zip

Elfaria 2 and the other ones you mentioned (even Japanese Super Mario Kart), all reached around 45 seconds ingame with no issues. given that on my eeepc this means around 5 minutes with my finger on the FFW key, I think I tested enough to remove a generic "do not work" report.
If more specific issues are reported, I can re-check them. Don't underestimate the time I spent on testing the games you listed: I never stopped to the title screen.

about me sucking at games, it's pretty much true when we talk about 8-16bit games, except for puzzle, platform and sport games (and I'm good at these only with a joypad, which I miss atm). that's why I appreciate if other people can help me with tests...

Finally, I cannot really imagine what is wrong with those broken sprites: tile and sprite code is pretty clean and it seems to follow bsnes one quite close (except for a bunch of possible missing masks, which I plan to implement soon)... I guess I'll have to debug a bit more the games, but I would point my finger towards the SNES reading/writing to OAM/VRAM at the wrong time...

I swear and repeat, they doesn't work here, probably it's some (init) corruption bug that happens on machine-specific stuff?

About you sucking at games ... I was just joking. ;P

The OBJ L OVER test works if you don't fast forward. It's because the RTO flag calculation is skipped if you fast forward.

Hahahah. Same reason I ended up disabling frame skipping entirely. The overhead of computing RTO ended up erasing more than half of the benefit of even having fast forward.

Going to try and get some TV pics of ASP, and then I'll look over your known bugs list to see if I remember any.

Here comes the game of madness, bearing gifts of death and torture!





http://byuusan.kuro-hitsuji.net/airstrikepatrol/MOV00737.MPG

The best part of all: that shadow is a key component of the game. It tells you where your bombs are going to land. By not showing up in emulators, it makes the game substantially more difficult.

try with a clean build. I tried to recompile everything and Super Mario Kart (Japan) is still perfectly playable...

can anyone else reproduce problems in SMK (J)?


I can still read smilies, so I knew that you were joking. but it's true that I suck on many games. with PSX-era games I got better in more game genres, but I still suck in some

I presume that's done INSIDE the VIDEO_UPDATE then, even though I've said to death to not do it here --"

I'd like to quote video/dc.c, because it's basically the same thing for this case:



fwiw ASP - Air Strike Patrol is the US name of Desert Fighter (J) ... one of the most famous games ... of this topic at least ;D They have done everything on that game ... interlacing, mixed modes 1-7, this new issue ... shrug ...


Tried many times ... probably you have something like OPTIMIZE=0 in makefile or dunno, it gives black screen specifically on my end for whatever reason ...
It remembers me a similar bug on Prikura Daisakusen for the ST-V back in the day ... I was getting correct graphics but Haze was getting just garbage ... turned out that I wasn't returning proper values on a DMA status bit ...


Practice makes perfect, that's the secret of VGs ... I suck at puzzle games and 1vs1 2d beat'em ups, but mainly because I don't play these at all.

do you refer to setting the flag or to clearing it or both? iirc, the clearing part is already outside video update (it's inside a timer that get set either by the scanline or the hblank timer); the setting part is done in snes_update_objects_rto which gets called before scanline drawing and that can be moved outside video_update if necessary. if the latter, can you suggest a smarter place to move snes_update_objects_rto at?



no I don't. base makefile compiled on Win32 with

make TARGET=mess MESSUI=0

however, I also tried a SYMBOLS=1 build (which sets OPTIMIZE=0) and it works as well.

what's the image crc? I'm testing the nointro dump:

crc C8002453
md5 F7AFA112D7EC1D532636703E4B02700A
sha1 CBB853BF911255C1D8EB27CD34FC7855A0DDA218

The only valid place is inside the read/write handler itself.



crc 67D8A078 ... shrug, bad dump, just realized that it doesn't work in bsnes either ^^U