What's new

OB64 emulation

gamerk2

Banned
me and my friends have been sick of the black screens that are in some games (ogre battle 64, jet force gemini, ect) and are going to attempt (I said ATTEMPT) a plugin which MAY resolve these issues (not likely).
I don't think it is a u-code error. Sometimes with PJ64, i pause the game (F2) and the screen is fully visible!! (but quickly dissappears). If it were a u-code error, it wouldn't show at all, right.
Any advice/guidence/or existing plugin (HAHAHA) would be very much appriciated.
Who knows what may happen...
 

blight

New member
which plugins did you try? jabos d3d? glN64? tr64gl? rice's d3d/gl? strmnnrmns d3d? glide64? i can't believe none of these plugins play the games you talked about...
source code is available for tr64gl, glN64, rice's and strmnnrmn's plugin afaik...
and most likely it IS an ucode problem because if it was a generic plugin problem you'd get that black screen with more than just one or two games...

my 2 cents..... :nuke:
 
There have always been small problems with these games, but I'm sure they are playable without too much problems (I don't have these games, but there are more threads about this subject. Use the search-option).
 
OP
G

gamerk2

Banned
I've been using Jabo, of course.
OB64 is playable, but i'm tired of this backround junk.
Jet Force Gemini works Most of the time, but in some parts of the game (second and third bosses) the screen is blank and u have to use wireframe mode to see anything (not fun).
 
OP
G

gamerk2

Banned
Well, progress made. Right now, main focus on my new plugin is speed. Hopfully, most games will run at a constant 60 fps (or close to) and not slow down (army men 1). Still trying to figure out Ogre Battle. I checked the forums, and some people CLAIM to have the backgrounds ok. I would appricate a picture of the first sceen (the one with the 6 questions) that has the background working and/or system specs.

If the backgrounds work for some people, then it is NOT a ucode issue. Hopfully, a public release can be done in the near future
but know unless ob64 works, i will probally stop working on the plugin.

Any further ideas will be appriciated.
 

Tagrineth

Dragony thingy
OB64 probably just uses some weird-as-hell, obscure video modes - it sure as hell isn't fitting those backgrounds into the microscopic texture cache.

It's also using some extremely careful sorting - it's by far the most anti-aliased game I've seen on the N64.
 

Gonetz

Plugin Developer (GlideN64)
I also tried to fix background problem in OB64. I have logged frames from 2 scenes - one with correct background and one with missing background. This game uses quad commands to draw backgrounds, not texrect as in most games. And parts of logs related to background are identical for both frames - the same sequence of commands, the same coordinates of vertices - the only difference is texture addresses. But in one case address points to correct texture image, and in second case it points to a empty place with some garbage.
My conclusion: this is a bug in emulators core, not in video plugins.
 

Rice

Emulator Developer
Gonetz said:
I also tried to fix background problem in OB64. I have logged frames from 2 scenes - one with correct background and one with missing background. This game uses quad commands to draw backgrounds, not texrect as in most games. And parts of logs related to background are identical for both frames - the same sequence of commands, the same coordinates of vertices - the only difference is texture addresses. But in one case address points to correct texture image, and in second case it points to a empty place with some garbage.
My conclusion: this is a bug in emulators core, not in video plugins.


Gonetz

Background is drawn by using a special textrect/sprite2d command to framebuffer and copied from frame buffer to video buffer. You need to implement frame buffer and the special textrect/sprite2d command to fix the background problem. This should be a video plugin problem, not a core problem.

The special textrect ucode is 0xda (the same as GBI2 matrix).
 
Last edited:

Gonetz

Plugin Developer (GlideN64)
Rice, thank you very much! When I worked on OB64, I did not knew what this sprite2d command is, so I ignored it. I implemented it after you told me about problems in "Space Station Silicon Valley". Now I have everything to fix this problem! :D
 

Gonetz

Plugin Developer (GlideN64)
Ops, it's not so easy...
First, OB64 uses F3DEX_GBI_2 microcode. This microcode can't use sprite2d command, it's for older F3DEX microcode. May be OB64 uses modified version of F3DEX_GBI_2? And is that special textrect/sprite2d command the same as sprite2d for F3DEX?

Then, as I understand, the sequence of commands must be as follow:

setcolorimage - [frame buffer address]
...
special textrect/sprite2d command - draw texture image into frame buffer (RDRAM) to address set by setcolorimage
...
settextureimage addr = frame buffer address
...
vertex
quad
quad
quad
...

But I not found setcolorimage command with the same address as in settextureimage. Where is my mistake?

And yet another question: how to distinguish GBI2 Mtx command from that special sprite2d command? All logged Mtx commands look quite correct.
 

Top