Hello everyone.
I'm "fighting" against PicodriveDS code in order to improve it performance.
The main reason is to get a decent Genesis emulator that could be played in DS bottom screen. Now I'm a bit noob coding in ASM, so I'm trying to port some easy functions to a .S file.
After some changes, I have discovered that FPS are not significantly increased, so I'm starting to think that the problem could be on one or more of those parts:
Update 7:
- Memory ARM functions now are in a separate .S file called: Memory_asm.s
- PicoRead8, PicoRead16 and PicoRead32 functions coded in ASM. The code could be improved, so everybody is invited to check it
- In a DSi console, the extra power help some games to run smooootly (55-60fps)
- UpdatePalette function now is called each 15 vblanks. Fade effects are not the bests, but we save some cycles.
To try it by yourself, download NDS file from master branch, not the release.
I'm "fighting" against PicodriveDS code in order to improve it performance.
The main reason is to get a decent Genesis emulator that could be played in DS bottom screen. Now I'm a bit noob coding in ASM, so I'm trying to port some easy functions to a .S file.
After some changes, I have discovered that FPS are not significantly increased, so I'm starting to think that the problem could be on one or more of those parts:
- Cyclone 68000 emulator originally used was v0.084, and there's a bit updated version: v0.088. Maybe an update could improve performance? The problem is that I can't get a compiled version that works with PicodriveDS
- Port more functions to ASM, specially all related to pixel process
- Maybe process frame in another way? Now, it seems that the program process each horizontal line, changing byte color info format (Genesis format to DS format) and printing the result at the end.
- The program was written using Devkitarm v20. Anyone knows if updating the code to a newer version would improve the performance?
Update 1:
Coding in ASM is a nightmare...
Anyway, there are visible improvements:
- Frameskip now is set from 4 to 3 and gameplay has not been affected (I think...)
- All new ASM functions are stored in Functions_asm.s
Update 2:
Coding in ASM is still a nightmare
- More functions coded and now the current frameskip is smoother (maybe in the future we could use this free cpu time to activate sound?)
- Function DmaFill is broken... anybody can check it, I have spent hours and the problem has not been located, so it has been renamed to DmaFill_fail and uncomment the old one in VideoPort.c
Update 3:
- DrawAllSprites and DrawSprite has been re-coded in ASM. DrawAllSprites is called in every frame and DrawSprite is called individually for each sprite. However, there's not an important change in FPS...
- Version will be 0.1.8 from now
Update 4:
- All code has been replaced with an adapted TwilightMenu version of Picodrive. Now it works independently of TWL.
- Some ASM have been undo. Sadly, my ASM code style sometimes is slower than C code
- Anybody knows why line 1053 of main.cpp now returns data abort when rom is changed? I have commented the line, but I'm not sure if it's a good idea...
Update 5:
- UpdatePalette functions has been called just before draw every frame, but palette changes less frequently. Now it's invoked only when there are more than 9 bytes changed in CRAM. With this change, FPS have been increased slightly, but not at any cost: the update time of the color palette shows inconsistencies for an instant when a scene changes.
Update 6:
- PicoRead8 function coded in ASM
- OtherRead16 function coded in ASM
- Damn... FPS are stucked in 45-50 (max frameskip=2) in a NDSLite for Sonic1
- Damn again... Flashback game doesn't start after the developer logo
Coding in ASM is a nightmare...
Anyway, there are visible improvements:
- Frameskip now is set from 4 to 3 and gameplay has not been affected (I think...)
- All new ASM functions are stored in Functions_asm.s
Update 2:
Coding in ASM is still a nightmare
- More functions coded and now the current frameskip is smoother (maybe in the future we could use this free cpu time to activate sound?)
- Function DmaFill is broken... anybody can check it, I have spent hours and the problem has not been located, so it has been renamed to DmaFill_fail and uncomment the old one in VideoPort.c
Update 3:
- DrawAllSprites and DrawSprite has been re-coded in ASM. DrawAllSprites is called in every frame and DrawSprite is called individually for each sprite. However, there's not an important change in FPS...
- Version will be 0.1.8 from now
Update 4:
- All code has been replaced with an adapted TwilightMenu version of Picodrive. Now it works independently of TWL.
- Some ASM have been undo. Sadly, my ASM code style sometimes is slower than C code
- Anybody knows why line 1053 of main.cpp now returns data abort when rom is changed? I have commented the line, but I'm not sure if it's a good idea...
Update 5:
- UpdatePalette functions has been called just before draw every frame, but palette changes less frequently. Now it's invoked only when there are more than 9 bytes changed in CRAM. With this change, FPS have been increased slightly, but not at any cost: the update time of the color palette shows inconsistencies for an instant when a scene changes.
Update 6:
- PicoRead8 function coded in ASM
- OtherRead16 function coded in ASM
- Damn... FPS are stucked in 45-50 (max frameskip=2) in a NDSLite for Sonic1
- Damn again... Flashback game doesn't start after the developer logo
Update 7:
- Memory ARM functions now are in a separate .S file called: Memory_asm.s
- PicoRead8, PicoRead16 and PicoRead32 functions coded in ASM. The code could be improved, so everybody is invited to check it
- In a DSi console, the extra power help some games to run smooootly (55-60fps)
- UpdatePalette function now is called each 15 vblanks. Fade effects are not the bests, but we save some cycles.
To try it by yourself, download NDS file from master branch, not the release.
Last edited by xonn,