News about GenesisPlusDC

Will Sams (aka Storminator16) reported about a few games he has tested with a new but still early WIP version of BlackAura's GenesisPlusDC:[br][br]"Note: When I say highly playable, I mean it's fast! [br][br]Sonic - runs well with the current emu's settings; highly playable [br]Alien 3 - seems to run a tad slower with varying speed ups, but playable [br]NHLPA '93 - right off the bat I got a 'pvr_wait_ready: timed out' then proceeded to some errors in the title screen, in-game menu, and game. My VGA monitor may be jacked up, but it seems I'm getting a black ice :/ Probably my monitor, it has been inverting colors lately. Playable, and speed runs well with current emu's settings. Highly playable asside from graphic errors. [br]Ghostbusters - Status bar at the bottom of the screen missing, would be highly playable but the status bar is important Runs fantastic otherwise [br]Chakan - The Forever Man seems to move slow, and the scrolling is jerky at times. Nevermind, this is how bad the game usually is. I have no reason why I tested this. Highly playable....if you like this garbage game. [br]Thunderforce 3 - Status bars missing, but highly playable I guess you have some foreground sprites not working or disabled, BA? [br]Streets of Rage 2 - Status bar missing, seems to run a tad slow. First "alleged" 16 meg rom I tried with this. [br]Valis 3 - Well, there is a color problem. All text in the opening cinema were black (or I just couldn't see it) and the in-game conversations are fudged. Overall all, the tiles on the right side of the screen are fudged. 'Course, status window is non-existent. Not very playable because of the graphical glitches, but speed-wise it's fine if you love this game. [br]Street Fighter 2 Turbo - The other "alleged" 16 meg rom I tried. Memory issue? The emu refuses to run it, and crashes. [br]Sonic 2 - Read what I said about Sonic 1. Works fine."[br][br]You can download the source code here [br][br]For a development status report by BlackAura have a look at the comments.

[Modified 06/21/04 14:36:07 by DCEmu_Newsposter]

Here's what BlackAura wrote about the progress he had the last two days with emulating the VDP:

Quote:

---

Update: I have it displaying sprites almost correctly.

I fixed a bug which was causing massive graphics corruption (because the emulator byte-swaps the whole of VRAM, every 2 pixels were flipped, so instead of 1,2,3,4 I was getting 3,4,1,2), now that patterns are all being drawn perfectly. It's just that multi-cell sprites which are made of more than one tile are borked.

So that means 8x8 sprites are displayed perfectly, but anything else isn't. It can draw a wide sprite if the sprite isn't flipped (and I think I know how to fix that one), but trying to draw sprites more than 1 cell high results in a garbled mess. Obviously there's a bit of a gap between my understanding of the VDP and the way it actually works. The documentation I have is a little sparse when it comes to the way things are actually rendered, and the Genesis Plus software renderer isn't a lot of help.

I tried using the PVR's texture flip bits to emulate the tile flipping, but I couldn't get that to work, so it's just futzing around with the texture coordinates at the moment. Somewhat inelegant, but it works.

Aside from that, I need to start using the punch-through display list so we can start getting some transparency, and it's rendering the sprites in the wrong order (thinking of OpenGL, I thought that higher Z coordinates meant further away, when they're the opposite way around on the Dreamcast. D'oh!)

Edit: Just dropped the screen resolution back to 320x240 (was using 640x480 for some debug info which I no longer need), and the graphic corruption is still there. Now it's swapping every alternate pixel, but the distortion wasn't bad enough to notice on 640x480.

Other than that, sprites now work 99% correctly. Figured out the multi-cell sprite thing (I was drawing width first, should have been drawing height first) and the flipping stuff. Woohoo!

Edit 2: Fixed the GFX corruption. Apparently the DC and Genesis pack their colour values into one byte in the opposite order. Now sprites are almost perfect (for now). I tried to use the Punch-through display list, but it crashed on me. Bugger.

---

There's only one (major) problem with the sprites at the moment. For whatever reason, some of the sprites look completely screwed up. Basically, they look as if they're displaying the wrong graphics. However, even if it's displaying the wrong graphics every single frame and you pause it, it suddenly fixes itself. So that probably means it's an issue with the tile cache code. It's probably because of deferred rendering - I think I'm uploading textures for frame X when the PVR is still rendering frame X-1, so the frame gets bits of the graphics from the next frame...

---

I'm going to let you guys play with this thing as soon as I've fixed one bug related to horizontal scrolling (and me not having a bloody clue how horizontal scrolling works, or what the hell Charles MacDonald was doing in Genesis Plus - both have been causing a lot of problems). Basically, the tile offset into the name table is scrolling the wrong way, but the pixel offset onto the screen is scrolling correctly.

Aside from that, it works, and it's a hair's breadth from being full speed (every few frames it just passes over the 16.6ms boundary and takes two frames instead of one). Compatability is utter crap at the moment, and there are a lot of graphics glitches on every game I've tested on, but it works!

(Thirty minutes later)

Fixed. [...] If anyone wants to try to fix a few of the more glaringly obvious bugs [...] please feel free. The fact that the rendering code ignores virtually every single register used to control the display is a major problem (stuff like the display enable bit, background colour, vertical scroll mode, that kind of thing), it doesn't handle 32-cell display modes properly (draws them as if they were 40-cell), column-based vertical scrolling doesn't work, shadow/hilight doesn't work, theres some weird graphics glitches on the sprites, it's a bit slow, and it draws garbage outside the borders of the display.

---

I'd like to thank all of you that are involved with Genesis / Mega Drive emulation on DC, especially Stef and BlackAura for their outstanding achievments.

Chris

BA corrected me on something: no frameskipping. This is truly fullspeed!

its not fullspeed, he already talked about that. fullspeed would mean that each frame takes 16ms to render, but this takes 18ms to render each frame. (im pretty sure about those numbers). So in effect it is around 90% or something. With C68k though, this will definetly be fullspeed, with room to spare.

:o ...the c68k isn't even implemented? Â*:o


I opened the source code yesterday. You must be correct with that: I saw only the Musashi as CPU core iirc Â*:-X

Unbelievable that isÂ*;D


@Storm: I've read that BA wrote about that 18ms frame render time lag and changed the newspost.


...unbelievable Â*:)



Chris

Basically, the thing renders most frames in less than 16ms, but a few frames (depending on the game) takes a little longer, like 18ms or so, and those frames take 32ms before they actually display. Rough guess, I'd say it's running at around 55FPS or so.

C68k would fix that instantly, as would some optimization. I'd like to get it actually working more-or-less correctly on most games before I start doing that though.

This is absolutely incredible. I tried playing Castlevania: Bloodlines with this emu, and it ran near perfectly. I am amazed at how far everything has come in these last few months.

Is this a problem just I am having, or is this a real issue: When I played the game, the screen seemed to be squished up, and only showed on about the left two-thirds of my TV.

If there'll be a Z80 core with some tweaking towards SHx as it's certainly needed for the final version of NeoCD anyway, this emu will be one of the best Genesis emus available for any system!

SegaCD? Here we come 8)

[quote author=quzar link=board=dcemu;num=1087827740;start=0#3 date=06/22/04 at 09:23:34]its not fullspeed, he already talked about that. fullspeed would mean that each frame takes 16ms to render, but this takes 18ms to render each frame. Â*(im pretty sure about those numbers). So in effect it is around 90% or something. With C68k though, this will definetly be fullspeed, with room to spare.[/quote]

Must a person always choose his words carefully around here? What I love is the long winded explainations to prove someone wrong. :D

this is great! like i've said before, you guys are magicians!