What's new

Ogre Battle 64 - Almost There!

Papacha

New member
Yes! YES! YYYEEESSS!!!!! (by the way, my question is a the end... it's true, I only wrote all that gliberish out of excitement so if you're not in the mood help yourself and skip it ^_^ )

Ogre Battle 64, almost working and way better loking then ever before!

Humm...

You know the kind of excitement you get when a game you've been truly expecting is on the brink of working out on a emulator and you just keep tweaking every known plugins in hope of finding the perfect fit? Well that's how I fell just about now... unfortunately, this time around I must admit that I've been rather thourough in my search for the missing plugins setting. And I must conclude the following:

On Nemu64 0.8, using the default mounted audio&input plugins there is now only 1 truly missing graphic layer; the floor!

Using the new Rice's Deadalus 4.5.0 the characters are visible making the game completly playable and middly enjoyable (if you don't like your army waring in the void that is). Unfortunatly, a lot of glitches come to screw the experience (transparency, glitchy shadow casting and such)... but it's playabale.

With good old Jabo's Direct3D7 1.40, none of those damned glitches are there to spoil the fun, in fact the game looks Perfect! Unfortunatly, there are some more missing graphic layers resulting in no characters at all in battle/town liberation sequences... No difference from before exept from the outburst of speed from Nemu64 0.8 outstanding release.

I tried a lot of other emulator and old video plugins... for naugh!


So here my riddle:

Since Jabo kick some major ***, and since 1.40 is "rather" old, is there a 1.50 out there? Or even better, did someone found a better setting than mine? I did get my hand on a Jabo's Direct3D6 1.50 (twice the size of the 1.40 version, got it at http://www.emulation64.net/plugins/video.php3) but the plugins isn't working right, corropted file or buggy prerelease? I search the web for an alternative download of the file and failed. Since Jabo's site doesn't shows wich version there working on, I was wandering if the 1.50 version existed at all.

Any clues?
 

Doomulation

?????????????????????????
It does indeed exist. But it shouldn't be distrubuted seperatly! That's why you don't find it!
Just go get pj 1.5 from the official site and you'll have that plugin.
 
OP
P

Papacha

New member
I see...

And is Jabo Direct3D 1.5 compatible with other emulator than pj64 v1.5?

I don't know if it's me who's totaly clueless, but it seems to me like Jabo Direct3D 1.5 & 1.4 are roughly the same thing... on pj64 v1.5 I get the same graphical performances using jabo 1.5 than I get on nemu using the 1.4 (minus the speed). I'd be curious to know if there has been ANY changes between the 2 versions.

So I guess that means that the only way out of this is to wait for a new gpu...

Haaa hahaha (sigh) ... well too bad. That was sure to good to be true anyway.

Well thanks for your help anyway!
 

Clements

Active member
Moderator
Papacha [/i][B] And is Jabo Direct3D 1.5 compatible with other emulator than pj64 v1.5? [/B][/QUOTE] Yes said:
I'd be curious to know if there has been ANY changes between the 2 versions.

1.5 is more compatible than 1.4.

There you go :)
 
Last edited:
OP
P

Papacha

New member
Hey! it worked!!!

The pj64's msvcr70.dll file was the missing element. Thanks for the tip Jack!

Well it didn't add any graphical layer whatsoever, but I'm glad it worked at all.

Now what exactly is the purpose of this driver? (msvcr70.dll)

Is it a security mesure to insure that Jabo's Direct3D6 1.5 won't be used by other emulator?

Since pj64 is open source, that sort of doesn't make sence right?

That really isn't crucial info, but does any body know anything about it?

"Thanks again Jack"
 

Trotterwatch

Active member
Got this from the Net;

This DLL is needed by applications compiled to use the Microsoft Foundation Classes (MFC) as a DLL, and compiled on a machine that has the Microsoft .NET SDK installed on it. This is no different than older MFC runtime DLL requirements; it's just that this is a very new runtime DLL and most folks don't have it. The system running this application (mapserver, compiled this way) also must have Microsoft Internet Explorer 4.0 or higher installed on it, since the runtime uses components from IE as well.

You tried out Rice's new Daedalus plugin with Orge Battle yet? Just wondering if it makes any improvements on it, if it does then I shall have to obtain a copy of the game. I've steered clear for the moment due to the fact that it has not been emulated perfectly (and I'm on a 56k).
 
OP
P

Papacha

New member
Like I said, with Rice's Deadalus 4.50 you get a bunch of "very minor glitches" throughout the game but the game now sports new layers (the bunch of heroes standing in the title screen looking at the horizon for exemple... not unlike Fina Fantasy 1 Opening Sequence). Well they're crappy I'll give you that but those new layers now allow you to see perfect characters (full colors & details) in battle/cities liberation sequences... minus the floor. The world map & edit windows is neer perfect (Jabo's better tho) so now hardcore fans can appreciate the game but purist like myself wil get anoyed by the fact that all battle sequences take place in the utter void...

As for you info on the dll, I take it pj64 needed to add it in it's main directory to lighten the weight of it's gpu (who could otherwise be included within the file, right?), but why deadalus & all the others (much larger) gpu don't take advantage of these new libraries? Either by having the new dll or extracting the needed components?

I know this question sounds irrelevant but I'm just wondering that if & when a perfect gpu will be made available, it should sports all the possible mapings used by the n64. And that new dll clearly is a step foward in this respect (or is it?). It went out nearly a year ago (since it's included in pj64 v1.5) and the new gpus don't seem to worry much about it. So those new libraries are either poor or not well known. The later case would be insteresting.

Ahhhh, good old undocumented speculations! My favorites!

:D
 
OP
P

Papacha

New member
I tried the new Rice 4.6.0 and I have to say I got a lot more bugs & missing graphics layers (or should I say microcode or maping libraries? I don't know yet).

So if any one can tell me; is the new Rice is optimised for some specific games (other than Ogre Battle 64) or is it me who's been using it the wrong way (I tried just about every options... but I often fail to even graps the real purposes so...)?

Also, i can't managed to get the glide64 v4.0 to run (I have a GeForce 2 agp7700 TI and I'm using the wrapper provided by glige64 web site eVoodoo v3.25) with no result (get a error when tring to get full screen). I don't fansy that much since the INI says that Ogre64 is playable with some missing backgrounds.

So even though yesterday was a busy day for gpu releases, seems like it's still insuficient.

If I'm wrong, or if you have any suggestions, I'm all hears!
 

Rice

Emulator Developer
You are right that 4.6.0 introduced more bugs to this perticular game. A good news is that I have found something regarding the missing background problem, it is a combined problem of a new ucode, YUV texture converting and frame buffer emulating. The new ucode is working now, but YUV texture converting is only partially working, and frame buffer is not emulated.

Frame buffer is the biggest problem left in my plugin, not only for this game, but also for many others, I am still working on it.
 
OP
P

Papacha

New member
Please forgive my severe lack of knowledge in the matter, but from what I gatter of your mail and my limited knowledge, the process you described is that ucode are sent, converted into texture then stored into several buffers...?

Then if a gpu fails to draw something it has to be deliberate... otherwise you'd have garbage a plenty. So are you missing a specific way to convert unknown data or is it simply that to convert the ucode is similar to trying to catch as many fish in a net? ... man what an analogy... hum. I'm trying to figure out if the data is easy to get but complety alien or is this shearly blind coding. And in any case, what do you do with all the remaining ucode? Or is the concept of frame buffer really that different then normal buffer... gee looking at all those questions, I must urge you not to reply if you feel like I'm a desperatly clueless sod! Haha! that'll remain true anyway!
 

Rice

Emulator Developer
I would rather not to reply as my reply could be totally nonsense to you. So you can just wait.
 

Top