FAME SH4 is here!

[BlackAura]

I actually have a lot of the special effects worked out already. It won't work correctly for every game, but most of them should look OK. As long as they don't rely on sprite masking, accurate shadow/hilight (I can only do an approximation of it), or accurate window emulation (again, only an approximation).

That reminds me... Got a quick explaination of how shadow/hilight mode works? I can actually render the stuff (approximately), but I can't find the appropriate VDP registers to turn it on and off again.

[Stef]

[quote author=BlackAura link=board=dcemu;num=1097277534;start=60#70 date=01/10/05 at 03:41:56]I actually have a lot of the special effects worked out already. It won't work correctly for every game, but most of them should look OK. As long as they don't rely on sprite masking, accurate shadow/hilight (I can only do an approximation of it), or accurate window emulation (again, only an approximation).[/quote]

What type of specials effects are actually working with your hardware accelerated core ?
As you said, some complex effects as sprite masking / complex priorities / hilight / shadow effect can't be done or not accuratly... but i'm thinking about scanline based scrolling or vertical cell scrolling, i guess you can't do them too right ?

That reminds me... Got a quick explaination of how shadow/hilight mode works? I can actually render the stuff (approximately), but I can't find the appropriate VDP registers to turn it on and off again.

Do you have the sega2.doc file (also exist in html version), you'll find all VDP register description.

[BlackAura]

Scanline scrolling works. Kinda. There's two ways to do it, and I've not yet decided which one is best. Basically, I need to benchmark them to find out which is faster.

The first way is to render each tile as 8 tristrips instead of one. That involves transferring 32 vertices and one polygon header (instead of 4+1), so it should be around 7 times slower. However, it would work pretty much perfectly, and it could probably be made a little faster.

The second way is to render each tile as one tristrip, but with 10 vertices instead of 4. This will work fine (and may actually look slightly better) for games that use scanline scrolling for distortion or wobble effects, such as heat haze (Sonic games), or using it to interpolate between tiles (Sonic 2 and 3 special stages). However, because each tile is still one object, large differences in the scroll values between adjacent scanlines will look ugly, because the PVR will interpolate between the scanlines. It's much faster than the previous method though - it should be just under 3 times slower than the standard per-tile renderer. This is the one I'm currently using.

Vertical cell scrolling should work, but I'm not sure how to make it interact with scanline scrolling. For the moment, I'm making the assumption that it doesn't, and I'm completely ignoring it when scanline scrolling is enabled. Obviously that's not correct, but I can't think of a good way to deal with that right now.

Changing the horizontal scroll values in the middle of a frame (Contra) will never work with the current renderer, because it needs scanline accuracy. I can deal with one mid-frame palette change per frame, but no more than that, because the code is somewhat... dumb. I could do better, but I'm not going to bother unless I find a game that actually needs it.

I could go to a per-scanline rendering system, but I think the additional overhead would probably kill any speed gains using the PVR would give us.

I don't have the sega2.doc file. I did at some point, but I was never able to actually open it with anything.

[Stef]

[quote author=BlackAura link=board=dcemu;num=1097277534;start=60#72 date=01/11/05 at 02:21:18]Scanline scrolling works. Kinda. There's two ways to do it, and I've not yet decided which one is best. Basically, I need to benchmark them to find out which is faster.

The first way is to render each tile as 8 tristrips instead of one. That involves transferring 32 vertices and one polygon header (instead of 4+1), so it should be around 7 times slower. However, it would work pretty much perfectly, and it could probably be made a little faster.
[/quote]

I remember i spoke with the author of PGen (genesis emulator for PS2) about this method... but i was always convinced the x8 overhead in vertices transfert will be too heavy to be really interesting.
I never got any news from the author of PGen about his hardware accelerated VDP core. I think he never had the time to do it :-/

The second way is to render each tile as one tristrip, but with 10 vertices instead of 4. This will work fine (and may actually look slightly better) for games that use scanline scrolling for distortion or wobble effects, such as heat haze (Sonic games), or using it to interpolate between tiles (Sonic 2 and 3 special stages). However, because each tile is still one object, large differences in the scroll values between adjacent scanlines will look ugly, because the PVR will interpolate between the scanlines. It's much faster than the previous method though - it should be just under 3 times slower than the standard per-tile renderer. This is the one I'm currently using.

Hehe, smart idea
As you said, interpolation will probably give stranges results on large scrolling between 2 scanlines, but i guess that deserves some tests

Vertical cell scrolling should work, but I'm not sure how to make it interact with scanline scrolling. For the moment, I'm making the assumption that it doesn't, and I'm completely ignoring it when scanline scrolling is enabled. Obviously that's not correct, but I can't think of a good way to deal with that right now.

Unfortunatly, vertical cell scrolling is almost time used with scanline horizontal scrolling to simule some rotation effect (jungle book logo...)... but as in my software render i always draw at least 1 tile scanline i guess there is some way of doing it by using the first method for scanline scroll, but again, it will them become too slow.
All the stuff is to find the best compromise between speed and accuracy

I could go to a per-scanline rendering system, but I think the additional overhead would probably kill any speed gains using the PVR would give us.

I agree, a software core would probably be more efficient here

I don't have the sega2.doc file. I did at some point, but I was never able to actually open it with anything.

The original SEGA2.DOC was corrupted, but i do know a html version exist somewhere... i'll try to find it.

[Mekanaizer]

Hi.

Stef, if you want PM me and i send to you my working sh4_asm Z80 core. You can do what ever you want with it.

Stef and BlackAura, here is the Sega2.doc converted to htm:

http://mekanaizer.planetaclix.pt/sega2f.htm

edit: There are some errors in the doc. Corrections can be fond on some genesisDEV forums and in some sites.

-Mekanaizer-

[quzar]

the z80 sh4 core you have just the core from Ishmair's spectrum emulator modified to be a seperate module right?

either way, do you think i could get some of that my way? ;D

[Stef]

[quote author=Mekanaizer link=board=dcemu;num=1097277534;start=60#74 date=01/11/05 at 11:09:13]Hi.

Stef, if you want PM me and i send to you my working sh4_asm Z80 core. You can do what ever you want with it.[/quote]

I'm not sure, but i believe i already have your ASM core.
Is it complete ? and how it performs ?
The current one i have here isn't complete and isn't very fast : about 20 Mhz Z80 on a 200 Mhz SH-4).

[fox68k]

It would be nice if Mekanaizer provides support to that core. The scene needs a fast and well supported Z80 core for the DC.

[Stef]

[quote author=quzar link=board=dcemu;num=1097277534;start=75#75 date=01/11/05 at 18:31:02]the z80 sh4 core you have just the core from Ishmair's spectrum emulator modified to be a seperate module right?

either way, do you think i could get some of that my way? Â*;D[/quote]

Yeah you're right, it's the core from Ishmair.
Unfortunatly, even if the core is done in SH4 assembly, the overall structure isn't really optimised and need majors changes to become really fast.
I guess actual C cores can perform as fast if not faster.

[Stef]

Well, some news about my C Z80 core (aka CZ80 ).
I'm currently working with the PC version of Genesis Plus for debug. CZ80 is heavily optimised for size more than speed since i did it first for Dreamcast architecture.
The base Z80 core used in Genesis Plus (J.B Z80) takes about 224 KB when compiled with -O1 level.
CZ80 takes only 35 KB... but as expected, it doesn't performed so great on PC and i was a bit disapointed when i compared it to J.B Z80 : CZ80 is only about 1.6 time faster :-/
I know that actuals C Z80 cores are already fast (compared to 68000 C core) and optimisations marges are smaller but anyway i was expecting better results.
I really hope to get at least a factor of 2 on DC...

Mekanaizer>
What about putting your Z80 ASM core sources available for every one ?
I think it can bring a lot to the DC Scene