FAME SH4 is here!

[wraggster]

Any newspostable News on the progress of Fame SH4??

[fox68k]

I am currently fixing errors. Chui is helping me finding them. He is debugging FAME running it in the NeoCD/SDL DC emu.

Hopefully i will release a new version soon.

[chui]

We try build a NeoCD/SDL 0.31 port with fame core and my new SDL variation with dma-transfer for speed up.
:P :

[quzar]

Is it any faster with FAME than c68k ? i'm going to be fixing the sfx issues as soon as evilo gets the sources to me, so I might need to get some extra speed in it =P.

[chui]

i run some benchs under neo4all x86 with fame and it's very fast, but blitter spend a lot of cpu.

i think, we must optimize neogeo blitter (video.c).

[evilo]

[quote author=chui link=board=dcemu;num=1097277534;start=30#44 date=11/09/04 at 08:54:55]i run some benchs under neo4all x86 with fame and it's very fast, but blitter spend a lot of cpu.

i think, we must optimize neogeo blitter (video.c).

[/quote]

gfx code is clearly the bottleneck in neocd, with good optimisation we could gain a lot in this.. problem is that the code is already quite compact and difficult to optimize unless you know it very very welll.. on ps2 the only optimisations I've managed to use are for statement tricks (reversed, etc.. ) and this kind of stuff...
fyi, I tried several weeks ago to update the code with the last one in mame (that most of all use zoom table in rom instead of dynamically rebuild it ) but general result is slower...

[quzar]

neo4all x86? ... wait, is that what you are calling neocd with fame in it?

[chui]

yes, neo4all is neocd with fame and my variation of SDL.

now compile and runs ok under Linux (x86) and Windows without sound.

[BlackAura]

Does anyone know how complex (or otherwise) the NeoGeo graphics hardware is?

Genesis Plus / DC was suffering from pretty much the same problem - the video rendering code was taking up a huge chunk of CPU time. So (as an experiment) I re-wrote the rendering code using the Dreamcast's 3D hardware as a fast blitter, which gave a truly insane speedup - around as much as replacing Musashi with C68K did.

Some of the techniques I used are really only applicable to the Dreamcast or the Genesis, but they might be applicable to the NeoGeo as well, depending on what kind of effects the video hardware is capable of, and how accurate the emulation needs to be.

The idea is that you convert all the tile data into textures, and upload those to VRAM. Then, once per frame, you draw the background and sprite layers using those textures. On the Dreamcast, the graphics hardware will deal with graphics / sprite priorities automatically, but most systems (including the PS2) won't.

Looking at the rendering code, that's more or less what the rendering code works anyway. Once a frame, it draws the tiles to the screen each in one piece, and isn't scanline-accurate. That means that a hardware accelerated renderer might work perfectly (no graphics glitches).

[quzar]

[quote author=BlackAura link=board=dcemu;num=1097277534;start=45#48 date=11/09/04 at 18:35:59]Does anyone know how complex (or otherwise) the NeoGeo graphics hardware is?

Genesis Plus / DC was suffering from pretty much the same problem - the video rendering code was taking up a huge chunk of CPU time. So (as an experiment) I re-wrote the rendering code using the Dreamcast's 3D hardware as a fast blitter, which gave a truly insane speedup - around as much as replacing Musashi with C68K did.

Some of the techniques I used are really only applicable to the Dreamcast or the Genesis, but they might be applicable to the NeoGeo as well, depending on what kind of effects the video hardware is capable of, and how accurate the emulation needs to be.

The idea is that you convert all the tile data into textures, and upload those to VRAM. Then, once per frame, you draw the background and sprite layers using those textures. On the Dreamcast, the graphics hardware will deal with graphics / sprite priorities automatically, but most systems (including the PS2) won't.

Looking at the rendering code, that's more or less what the rendering code works anyway. Once a frame, it draws the tiles to the screen each in one piece, and isn't scanline-accurate. That means that a hardware accelerated renderer might work perfectly (no graphics glitches).[/quote]

Right now im working at fixing the sound using evilo's sources for the PS2 version, and it doesnt seem like speed will be an issue, since what IM did to slow down the emulator for 9.3 was turn on the z80. If it still needs a lot of speed after the sound get to working, I'd love to try and see if I might be able to, using the example of your genesis plus previews implement hardware rendering for neocd. from all that i have poked at the renderer it seems VERY simple compared to other systems that i have looked at (tg16 ugh, genesis, cps)