Register | Login
Views: 19364387
Main | Memberlist | Active users | ACS | Commons | Calendar | Online users
Ranks | FAQ | Color Chart | Photo album | IRC Chat
11-02-05 12:59 PM
1 user currently in Super Mario World hacking: labmaster | 3 guests
Acmlm's Board - I2 Archive - Super Mario World hacking - Status Bar flickering
  
User name:
Password:
Reply:
 

UserPost
d4s
Posts: 259/325
Originally posted by HyperHacker
Well, poo. Don't suppose a fastROM manual copy could be faster than slowROM DMA then?


not really, no.
thats what dma is for, transfer data even faster than tight copyloops.

for my own projects, i usually substitute the games palette or oam buffer upload for my own vram uploads to be sure to stay inside vblank (cause most games nmi routines are packed with vram transfers to the max already), but that only works if theres slim to none action on-screen.

it works fine for rpg textboxes for example, because these are usually halted while textboxes are displayed.
there, you hardly notice if a palette rotates/sprites are updated a frame later than normal, but if you upload stuff each frame in a fast-paced game like mario world, it will be instantly noticeable.

and these (oam and cg data) are just $220/$200 bytes each, not anywhere near the $c00 bytes iceman is trying to upload.
HyperLamer
Posts: 5887/8210
Well, poo. Don't suppose a fastROM manual copy could be faster than slowROM DMA then?
d4s
Posts: 258/325
Originally posted by HyperHacker
How efficient is the animation code? Maybe it could be sped up a bit, and/or converted to FastROM. For that matter, someone made a FastROM patch a while ago that fixes a lot of these problems, though it doesn't change the hacks LM adds.


i made that fastrom patch, its already included in icemans hack.

fusoyas routines dont need to be fastrom-patched, they have little to none impact on the games overall performance.
its not the code that breaks smw here, anyway.
its the length of the dma transfers.

fusoya didnt limit the amount of data that can be uploaded each frame.

some of the levels in this hack transfer more than 3kb per frame, simply too much for smw.

oh, and by the way dude, dma transfers are always slowrom, just in case you want to suggest changing these to fastrom aswell.
HyperLamer
Posts: 5873/8210
How efficient is the animation code? Maybe it could be sped up a bit, and/or converted to FastROM. For that matter, someone made a FastROM patch a while ago that fixes a lot of these problems, though it doesn't change the hacks LM adds.
ExKay
Posts: 821/1114
Thought so.

BTW: It also stands in LMs help file, that the staus bar begins to flicker.
BMF98567
Posts: 991/1261
The SNES only has so much VBlank time (as I've found out the hard way), and animating tiles takes up a lot of it. You're going to have to get rid of some animations, nothing else you can do about it.
Sukasa
Posts: 1291/1981
could you try to rearrange your GFX and then use different animations, like where if you have 3 tiles side-by-side that are animated, you could use one GFX animation slot, and set it to 3 side-by-side 8x8 tiles instead of 3 individual entries. Does that help any?
ExKay
Posts: 819/1114
When I start my hack in SNES9x and enter a level with a lot of animations, the above part of the status bar begins to flicker. Now I want to disable the flickering, but without having to delete my animations. Is there a way to disable the flickering.

BTW: It works fine with ZSNES and it crashed on the real SNES.

Edit: Here is a screen of how it looks like.

Acmlm's Board - I2 Archive - Super Mario World hacking - Status Bar flickering


ABII


AcmlmBoard vl.ol (11-01-05)
© 2000-2005 Acmlm, Emuz, et al



Page rendered in 0.002 seconds.