FAME SH4 is here!

[evilo]

[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?

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.

[/quote]

yes, you're right, this is the best way to do it... then a good point on the ps2, is that while you are uploading a texture through dma, you can continue with the rest during the transfert ! Then I don't know on which fact you are telling that the ps2 cannot handle this... but even If I'm not the one knowing deeply the ps2, if you ask me how to manage sprite priority using the hardware, I would quickly answer you using the Z buffer !

quzar :
any result yet ?? note that for FM emulation (-> music in bust a move), the ym2610 can be a speed issue.

[quzar]

did you get any sound out of the "full bak mame" part? of just of the first part?

I spent most of my time yesterday just getting it to compile, as ian had left the sources quite broken. Then i fixed an issues with vmu loading that i noticed once i started testing, that if you dont have a vmu in, it crashes. This probably accounted for a lot of users who would say that they couldnt get it to load any games.

I also made space for a mechanism to vary the cycles per vblank based on the outputfreq of the console.

I think that one of the main probelms you might be having is that you are only taking the sound directly from the ym2610 as opposed to passing it to the fm emulation. (if i read your sound.c correctly).

ill try to remove the streaming from the DC version using the SDL and replace it with OSD functions similar to what you use (grab audio buffer, stuff it into sound chip). and see what happens.

[evilo]

I actually get sound from 3 different tests, original flavour, part mame and full mame, with same result except speed that decrease when I use last mame source.

fm.c is actually the ym2610, don't be confused with 2610intf.c as it's only the cpu interface call by sound.c

at this point I have both fm (so music) & sfx working except in a few games that hangs up, but from what I found it's the IOP ("co-processor&quot of the ps2 that actually hangs up with probably a memory alignement issue.

[BlackAura]

[quote author=evilo link=board=dcemu;num=1097277534;start=45#50 date=11/10/04 at 04:27:01]

yes, you're right, this is the best way to do it... then a good point on the ps2, is that while you are uploading a texture through dma, you can continue with the rest during the transfert ! Then I don't know on which fact you are telling that the ps2 cannot handle this... but even If I'm not the one knowing deeply the ps2, if you ask me how to manage sprite priority using the hardware, I would quickly answer you using the Z buffer ! [/quote]

The DC's graphics hardware works a little differently. It doesn't really have a Z buffer, and the graphics hardware works by taking all the data for an entire scene, and then rendering it in one pass, automatically depth sorting everything. The main advantage that gives you is that you don't have to bother sorting transparent polygons - the hardware will automatically do that for you, so you can send the polygons in pretty much any order you like, and still get the same result.

The PS2 has a more conventional graphics chip, as far as I'm aware, which has a Z buffer, and renders things immediately like PC graphics cards do. This doesn't make a hardware-accelerated renderer impossible, but it might make it a little trickier to implement unless you can find some way to sort the data with little speed penalty.

Taking GP/DC as an example, the Genesis hardware deals with three layers (background 1, background 2, sprite), and each tile can have either low or high priority. On the Dreamcast, you don't really even need to worry about that - you just send the data to the video hardware any way you feel like (I did BG1, BG2, then sprites), and simply change the Z value appropriately. The hardware sorts it all out for you.

That would work on conventional hardware (like the PS2) too, were it not for the fact that the Z buffer doesn't take transparent geometry into account. You might draw a high-priority tile from BG1 first, which should appear above a low-priority tile from BG2. However, if you then try to draw a low-priority tile from BG2 beneath it, nothing will be drawn. The depth buffer values will have been set for the entire tile, not just the opaque parts, so you won't be able to see graphics behind other graphics, depending on the order you draw them.

This doesn't much matter for most 3D games, since they tend to be mostly opaque geometry, with transparency and blending usually used for special effects or 2D displays. To get them to appear properly, they're typically sorted by depth, and then sent in the correct order (usually with depth buffer writes turned off), from furthest to nearest.

The only easy way out of this is to find some way to efficiently sort the tiles into a depth order. For a Genesis, that means you'd need six rendering passes (Low priority BG1, BG2, Sprites, High priority BG1, BG2, Sprites) instead of 3, which is a lot more work to do. For a NeoGeo, the text layer is easy (draw it last). The sprite layer is more difficult, since each sprite has it's own priority value, and they could be sent in any order the game feels like. You'd probably have to sort the sprites by depth first, then draw them in that order.

That said, the PS2 might have some way to deal with this kind of thing. I know that the GS is a very weird graphics chip, so it might have some mode that you can use to eliminate the need for depth sorting.

[evilo]

no, you are wrong, as for the dc, you just need to send the data for each component (bg, layer 1, 2 etc..) in any way/order you want, and just need to specify the z value and alpha value, then the GS will do all the job for you... This is actually how I'm designing the ingame menu in neocd, as each part (shaded background, menu box, menu box gb, menu items, etc... ) are all on a separate plan. But I don't know why I didn't think to adapt it to the blitter...

anyway you should come to ps2dev, and have a look to document, or code samples, it's for sure a weird stuff, but it's surely more complex / advanced that you think !

[BlackAura]

[quote author=evilo link=board=dcemu;num=1097277534;start=45#54 date=11/11/04 at 05:47:51]
no, you are wrong, as for the dc, you just need to send the data for each component (bg, layer 1, 2 etc..) in any way/order you want, and just need to specify the z value and alpha value, then the GS will do all the job for you...[/quote]

I thought that was more the job of the EE / vector units.

Just had a look at some more info on the GS. Damn, that thing must be a pain to write software for. It seems to have been designed by some insane Japanese guy who'd been locked in a room for several years, and fed all kinds of strange hallucinogens.

But I don't know why I didn't think to adapt it to the blitter...

It's one of those things that seems obvious, but you just wouldn't think of it. I actually didn't think of it either - Dan Potter did, except he thought it might work well for a SNES emulator.

Everybody disagreed, because SNES games really require a very high level of accuracy, and many of the effects the SNES PPU uses just can't be simulated (quickly) using 3D hardware. The MD's VDP is a lot simpler, and most games don't rely on it doing funky things as much, so you can get away with it.

Since the existing renderer in NCD is really simplistic (little more than a simple tile blitter), a hardware blitter approach should work brilliantly.

However, I don't think it'll work on the Dreamcast. The NeoGeo CD has a palette of 4096 colours (out of a total of 64k), and it can display all of those at once. The Dreamcast's palette hardware has entries for 1024 colours, and since you need to describe the entire scene (including palettes) before it starts rendering, there's no way to display all the colours. Actually, there might be a way, but I don't think it'd be much fun.

[fox68k]

Well, after a hard debugging work, here is a stable version of FAME.
Lots of bugs have been fixed and now a good bunch of Neo Geo CD games work on Neo4All and Genesis Plus perfectly.

I would love to hear from coders trying to use FAME in their projects.

Special thanks goes here to Chui, for his excellent, unvaluable help and contribution to FAME. And to BlackAura and Mekanaizer for his efforts trying to get FAME up in Genesis Plus.

Download the package here.

P.D: Keep me updated with any bug or problem with FAME. I will try to help you as soon as possible.

[rattboi]

[quote author=fox68k link=board=dcemu;num=1097277534;start=45#56 date=12/16/04 at 18:29:15]

Special thanks goes here to Chui, for his excellent, unvaluable help and contribution to FAME. And to BlackAura and Mekanaizer for his efforts trying to get FAME up in Genesis Plus.

[/quote]

lol, "unvaluable"

[BlackAura]

I have it working in Genesis Plus / DC. At least, I do on my PC test version. When I get around to merging it with the Dreamcast code again, I'll test it out there.

It does seem a little buggy though. A few games don't seem to work properly (they usually crash the entire emulator), or crash periodically, and a few games exhibit some weird bugs. I'll have to set up some decent debugging / tracing capability, so we can tell where FAME does things differently to the other CPU emulators I can use in Genesis Plus (at the moment, Musashi, C68k, and StarScream).

[Stef]

What about FAME's core by the way ? what about the speed ?
I guess it can still help in NeoCD...
My C Z80 core is almost done, need a lot of debug though
I really optimised it for code size, not really for speed.
But on dreamcast optimisation for code size give good result on speed
I'm impatient to see it in action with Genesis Plus