One of the most significant improvements to the Cool Riders emulation over the last day and a bit has been the addition of Priority handling, allowing you to see most of the objects as they were meant to appear.
It turns out the system uses what appears to be a 12 + 2 bit z-buffer (although it could possible be full 16-bit, and the 2 separate bits MIGHT have additional separate meaning) This is a lot more priority depth than most 2D systems have, and is actually closer to what you’d find on a 3D system. Either way, simply implementing it as a 14-bit z-buffer and doing a z-compare for every pixel write at least fixes most priorities, leaving the game mostly playable again.
The other fix made over the last few days involves the transparent pens. Previously there were pixels missing from most objects (not the zoom gaps, I’ll talk about those later) This was caused by us filtering out all 0x0000 value pixels when copying our framebuffer to the screen. This was actually incorrect because 0x0000 means the pen is black, instead pens which should be (fully) transparent have a value of 0x8000. The most significant bit also seems to have other meanings tho, and is set on some objects which should be alpha-blended, as well as the text and various other objects for reasons I don’t yet understand. We actually have a 2nd palette offset with some sprites too, although it’s usually set to the same value. Either way there are still questions to be answered, because if the 0x8000 bit specifies alpha blending, how do you blend a black pen? It could of course be additive blending, in which case a black pen would blend to the same colour as the source, but I’m not sure of this yet. At least now however objects look a bit better.
There are still imperfections, other than the missing transparency effects my zoom precision is still inaccurate, this is what is causing the gaps between sprite tiles in many cases. It’s easy to understand why, each tile is 16-pixels wide, sprites can be made of multiple tiles (and usually are) The zoom value for 1:1 drawing is 0x40 (128) to draw 16 pixels, and so the lower bits of the zoom, if looked at on a per-tile scale have no effect, you’d need to span multiple tiles to see them. The problem is my zoom drawing currently only considers the current tile when drawing it, but the full zoomed width of the sprite when placing it, hence gaps. It shouldn’t be too hard to come up with a better algorithm and elimiate the gaps, but zooming in emulation is rarely perfect because the actual algorithms applied by hardware when deciding which pixels to shrink / expand vary wildly, and only in some cases is it obviously contains in a ROM table (NeoGeo being one such example)
Performance is currently an issue too. For all I’ve said about this being a sprite-scaler it can throw as much at the screen as most 3D systems, make that 2 screens, each running at a medium resolution (same as Daytona etc.) with lots of scaling, z-checking, and (once implemented) blending and you can see it’s expensive. Currently for good performance you’ll need a decent i3/i5, my Core2 doesn’t quite cut it in places. I’m still trying to optimize it, and there is definitely room for improvement in some area. I was hoping that threading the sprite rendering would help some, but it doesn’t, it helps a little, but also becomes very sensitive to any other use of the 2nd core by the host PC (are MAME threads running at a really low priority or something?) so while you get some gains you can get nasty performance spikes if the PC decides to do something else in the background. I’m not out of ideas yet, but I thought it fair to warn people that in the current state it is kinda slow. Just emulating the CPUs, and sound chips alone (even with SH2 recompiler) is actually quite a drag, so I don’t have THAT much room for maneuver.
There are still other missing features too, quite a few registers are ignored, and there are definitely clipping window effects I need to implement. How the tilemaps get enabled / disabled isn’t known either.
*edit* Zoom handling has been improved, gaps (mostly) gone
Here’s the video to go with this update, sorry for the delay, I’ve probably hit some kind of unwritten monthly upload limit because my uploads are terribly slow right now ;-) A few changes have been made since this was recorded, but they’ll have to wait.
Amazing improvement in a few days, great work.
I looks like a pretty advance raster road effect.
I don’t believe in screenshots, I’ll just wait for video :D
Off topic (sorry) – We need “spreading the word” for Wyvern F0, since the Guru site was deleted from MameWorld ( the new one is : http://members.iinet.net.au/~lantra9jp1/gurudumps/ ) and too many people does not know it, also Guru is willing to halve the price for that game ($3000) and The current Wyvern F0 donation total is $585 (last donation 10th Feb 2013).
Thanks for everything You do !
I don’t think people should donate to that. It will turn up for far less (one was sold recently for $1000, why pay $3000?) It’s only ‘half the price’ because the original deal was ludicrous.
The only reason we didn’t get a dump of the one that was sold *for free* is because the guy working at the repair/test shop was on holiday the week it was in, and by the time he got back it was already gone and his junior didn’t see the need to dump the roms (usually part of their standard procedure)
Seriously, there are better causes to donate towards.
I didn’t know that – sorry my bad :(
(my hopes were bound to emulation, not the actual cost of the game)
I can see where you’re coming from, but I just don’t think from a logical view it makes any sense at all. If the board is even worth a fraction of that, Guru still has the board. Admittedly if the MCU needs decapping there is a risk that won’t be the case, but we don’t even know what the protection involves at this stage and if it can be simulated with any confidence. AFAIK the deal offered doesn’t even provide guarantees for the MCU being decapped anyway.
A significant amount of value of the game is from the custom cabinet more than the PCB, it’s a fancy dual output thing, which mirrors one layer hovering above the other, very special. A PCB from a dead cabinet would probably also be very cheap if they were to become separated because it’s practically useless then.
Just wow … This is just another Guru scam. He dumped it already a long time ago. Reminded me of the unfamous decapping list hosted on his site, where you could make donation for the chip you wanted. Page was never updated, so he would gather multiple donations from different clueless suckers.
And don t even get me started with the chack n pop debacle…
Wow… that is a down right impressive amount of “3d” for a game with rotoscoped sprites.
Fantastic work on this. I would really like to see you take a stab at some more of these old drivers that have been stuck in limbo.
In regards to the operational bit (keep in mind I haven’t even looked at the source so I’m just geussing here) sometimes the simplest answer is the correct one.
How do you alpha blend black? Simple, you don’t.
A few dx games I’ve written in the past have had a similar flag system that caused a similar issue. The easiest way for me to keep things simple was to never use true black on a texture that was going to be blended. I would use a slighty off color black (like 001,001,001 instead of 000,000,000) instead.
But seeing as how this game has a pallette that might not be the case. It would be worth looking into though.
I’d say it was additive blending in most cases, so 0x8000 is adding a value of 0x0000, and is thus the same as transparent anyway
at least looking at the ‘to be blended’ sprites we have, most have ‘hard’ darker edges, which is typically a sign of additive blending, because you want less of the colour applied on the edge, so use darker pens.
Nice work Haze :)
This game looks like the result of Outrunners and Super Hang-On getting drunk at a party and sleeping together.
For threading you could use something like proc explorer to figure out what they are, or look at the flags on the createthread. However, keep in mind threading on windows is pretty much by definition non deterministic. Even with locks you still get some jitter on the barrier. You can get close though. For a master/slave relationship it works out really well. For something where you want the timing to be ‘just right’ not so much depending on your slice of time.
There must be some other bit, in some other area telling the blend type then. I was hoping it would be an easier fix for you. :(
Yeah multithreading isn’t all that it’s cracked up to be if you want to do something accurately. It’s good for unloading stuff that isn’t time critical though.
All the input/artwork stuff could be put on a seperate thread, but seeing as how that stuff barely takes any resources anyway, I don’t see how it would help.
I’ve found from personal use (which is admittedly limited) that any priority value other than the default causes issues one way or another. You put it too high and everything in the background locks up, potentially crashing, you put it too low and all of your background processes run all over the main program.
I wonder in win 8 handles this stuff any better? I doubt it, it’s essentially win 7, but I haven’t messed with the OS yet.
@HowardC Yeah in wince it was even worse with respect to priority (the schedule was not as forgiving as the winnt one). I usually use higher priority for message passing sorts of items. Then leave everything else at a lower ‘normal’ level. The trick with higher priority is to understand they need to be short and sweet and get back to the yield state quickly or they will do like you say and starve the lower ones.
Also if you have a crash its probably a race condition that playing with priorities is bringing out.
Now that I think about it you may be able to get a more deterministic state using fibers (nt4 sp2 feature) as you basically control the scheduler. Not perfect but most certainly closer to what you guys are trying to do.
Thanks for sharing this journey it is so interesting to see the process! I am truly amazed with your work.
This made my day! Thanks Haze! We got three away to get to the finish line!
Awesome! The graphics are now viewable! But two things I noticed in the video.
1. Like GTI Club, the FBI/USA logo is “sticking” to the background layer.
2. Some sounds were repeated a lot, when not needed.
Anyway, the missing transition effect is the reason of why the backgrounds timed incorrectly.
The omnipresent FBI logo is an official replacement to the actual Sun, making sure that winners don’t use drugs anywhere.
Although actually it’s already been fixed earlier today (just after the video was made)
It was fixed in GTI Club in the last release too
as for sounds, yeah, they’re broken, it’s complex, and I don’t have a clue when it comes to sound emulation.
Let Kale handle the sounds :P
lol
I personally love the old FBI messages. To this day the only two FBI directors I know by name are Herbert Hoover and William Sessions.
The course layout on this game goes like this if you’re first time playing this game (i read it on the game’s manual):
Starting from Niagara Falls: Goes all the way from the East Coast going through Europe all the way to Asia, Arctic and The Antarctic.
Starting from New York: It’s an All-American route.
Starting from Grand Canyon: Goes from West Coast going through Asia until Europe, Arctic and Antarctic.
Wow! This is excellent,didn’t expect you will do it as fastest as you did.
Really great work Haze.
The FBI logos are also very useful when it comes to emulation.
In many cases the code is added after the game is finished, often meanings it just ends up being a very direct piece of code to do one specific task, and can give early clues into how things work.
In this case the way they upload the palette for it is different to some other things, so tells us a bit more about the hardware + mirroring. It helped rule out some early theories about how the palette worked.